Translating Tickets Into Business Language

Thursday, 14:00, at Redbrook Engineering. Leo, who runs the three-person desk, has been given ten minutes at the end of the operations meeting. He has prepared. "Backlog is up to ninety-two. We had thirty-eight priority-two incidents, which is high for us, first response slipped, and we have twelve tickets open against the design office workstations." He looks up. Six people are looking back at him with the polite expression people use at a presentation in a language they almost speak. Sunita, the operations director, waits for him to finish. She asks the only question anyone in the room has: "Leo, is anybody on the shop floor waiting on us for anything right now?" He knows the answer is in the ninety-two. He does not know what it is.

Translating tickets into business language means restating what the desk counts as what the organisation loses or risks. The desk counts tickets, ages, statuses, priorities and times. The business terms are people who cannot work, hours gone, work that is late, and risk being carried. The desk's units are tickets; the organisation's units are people, hours, dates and risk. And a number in the wrong units is a number nobody can use. The general method for explaining anything technical to a person whose job is to decide uses risk, cost, time and options. It is in Explaining Technical Things to Management, along with the one-page decision brief. This article is the help desk's dictionary for it. This article is part of our Reporting to Leadership series, and it is about the sentence Leo should have had ready.

It covers why the desk's words do not carry. It covers the four business units: people blocked, hours lost, work delayed and risk carried. Next come the arithmetic in hours, with ranges, and translating each of the standard desk numbers. Then come writing sentences that carry, the traps, a short war story, and the translation table to copy, in that order.

Why the Desk's Words Do Not Carry

Every word the desk uses about its work means one exact thing to the desk and almost nothing to anyone else. A ticket is a record of one request; to the reader it is a piece of paper. Backlog is the count of open tickets; to the reader it is a word from a factory. Priority two is a rung on a ladder the desk built. The reader does not know how many rungs there are or what the top one means. SLA, the service level agreement, which is the promise about how fast the desk responds and resolves, is three letters that sound like a regulation. None of these words is wrong. They are simply addressed to the wrong listener. A listener who has to translate as they go stops listening in the second sentence.

The reader's units are the organisation's own. People: how many, which group, by name if the group is small. Hours: of work that did not happen, or happened twice, or happened late. Dates: when something was due and when it actually arrived. Risk: what could go wrong that has not yet, and how bad it would be in those same units. And there is money, which the desk should leave to the reader to apply. The reader knows what an hour of a claims handler costs the organisation and the desk does not. A desk that guesses at a rate hands the reader a number to argue with instead of a fact to act on. Hours are as far as the desk goes. The reader does the rest, and does it more credibly than you could.

Translation is not simplification, and the distinction matters. Simplifying "thirty-eight priority-two incidents" gives "quite a few medium-sized problems", which is shorter and says even less. Translating it gives "thirty-eight times this month a group of people stopped work until we fixed something; the longest stop was the design office for a morning". The second sentence is longer than the first and is the one that gets a decision. Every word in it is in the listener's units. You are not dumbing anything down. You are changing currency.

Leo's ten minutes were accurate, complete and in the wrong language, which is the most expensive kind of accurate there is.

The Four Business Units

Almost everything the desk knows can be restated in one of four business units. The first is people blocked: the count of distinct people who cannot do some part of their job until a ticket is resolved. Not every open ticket blocks someone. A request for a second monitor blocks nobody. A request for access to the quoting system blocks a salesperson entirely. The count is of people, not tickets. One ticket about a shared system can stand for forty people. Forty tickets about a mouse each stand for one person for ten minutes. If you run QuerySolv, every ticket carries its requester whichever door it came in by. In that case, the people behind the backlog are names to be counted rather than guessed at. In any tool, the method is the same. Read the open list once and tally the people, not the rows.

The second is hours lost: people blocked, times the hours each of them could not work. And it is the unit leadership repeats most readily because it is the one they already think in. The honest version is a range, because a person without a working system rarely loses the whole hour. They do something else, less useful, and some of the hour is recovered. "About 140 people lost somewhere between one and three hours each" is a true sentence. "420 hours lost" is the top of that range dressed as a fact, and someone in the room will know it. The arithmetic and its traps are the subject of The Cost of Waiting; this article is about saying the result.

The third is work delayed: the named business process that happened late or did not happen, in the organisation's own words for it. "Payroll ran a day late." "Three quotes went out on Monday instead of Friday." "The month-end close waited two days for the finance system." This unit carries further than hours lost, because the reader knows exactly what a late payroll means and does not need to multiply anything. Find the process behind the ticket by asking the requester one question: "what were you trying to do?" Write the answer down in their words.

The fourth is risk carried: the thing that has not gone wrong yet but is one ticket away from it. A backup fault open for forty days is a ticket to the desk and an unprotected month of the organisation's records to the reader. A server that cannot be patched because the application vendor has not answered is a known hole with a date on it. Risk is the hardest unit to translate, because it has no number of its own. It is stated as what would happen, to whom, in the other three units, and how long the exposure has lasted. "If the design office's file server fails before the replacement arrives, about thirty people lose their work for the time it takes to restore from a backup we last tested in the spring" is a risk in business language. "Ticket 4471, pending, 61 days" is the same risk in the desk's.

