Explaining the Backlog to Management in One Honest Page

The e-mail arrived at 16:12 on a Thursday. "Can you send me a quick summary of where we are with the backlog? Nothing fancy, just so I have it for Monday." Imogen read it three times, because every word in it was doing something. "Quick" meant the director did not want to read much. "Summary" meant a number, not a list. "Where we are" meant the director already suspected the answer. And "for Monday" meant someone more senior had asked the director, who did not know, and now needed to.

There are three ways to answer that e-mail badly, and I have sent all three. The first is the spreadsheet: an export of 412 open tickets as an attachment, which answers the question completely and is never opened. The second is the reassurance: "It's a bit high at the moment but we're on top of it". That is not a summary. It will be quoted back on the day it turns out not to be true. The third is the essay: four screens of context, history, tool limitations and staffing. The director scrolls through them looking for a number and does not find one. The good answer fits on one page, has five numbers on it, and says what caused them and what you need. It takes about an hour to write the first time, and it is the most important hour in this series.

A backlog brief is a one-page account of the backlog for someone who does not run the desk. It covers how big it is and how old, why it happened, what the desk is doing, and what it needs. It is written in numbers and plain sentences, with no adjectives and no villain. This article is part of our Backlog Recovery series. The numbers in the brief come from the measurement sheet in How a Ticket Mountain Forms and the inventory in Taking Stock Before You Dig. This article is about turning them into a page a director can act on.

It covers what management actually wants to know, and the numbers that matter and the ones that mislead. Then come saying what caused it without blaming anyone, and saying what you need, with a number. Writing the page itself and the conversation that follows are next. Then it covers what to report during and after the dig-out, and the mistakes that cost credibility. The brief to copy comes last.

What Management Actually Wants to Know

A manager asking about the backlog wants three things, in this order: how bad is it, why did it happen, and what do you need from me. Everything else on the page serves one of those three or is cut. "How bad" is a number with a comparison, because a number on its own has no meaning to someone who does not know what normal is. "Why" is a cause, stated in one or two sentences, that does not require the manager to understand ticket statuses. "What do you need" is a decision they can make, with its cost and what it buys. A brief that answers those three in that order is read to the end. A brief that starts with the history of the ticketing tool is not.

Managers also have a fourth question they will rarely ask aloud, which is "am I going to be embarrassed by this?". The honest brief answers it by saying the worst number first, in the first line. That way, nothing in the rest of the page or in Monday's meeting can surprise them. A director who learns the oldest ticket is fourteen months old from your brief is a director with a plan. One who learns it from the person whose ticket it is, in the meeting, is a director who will not trust the next brief, however good. The first line is where the bad news goes. There is nowhere else it is safe.

What they do not want is also worth listing, because it is what most briefs contain. They do not want the list of tickets. They do not want to know which statuses exist, how the SLA is configured, or what the tool cannot do. They do not want the technician's week described. They do not want the word "unfortunately". They want to know whether the organisation's requests are being answered, how far behind the answer is, and what it would take to fix that. Translating a desk's problems into an organisation's terms is the whole craft of talking upwards, and Talking ITIL With Management covers the general version. The backlog is the special case where the translation is mostly arithmetic.

The Numbers That Matter

Five numbers go on the page, and the first four come straight from the measurement sheet. The open count: every ticket not resolved or closed, with the same count from three months ago beside it, so the direction is visible. The over-ninety count: how many of those are older than three months, which is the number that turns "busy" into "backlog" for a reader. The oldest ticket: its age in days and a five-word description, because one real example does what a hundred rows cannot. The weekly gap: created minus solved, averaged over the last four weeks, because it is the only number on the page that predicts the future. And the capacity envelope: how many tickets a week the desk can close with the time it has against how many arrive. That is the number the fourth question comes back to.

Three numbers do not go on the page, however good they look, because each one hides the backlog by design. The closed count, "we closed 620 tickets last month", measures effort and says nothing about what is left. A desk can close 620 a month while the pile grows. Most mountains were built under exactly that report. The average resolution time on closed tickets, because it excludes every open ticket, which is to say it excludes the thing the brief is about. And the share of tickets within SLA target, because it is measured mostly on recent tickets and because a desk under pressure parks tickets in waiting statuses to protect it. If your management already receives those three monthly, do not stop sending them. In that case, put the honest number beside each one and let the reader see the gap. The flattering number next to the true one is more persuasive than the true one alone.

