"What did you actually do for us this month?" is a fair question, and it usually arrives at the worst moment: when an invoice is due, a site has had a bad week, or a new marketing manager is auditing suppliers. If your answer is "trust me, plenty", you have lost the argument before you started.
An activity log turns that answer into a list with dates. It is the cheapest piece of client retention an agency can build, and most agencies build it too late.
Why "trust me" fails
Care plans are invisible when they work. A site that stays up, updates cleanly and never gets hacked generates no events the client can see. From their side, they are paying a monthly fee and nothing happened. The better your work, the harder it is to justify.
This is the paradox of maintenance: the value is the disaster that did not occur. You cannot show a client the hack that did not happen. You can show them every update, backup and check that was done to prevent it, if you recorded them. The number will be whatever your log says, which is exactly the point.
What belongs in an activity log
A log is only useful if it is specific enough to be believed and short enough to be read. For a WordPress care plan, the entries that matter are:
- Updates applied: which plugin, theme or core version, from what to what, and when.
- Backups taken, and whether they succeeded.
- Security events: vulnerabilities found, what was done about them.
- Downtime incidents: when they started, how long they lasted, what caused them.
- Manual work: the content edit, the redirect, the form fix, with who did it.
The last item is the one agencies most often skip. Automated events are easy to capture; the ten-minute tweak done from a phone is not. If it never gets logged, it never gets credited.
Specificity is what earns trust. "Updated plugins" is a shrug. A line like "Updated WooCommerce from 9.1 to 9.2 on the 14th after a restore point was taken; no visual changes detected" is a fact a client can repeat to their boss.
Log for the client, log for yourself
There are two audiences, and they want different things.
The client wants a monthly summary: a page of plain-language statements about what was done and what it protected. They do not want raw entries and they do not want jargon.
You want the detailed record, for three reasons. First, incident forensics: when something breaks on the 22nd, you need to know what changed on the 21st. Second, accountability inside your team: who touched the site and when. Third, dispute resolution. If a client claims an update broke their checkout, a timestamped history is how you find out whether it was your update or their marketing plugin.
Build one record and derive both views from it. Two separate systems mean one of them will be out of date.
Turning the log into a monthly report
A useful report has a fixed shape, so the client learns where to look:
- A one-line headline: the site is healthy, or here is what needs attention.
- What was done: updates, backups, security, incidents, manual requests, grouped and counted.
- What was prevented or found: vulnerabilities addressed, downtime avoided or resolved.
- What is coming: the next update window, an expiring certificate, a plugin that needs replacing.
Keep it to one page. If a client wants the detail, it is in the log, and offering that is a stronger signal than dumping it on them.
Branded PDFs matter more than they sound. A report with your logo and your voice reads as your service. A screenshot of a third party's dashboard reads as a resold tool. Whichever tool you use, check that the report can carry your branding and that a client can open it without a login.
The uncomfortable entries
Log the failures too. An outage that lasted twenty minutes because a host restarted a server, resolved and explained, builds more trust than a report that shows a suspiciously perfect month. Clients know that things break; what they judge is whether you noticed, how fast, and whether you told them first.
There is also a discipline point. If the log only ever records good news, you will stop trusting it yourself, and the team will treat it as marketing.
Using the log to price and to say no
A log also answers questions that are nothing to do with reassurance. If a client's site consumes triple the manual hours of your average plan, the log shows it, and that is your evidence for a plan change. If a client asks for something the plan does not cover, the log lets you say "here is what is included, and here is what you are asking for on top". Because you have shown the work already, the conversation is about scope rather than whether you do anything at all.
For a starting point on what a care plan should include, the maintenance checklist clients pay for is a reasonable structure to log against.
Practical setup
You do not need a heavy process. Pick where events are captured, make it automatic wherever you can, and set a habit for the manual entries: a single line at the moment you finish the job, not a reconstruction at month end. Reconstruction is where accuracy dies, and it is the reason most hand-written reports feel padded.
Review the log for one site each week for a month. You will quickly see which categories are noisy, which are missing, and which entries a client would actually care about.
In WPClientHub, an activity log records what happens on each site, and branded PDF reports pull that work into something you can send. It is one piece of a larger setup, not the whole point.
Where this leaves you
The question "what did you do this month?" should never need a scramble. Record events as they happen, keep failures in the record, and send a one-page summary before the client has to ask. WPClientHub is free for 3 sites if you want to try this on a real client site: register here.