The Training-Gap Signal: When the Queue Is Teaching a Class

Thursday, 14:10, at Northgate Retail. Marcus is explaining, for the fourth time today, how to process a refund on the new tills. Open the sale, choose the line, choose the reason, confirm, and wait for the receipt before closing the drawer. Each call has come from a different store, and each caller has been polite and slightly embarrassed. Each ticket has been closed in nine minutes with the note "talked through refund steps". The tills went in three weeks ago. The training was a seven-minute video sent to the store managers by e-mail on the morning of the switch, with the subject line "FYI". The desk has become the training department for eleven stores, one phone call at a time, and nobody has told the desk that this is its new job.

A training-gap signal is a run of tickets in which nothing is broken, the question is "how do I", and the answer is the same every time. The system works. The person has not been shown. Each ticket is pleasant, short and cheap, which is why the signal is the easiest of the five in this series to miss. No one ticket is a problem, and the pile is a course the desk is teaching without a syllabus. This article is part of our Ticket Data as Organisational Intelligence series. It is about seeing that pile, proving it in hours, and offering the team's manager a way to end it that they will say yes to.

It starts with why how-do-I is not a fault, the three shapes the gap takes, and reading it in the queue. Then come the evidence a manager will accept, the offer rather than the verdict, and why the desk should not simply keep answering. Next is measuring whether the fix worked. A short war story and the training-gap brief to copy finish the article.

How-Do-I Is Not a Fault

A how-do-I ticket is one in which the requester wants to do something the system already does and does not know the steps. It is distinct from a fault, where the system does not do the thing, and from a request, where the requester wants something they do not have. The distinction matters because the three have different owners. A fault belongs to the desk or the vendor, a request to a process, and a how-do-I to whoever was supposed to teach the person. That is nearly always a manager outside IT and nearly never the desk.

How-do-I tickets are not the requester's fault, and the desk that forgets this will write a brief that reads as an insult. Nobody chooses not to know how the refund screen works. They were handed a till and a link, on a Monday, in a store with a queue at the counter. They did what anyone would do: they phoned the number that answers. The desk's tone towards the caller is the same as for any ticket, warm and quick. The desk's tone in the brief is the same: the team was not trained, and here is how we can help. A training gap is a finding about an organisation that did not schedule something. It is never a finding about the people who were not scheduled.

The pile is worth reading precisely because each ticket is so small. A fault that costs an hour gets noticed. Forty questions that cost ten minutes each cost more than six of those faults, arrive spread across three weeks and eleven callers, and never register as anything but a pleasant afternoon. A desk that only reads its big tickets will never see its biggest pile.

The Three Shapes

The first shape is the same how-do-I from one team. One department does the task, and the department's own knowledge of it lives in one person. The task reaches the desk whenever that person is away, busy or gone. Expenses claims, a stock adjustment, a particular report, a month-end export. The tell is that the question comes from one team and concerns one task. The desk's answer is a procedure the desk itself learned from a ticket two years ago. The desk is holding the team's own process knowledge, which is a strange place for it to live.

The second shape is the new system nobody was trained on. A rollout, often by another department and sometimes by the desk, whose training was a video, a slide deck or a line in an e-mail. How-do-I rises in the week after go-live, which is expected, and then does not fall, which is not. The tell is the date: the pile starts on launch day and the questions are the same five tasks, repeated by each person as they first meet each task. (The rollout plan had a line that said "training: complete". It was referring to the e-mail.)

The third shape is the starter wave, the five questions every new person asks in their first week. Where the shared drive is, how to book a room, how to set up the phone. How to log a ticket, how to find the one system their job needs. Each starter asks them once; the desk answers them once per starter, forever. The tell is the requester's start date, within a fortnight of the ticket. The week-one guide and the first-week routine that absorb most of this are in First-Week Support for New Starters. The starter wave is only in this article because its tickets are how-do-I tickets and read the same way.

Reading It in the Queue

How-do-I is read from wording first and from the resolution second. Search subject lines and first messages for "how do I", "how can I", "where is", "where do I", "is it possible to", "can you show me" and "what's the process for". Then read a sample of resolution notes. A how-do-I resolution explains rather than changes, so the note says "talked them through" or "sent the steps" and the desk altered nothing. A ticket that matches on both is a how-do-I, whatever it was categorised as at open, which was probably "other". Tagging the type at close, as Categorize at Close, Not Just at Open describes, makes next quarter's reading a filter instead of a search.

