How to Use Gemini to Draft a Quarterly SLA Service-Review Narrative From Ticket Data

The short answer: Gemini can read a quarter of helpdesk ticket exports and CSAT responses and draft the service-review narrative — the trend, the outliers, and the specific things worth arguing about — in about an hour. What you get is an independent reading of your own vendor's numbers. It cannot tell you whether the service is actually good.

The monthly service report arrives on the eighth working day, as contracted. It is nine pages, it opens with a green dashboard, and the IT manager at a 220-person firm forwards it into a folder without reading past page two. Three of these accumulate, and then a quarterly service review appears in the calendar.

At the review, the account manager presents the same numbers in the same green, everyone agrees the service is fine, and the hour ends early. Two weeks later the finance director asks why the helpdesk "feels slow," and there is no document anywhere that answers that question.

The raw material for a real answer exists. It is sitting in ManageEngine ServiceDesk Plus, Freshservice, Jira Service Management or Zendesk as a ticket export, and in whatever tool sends the CSAT emails. What is missing is the several hours of spreadsheet work that turn three months of rows into a story with a point of view.

That is the part worth handing to a model — not the judgement about whether the service is good, but the reading of the data that makes the judgement possible.

Why Monthly SLA Reports Pile Up Without Ever Becoming a Real Conversation

A monthly SLA report is a compliance artefact. It exists to demonstrate that a contractual threshold was met, and it is written by the party being measured. Both facts shape it: it reports against the targets in the contract, and it reports them in the most defensible way available.

Nothing in that is dishonest. But "P2 resolution SLA met in 97.4% of cases" is a statement about a threshold, not about the experience of the people raising tickets. A quarter in which median P3 resolution time doubled while staying inside a generous SLA shows as green on every page.

The reports also arrive monthly and get read monthly, which is the wrong cadence for noticing anything. Trends live across quarters. A single month cannot show you that the same five users have raised forty per cent of tickets since March, or that Monday-morning wait times have crept up by eleven minutes since a staffing change.

So the quarterly review — the meeting where this should surface — opens with the vendor's own deck, because nobody on the client side has prepared an alternative reading. The meeting is then conducted in the vendor's framing by default, which is nobody's fault and everybody's problem.

What Gemini Can Actually Do With Ticket and CSAT Exports

Gemini works with spreadsheet data through the side panel in Google Sheets and as an uploaded file in the Gemini app. Which features and file limits you get depends on your Workspace tier, and these change — check the current documentation for the plan you are on. The capability that matters here is unglamorous: reading a few thousand rows carefully and describing what changed.

Two outputs justify the hour.

Turning a spreadsheet of response and resolution times into a trend narrative

Given three months of ticket rows — created, first response, resolved, priority, category, requester department — it will compute the obvious aggregates and, far more usefully, write the paragraph: "Median first response held at 14 minutes; median P3 resolution moved from 4.2 hours in April to 7.8 hours in June, driven mostly by the software-install category."

That sentence is what a service review actually needs, and it is what almost never gets written, because writing it requires someone to sit with a pivot table for two hours and then form an opinion in prose.

Ask for the comparison explicitly — this quarter against last quarter, and against the same quarter last year if you have the data. A narrative without a baseline is a number with adjectives around it.

Flagging the tickets and patterns worth raising in the actual review meeting

The second output is a shortlist. Ask it to surface the ten longest-running tickets, every ticket reopened more than once, every category whose volume grew by more than a quarter, and every CSAT response scoring three or below with its free-text comment attached.

That list is your agenda. It converts the review from "are we hitting the SLA" into "here are eleven specific things that happened — what do we do about them," which is the conversation that actually improves service, and the one a provider with nothing to hide generally welcomes.

A Practical Workflow — From a CSV Export to a Review-Ready Draft

1. Get the raw export, not the report. Ask your MSP or your own helpdesk admin for a ticket-level CSV covering the quarter, with timestamps, priority, category, requester department and resolution notes. If your contract does not entitle you to this, that is worth discovering well before the next renewal — it is a reasonable thing to ask for and an awkward thing to refuse.

2. Strip what shouldn't leave your environment. Requester names and email addresses, anything in a resolution note resembling a password or an internal path, and any free text naming one of your own clients. Replacing names with a department label preserves every analysis you need and removes most of the risk.

3. Do the arithmetic in the spreadsheet, not in the prompt. Add the derived columns yourself — time to first response, time to resolution, breach yes/no, week number. A model is far more reliable describing a number already sitting in a cell than computing it from two timestamps across four thousand rows.

4. Ask for the trend paragraphs first, with the baseline named. "Compare Q2 against Q1 on median first response, median resolution by priority, ticket volume by category, and reopen rate. Write four paragraphs. Cite the figures you used." The citation instruction is the important half — it is what makes checking possible.

5. Ask for the exception list as a separate pass. Longest-running tickets, repeat reopens, fastest-growing categories, low CSAT scores with their comments. Keep it as a numbered list carrying ticket IDs, so every item can be looked up in seconds during the meeting.

6. Check three numbers by hand before you trust the other thirty. Pick figures from the narrative and verify them against the sheet. If those three are right, the method is working. If one is wrong, the narrative is unusable, and you need to know that before the meeting rather than during it.

7. Write the interpretation yourself. The model can tell you resolution times rose in the software-install category. Only you know that the same quarter is when procurement changed the laptop model and every new machine needed three extra applications. That sentence is the value you add, and it is not in the data.