The Arithmetic in Hours, With Ranges

Here is the sum done once, at Redbrook Engineering, the fictional desk this article uses for its numbers. For a week in the spring, the production planning system slowed to the point that each screen took half a minute to load. About sixty people in planning, purchasing and the shop-floor office used it through the day. Each of them, when Leo asked a handful, reckoned they were losing between one and two hours a day to the waiting. Sixty people, five working days, one to two hours a day: that is between three hundred and six hundred hours of their time. That is all in one week, from one slow system. On the desk that week was one ticket, priority three, status "waiting on vendor", because nothing was actually down.

The range is the honest part and the part most people cut. Three hundred to six hundred is a wide range and it is the true one. Nobody knows whether the purchasing clerk lost one hour or two. A report that says "450 hours" has invented a precision it does not have. Give the range, give the basis in a clause ("from asking six of the people affected"), and let the reader pick a point. They will pick one nearer the top than you would have dared to, because they believe the range. They would have halved a single number out of habit. Ranges are not weakness. They are what a number looks like when it is telling the truth.

Never multiply by a salary, a day rate or a cost per hour, even when you know one, even when the reader asks. The moment hours become money, the conversation moves from what happened to whose figure for an hour is right. And the desk loses that argument on territory it does not own. Give the hours and the people, and if the reader wants money they will apply the rate they trust, which is theirs. The one exception is when the organisation has a published figure that everyone already uses. Even then, write "at the standard internal rate" and let the finance reader do the multiplication in their head. (They will, before you have finished the sentence.)

Keep the arithmetic visible, in one line, next to the result, every time. "About sixty people, five days, one to two hours a day: three to six hundred hours" takes fourteen words and makes the number unarguable. A reader who wants to disagree has to say which of the three inputs is wrong. They are all facts the desk can show. A bare total invites a bare "that seems high". A total with its working invites a conversation about the planning system, which is the conversation you wanted.

Translating the Standard Desk Numbers

Each of the numbers the desk tracks has a business-language form. And the translation is nearly always a change of subject from the ticket to the person. Volume, the count of tickets arriving, becomes demand: "about four hundred times this month someone in the organisation needed us". Backlog becomes people waiting: "ninety-two requests open, from about seventy people, of whom about twenty cannot do part of their job until we are done". The age of the backlog becomes how long they have waited: "fourteen of those people have been waiting more than a month". Each of these sentences is the same fact as the number, with the camera turned round to face the requester.

The time numbers translate into the requester's experience. First response time is how long until someone on the desk first dealt with the ticket. It becomes "how long before someone looked at it", which the reader has felt personally and understands at once. Time to resolution becomes "how long before they could work again". The median rather than the average is quoted, as "half the people who asked us for something had it within a working day". Resolved-within-target, where the desk has agreed service levels, becomes "we kept the promise on all but nine requests this month, and here is what the nine were". What the promises should be in the first place is the subject of the SLA Design series; the translation only reports against them.

The quality numbers translate into trust. The reopen rate is the share of resolved tickets the requester sent back because the fix did not hold. It becomes "fixes that did not stick: eleven this month". Satisfaction becomes what people said, with the count of people who said it: "fifty-six of the sixty-one people who replied said we helped, and the five who did not were all about the expenses system". First contact resolution, the share of requests fixed in the first conversation, becomes "about two in three people got their answer the first time they asked". Escalation is where the desk had to hand a ticket to someone with more skill or authority. It becomes "problems the desk could not solve alone", which is a useful sentence for a leadership reader. It is the one that points at other departments and vendors rather than at the desk.

The numbers that do not translate stay off the leadership page. Tickets per technician, average handling time, utilisation, tickets by category by week: the desk reads these to run itself. None of them has a business-language form because none of them is about what the organisation lost or gained. Trying to translate "Priya closed 118 tickets" produces "Priya helped 118 people", which sounds like a translation and is a ranking in disguise. Which numbers go up and which stay on the desk is the subject of The Numbers to Show and the Numbers to Keep. The rule for this article is that a number without a business unit is a number for the desk.

Sentences That Carry

The business-language sentence has a fixed shape: who could not do what, for how long, because of what, and whether it is fixed. "About 140 people could not reach the shared drive for three hours on Tuesday morning because its storage controller failed; it is fixed, and the controller has been replaced." Four facts and a status, in that order, with the people first. The desk's version of the same event, "P1 incident, shared storage, 3 h, resolved", contains the same information and is read by nobody. It begins with a code and ends with a status word instead of a person and a verb.

Name the group, not the system. "The design office" carries; "the CAD file server" does not, because the reader knows thirty people in the design office and has never seen the server. Use the organisation's own names for its processes and places: "month-end", "the depot", "the Tuesday payroll run", "goods-in". The desk learns these names by asking requesters what they were trying to do and writing it down. The names collected over a few months become the dictionary. A desk that speaks the organisation's names back to it is understood instantly. It is also, incidentally, trusted more, because it has visibly been listening.

