By Yair Knijn · June 25, 2025

You have 40,000 tickets and nothing to show the board: when reporting was never designed in

The COO asks a simple question two weeks before the board meeting: how did the desk do this quarter, by client, by category, against SLA. The service desk lead says "I'll pull it" because the tool has every ticket since 2021 and surely the answer is in there. It is not. Forty thousand tickets, and not one of them was filed in a shape a report can read.

Here is the assumption that breaks: volume is not data. A queue full of tickets feels like an asset until someone asks it a question it was never structured to answer. Reporting is a schema decision you make at intake, not a query you run at quarter-end. A desk that let agents type the category in a free-text box has a pile of incidents and no narrative to put in front of a board.

The QBR questions every director gets asked and can't answer

The board does not want the ticket count. They want trend, cost, and risk: which clients consumed the most effort, what kind of work is growing, where did you breach, and is it getting better or worse. Those are four pivots — by client, by category, by SLA outcome, by month — and every one of them needs a field that was structured at creation. If client lived in the email domain and category lived in a sentence the agent typed at 4pm on a Friday, none of those pivots exist.

So the lead spends the weekend in CSV exports, building the report by hand with a spreadsheet and a prayer, normalizing "pwd reset", "password", "PW reset" and "can't log in" into one bucket. The number that lands in the deck is an estimate dressed as a fact, and everyone in the room can feel the difference.

Free-text categories: how you destroyed your own reporting at intake

A free-text category field is the single most expensive shortcut a desk can take. It feels faster for the agent and it is, for ninety seconds. Then it costs you every report you will ever try to run, forever, because there is no enumerated set to group on. You cannot aggregate text that forty people spelled forty ways.

The damage compounds in a way you only see in hindsight. Each agent invents their own vocabulary, no two months are comparable, and the work to reconstruct categories after the fact grows linearly with volume. Reporting was destroyed on day one, in the form builder, when someone chose a text input over a closed picklist tied to a category taxonomy. The fix is not a dashboard. The fix is a constrained field that agents cannot leave empty or freehand.

FCR, reopen rate, SLA attainment: the metrics that survive scrutiny

Three metrics hold up when a board pushes on them, and all three depend on structured fields. First-contact resolution is the percentage of tickets closed in a single interaction; the recognized industry band sits around 70 to 79 percent, with 80-plus considered world-class — and it is meaningless without its honest twin. Reopen rate is the check on FCR: a closed ticket that comes back exposes a resolution that was never real. Quote an FCR number with no reopen rate beside it and a sharp director will, correctly, distrust it.

• First-contact resolution: needs a reliable "resolved on first touch" flag, not a guess from timestamps.
• Reopen rate: needs a state machine that records when a closed ticket reopens, by reason.
• SLA attainment: needs response and resolution clocks per priority, captured at creation and stopped at the right event.

Each of these is a field-level design choice. You either captured the right state at the right moment or you are reverse-engineering it from a free-text trail, and reverse-engineering is what produces the weekend in the spreadsheet.

Designing the schema backwards from the report you'll have to present

Start from the QBR slide and work backwards. Write the four pivots the board will ask for, then make every one of them a required, enumerated field on the ticket form: client, category, priority, resolution type. If a pivot you need does not map to a structured field, you have found a reporting gap before it becomes a crisis instead of after. Design the schema to answer the question you already know is coming.

This is what an operations workspace gives you that a ticket bucket does not: categories that are constrained at intake, SLA clocks that run per priority, and FCR and reopen rate that come out of the data model instead of out of a weekend. When the board asks how the quarter went, the answer is a saved report, not an archaeology project. If you want to see the schema before you migrate forty thousand tickets into it, walk the reporting model first.