8. Send the agenda three days before the meeting. A page of specific questions, sent in advance, changes the meeting completely: the vendor arrives having already looked into the same eleven tickets, and the hour goes on causes rather than on a dashboard.

An AI-Drafted QBR Narrative vs a Vendor-Written Review vs No Formal Review at All

• An AI-drafted narrative from your own data. Independent of the vendor's framing, cheap enough to repeat every quarter, and thorough in a way a tired person at 6pm is not. It has no context about your business, will happily describe a statistical artefact as a trend, and cannot judge whether a number is acceptable. Correct use: your preparation for the meeting, never the meeting's conclusion.
• A vendor-written service review. Prepared by people who know the environment, the history, and the reason that one ticket took nine days. That knowledge is real and worth having. It is also written by the party being assessed, against thresholds they helped set — not a criticism of any particular provider, just a structural fact worth compensating for.
• No formal review at all. The most common arrangement in firms under about 300 staff. Service quality then gets assessed by feeling, usually just after an incident, and the conversation happens at renewal — when the leverage is highest and the goodwill is lowest.

The pairing that works is the first two together. The vendor brings context, you bring an independent reading, and the meeting has two sources instead of one.

Where It Gets the Story Wrong

CSAT is a survivorship-biased sample that reads like a census. The users who answer surveys are the delighted and the furious. A rising average often means the mildly annoyed have stopped replying. Any narrative built on CSAT alone will be confidently wrong about the middle of your organisation, which is most of it.

A headline metric can hide the failure it is measuring. Ninety-eight per cent attainment across 3,000 tickets still leaves sixty breaches. If fifty of them belong to the finance team in the week of month-end close, you have a serious problem and a green dashboard simultaneously. Ask for breaches broken down by department and by week, every time.

It cannot distinguish a trend from a reorganisation. Ticket volume falling thirty per cent looks like an improvement, and is just as likely to mean a frustrated department stopped raising tickets and started calling someone's mobile instead. The data cannot see the shadow queue. You can.

Resolution notes are written to close tickets, not to describe reality. "Resolved, user advised" covers everything from a genuine fix to a shrug. A model reading a quarter of resolution notes produces a summary faithful to what was typed and unfaithful to what happened.

Getting This Right — Ticket Data Sensitivity, Vendor Objectivity, and When to Bring in IT

A ticket export is more sensitive than it looks. Resolution notes contain server names, share paths, application versions, the occasional credential that should never have been typed there, and a candid running record of which of your systems is fragile. Treat the file the way you would treat a network diagram.

Sanitize by rule, not by judgement. A standing pre-processing step that drops the requester name and email columns and scans free text for anything credential-shaped survives a busy quarter. An intention to be careful does not.

Know your tool's terms before the data goes in. Consumer, business and enterprise tiers differ in retention and in whether content may be used for training, and the terms change. Check the current documentation for your specific plan, then set one company-level rule about which tools may receive operational data, rather than leaving it to whoever happens to be preparing the review.

Bringing an independent reading to a vendor review is healthy, and it should be visible. Tell your provider you are doing it. One that welcomes a client arriving with their own analysis is telling you something useful about how they work; so is one that doesn't.

Deciding where AI belongs in your operational reporting, and writing the prompts and sanitization rules that make it repeatable, is AI+ Support work. The measurement framework underneath it — defined response and resolution targets, monthly reporting, CSAT collection, and a quarterly service review that is a real conversation — is our SLA and quality framework, and the delivery it measures is managed IT support. If you are building similar narratives from other spreadsheet exports, our write-ups on automating monthly sales reports in Google Sheets and drafting helpdesk ticket responses cover the adjacent problems.

Frequently Asked Questions

Can I trust an AI summary of my own vendor's performance?

Trust it as a reading of the data you gave it, and verify three figures by hand before relying on any of them. Its advantage over the vendor's report is not accuracy — it is independence. It describes your export against the questions you asked, rather than against the thresholds written into the contract. The judgement about whether those numbers are acceptable stays with you.

What if my MSP doesn't provide raw ticket exports?

Ask in writing, and note the answer. Ticket-level data about your own users and your own systems is a reasonable thing for a client to hold, and most providers supply a CSV without fuss. A refusal is not proof of anything on its own, but it is a data point — and the next renewal is the moment to turn the request into an explicit contractual entitlement.

How is this different from the report my vendor already sends?

Different author, different question. Their report answers "did we meet the agreed thresholds," which is the question the contract asks. Yours answers "what changed this quarter and what should we do about it," which is the question the business asks. Both are legitimate. Only one of them is currently being written.

Does this work with data from any helpdesk tool?

Any tool that exports ticket-level CSV, which is effectively all of them — ServiceDesk Plus, Freshservice, Jira Service Management, Zendesk, Halo. Column names differ; the work of adding derived columns is the same everywhere. What varies far more than the tool is the discipline of ticket categorisation: if half your tickets are filed as "Other," no analysis will rescue that.

How long does the first one take?

Most of a morning, and most of that is spreadsheet preparation rather than prompting. Later quarters take about an hour, because the export, the derived columns and the prompts are all reusable. It is a genuine addition of effort compared with skimming the vendor's deck on the way into the meeting — justified by it being the only independent view of the service that anyone has.