How MSPs Use AI to Write Quarterly Business Reviews

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How MSPs Use AI to Write Quarterly Business Reviews.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How MSPs Use AI to Write Quarterly Business Reviews.

Export the quarter's numbers from your PSA (the ticketing and billing system), security and asset tools, calculate the metrics in a spreadsheet first, then give AI the figures, your account notes and a fixed QBR template to draft the narrative. An account manager then edits the recommendations and budget. AI should write the "so what", never the numbers.

That split matters because a QBR is a trust document. A client who spots one wrong figure, such as a ticket count that doesn't match their memory of a bad month, stops believing the recommendations that follow. It also keeps you careful with data: client network details and security findings belong in an AI tool on a business plan, never a free chatbot.

Follow me on Instagram@sagnikteaches

The QBR a small-business owner reads to the end

Most MSP QBRs are too long. A 22-page deck of charts suits the MSP's view of its own work; the owner of a 20-person business wants to know three things: is my IT under control, what's at risk, and what should I spend next. Build the document around that, on one or two pages, with charts in an appendix:

Connect on LinkedInSagnik Bhattacharya
  1. The quarter in three lines. The headline, in plain words.
  2. Service. Tickets raised and resolved, response and resolution times against your agreement, and the top three recurring issues.
  3. Security. Multi-factor sign-in coverage, patch compliance, backup test results, and the trend in the client's security score.
  4. Lifecycle. Devices out of warranty or due for replacement, licences due for renewal, anything end-of-support.
  5. Recommendations. Two to four, each tied to something observed, with a cost range and priority.
  6. Next quarter. What you'll do, what you need from them.

The narrative in sections 1 and 5 is where the AI earns its place. Sections 2 to 4 are numbers, and numbers come from your tools.

Subscribe on YouTube@codingliquids

Mapping each QBR metric to your PSA, RMM and backup tools

Map every metric to a source before you automate anything. A typical small MSP's list:

MetricSourceExportWatch out for
Tickets by category, response and resolution timesYour PSATicket report filtered by client and date range, as CSVMerged or reopened tickets counted twice; internal tickets logged against the client
Patch complianceYour RMM (remote monitoring and management tool)Patch status report per deviceOffline devices showing as non-compliant
Security score trendMicrosoft Secure Score; for multi-tenant views, Microsoft 365 LighthouseScore at start and end of quarterScore changes caused by Microsoft adding new controls, not by the client
Backup resultsBackup consoleJob success rate and last restore test date"Success" jobs that skipped files
Warranty and replacement datesAsset or lifecycle tool, or manufacturer lookupsDevice list with warranty end datesDevices bought by the client outside your procurement
Copilot adoption (clients with Copilot licences)Microsoft 365 admin centre usage reportActive users over 28 or 90 daysLicences assigned to people who've left

The Copilot line is newer and increasingly useful. Clients who bought Microsoft 365 Copilot seats want to know whether anyone uses them, and the admin centre's usage report (active users over 7, 28, 90 or 180 days) answers it. A QBR that says "9 of 15 licensed users were active in the last 28 days; here's what the other six would use it for" is a far better conversation than a renewal invoice.

Calculate first, narrate second

Put the exports into a spreadsheet and calculate the metrics there, with formulas you can check. Don't paste a raw 600-row ticket export into a chatbot and ask "how many tickets did they raise?". Language models are poor at counting and summing long tables and will give a confident, plausible and wrong total; the reasons are explained in why AI is bad at maths.

A realistic example of how that fails: an MSP pastes a quarter's CSV into a chatbot, which reports 412 tickets. The export contained 380 real tickets plus 32 duplicates created when tickets were merged. A pivot table with the duplicates filtered out gives 380. The client's operations manager, who approves every ticket, knew it was "about 380". The QBR's credibility was gone before the recommendations page.

A two-minute reconciliation catches most export problems before a client does. Pick one headline figure, usually tickets raised, and compare the spreadsheet with the count your PSA's own client dashboard shows for the same dates. When they differ, the gap is nearly always one of three things: merged tickets still in the export, a date filter on "last updated" instead of "created", or tickets your own team logged against the client for internal work. In the example above, a count that excluded the Merged status took 412 down to 380, which matched the dashboard:

=COUNTIFS(Tickets[Client],"Subscription box co",
          Tickets[Status],"<>Merged",
          Tickets[Created],">="&DATE(2026,7,1),
          Tickets[Created],"<"&DATE(2026,10,1))