Give every number a comparison and a unit a manager can picture. "412 open" means little. "412 open, which is about two and a half weeks of requests; it was 95 three months ago" means a great deal. "280 over ninety days" is a count. "280 requests have waited more than a quarter, including 40 from finance" is a fact with a department attached. "Gap of ten a week" is arithmetic. "We receive ten more requests a week than we can close. Without a change the backlog returns to this size in about a year." That is a forecast the manager can act on. Numbers persuade when they are translated. Untranslated, they are decoration.

Saying What Caused It Without a Villain

The cause section is two to four sentences and names no one. A backlog has structural causes: inflow above capacity for a long time, or waiting statuses with no closing rule. Other causes are an event that was never worked off, or a departure whose tickets nobody inherited. Every one of those can be stated as a fact about the system rather than a fault in a person. "The desk has received more requests than it could close for about a year, by eight to twelve a week" is a cause. "The team fell behind" is a verdict. A verdict about your own team in a document to their director is a sentence you will not get back.

Own the desk's part plainly, because it is there and the reader knows it. If tickets waited in Awaiting Reply for a year because nobody had a rule for closing them, say so: "We had no rule for closing a request when the requester stopped responding, so about 160 of the old tickets are ones we should have closed months ago." That sentence costs a little and buys a great deal, because a brief that admits the desk's part is believed when it describes the organisation's part. A brief that blames only volumes, vendors and the tool is read as a defence, and defences are not acted on.

State the organisation's part as a fact, not a complaint. "Requests rose from about 140 to 180 a week over the year as the company grew by sixty people, and the desk stayed at three" is a fact. "We were never given the resources" is a complaint, and it may be true, and it will still lose the room. The first version lets the manager draw the conclusion themselves, which is the only way a conclusion ever sticks. The second version draws it for them, and they will resist it on principle, because people do.

Use the four shapes from the first article in this series as the vocabulary, translated. A steady leak becomes "requests have exceeded what we can close by a small amount for a long time". A step becomes "the office move in the spring produced about 300 requests in two weeks, and we absorbed them without ever clearing them". A seasonal tide becomes "we are staffed for the average week and the start of each term is three times the average". A hidden pile becomes "we are keeping up with current requests and carrying about 280 old ones that have not been looked at". Each is one sentence, each is true, and none of them has a villain in it. The system did it. The page says so, and then says what to do about the system.

Saying What You Need

The ask is the reason the brief exists, and it is one of three kinds: time, a decision, or capacity. Pick the one that matches the cause, state it as a number, and say what it buys. A brief with no ask is a complaint with figures. A brief with three asks is a wish list, and wish lists get the cheapest item.

Time is the ask for the dig-out: "two technicians protected from project work and meetings between one and four every afternoon for ten working days, with you as the person who says no to interruptions in those hours". It is cheap, it is specific, and it has a date on which it ends, which is why it is usually granted. Say what it buys: "we expect to take the over-ninety count from 280 to under 60 and to close or re-triage every request older than a quarter with a reply to each requester".

A decision is the ask for a cluster or a rule: "approval to close the 71 requests about the old warehouse scanning application, each with a message inviting the requester to come back". Or it might be "agreement that requests waiting on the requester for ten working days without a reply are closed with a message". Decisions cost nothing and managers like making them, provided the risk is stated. State it: "we expect about one in ten to come back, and we will answer those within two working days".

Capacity is the ask for hours or a person, and it is the one that needs the envelope. "We can close about 130 requests a week with the time we have; we receive 150. The gap is 20 a week. Removing the top five repeat requests with knowledge articles and one process fix would close about half of it at no cost. The other half is either four hours a week moved off project work, or a longer agreed response time for low-priority requests, or, in time, a fourth person." Three options with their costs, in a sentence each, and a recommendation. A manager given three costed options chooses one. A manager given "we need another person" says "not this year" and the conversation is over for twelve months.

Always include the cost of doing nothing, in one sentence, without drama. "If nothing changes, the backlog returns to its current size in about a year and the oldest requests will again be over twelve months old." It is not a threat. It is the forecast from the gap. A manager who later asks "why didn't you warn us?" should be able to be shown the line. (They will not ask. The line is why.)

Writing the Page

The page has six short sections in a fixed order. They are the headline numbers, the cause, what the desk is doing now, and what we need. Then come what happens if nothing changes, and when the next update arrives. The whole thing fits on one side, in plain sentences, with the numbers in bold or in a short table and nothing else formatted. No charts unless one chart does the whole job, in which case created-versus-solved with the gap shaded is the one. No screenshots of the tool. No appendix. If a manager wants the detail, the inventory table exists and can follow. The brief is the page they read in the car park.