Remove the desk's words from the sentence entirely and see what is left. "Ticket", "incident", "pending", "escalated", "P1", "SLA", "resolved", "closed": strike every one. If the sentence still stands, it was in business language. If it collapses, it was a ticket note with better grammar. "The escalated P2 was resolved within SLA" collapses to nothing. "The finance team's reporting tool was back within the four hours we promise for a fault that stops a department" stands, and says more. The strike test takes ten seconds and is the single most useful habit in this article.

State what is fixed and what is not, every time, because the reader's next question is always "and now?". A sentence about an outage that ends without a status leaves the reader deciding whether to worry, and they will decide to. "It is fixed" ends the worry. "It is not fixed; about twelve people are working on borrowed machines until the replacement arrives next week" starts a decision, which is the point. The three sentences on the monthly page in The Monthly Report They Will Actually Read are exactly this shape, once a month, about the month's biggest movement.

The Traps

The first trap is inflation. Every blocked hour is counted as a lost hour. Every person who touched a system is counted as blocked by it. The top of every range is quoted as the figure. Inflation is tempting because the big number gets attention. It is fatal because the big number gets checked, once. The checker was in the room during the outage and knows they went to a meeting instead. After that, every number from the desk is quietly halved by its readers, including the honest ones. Quote the range, with the low end first, and let the high end speak for itself.

The second is the rate, dealt with above and worth repeating as a rule: the desk reports hours and people; the reader applies money. The third is the blame translation, where the business-language sentence turns out to point at a department. "The finance team keeps breaking the expenses system" is not a translation of eleven tickets; it is an opinion wearing a number. The translation is "eleven people in finance raised the same fault with the expenses system this month, which suggests the fault is in the system rather than the people". That translation points at the system, which is where the fix is. Business language punches at the system or at nothing. Never at the people who raised the tickets, who were doing the organisation a favour by telling you.

The fourth trap is the jargon that sneaks back in through the side door. You have written "people waiting" instead of "backlog" and then added "(92 tickets, 14 aged over 30 days, 3 pending vendor)" in brackets. The detail felt like evidence. The bracket undoes the sentence; the reader's eye goes to the codes and the translation is lost. Put the detail in the appendix or the sources line, and leave the sentence alone. The fifth is translating the mechanism instead of the effect: "the storage controller's firmware had a known fault" is a translated mechanism. And the reader did not ask how it broke; they asked who could not work. Mechanism goes in the incident review, where the people who fix things will read it.

The last trap is the one the translation itself springs on you, which is that the translated month sometimes looks worse than the desk's month did. The desk closed 405 tickets, the median was good, the survey was kind, and 140 people lost a morning. In the desk's words that was a strong month with one incident. In the organisation's words it was a morning the organisation lost, and the strong month is the context. Report it in the organisation's words anyway. A translation that only translates the good news is a press release, and leadership has read those before. How to write the page when the honest translation is bad news is the subject of When the Numbers Are Bad.

A Short War Story: The Ticket of One at Stonebridge Insurance

At Stonebridge Insurance, a desk lead called Grace sent the claims director a monthly summary. For three months running, it read: "backlog stable at around sixty, response times within target, one long-running known error with the claims intake form, workaround in place". The known error was that the form crashed about once an hour for each of the fourteen claims handlers who used it. The workaround was to save every two minutes and re-enter whatever was lost. Each handler reckoned the workaround cost them about forty minutes a day. On the desk it was one ticket, priority three, status "pending vendor", age ninety days. It counted as one in the backlog of sixty. Translated, it was fourteen people losing between a half and one hour each, every working day, for three months. That was somewhere between four hundred and eight hundred hours of claims handling. There was also a run of claims paid late that the director first heard about from a customer's letter of complaint. The director asked Grace why none of this had been in the summary. Grace said, truthfully, that it had been, as the known error with the workaround in place. The claims team got a fix within a fortnight once the director phoned the vendor's account manager personally. Grace had been asking the desk's contact to arrange that for a quarter. A backlog of one is not small when fourteen people are standing behind it.

The Translation Table

The table below is the dictionary, one row per desk word. The desk's own meaning sits beside the leadership form and an example sentence in the shape from this article. Copy it, replace the examples with your organisation's own names and figures, and keep it next to the monthly page when you write the three sentences. Add a row each time a leader asks "what does that mean?", because that question is a missing row telling you where it goes. The example figures are from the fictional desks in this article and are there to show the shape of the sentence, not to be reused.

Leo rewrote his ten minutes for the next operations meeting with the table beside him, and it came to four sentences. "About twenty people cannot do part of their job today until we finish something, twelve of them in the design office on borrowed machines while two workstations are repaired. Planning lost somewhere between three and six hundred hours last week to the slow planning system, and the vendor has a fix scheduled for Friday. Fourteen people have been waiting on us for more than a month, nine of them for the housing supplier, and I need someone with a louder voice than mine to phone their account manager. Nothing else needs a decision." Sunita asked who the nine were and phoned the account manager that afternoon. She gave Leo five minutes the following month instead of ten, which he took as the compliment it was.

Frequently Asked Questions