Then cut the how-do-I pile three ways: by team, by system, and by task. Team and system are columns. Task is a reading: open the tickets and write a short task name beside each, "refund", "end-of-day cash-up", "void a line". Keep going until the names repeat, which they will quickly. The result is a small table of tasks with a count against each, and that table is the whole finding. Five tasks will usually account for most of the pile, and two of the five for most of those. The training gap is not "the till". It is "refunds and cash-up", and a manager can do something about two tasks.

Normalise before concluding. Forty how-do-I tickets from a team of sixty in the week after a rollout is a rollout. Forty from a team of eight over a quarter about a system that has not changed is a gap. The signal-or-noise tests in What the Queue Already Knows About the Company apply here as everywhere: it repeats, it clusters on a team or a task, and it survives a per-head check. A how-do-I pile that fails those tests goes on the watch list and gets a knowledge base article anyway, because an article costs twenty minutes and is never wasted.

The Evidence a Manager Will Accept

A manager will accept four things: the task table, the count per head, the hours, and three example tickets with the names removed. The task table says what the team cannot do. The count per head says it is the team and not one person. "Thirty-eight tickets across eleven stores" is a gap. "Thirty-eight tickets from one store" is a conversation of a different kind that the desk does not have. The hours say why it matters to the manager rather than to IT. The examples make it real. The brief at the end of this article carries exactly these and nothing else.

The hours are counted on both sides and the team's side comes first. At Northgate, the three weeks after the till switch produced thirty-eight how-do-I tickets about the tills from eleven stores, on five distinct tasks. Refunds and end-of-day cash-up accounted for twenty-nine. Each call took the desk about ten minutes and the store about the same, with a customer waiting at the counter for the refund calls. That is roughly twelve to fourteen hours in three weeks, half of it store time with a customer in front of it, for two tasks that a one-page guide covers. The hours that were not counted were the refunds done wrong by people who did not phone, which finance found at the month-end reconciliation. The brief said that those existed and could not be counted. A manager believes a desk that says what it cannot count.

Notice the last row. Not every how-do-I is a training gap. Some are tasks the requester should never have had to know, and the right answer is for the desk to do them or automate them. The table is where that distinction is made, before the brief is written, so that the manager is asked to train on the things that are theirs and nothing else.

The Offer, Not the Verdict

The brief is an offer. "Your team was not given training on refunds and cash-up when the tills changed, and we can help" is a sentence a store operations manager can accept in front of colleagues. "Your stores don't know how to use the tills" is the same fact and will be defended against for a month. The difference is not tact for its own sake; it is that the manager owns the training and the desk owns the material. The brief has to leave both of those where they belong. The desk can write the guide. It cannot make anyone read it, and should not try.

Offer four things, in rising order of cost, and let the manager choose. A one-page guide in the knowledge base, which the desk writes from its own resolution notes in an hour. The craft of a guide that can actually be followed is in The Anatomy of a Followable Article. A short video of the task, under two minutes, for the tasks that are easier to watch than to read, which The Ninety-Second Video shows how to make cheaply. A session: fifteen or thirty minutes at the team's own meeting, run by the desk, covering the two tasks from the top of the table and nothing else. And a change to onboarding, so that the task is on the starter checklist and the guide is in the welcome pack. This is the only one of the four that stops the next starter wave. If you run QuerySolv, a knowledge base article can be visible to everyone rather than only to the desk. Then the reply to the next how-do-I is a link and the guide is already where the requester was looking.

Let the manager pick the cheapest thing that might work and count again. Most pick the guide and the session. Some pick only the guide, and the count will say whether that was enough. The manager who picks nothing has still been told, politely, with a count. The count will be in the quarterly review with the status "offered". What to do then is the subject of Taking the Signal to the Owner Without Making an Enemy. The desk's job was the offer. Teaching the team is theirs, and a desk that tries to do it for them will be the training department permanently.

Why Not Just Keep Answering

The honest objection is that the tickets are easy, the callers are grateful, and a desk that answers forty quick questions is a desk that people like. All true, and the desk should keep answering every one that arrives. The problem is what answering alone does to the organisation. The knowledge stays on the desk, so the team is dependent on it. The team never develops the one person who knows, so the desk becomes that person for every team in the building. A desk of three cannot be the institutional memory of two hundred people, and will find that out on the first day two of the three are off.

The hours also compound in a way that is invisible from inside any one week. Twelve hours in three weeks is a nuisance. The same gap left for a year is somewhere between a hundred and fifty and two hundred hours of combined desk and store time. That is a month of a person, spent explaining the same two screens to people who would have been glad of a one-page guide. And the uncounted cost is the larger one: the people who did not phone and did the task wrong, which the desk never sees and finance eventually does. A desk that only keeps answering is choosing the most expensive form of training there is, on behalf of a manager who was never asked.

