A WordPress maintenance plan is insurance sold as chores
The deliverable most maintenance plans put in front of a client is a monthly report saying twelve plugins were updated, backups ran, and no issues were found. It is honest, it is accurate, and it is the worst possible thing to send.
Read it as the client does. Twelve buttons were pressed. Nothing happened. The bill is the same as last month. In the months where you are doing the job perfectly, the report is a receipt for nothing, and the cancellation conversation arrives after a long run of quiet ones.
The product is not the updates. The updates are the cost of goods. The product is that when something breaks, and it will, the site is back quickly and the client did not find out from a customer.
What is actually being bought
| What the client thinks they buy | What they are buying | What proves it |
|---|---|---|
| Plugin and core updates | Updates that can be undone in minutes | A restore performed on a copy, with a date |
| Backups | Restores | The last time one was actually run |
| Security | A short window between a disclosure and your patch | PHP and core version currency, written down |
| Monitoring | Finding out before they do | The last three incidents and who noticed first |
| Support | A known person answering within a stated time | The stated time |
The right-hand column is the one to put in the contract and in the monthly note, because every entry in it is a fact that survives a quiet month. "Restore tested on 14 March, thirty-one minutes from decision to working site" is worth reading. "12 plugins updated" is not.
The backup line, which is where most plans are fiction
Almost every plan promises backups. Very few can say when a restore was last performed, and a backup that has never been restored is a file, not a safeguard.
The failure modes are boring and they are all silent. The backup contains the database and not the uploads directory, so the site returns with no images. It contains everything but the archive is truncated because the disk filled during the copy. It lives on the same server that will be the thing that dies. It runs from a plugin that stopped a year ago because a scheduled task stopped firing, and the plugin's dashboard still shows a reassuring green tick because it reports on the last run rather than on the last few days.
Test one restore per client per year, into a throwaway environment, and time it. The time is the number that goes in the report and the number that justifies the fee. It is also, in my experience, the number that surprises everybody the first time, because it is never as fast as anyone assumed and it is always slower on the site with the most content, which is the client who would least tolerate the wait.
The inventory nobody keeps
You cannot maintain what you have not written down, and at twenty sites nobody holds it in their head. This is the single highest-value document in an agency and it usually does not exist.
Per site, one row: the host and how to reach support, where DNS is hosted, where the domain is registered and when it expires, PHP version, what issues the certificate and how, how scheduled tasks actually run, where backups land and who can read them, and one string that must be present on the page for the site to be considered working.
That last field is worth more than the rest combined. It is what turns "the site is up" into "the site is doing its job", and it is the only entry that requires thinking about what the client actually sells. The reason it matters is that a WordPress site fails at 200 far more often than it fails loudly: an empty product grid after a feed error, a page that lost its stylesheet, a fatal printed into the body by a host that returns success anyway. All of it invisible to any check that reads the first line and stops, which is what a 200 does not prove.
Two things to stop doing
Stop pricing by plugin count. It anchors the whole relationship on the chores framing, it invites the client to argue about a site with fewer plugins, and it prices the one thing whose cost you can automate to nearly zero. Price by what you are on the hook for: how quickly you answer, how quickly you restore, how much of the stack you are responsible for.
Stop applying every update on the day it lands. A same-day update policy sounds diligent and it means your clients are the ones who find the regression. Security releases go immediately, everything else waits a short, stated interval, and anything with a database migration goes on a copy first. Write the interval into the plan so that the delay is a policy rather than a lapse.
The conversation that renews the contract
Once a year, send three things: the incidents that happened and how long each took to resolve, the incidents that did not happen because something was caught early, and the restore test with its timing.
The middle item is the one clients have never been shown. A certificate that was renewed after the automation broke, quietly, two weeks before it would have expired. A disk that reached its quota on a Sunday and was cleared before the uploads started failing. A plugin update rolled back within the hour. None of those became an outage, so none of them exists in the client's memory, and every one of them is exactly what they are paying for.
That is also the argument for having the monitoring be something you can point at rather than a claim. Ours is open source and reads the body of the page rather than only the status line, which is what makes the "did not happen" list possible to write honestly: what it checks, and how.
None of this requires a bigger plan or a different tool. It requires that the artefact you hand over each month be a statement about risk rather than a list of buttons pressed, because the list of buttons is the only version of this job whose value falls to zero exactly when you are doing it well.
One caution about the number most of these plans lead with. Clients hear "99.9 percent uptime" as a promise of never, and it is a promise of roughly forty-three minutes a month. Saying so before you sign is a much cheaper conversation than saying so afterwards, and the arithmetic is worth doing once.
