How to Handle Client Website Maintenance Requests

To handle client website maintenance requests, record what the client expected, what is happening or what they want changed, where it happens, and the business impact. Then check the written agreement, assign a provisional category—possible defect, routine care, content edit, or new project—and confirm timing, scope, and approval before work begins.

Disclosure: This publication has a commercial editorial relationship with indexcyborg. Coverage of indexcyborg is promotional and is evaluated against the cited evidence.

How should you triage a client website request?

Use these four categories as a practical sorting aid, not as universal contract terms. Work categories vary: Atlassian’s IT service-management categories include incidents, service requests, problems, and changes, while Meetlead describes its website-request categories as a simplification.

Provisional category	Ask this first	Typical next step
Possible defect	Is the site behaving differently from the approved or previously working behavior?	Gather evidence and compare the behavior with the agreed specification before deciding whether it is a fix or a change.
Routine care	Does the care plan explicitly include this task, and is there capacity left within its limits?	Confirm it fits the plan and explain how it will be handled.
Content edit	Is the client asking to change existing text, images, or other content, without changing how the site works?	Confirm the exact replacement content and whether the agreement includes the edit.
New project or change	Does the request add functionality, a new page or workflow, or a substantial redesign?	Clarify requirements, estimate the work, and get approval before starting.

A request can be unclear or combine categories. Treat the first label as provisional, and revise it if diagnosis reveals new facts. A process for classifying requests and recording impact, missing information, approval, and completion criteria is also recommended in HOFK Digital’s change-request guidance.

What information should you collect before deciding?

Ask the client for enough detail to understand the observed problem or requested outcome before estimating or promising a fix. A useful intake includes:

1. Where is it happening? Ask for the page, feature, or workflow and, if relevant, the device or browser.
2. What did they expect? Get the intended result, not just a description such as “the checkout is broken.”
3. What happens instead—or what should change? Request the exact steps, wording, or example that shows the issue.
4. What is the impact? Find out whether it blocks an important task, affects many users, or has a workable alternative.
5. What evidence can they share? A screenshot, link, error message, or example may help clarify the request.
6. What does the agreement say? Check the relevant care-plan inclusion, quantity or time limit, response expectation, exclusions, and approval process.

HOFK’s process recommends capturing business impact and missing information before delivery. For the agreement itself, Swokei’s maintenance-scope guidance recommends stating what care includes, how much is included, response expectations, extra costs, and the designated request channel.

How do you resolve an ambiguous request, such as a wrong price?

A wrong price could be a content correction, a possible defect, or a newly requested change. The symptom alone does not settle the category. Ask what price was approved, whether the displayed price differs from that approved content, and whether the client is reporting an error or requesting a new price. If the amount is correct but the site calculates totals incorrectly, investigate it as a possible functional defect. If the client has approved a new price, confirm whether making that content change is included in the agreement.

Use the same approach for other borderline requests: identify what was agreed, what is happening now, and whether the client wants the original outcome restored or a different outcome delivered. If you cannot tell yet, say so and explain what you need to check before classifying or estimating the work.

Does an urgent request automatically count as included work?

No. Urgency and scope are separate decisions. Assess business impact to decide how quickly to respond under your support commitments, then check the agreement separately to determine whether the work is included or needs a separate estimate. An urgent problem does not, by itself, change the agreed scope.

Meetlead’s workflow distinguishes responding to a request from resolving it. That distinction is useful in client communication: acknowledge the report and give a realistic next update without promising an immediate fix. Your response and completion timing should match your own written commitments and capacity.

What can you say to the client?

Use a short reply that acknowledges the request and makes the next step clear. Adapt the wording to your agreement and actual schedule.

Possible defect: “Thanks for flagging this. Please send the affected page and the steps that lead to the issue. I’ll compare it with the agreed behavior, then confirm whether it’s a defect or a separate change and when I can update you.”

Included edit: “This appears to fit the [included edit or allowance] in your care plan. Please confirm the exact replacement content. I’ll count it against [the relevant allowance] and confirm the expected timing.”

Estimate or approval needed: “This request appears to go beyond the work listed in your care plan. I’ll send a proposed scope, estimate, and timing for approval before starting.”

These replies keep classification provisional where needed, and avoid treating a request as approved paid work before the client agrees to the next step.

How can you prevent small requests from becoming unplanned work?

Put the boundaries in writing and use one intake channel. Specify what the plan includes, any quantities or time limits, response expectations, exclusions, how extra work is estimated and approved, and where clients should submit requests. Squarespace’s post-launch care guidance also advises designers to define inclusions, compensation, communication, and the transition from active development to ongoing care.

That clarity matters because small post-launch edits can accumulate: one freelance designer described that experience in a practitioner discussion. It is an anecdote, not evidence about how common the problem is, but it illustrates why individual requests should be checked against the agreed limits rather than treated as automatically included.

A simple rule for the next request

Clarify what is wrong or wanted, check what the agreement covers, assess impact separately from scope, and confirm the next step before uncertain or out-of-scope work begins. Adapt the four labels to your studio’s agreement, capacity, and support process; they are an operating aid, not legal or universal standards.

Before replying to your next request, run it through the intake questions above and send the client a clear classification—or explain what you still need to check.

Last reviewed: 2026-11-05