Support is unscheduled work. That makes it a staffing problem before it is a pricing one. Here is how to scope it, set an honest SLA, and price it on ticket volume.
This distinction sounds academic until you price it. Maintenance is a known quantity: a set of tasks, a known frequency, a predictable number of hours. You can multiply it out and know your cost within a few percent. Support has none of those properties. It is demand you do not control, arriving at times you did not choose, at a volume that varies with how well the maintenance was done.
That is why flat-fee WordPress support plans fail more often than care plans do. The agency prices for the average month, then meets a month with a compromised site, a failed migration and a client launching a campaign. Average-case pricing against worst-case demand is the whole problem.
If you have not scoped the scheduled side yet, the WordPress care plans guide covers tiering and pricing for the preventive work. This page assumes that exists and deals with what arrives anyway.
Almost every dispute about a WordPress support plan is a disagreement about whether something counted as support. The fix is a short, blunt list on both sides of the line.
“Something that worked yesterday and does not work today” is the cleanest definition of support anyone has written. It covers regressions without covering wishes. A client asking why the site is down is support; a client asking for a booking system is a project. State the test in the contract and you will rarely need to argue the specific case.
A single “24-hour response” promise is either too slow for an outage or too fast for a content tweak. Tier by what has actually happened.
| Situation | Standard | Priority | Critical |
|---|---|---|---|
| Site offline | 4 business hours | 1 business hour | 1 hour, incl. weekends |
| Checkout or forms broken | 1 business day | 4 business hours | 1 hour |
| Something looks wrong | 3 business days | 1 business day | 4 business hours |
| Content change request | 5 business days | 2 business days | 1 business day |
| Question / how do I… | 5 business days | 2 business days | 1 business day |
| Channel | Email + portal | Email + portal + phone | |
| Hours covered | Mon–Fri 9–5 | Mon–Fri 8–6 | Mon–Sun, on-call rota |
The temptation is to set response times against how quickly you usually reply. But an SLA is only tested when you are already busy — during an outage, on the week two clients need you at once, in the middle of a launch. A slower commitment you always meet builds more trust than a fast one you miss occasionally.
“Same-day support” on a Saturday means someone is working Saturday. If you are a two-person studio, weekend cover is a rota you have to actually staff, and selling it before you have arranged it is how burnout starts. Sell business-hours support honestly, and charge properly for out-of-hours as a separate tier.
A one-hour response commitment is worthless if the first forty minutes go on finding credentials. Whatever you promise, the access, the backups and the ability to reverse a change need to be in place before the ticket arrives, not assembled during it.
Care plan pricing multiplies scheduled hours by a rate. Support pricing cannot, because the hours are not scheduled. What you can do is measure the queue:
The inputs below are the ones worth tracking for a month before you publish a price list. Ticket volume in particular is almost always underestimated, and it is the term everything else multiplies.
| Input | Why it moves the number |
|---|---|
| Tickets per site per month | Track it. Most agencies guess 1 and discover it is nearer 3 on older sites. |
| Average handling time | Includes reading, clarifying, doing, testing and replying — not just the fix. |
| Context-switch cost | An interrupt costs more than the same task scheduled. Bill the interruption, not the minutes. |
| Coverage window | Evenings and weekends are a rota, not a feature. Only sell what someone will genuinely answer. |
| Escalation rate | The share of tickets that become real work. This is the number that blows up flat-fee plans. |
| Included-change allowance | A stated cap in minutes. Uncapped support is how a profitable plan becomes a salary. |
Clients want one number and one invoice, which is why WordPress support and maintenance packages sell better than either half alone. Internally, keep the two lines separate: the maintenance line is predictable and can be automated toward near-zero marginal cost, while the support line is capacity you must staff. Blending them hides which half is losing money.
Use the care plan pricing calculator for the scheduled half, then add your support loading on top.
Most WordPress support tickets are not unique. They cluster around a handful of causes, and each cause has a fix that removes it permanently rather than per-incident.
The single largest ticket category. When a bad change is one click from reversed, the ticket becomes a two-minute reply instead of a restore, a phone call and an apology.
One-click undoSmall repeat edits across many sites. Handled as a scheduled routine or a single instruction rather than a context switch per request.
Not a support ticket, but it lands in the same inbox and costs the same context switch. A monthly report answers it before it is asked.
White-label reportsNone of this removes the need for a human on the difficult tickets, and it should not. What it changes is the ratio: when the routine work runs itself and mistakes are reversible, the queue that reaches you is smaller and more genuinely worth your rate. The WordPress maintenance guide covers the scheduled side, and the agency overview covers running it across a portfolio.
A WordPress support plan is a recurring agreement covering unscheduled help: fixing things that break, answering questions and making small changes, within an agreed response time. It differs from a care plan, which covers scheduled work like updates, backups and monitoring. Most agencies sell them together as WordPress maintenance and support.
Maintenance is planned and happens whether or not anything is wrong — updates, backups, security scans, monitoring. Support is reactive: it starts when someone reports a problem or asks for a change. They are priced differently because maintenance is a predictable number of hours and support is a queue with variable demand.
Reduce the volume of tickets that need a human before you extend the hours. Most support queues are dominated by repeat causes — failed updates, plugin conflicts, broken links, users who need the same change made again. Automating the recurring maintenance that causes them, and being able to reverse a bad change in one click rather than restoring a backup, removes a large share of the queue.
No, and say so in the contract. Rollover turns a capacity agreement into a bank of hours, and clients then arrive in month six expecting five hours of work at once — which is exactly the spike your staffing cannot absorb. You are selling availability, not a block of time.
Whatever you can honour on your worst week, not your average one. A missed same-day promise damages the relationship more than a slower promise reliably kept. Define response as a human replying rather than the issue being resolved, and put that distinction in writing.
Selling them together is simpler to buy and easier to price, which is why WordPress support and maintenance packages are the common format. Keep them as separate line items inside the plan, though — it makes the value visible and lets you adjust one without renegotiating the other.
Automate the recurring work that generates support requests — and reverse any change in one click when something does go wrong.
Start free