Why War Stories Matter to a Help Desk, and Their One Rule
Monday, 09:20, at Northgate Retail. Leah is in her second week on the desk and has just claimed ticket 4418, which reads, in full, "Till 3 at Harbor Street dead again, please send someone." She reaches for the phone to book a van. Priya, at the next desk, does not look up from her screen. "Ask them if the night cleaner has been in." Leah asks why, and Priya gives her forty seconds. It was the flagship store, two winters ago, with a till that died every Monday and worked every Tuesday. A technician was sent with a spare. The floor polisher lived in the till's socket from Sunday night until the cleaner put it away. Leah phones the store. The floor polisher is in the till's socket. The till is working by 09:26. Leah has learned a rule, the cheapest check first, that she will never need to look up. It is still written down in the diagnostic order.
A war story is a short account of a ticket that went somewhere unexpected, told after the fact, for the lesson in it and the laugh that makes the lesson stick. It is not a complaint, not gossip and not an incident review. It is the desk's own folk memory, passed from one technician to the next at the moment it is needed. This article is part of our Helpdesk War Stories & the Ticket Hall of Fame series, which is about keeping those stories, telling them well, and building a small ritual around them. One thing to say before anything else: every story in this series, and every short war story in every article of this library, is fictional. The organisations are invented, and the people have first names only and never existed. If one of them sounds exactly like your desk, that is because every desk has the same stories.
It covers what a war story is and what it is not, then the story as the desk's memory, as training, and as culture. Next comes the one rule, which is that the lesson is the point and ridicule is never allowed. We cover why the user is the hero or the bystander and never the butt, then why every story here is fictional and says so. Next come where stories live on a working desk and a short war story. We finish with the five war-story rules to copy, in that order.
What a War Story Is, and What It Is Not
A war story has a shape, and the shape is what separates it from an anecdote. Something came in, worded the way the requester worded it. Something turned out to be going on that nobody expected. Something put it right, at a cost that can be named. And there is a lesson, one sentence long, which is the reason the story is still being told. The laugh, where there is one, comes from the gap between the drama of the symptom and the smallness of the cause. A monitor dead for a day, two escalations, a spare in a van, and a plug.
A war story is not a complaint about a user. "You will not believe what finance did this time" is a story with the same facts and the opposite purpose. It teaches the new technician exactly one thing, which is that this desk laughs at the people it serves. It is also not an incident review. The review of a major incident has a form, a chair, a timeline and a list of actions. And it belongs in closing the incident and the review. The war story is what survives of the review a year later. The form has been filed and the actions closed. All anyone remembers is "the night the certificate expired and nobody could get in to renew it".
The length is a tell. A war story told aloud takes thirty to sixty seconds. Written down it is a paragraph, perhaps two. If it needs longer than that, it is either two stories or a report. Both are fine things to be, but neither will be remembered on a Monday morning with a phone in one hand.
The Story as the Desk's Memory
A desk's memory lives in three places: the tickets, the documents, and the people. The tickets hold everything and are searchable, but nobody searches for what they do not know to look for. Leah had no reason to type "floor polisher" into anything. The documents, the runbooks and the knowledge base, hold the rules, but a rule is only found by someone who already suspects it applies. The people hold the stories, and the story is indexed in a way no search box can match: by the shape of the symptom. "A till that dies on Mondays" is enough to make Priya say "ask about the cleaner" before she has consciously remembered why.
That indexing is why stories survive where documentation does not. A runbook that says "check the power socket before dispatching a replacement" is correct, dull, and skipped by every technician who is sure this one is different. The story of the floor polisher is the same rule with a reason and a face attached. A technician who has heard it will check the socket while feeling slightly foolish for doing so, which is exactly the right amount of foolish. The rule tells you what to do. The story makes you do it.
The weakness of the people's memory is that people leave. A desk whose stories live only in its senior technician has a memory with a notice period. The first job of this series is to get the stories out of heads and into something that stays: a page, a board, a ritual. The later articles cover the how. The point here is that the stories are already the desk's memory, whether or not anyone has noticed. And a memory nobody has written down is one resignation from being gone.
The ticket is the story's anchor, and it should be named in every telling. If you run QuerySolv, the event history on the ticket already holds the timeline of who did what and when. That way, the story can be checked against what happened whenever someone doubts the floor polisher. In any tool, the story carries the ticket number, and the ticket carries the facts. The story is what makes anyone go and look.
The Story as Training
A new technician learns the desk's rules twice. Once is from the documents, which they read in the first week and forget. The other is from the stories, which they hear when they need them and keep. The second kind of learning is the one that changes behaviour. And it is cheaper than any course, because it happens in forty seconds at the next desk at the moment the rule is about to be broken. The articles on the new technician's first thirty days and on building troubleshooting instinct describe the structured version of that training. The stories are the unstructured version that runs alongside it. The two work best when the desk does both on purpose.
Every rule worth teaching has a story that teaches it. Cheapest check first has the plug. Ask what changed has the fridge that facilities installed on the printer's circuit. Verify before you reset has the caller who sounded exactly like the director and turned out to be the director, and was grateful later. Disable the leaver's account first has the ghost who kept accepting meeting invitations for three months. A desk that lists its ten most important rules and finds a story for each has a training set that fits on one page and installs itself in a month of huddles. The six lessons that sit behind most stories, and the article that owns each, are indexed in the lessons behind the laughs.
The story also teaches something the rule cannot, which is proportion. A rule says "check the socket". A story says "a senior technician, a spare monitor and a van were spent on a plug, and the technician in question is telling you this story, so you can imagine how he felt". The new starter learns the rule and learns that breaking it is survivable, ordinary and slightly embarrassing, which is the right emotional weight for a rule about plugs. Rules carry instructions. Stories carry the weight.
The Story as Culture
What a desk laughs at is the fastest lesson a new starter gets about what the desk values. That lesson arrives before anyone has shown them the queue. A desk that laughs at the user who put a mug on the drive tray is teaching that users are the problem. A desk that laughs at itself for sending a van before checking a socket is teaching that the system is the problem and the desk is honest about its part in it. Both desks tell the same story. Only one of them is a desk a new technician should want to join.
The most valuable story a desk owns is the one about its own mistake. Take the silent close that cost a department's trust, the backlog that reached four hundred before anyone counted it, or the migration that lost a month of notes. Told plainly, with the cost, by the people who were there, these stories do more for a desk's culture than any value written on a poster. They say that this desk tells the truth about itself, which is the only foundation on which a culture of reporting can be built. The same principle drives security without blame, where the user who reports the click in minutes is the hero and the one who hides it for days was taught to by somebody's laughter.
Culture is also what the stories leave out. A desk whose stories never feature a user doing something right has a view of users that will show in every reply it writes. Look for the stories in which the requester noticed the pattern first, reported the spill in the first minute, or asked the question that nobody on the desk had thought to ask. Those stories exist on every desk. On the good desks they get told.
The One Rule: The Lesson Is the Point
A war story is allowed exactly one purpose, which is to carry a lesson. The test of whether a story is doing that is whether the lesson can be said in one sentence after it. "Check the socket before you send the van." "Ask what changed, including who else uses the desk." "Disable the account before anything else on the leaver's checklist." If nobody at the table can state the lesson, the story is entertainment, and entertainment about the people the desk serves has a short road to contempt.
The corollary is that ridicule is never allowed, and this is not a courtesy but a mechanism. The moment a story's purpose becomes making someone look foolish, the lesson disappears, because the audience is laughing at the person instead of noticing the rule. A technician who hears "the finance director couldn't even check a plug" learns nothing about diagnostics and something about how this desk talks about directors. A technician who hears "we sent a van before anyone checked the plug" learns the diagnostic order and will remember it on Monday. The second version is also, as it happens, the true one.
State the lesson every time, and point at where the rule lives. On a working desk that is the runbook or the knowledge base article. In this library it is the article that owns the rule, which is why every story in this series ends with a sentence naming the lesson and linking it. The story is the memorable form of the rule. The rule is where the story sends you.
Remember: a war story exists to carry one lesson, stated in one sentence after it is told. The person who asked for help is the hero or the bystander and is never the butt. A story that cannot pass both tests is not told.
Why the User Is the Hero or the Bystander
In almost every war story the person who asked for help did the reasonable thing, and the expensive part was done by the system or by the desk. The finance director reported a dead monitor, which it was. The packing clerk put a mug on a tray that opened at knee height and looked like a shelf. The new starter used the password his manager gave him. None of them had the information that would have made the cheap cause visible, and the desk, which did have it, skipped the check. Told honestly, the user is a bystander to a mistake the desk made, or the hero who reported quickly and saved the day. Told dishonestly, they are the punchline, and the desk has quietly rewritten who was at fault.
There is a whole genre of support humour built on the foolish user. The desks that collect it pay for it in ways they do not connect to the jokes. The user who has heard themselves described in a corridor stops raising tickets and starts asking a colleague. The department that suspects the desk laughs at it finds its own fixer. Every "stupid user" story is a small deposit into a shadow channel. And the shadow channel is where the desk's volume quietly goes to die. The section on patience without condescension explains why the tone matters in the moment. The war story is where the tone is rehearsed when the user is not in the room.
The practical test is simple. Could the person in the story sit at the table while it was told and nod along? If yes, tell it. If they would wince, the story is about them rather than about the lesson, and it needs either a rewrite or a bin. Nobody has ever learned anything from a story that was really a grudge.
Why Every Story Here Is Fictional, and Says So
Every war story in this library is invented, and this series is where the convention is stated. The organisations are synthetic: Northgate Retail, Harbourview Clinic, Redbrook Engineering and the rest exist only in these pages. And any resemblance to a real company is because retail, clinics and engineering firms all have printers. The people have first names and no surnames. And the first names were chosen for how they read, not for anyone the authors have met. Hosts and addresses, where they appear, use example.com. The costs are plausible and the lessons are real, because the lessons are the only part that was not invented.
The reason is consent. A real story about a real person is owed a conversation with that person before it is told to anyone outside the desk. And a library read by strangers cannot have that conversation. A fictional story owes nobody anything and teaches exactly as well, because the lesson does not depend on whether the cleaner existed. Where a real story would be stronger, and sometimes it would, the price of telling it is a person's agreement. The later article on the stories the community tells sets out what that agreement has to cover.
The convention runs through the whole library, not just this series. Every article ends with a section headed "A Short War Story", in three to six sentences, past tense. It has a fictional organisation, a named person, a cost and the lesson in the last line. The articles in this series carry one too, which means that further down this page there is a war story about war stories. The format requires it, and the author has made peace with that.
Where the Stories Live on a Working Desk
Stories need a home, or they live in one person and leave with them. On most small desks there are four homes, each with a different audience and cadence, and the table below sets them out. The later articles build two of them in detail. One is the weekly huddle, where the ticket of the week is already a war story in working clothes. The other is the hall of fame, which is a board and a nomination card and ten minutes a month. The others are the induction, where a new starter hears the classics in their first week, and the page. The page is wherever the written versions are kept so that the stories survive the storyteller.
| Home | Audience | Cadence | What belongs there |
|---|---|---|---|
| The weekly huddle | The desk | Weekly, fifteen minutes | One solved ticket told in enough detail to solve the next one like it; the lesson stated aloud |
| The hall of fame | The desk, and visitors to the desk | Nominated all month, chosen monthly | The tickets worth remembering, under categories that reward the lesson rather than the volume |
| The induction | Each new starter | Once, in the first week | The classics and the desk's own mistakes, told by the people who were there, with the rule each one carries |
| The page | The desk, now and later | Updated as stories are told | The written versions, each with its ticket number and its one-sentence lesson, kept where the runbooks are kept |
Beyond the desk there is a fifth home, which is the rest of the organisation: the internal newsletter, the all-hands slot, the talk at a user group. Those are where a story does the most for the desk's reputation and where the consent rules are strictest. And they have an article of their own at the end of this series. Start with the four inside the desk. A story has to be safe at home before it travels.
A Short War Story: The Story Nobody Wrote Down at Redbrook Engineering
Redbrook Engineering's desk had one senior technician, Tomas, who had been there eleven years and knew why everything was the way it was. That included why the design team's licence service fell over on the first working morning of every month. He knew how to bring it back in four minutes by restarting it after the monthly archive job had let go of its folder. He had told the story many times, at lunch and in the pub, always to laughter. And he had never written it anywhere because it was not a ticket, it was a story. Tomas left for a job at a larger firm. Five months later the licence service fell over on a Monday morning for a new technician called Aisha, who had never heard of it. Aisha spent most of two days with the vendor's support line and a rebuilt server before someone from the design team said "oh, Tomas used to just restart it". The review counted roughly fourteen hours of Aisha's time and a morning on which twelve designers could not open their drawings. There was also a vendor case that was closed as "no fault found". The desk started a page that week, with the licence service as its first entry and the ticket number beside it. And the second entry was the story of the first entry. A story told once is a memory, and a memory that lives in one person leaves when they do. The fix is in when the expert leaves.
The Five War-Story Rules
The rules below are the whole discipline on one card. And they are meant to be pinned where the stories are told, which on most desks is above the kettle. The first two are about the lesson, the third and fourth about the people, and the fifth about where the story goes afterwards. A desk that keeps all five can tell any story it likes, including the ones about itself, and lose nothing by it.
THE FIVE WAR-STORY RULES — ONE CARD
Desk: ______________________ Owner of the stories page: ______________
1. THE LESSON IS THE POINT
Every story ends with its lesson in one sentence.
If nobody can say the lesson, the story is not told.
2. THE STORY HAS A TICKET
Every story names its ticket number.
The ticket holds the facts; the story holds the lesson.
3. THE PERSON WHO ASKED IS NEVER THE BUTT
The requester is the hero or the bystander.
Test: could they sit at the table and nod along?
4. THE DESK TELLS STORIES ABOUT ITSELF
The desk's own mistakes are told first, plainly, with the cost.
No story on this desk has a villain.
5. THE STORY IS WRITTEN DOWN
Told aloud at the huddle, then written on the page:
Ticket: ________ Told by: ________ Lesson: ______________________
Nothing leaves the desk without the consent checklist.
Leah heard the story of the floor polisher at 09:21 and used it at 09:24. By the end of her first month she had heard the other five classics and told one of them herself, badly, to a technician who started the week after her. That is the entire mechanism. The rules exist so that the mechanism keeps working after Priya leaves. They also exist so that nobody at Harbor Street store ever hears themselves described as the punchline of a story that was, from start to finish, about a plug.
Frequently Asked Questions
Is a war story just a knowledge base article told out loud?
How do I stop war stories turning into complaints about users?
Our desk is two people. Is any of this worth doing?
Should the stories name the technician who made the mistake?
What if a story is funny but has no lesson?
Why does this library say every story is fictional?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