Write it in the plainest verbs you have. Requests arrive, wait, are answered, are closed. The desk receives, closes, chases, needs. Avoid "leverage", "bandwidth", "resourcing", "going forward", and any sentence beginning "unfortunately" or "due to". Avoid adjectives entirely, because "significant backlog" tells the reader you have an opinion about the number. And "280 requests over ninety days" tells them the number. A page with no adjectives reads as calm, and calm is persuasive in a document about a problem.

Here is the first section of the brief Imogen sent, from Lindholm Timber, a timber merchant with a desk of three. "The desk has 412 open requests today, about two and a half weeks' worth; three months ago it had 95. 280 of them are older than ninety days, including 40 from finance and 31 from the yard. The oldest is a monitor request from fourteen months ago; the requester has since changed roles twice. We receive about ten more requests a week than we close and have done for roughly a year. With the time we currently have on requests, we can close about 150 a week against 160 arriving." Five sentences, five numbers, one example, no adjectives. The director replied within the hour, which had never happened to a backlog e-mail before.

Read the finished page as the director's director would, because that is who it is for. Does the first line say how bad it is? Can every number be defended with a sheet? Is there a sentence anyone could call blame? Is the ask one thing with a cost? Would the page survive being forwarded with the comment "did you know about this?". If it would, send it. If it would not, the usual fix is to cut it, not to add to it. Every sentence that is not a number, a cause, an action or an ask is a sentence that makes the page longer and the reader less sure.

The Conversation After the Page

The brief produces a conversation. The conversation has about five questions in it, every time, and it is worth having the answers ready. The first is "why didn't we know about this sooner?" The honest answer is the one from the measurement article. The monthly report counted what was closed and not what was open. The desk has changed the report so it does both. Say that, without defending the old report. The question is fair.

The second is "can't the team just work harder for a few weeks?" The answer is that they will, in the protected blocks, and that the protection is the ask. Unprotected extra effort was tried, in the spring, and moved the count by eleven. Then move to the arithmetic. The gap is structural, and a fortnight of effort clears the pile but does not close the gap. That is why the brief asks for the rule change or the inflow work as well. Do not accept "work harder" as the whole answer, kindly, with the envelope.

The third is "how do we know it won't happen again?" The answer is the weekly check and the monthly four numbers from Keeping the Backlog From Rebuilding. You will see the over-thirty count and the gap every month, and a red threshold reaches you the week it is crossed. That is an answer a manager can hold the desk to, which is exactly why it works. The fourth is "what is the risk if we do nothing?" The brief already has the sentence. The fifth is "what are the other departments going to say?" The answer is the bankruptcy message and the organisation-wide note, both already written. The manager will want to see those, and should.

Expect one question you did not prepare for, usually about a specific ticket the manager has heard about. Answer it by looking it up rather than from memory. A brief that was built from real sheets survives that question. One built from impressions does not, and the manager will know within a sentence which kind they have.

Reporting During and After

During the dig-out, management gets one number every Friday afternoon, by e-mail, in one line: "Over-ninety count: 280 on Monday, 162 today; on plan for under 60 by next Friday." No commentary, no chart, no explanation unless the number is off plan, in which case one more sentence says why and what changed. The Friday line teaches the manager the shape of the fortnight and makes the final number unsurprising, which is the point. A fortnight with no update and then a final report is a fortnight in which the manager wondered, and wondering is where confidence leaks.

After the dig-out, the brief is written again as an after-page, in the same six sections, with before and after beside each number. 412 to 118. 280 over ninety to 11, each with an owner and a date. Oldest ticket 420 days to 38 days. Gap unchanged at ten a week, which is the sentence that leads into the ask that matters, because the dig-out did not touch it. This is the page that gets the inflow work approved, or the hours moved, or the longer response time agreed for low-priority requests. It is delivered on the back of a visible success. It says plainly that the success will not last without the next step.

Then monthly: four numbers in one paragraph on the first working day, the same shape every month, as described in the previous article. The brief is a one-time document. The monthly paragraph is its descendant, and its job is to make sure the brief never has to be written twice. Where the desk has made promises about response times, the monthly paragraph is also where those are reported against. Promising only what the desk can actually keep is the subject of What to Promise and What Never to Promise. A backlog brief that promises a response time the capacity envelope cannot support has just written next year's brief.

Mistakes That Cost Credibility

The table below lists the mistakes that cost the most, from briefs I have written or been handed. Each one feels reasonable while it is being made, which is why they are listed with the reason they backfire and the sentence to write instead. The common thread is that each one asks the reader to trust the desk's judgement instead of showing them the number.