Write the reconciled figure and the date you checked it in a corner of the sheet. Next quarter, whoever prepares the QBR can see the check was done and repeat it in the same way.

Once the spreadsheet is built for one client, copy it as a template. A filled-in metrics block for an illustrative 22-user subscription box company looks like this, and it's what goes into the prompt:

CLIENT: [subscription box company], 22 users, 1 office + warehouse
QUARTER: Q3            PREVIOUS: Q2
Tickets raised: 96 (Q2: 71)          Resolved within agreed time: 91% (Q2: 95%)
Top categories: Warehouse label printers 31 | New starters/leavers 18 |
                Email and phishing reports 14
Median first response: 22 min (target 60)
MFA coverage: 22/22 users | Admin accounts with MFA: 3/3
Patch compliance (end of quarter): 88% (Q2: 96%) - 3 warehouse PCs offline
Secure Score: 61% (Q2: 58%)
Backups: 100% job success; last restore test 12 Aug, passed
Devices: 5 of 24 out of warranty by end of Q1 next year (all warehouse PCs)
Copilot: not licensed
Account notes: peak season Oct-Dec; warehouse temp staff double in Nov;
owner mentioned opening a second packing site next year.

The narrative prompt, and what comes back

Keep the prompt fixed across clients so every QBR has the same shape, and change only the metrics block and notes:

You are writing the summary and recommendations for an IT managed service
provider's quarterly business review. The reader is the owner of a small
business, not technical. Use ONLY the metrics and notes below; do not calculate
new figures or invent any.

Write:
1. THE QUARTER IN THREE LINES: plain English, lead with what matters to the
   business, not to IT.
2. WHAT CHANGED AND WHY: 3-5 bullet points explaining the biggest movements,
   using the account notes for context. If the cause is unclear, say so.
3. RECOMMENDATIONS: 2-4 items. Each must link to a specific figure or note,
   give a reason in business terms, and end with "Priority: high/medium/low".
   Leave cost as [COST] for the account manager. Include the option of doing
   nothing where it is reasonable.
Tone: calm, specific, no jargon, no sales language.

[metrics block]

An illustrative first draft from that input:

THE QUARTER IN THREE LINES
IT support demand rose by about a third this quarter, driven mostly by the
warehouse label printers. Security improved slightly and every user is
protected by two-step sign-in. The warehouse PCs are the main risk going into
your busiest season.

WHAT CHANGED AND WHY
- Tickets rose from 71 to 96. Label printers accounted for 31, almost a third.
- Fewer tickets were resolved within the agreed time (91% vs 95%), mainly
  printer faults needing on-site visits.
- Patch compliance fell to 88% because three warehouse PCs were offline at the
  end of the quarter.
- Five warehouse PCs go out of warranty before the end of Q1.

RECOMMENDATIONS
1. Replace the warehouse label printers before October to avoid disruption
   during peak season. Priority: high. Cost: [COST]
2. Replace the five warehouse PCs, ideally with the printers, so the warehouse
   is on supported hardware for the new site. Priority: medium. Cost: [COST]
3. Set up a starter and leaver process for November's temporary staff.
   Priority: high. Cost: [COST]

What the account manager fixes:

  • Recommendation 1 overreaches. The data shows printer tickets, not that the printers are failing. The account manager knows the real cause is a driver problem after a label-size change, fixable in an afternoon. The recommendation becomes "Standardise the printer drivers and label templates (half-day visit); review replacement if faults continue."
  • "Every user is protected by two-step sign-in" is right today, but November's temporary staff will need accounts. Link it to recommendation 3.
  • No do-nothing option for the PCs, though the prompt asked. Add: "Or keep them to the end of peak season and replace in January; the risk is a failure in December."
  • The second site is in the notes but missing from the draft. Add a line for next quarter: "Talk about the network and devices the new packing site will need."

Twenty minutes of editing turns a competent draft into advice. That's the job AI can't do: it doesn't know the printer story, the owner's mood or which recommendation the client already rejected last quarter.

When a figure moves for reasons the client didn't cause

Some movements have nothing to do with the client's behaviour or your work, and a model told to explain "what changed and why" will invent a cause anyway. Take an illustrative eight-person architecture practice whose Secure Score went from 64% to 57% in a quarter when nobody changed a setting: new recommended controls had been added to the scoring, so the same configuration scored lower. The first draft said "Your security position weakened this quarter", which would have alarmed the owner for no reason. Tickets can do the same thing in reverse. A client whose office shut for a fortnight in August will show a drop that the draft credits to "improvements in stability".

