The phone rings at the service desk. A technician at some plant wants to know which bolt to loosen first on a gearbox cover, because the drawing in the manual does not match the unit he is standing in front of. The agent walks him through it, logs the call as resolved, and picks up the next line.
Three weeks later a different technician, at a different plant, calls about the same cover on the same model machine. Then a third call, same question, same model, a different country this time. Three tickets, three agents, three case numbers. Nobody at the desk is looking across tickets, so nobody notices that the manual has now failed three people in a row.
By the end of the quarter the desk has answered that question nine times. The page causing it has not changed, because the person who could change it has never seen more than one call at a time.
Why we build it this way
A service desk looks like it should already know this. Every call gets logged, every ticket gets a category and a resolution code, and somebody runs a report on it every quarter. It still misses the pattern, because a ticket is written up after the fact, by whoever took the call, in whatever words fit the form. The exact step, the exact unit, what the technician actually tried before calling — most of that is gone by the time it gets typed in.
The usual fix is to read the tickets more carefully: a service audit, a call to the field team, a spreadsheet somebody keeps by hand. That depends on a person noticing the repeat, remembering the earlier calls well enough to connect them, and finding the time to do it between everything else on their desk. It catches the pattern eventually — weeks or months after the ninth call, not before the tenth.
The real problem is that the signal — this step confuses people, reliably, across machines — gets generated at the exact moment someone asks for help, and then thrown away before it reaches whoever could act on it.
A service desk should not have to answer the same question nine times before anyone sees it as one problem instead of nine.
How it works, roughly
Nirdesh reads:
- The exact procedure and step a person is asking about, not the category a ticket later gets filed under.
- How often that same step draws a question, across every customer and every unit of that machine, not just the ones who happened to call in.
- What the person was actually trying to do when they asked, tied to that step.
One question, on one machine, is just an answer given on the spot. The same question, asked again on other units of the same model, is a pattern — and that is what reaches the OEM: a short, ranked list of the steps actually costing the service desk the most calls, not a transcript of every conversation that produced it. What to do with that list — rewrite the step, flag it for the next revision, or leave it as it is — stays a decision for a person on the OEM's own engineering team. Nirdesh's job stops at surfacing the pattern clearly; it does not rewrite the manual itself.
A year of that is an OEM that finds its own worst pages from a ranked list instead of a stack of unrelated tickets, and fixes them while the cost is still a handful of calls a month. What any one technician asked stays with that technician's machine, in the customer's building; what reaches the OEM is only the pattern, never who raised it.
Read about Nirdesh →