Be clear what the meeting is for
A service review has three jobs: demonstrate that you delivered what was agreed, surface anything that needs a decision, and agree what happens next. It is not a technical briefing and it is not a sales meeting, and reviews that drift into either tend to stop being attended by the people who matter.
The test for any slide is whether it changes a decision. A chart nobody acts on is a chart that trains the client to skim.
What belongs in it
- Volume: incidents raised and resolved this period, against the previous four. Trend matters far more than the total.
- Responsiveness: performance against agreed targets, including the times you missed.
- What was delivered: projects completed, work in flight, and anything that slipped with the reason.
- What you supply: the services in place, so nobody is surprised by a line at renewal.
- Spend: what it cost them this period and how that compares.
- What is coming: renewals due, work planned, and anything you recommend they consider.
- Decisions needed: a short list, with the decision stated. This is the slide people actually engage with.
What to leave out
- Vanity metrics with no comparison. "412 tickets resolved" means nothing without last quarter’s figure.
- Technical detail the audience cannot act on. Patch compliance by device class belongs in an appendix at most.
- Anything you cannot evidence. One challenged figure costs more credibility than ten good ones earn.
- A page of green ticks. It is easy to produce, and every client has seen enough of them to discount it entirely.
Including a target you missed, with what you did about it, buys more credibility than any number of met targets. Clients know a difficult quarter when they have lived through one.
Getting preparation down to twenty minutes
The reason reviews take a day is that the data is assembled from several places at the moment it is needed. Every figure exists already - in the ticket queue, the time entries, the project boards and the service records - but not in one place and not in a form that composes.
The fix is structural rather than editorial. If incidents are logged against clients, time is booked against incidents, projects live on boards and services are held with prices, then the review is a query rather than a construction exercise. Preparation becomes reading, editing the narrative and approving.
This is what CubeMSP does with reviews, and it is worth saying plainly that the benefit comes from the data being connected in the first place. A tool that generates a review from disconnected sources is solving the wrong half of the problem.
Where AI helps, and where it must not be allowed near
Writing a coherent narrative around a set of figures is a good use of a language model. It is fast, it is consistent, and the output is easy for a human to correct.
Producing the figures is not. A model asked how many incidents were raised will produce a plausible number, and a plausible number in a client-facing document is considerably worse than no number at all. Every figure must be computed from the data and handed to the model as input.
The second rule is that nothing reaches a client without a human approving it. Not because the output is usually wrong, but because putting your name to what you send a client is the whole basis of the relationship.
If a supplier cannot explain clearly which numbers in a generated review are computed and which are generated, assume all of them are generated and act accordingly.
Cadence and who attends
Quarterly suits most clients. Monthly is usually too frequent to show a trend and becomes an operational catch-up; annual is too infrequent to change anything before it has already happened.
The attendee who matters is the person who signs the contract, not the person you speak to weekly. A review attended only by your day-to-day contact is a useful conversation and does very little for the renewal.