Website maintenance requests are where agencies and freelancers most often lose control of their time after launch. The project has an end date, but the requests do not: "the contact form isn't sending", "swap this photo", "why does Google still show the old title?". Each one arrives through a different channel and each one sounds urgent. Without rules, the loudest client wins.
This guide organises the work around four decisions: where the client reports an issue, what you call it, how quickly you respond and what your maintenance plan covers. No contract template, just criteria, message templates and an order of steps a small team can adopt within a week.
Website maintenance starts with one intake channel
A request sent to a designer's personal phone does not exist for the rest of the team. Nobody else sees it, covers it during a holiday or checks later what was agreed. So the first decision is a single place to receive requests. Other channels can stay, but everything lands in one record.
Kreska, a fictional studio, maintains a dozen or so websites for service businesses. Clients used to write to whoever had built their site. The studio introduced one rule: a request without a case number has not been accepted yet. Anyone who receives a request outside the channel creates a case and sends the client its number.
- Pick the main channel.A form, a chat or a shared address. What matters is that every case gets a number and a history the whole team can see.
- Collect the minimum.The site address, what the request is about, what the client sees and since when. A screenshot or page link saves a round of questions.
- Log requests from other channels.Phone calls and messaging apps do not disappear. Whoever took the request creates a case and sends its number back to the client.
- Assign a daily triage owner.One person reviews new cases each day and sets their type. Otherwise the channel becomes another ownerless inbox.
Incident, change or question: three types to start with
The type of a request decides how fast you respond and whether the work falls under maintenance. Three categories are enough to begin. An incident means something that used to work has stopped working. A change is a request for different design, content or behaviour. A question needs an answer or instructions rather than work on the site.
Scroll the table sideways to see all columns.
| Type | Example | First step |
|---|---|---|
| Incident | The contact form has stopped sending messages | Confirm the symptom and check whether the whole site is affected |
| Change | A new pricing page or a different header image | Compare it with the maintenance scope and assess the work |
| Question | How to publish a blog post in the site admin | Reply with instructions or a link to a recording |
The line between an incident and a change gets contested when a client reports that something "doesn't work" about a feature they never ordered. The criteria for that call are covered in bug or feature request. Here one rule is enough: the triage owner sets the type, and the client can challenge it with a reason.
The Jira Service Management documentation describes five IT service management work categories, including service requests (which cover requests for information), incidents, meaning unplanned disruptions to a service, and changes to IT infrastructure. It says nothing about website maintenance or agency billing; the three types above are our own simplification: Atlassian: work categories.
A separate response time for each type
One promise for every request backfires both ways. Answer questions as fast as incidents and no time is left for work; let an incident wait as long as a question and the client loses trust. Set a separate first-response time for each type, counted in business hours, and define what counts as a response: a human reply that addresses the case, not an automatic acknowledgement.
Kreska chose, as an example, a same-business-day response for incidents and two business days for changes and questions. This illustrates the rule; it is not a recommendation. A response is not a fix. For an incident, the first message says what you are checking and when you will write again; for a change, when the client will receive a scope assessment.
"Thank you, your request is case [number] and we have marked it as an incident. We are checking the form on [site address]. We will send the next update today by [time], even if we have not found the cause yet."
How to count business hours, pause the clock and avoid promising more than your team can deliver is explained in the guide to customer support SLAs. When one outage affects several clients at once, follow the rules for incident communication instead of answering everyone differently.
What maintenance covers and what counts as new work
An argument over "it's only a small thing" is rarely about the work itself. Usually nobody wrote down what the plan includes. A short scope description, sent at the start and quoted in replies, settles most of these conversations. It is a working list, not a contract. The easiest place for it is the website handover checklist, together with the name of the request channel.
- Fixing incidents in what was delivered and worked at sign-off.
- Updates to the CMS, theme and plugins, with a backup before each change.
- Small content edits within a monthly limit of time or requests.
- Answers to questions about using the site admin.
- New pages, features and integrations quoted separately.
- How the client is told when the monthly limit is running out.
An out-of-scope request is not a problem if you call it new work straight away and do not start it before the client decides. How to describe the difference, the impact and the options is covered in when a client changes the project scope.
The WordPress documentation advises updating to the latest version and backing up before an update; most installations apply minor and security updates automatically, while major releases must be started manually. The source does not say what an agency plan should include: WordPress: updating.
Every request linked to a task
Incidents and accepted changes need work, so they get a task linked to the client's case. The person doing the work sees where the request came from, and the person handling the client sees progress without chasing. When a ticket actually needs a task, and how to split responsibility, is covered in from support ticket to task. Questions usually just need a reply, not a card.
In Meetlead, chat, the offline form and callback requests can create a ticket with a number, type, priority, status and assignee; in the panel, the types in this guide map to Bug, Feature request and Question. An operator can also open a case manually after a phone call. In the Projects app you link a task to a ticket or a session recording and move it across the board. A formal SLA policy with first-response and resolution targets and business hours is set in Analytics; treat separate targets per type as a team rule and check them by hand. Projects requires an account, an active app and plan access.
How to tell the client about status and boundaries
The client does not need your board, only the request type, what is happening and when you will be back in touch. The hardest message is the one where a request turns out to be new work. Write it plainly, with no apology and no date before the assessment.
"A new pricing page goes beyond maintenance, which covers edits to existing content. We will send you an assessment by [day]. We will not start work until you decide, and all other maintenance requests continue as usual."
Once a month, send the client a short summary: closed cases by type, open changes awaiting a decision and how much of the limit was used. It shows the value of maintenance better than an invoice. A structure for updates with decisions and risks is in the guide to client project status updates.
Questions about post-launch requests
What if a client keeps messaging a personal number? Do not ignore it, but move each message into the main channel and reply with the case number. Most clients adapt after a few such replies. If the issue is urgent, call back, then record what was agreed in the case.
Can a question turn into a change? Yes. "How do I add a gallery?" may be a question about the admin, or a request for a feature the site does not have. In that case change the type, tell the client it is new work and assess it like any other change. Leave a note in the history explaining why the type changed.