The fix is one extra line in the metrics block and one in the prompt:

Known external causes: Secure Score scoring changed this quarter (new
controls added); office closed 4-15 Aug.

[Add to the prompt:] If a figure moved because of something listed under
"Known external causes", say so in one sentence and do not treat it as a
trend.

With that in place, the same draft read: "Your security score fell from 64% to 57%, but only because the scoring now includes new checks. Nothing on your systems changed. Two of the new checks are worth doing, and they're in the recommendations." That's accurate, and it turns a scary number into a small piece of work.

What the process saves an MSP with 30 clients

The MSP in this illustration has four technicians and one account manager, looking after 30 small-business clients. Before, a proper QBR took about four hours: pulling reports from five tools, building charts, writing the summary. So QBRs happened for the ten largest clients and the rest got an invoice and a phone call.

With a metrics spreadsheet template per client and the prompt above, the time splits like this:

StepBeforeAfter
Exporting from the PSA, RMM, backup and security tools60 min25 min (saved report filters)
Calculating metrics and charts60 min15 min (template spreadsheet)
Writing summary and recommendations90 min10 min AI draft plus 20 min editing
Formatting the document30 min10 min (fixed template)
Totalabout 4 hoursabout 80 minutes

At 80 minutes, all 30 clients can get a QBR every quarter for roughly the time the top ten used to take. The value isn't only hours: QBRs are where MSPs find project work, and the twenty smaller clients who never had one are where the unreplaced hardware and unmanaged leavers are.

One more use before the meeting itself: paste the finished QBR back into the AI tool and ask, "What three questions is this business owner most likely to ask, and which figure in the document would each question be about?" For the subscription box company, an illustrative answer would be "Why did support tickets go up by a third?", "Do I need to replace the PCs before peak season?" and "What will the new site cost me in IT?". Having a one-line answer ready for each makes a twenty-minute review feel prepared rather than scripted. It also shows you where the document is unclear: if the AI's likely questions are about things the QBR already answers, those sections need rewriting in plainer words.

Recommendations that read as advice, not upselling

Clients learn fast to skim a recommendations page that's a product list. Four rules keep it useful: every recommendation points to a figure or note in the same document; each gives the business reason before the technical one; costs are ranges, not surprise quotes; and "do nothing" appears where it's a reasonable choice.

Compare two versions of the same recommendation:

Before: "We recommend upgrading to our Advanced Security bundle for enhanced
         protection against evolving threats."

After:  "Fourteen tickets this quarter were staff reporting suspicious emails,
         and two people clicked a link before reporting. Adding email link
         scanning and a short phishing refresher would reduce that risk.
         About [COST] a month. Priority: medium. Alternatively, run the
         refresher alone this quarter and review the ticket count in Q4."

Put the rules in the prompt as well as in your head. The drafting improves noticeably when the model is told that each recommendation must quote the figure it's based on.

A quarter with an incident needs a section written by a person

The calm, even tone that suits a normal quarter is wrong after something went badly. If a client had a compromised mailbox, a failed backup restore or a day without email, an AI summary tends to fold it into a bullet between the ticket count and the patch figure, as if it were one statistic among many. The owner remembers that week very differently.

So write the incident paragraph yourself, first, and pass it to the model as fixed text. Say what happened, how long the business was affected, what it cost them in time, what you changed, and what remains open. Then add to the prompt: "An incident summary written by the account manager appears above. Do not restate, soften or reword it. Refer to it once where relevant." An illustrative version for a small recruitment agency:

INCIDENT (written by account manager, not for rewording)
On 9 September one staff mailbox was accessed from an unknown location
after a phishing email. It was locked within 40 minutes of the alert.
Fourteen suspicious emails were sent to candidates before we stopped it;
we have the list and helped you send a correction the same day. Since
then: sign-in alerts go to us and to you, and forwarding rules to outside
addresses are blocked. Still open: phishing refresher for all staff,
booked for 2 October.

Everything after that paragraph can be drafted as usual, and the recommendations will naturally point back to it. Clients tend to trust an MSP more after a well-handled incident, provided the account of it is plainly theirs and not smoothed over.

Running QBRs for 30 clients without them sounding the same

