If you manage projects at an MSP, Friday afternoon probably looks the same every week. A list of client updates to write, a risk log that needs updating, action items to chase, and a status report due by end of play. Most service delivery managers spend between 3 and 5 hours on this every single week. That is roughly 200 hours a year — five full working weeks — spent reformatting the same information into different documents.
The real cost of manual reporting
The problem is not just the time. It is the context switching. Moving from delivery work into writing mode, finding last week's notes, remembering what happened with each client — all of this carries a cognitive cost that the clock does not capture.
For a team of three PMs each spending 90 minutes on reporting twice a week, that is 9 hours of billable time absorbed by administration. At £75 per hour that is £675 per week leaving value on the table.
The other cost is inconsistency. When reporting is manual, the quality varies with how much time you have. A rushed Friday client email is not the same as a carefully written one. Clients notice even if they do not say anything.
What a good weekly client update actually contains
Most MSP client updates contain the same five elements regardless of what happened that week. Getting clear on the structure makes them faster to write and easier for clients to read.
- 1. Current status — One sentence on where the project stands. On track, at risk, or blocked. Clients want this first, not buried in paragraph three.
- 2. Progress this week — What actually happened. Specific, not vague. "Phase 1 migration complete" is useful. "Good progress made" is not.
- 3. Actions and owners — Who is doing what and by when. This is the part clients refer back to. If it is not specific it is not useful.
- 4. Risks and blockers — Anything that could delay the project or needs client input. Surfacing risks early builds trust. Hiding them and hoping they resolve does not.
- 5. Next steps — What happens before the next update. Gives the client something to hold you to and shows the project is moving.
How to structure an action log that people actually use
Most action logs fail for the same reason: they live in a spreadsheet that only the PM looks at. The format matters less than the discipline of updating it and sharing it. A simple four-column table — task, owner, priority, status — is enough for most MSP projects.
The biggest mistake is conflating actions with tasks. A task is something on your internal board. An action is something with an owner and a deadline that you are communicating to a stakeholder. They are not the same thing and mixing them creates noise.
Keep it to genuine actions from the current period. An action log with 40 items from the last six months is not an action log — it is a backlog. Archive anything older than the previous sprint and keep the live document focused on what is happening now.
Writing client emails that do not sound like they were written by AI
The giveaway phrases are consistent. "I hope this message finds you well." "I wanted to reach out." "Please do not hesitate." "Moving forward." These phrases have been so overused that they have become invisible — and clients have started to notice when emails read like they came from a template.
The fix is specificity. Reference the actual project. Mention the specific blocker. Name the engineer who is working on it. A client email that contains three specific details from this week's work takes the same amount of time to write as a generic one and does significantly more to maintain the relationship.
The opening line is the most important. "Following this week's review, here is where the Azure migration stands." does more work than two paragraphs of pleasantries. Get to the point. Your clients are as busy as you are.
Cutting the time without cutting the quality
The fastest legitimate shortcut is having a template that is genuinely good. Not a generic one from Google — one that reflects how your team writes and what your clients expect. Once you have that, weekly reporting becomes a matter of filling in the specific details rather than constructing something from scratch.
Tools that connect directly to your PSA can take this further. If your ticket data can be pulled automatically and structured into a client update, the PM's job becomes editing and approving rather than writing from scratch. Handover (gethandover.uk) does this for HaloPSA — pulling tickets directly and generating a client email, action log, risk log and status report in one step. The output still needs a human review before it goes to a client, but the heavy lifting is done.
The five-hour reporting week is not inevitable. It is the result of doing something manually that can be systematised. The MSPs that get this right free up their PMs to do the work that actually builds client relationships — the conversations, the problem solving, the proactive communication that no template can replace.