Rounding down deserves a second warning, because it is the one that feels most harmless. Four hundred and twelve becomes "around four hundred". That becomes "a few hundred" in the manager's retelling. It becomes "a couple of hundred" by the time it reaches the board. When the real number surfaces the desk is the one who said "a couple of hundred". Say 412. Numbers that are exact are repeated exactly.

A Short War Story: The Twenty-Two Slides at Stonebridge Insurance

Stonebridge Insurance's desk, five technicians for a regional insurer, had about 900 open tickets and a request in for a sixth person. Declan, the desk manager, was given twenty minutes with the operations director to make the case. He brought twenty-two slides. They included screenshots of the ticketing tool, the SLA compliance figures by priority, and a chart of monthly closed counts. There were three slides on the tool's reporting limits, and a staffing comparison with "industry norms" he had found somewhere. The director listened to slide nine, then asked a single question: "How many of the nine hundred are more than three months old?" Nobody in the room knew. The meeting ended with "come back when you do". In that organisation that meant the next budget round, six months away. The desk spent those six months with five people and a growing pile. The sixth person was approved only after Declan sent a one-page brief. It opened with "612 of our 940 open requests are older than ninety days, including 88 from claims", followed by the gap, the envelope and one ask. The cost was six months without the hire and a deck that twenty-one slides of nobody ever saw. The lesson Declan now gives other desk managers is that the one number the director will ask for is the one you must already know. It is never on a screenshot.

The one-page brief took him forty minutes to write. He had spent two days on the slides.

The Backlog Brief

The brief below is the six sections on one page. Fill it in from the measurement sheet and the inventory table. Keep the sentences. Cut anything that is not a number, a cause, an action or an ask. Read it once as the reader's own manager before sending. It is plain text so it can go in the body of an e-mail, where it will be read, rather than as an attachment, where it will not.

BACKLOG BRIEF — ONE PAGE
Desk: __________________  Date: ______________  Prepared by: ____________
For: ______________________

1. WHERE WE ARE
  Open requests today: ____  (about ____ weeks of requests; three months ago: ____)
  Older than 90 days: ____   including ____ from ______________ and ____ from ______________
  Oldest request: ____ days; ________________________________ (five words)
  Requests arriving per week: ____   Requests closed per week: ____   Gap: ____
  What we can close per week with current time on requests: about ____

2. WHAT CAUSED IT (two to four sentences, no names)
  Our part: ____________________________________________________________
  The organisation's part, as a fact: __________________________________
  ______________________________________________________________________

3. WHAT WE ARE DOING NOW
  A two-week dig-out from ________ to ________: protected afternoons,
  oldest and abandoned requests first, a reply to every requester.
  Expected result by ________: older-than-90 count from ____ to under ____.
  Closing old abandoned requests with a message on ________; about one in
  ten expected to come back, answered within ____ working days.

4. WHAT WE NEED (one ask)
  [ ] Time: ____ people protected ____:__ to ____:__ for ____ working days;
      you as the person who declines interruptions in those hours
  [ ] A decision: ______________________________________________________
  [ ] Capacity: the gap of ____ a week closed by
      (a) ____________________________ at no cost, worth about ____ a week
      (b) ____________________________ costing ____, worth about ____ a week
      (c) ____________________________ costing ____, worth about ____ a week
      Recommended: ____

5. IF NOTHING CHANGES
  At the current gap the backlog returns to ____ in about ____ months and
  the oldest requests will again be over ____ months old.

6. NEXT UPDATE
  One line every Friday during the dig-out; four numbers on the first
  working day of each month after it; the same day you will hear about
  any threshold that is crossed.

A desk of one fills in the same page and will find section 4 the hardest to write honestly. The capacity envelope for one person is short and the asks are large. Write it anyway, because a solo desk that never writes the page is the one whose backlog is discovered by the director personally. A desk with several departments writes one page with a line per department in section 1 and a shared cause and ask, unless the departments really are different problems. In that case, two pages beat one muddled one.

Imogen's page went at 09:20 on the Friday, fourteen hours after the e-mail that asked for it. That was long enough to count and not long enough to be chased. The director's Monday meeting had the number in it before anyone else could supply one. The dig-out blocks were approved by Tuesday. The closing rule for abandoned requests was agreed in the same conversation. It was on the page as a decision with its risk beside it. None of that happened because the page was clever. It happened because it was one page, it started with the worst number, and nobody who read it was surprised by anything afterwards. That is the entire art. The rest is counting.

Frequently Asked Questions