The risk of a fixed prompt is thirty QBRs with identical sentences. Three habits prevent that:

  • A context file per client. Half a page kept in the client's folder or project: what the business does, its busy seasons, the owner's priorities, past recommendations and their outcomes. Paste it in with the metrics. A catering company's QBR should talk about event weekends; a furniture maker's should talk about the workshop PCs that run the cutting machines.
  • Last quarter's recommendations as an input. "Recommended in Q2: printer drivers (done), PC replacement (declined, revisit Q4)." The draft then follows up instead of repeating itself.
  • The account manager's own opening line. One sentence written by a person at the top of every QBR, before the AI summary. Clients notice.

A filled-in context file for the furniture maker, kept to the half page that actually changes the draft:

CLIENT CONTEXT: [furniture maker], 14 users, workshop + showroom
What they do: made-to-order furniture. The CNC cutting machine is run
  from two workshop PCs that must stay on the machine supplier's tested
  software version.
Busy season: Sep-Nov (holiday-season orders). Showroom open weekends.
Owner's priorities: machine uptime; dislikes surprise costs; wants the
  next quarter's IT spend as one number.
Past recommendations: Q1 put the CNC PCs on their own network (done).
  Q2 replace showroom tablet (declined, "next year").
Handle with care: the Q1 leaver account issue is closed; don't raise it.
Decision-maker: owner. Day-to-day contact: office manager.

Without that file, the draft recommended bringing the two CNC PCs up to date to fix the patch compliance figure, which would have stopped the cutting machine. With it, the draft explained that the two PCs are excluded by agreement and already isolated, then worked out compliance on the remaining twelve devices. One paragraph of context was the difference between a sensible QBR and one the owner would have forwarded to the machine supplier with a question mark.

The same habit prevents a quieter mistake. An account manager drafting six QBRs in one long chat found the fourth, for a small law firm, recommending "accounts for temporary staff before peak season". The law firm has no temporary staff and no peak season: the subscription box company's notes from earlier in the conversation had carried into the draft. Start a new chat, or use a separate project, for each client, and before sending, search the draft for other clients' names and their tell-tale details (warehouse, peak season, CNC).

If you'd rather buy than build, dedicated platforms exist: ScalePad's Lifecycle Manager, for example, produces QBR reports and presentations from asset, user and contract data and adds AI-generated client summaries. Weigh that against a spreadsheet template and a prompt, which cost little but need someone to maintain them. For the rest of your AI stack, see the best AI help desk tools for small MSPs, and for the tickets these reviews keep reporting, turn fixed tickets into a searchable knowledge base.

Checking the QBR process is working after two quarters

Time saved is the easy measure and the least interesting one. After two quarters, three figures tell you whether the QBRs are doing their job:

  • Recommendation outcomes. Tag every recommendation as accepted, declined or deferred in the client's context file. Illustratively, 30 clients with three recommendations each gives 90 a quarter. If the ten larger clients accept about a third and the twenty smaller ones accept almost none, the smaller clients' recommendations are probably generic. Read five of them side by side and you'll usually see the same three items with different names.
  • Corrections found by clients. Count any figure a client queried and turned out to be right about. One is a lesson; more than one a quarter means the reconciliation step is being skipped.
  • Editing time. If account managers are spending 45 minutes rewriting each draft instead of 20, the prompt or the context files are thin. Look at what they keep changing and move that into the prompt or the client file.

A simple test on any finished QBR: cover the client's name and ask a colleague which client it is. If they can't tell from the recommendations and the opening line, it isn't specific enough to send.

Keeping client data safe while you prepare QBRs

QBR inputs are among the most sensitive things an MSP holds: device lists, security gaps, user names, sometimes vulnerability findings. Use an AI tool on a business plan (ChatGPT Business, Claude Team or Microsoft 365 Copilot) where content isn't used for training by default, and keep each client's material in a separate project. Strip hostnames, IP addresses and anything credential-like from the notes; the narrative doesn't need them. Check your managed services agreement covers processing client data with the tools you use. Marketing agencies face the same reporting problem with different data, and how agencies automate client reporting has ideas worth borrowing for the charts appendix.

Further reads

Sources: Microsoft Learn, Microsoft 365 Lighthouse overview; Microsoft 365 admin centre Copilot usage report; ScalePad Lifecycle Manager QBR and Deliverables pages; OpenAI and Anthropic business plan data terms.

Want QBRs that write themselves from your PSA data?

On a 1:1 call we'll look at the reports your PSA and tools already produce, build the metrics sheet and prompt around them, and decide what your account managers should still write by hand.

Book a 1:1 call with me