There is a quieter reason too. Each how-do-I ticket is a person admitting, to a stranger, that they do not know how to do their job. Most people would rather read a guide at the till than phone IT with a customer watching. The guide is kinder as well as cheaper. The ticket was never the help they wanted. It was the help they could find.

Measuring Whether It Worked

Count the same pile again a month after the guide, the session or the checklist change: how-do-I tickets, same team, same tasks, per head. Expect it to fall and not to vanish. New starters will still ask until the task is on their checklist. The one task that is genuinely confusing will still produce a trickle. A small residue of people will always prefer to phone, which is fine. A fall from twenty-nine to a handful on the two top tasks is a result. Report it to the manager either way, with thanks if it worked and without comment if it did not. Let the count carry the message.

Keep the task table as the standing record and add a column each quarter. Over a year it becomes a history of what the organisation taught itself with the desk's help, and a list of the tasks that still need teaching. That is useful to the manager, to HR and to the next rollout's plan. It is also, read the other way, a list of systems that are harder to use than they should be. A task that stays on the table after a guide, a session and a checklist is sometimes a bad-tool signal in disguise. The next article in this series takes it from there.

A Short War Story: The Claims System at Stonebridge Insurance

Stonebridge Insurance replaced its claims system in the spring. The project plan's training line said that the six team leads would be trained by the vendor and would cascade to the forty claims handlers before go-live. The team leads were trained, and then go-live was brought forward two weeks. The cascade became a shared document that four of the six leads had not had time to read themselves. In the two months after go-live the desk closed a hundred and forty how-do-I tickets about the new system. Each took Ingrid or one of her two technicians about a quarter of an hour, and the claims handlers at least as long. That was roughly seventy hours on each side, on nine distinct tasks of which three made up two thirds. Ingrid wrote the task table and took it to the claims manager with three example tickets. She offered six one-page guides and two half-hour sessions at the handlers' own weekly meeting. The claims manager, who had believed the cascade had happened, took both. The following two months produced eleven how-do-I tickets about the system, seven of them from two new starters. The six guides went into the starter pack. Training that is delegated to a cascade is training nobody has scheduled, and the queue had been the schedule.

The Training-Gap Brief

The brief below is one page, addressed to the manager of the team rather than to IT. It is built so that the first thing the manager reads is their own team's time and the last thing is a choice. Fill the task table from the reading, strip every requester's name, and state what cannot be counted. Offer the four options with the desk's cost beside each so that the manager can see that saying yes costs them very little. Keep the tone of the offer in the title; the brief is called a gap, not a failure, and it says so.

TRAINING-GAP BRIEF — ONE PAGE
To (role): ______________________   From: ______________________   Date: ____________

1. WHAT WE ARE SEEING
   Team: ______________________   System or process: ______________________
   Since (rollout date / start of period): ____________
   How-do-I tickets in the period: ______   People asking: ______ of ______ in the team
   Nothing is broken; the system works and the steps have not been shown.

2. THE TASKS (from the tickets; most common first)
   Task ____________________  tickets ____   Task ____________________  tickets ____
   Task ____________________  tickets ____   Task ____________________  tickets ____
   Tasks the desk should do instead of teaching: ____________________

3. WHAT IT COSTS
   Your team's time: ____ to ____ hours in the period (____ minutes per question)
   The desk's time:  ____ to ____ hours in the period
   Not counted: tasks done wrong by people who did not ask

4. WHAT WE CAN OFFER (choose any; desk cost beside each)
   [ ] A one-page guide per task in the knowledge base ........ desk: ____ hours
   [ ] A short video of the top task or two ..................... desk: ____ hours
   [ ] A session at your team meeting, ____ minutes, top tasks only .. desk: ____ hours
   [ ] The guides added to your starter checklist ............... desk: ____ hours

5. THREE EXAMPLE TICKETS, NAMES REMOVED
   #______   #______   #______

6. WHAT HAPPENS NEXT
   We will count the same tasks again on ____________ and send you the result either way.

Marcus sent the Northgate brief to the store operations manager on the Friday with the two guides already written. An offer with the guide attached is easier to say yes to than an offer to write one. The reply asked for the ten-minute walk-through at the next managers' call and for the guides to be printed and taped beside every till. The desk had not thought of printing the guides and taping them beside every till. That worked better than the knowledge base did. A month later the two top tasks had produced five tickets between them, three from a store that had opened that week. The desk still answered those in nine minutes each. It had simply stopped being the only place the answer lived.

Frequently Asked Questions