Writing a Help Desk War Story Well, in Five Parts

Wednesday, 12:15, at Meridian Parts. Priya asked Daniel on Monday to write up "the forklift one" for the stories page, because he closed it and because he tells it well. What arrives is nine hundred words. It opens with the twist, so there is nothing to wait for. It names the warehouse supervisor in full, with her job title and the fact that she "insisted" the scanner cradle was faulty. It has no lesson that anyone could say in a sentence, and it ends with "LOL". Priya reads it twice and says "this is a good story and a bad write-up". Priya draws five boxes on a notepad: the ticket, the twist, the fix, the lesson, the laugh. "In that order. Two hundred words. And she's the one who found the pattern, so write it that way."

Writing a war story well means putting five parts in a fixed order, at a fixed length. The person who asked for help is the hero or the bystander, and the lesson is in one sentence at the end. It is a small craft with a few rules. And the rules exist because a story written badly teaches the wrong thing or hurts somebody, and sometimes both. This article is part of our Helpdesk War Stories & the Ticket Hall of Fame series. Every story in it, like every story in the series, is fictional.

It covers the five parts and their order, then each part in turn: the ticket, the twist, the fix, the lesson and the laugh. Next comes anonymising properly, which is harder than removing a name, followed by the user as the hero or the bystander. We cover length and the three formats a story takes, including this library's own. Then come a worked example before and after, a short war story, and the war-story skeleton to copy.

The Five Parts, in Order

A war story has five parts, and the order is not negotiable, because the order is what makes the twist a twist. The ticket comes first, as it was worded, so the reader stands where the desk stood. The twist comes second, because that is where the desk discovered it. The fix comes third with its cost, and the lesson comes fourth in one sentence. The laugh comes last or is threaded through, aimed at the system and never at a person. A story that opens with the twist has given away the only thing the reader was going to feel. A story that ends without the lesson has been entertainment.

The picture below draws the five parts as a strip, with the plug story under them as a worked example. It starts with a monitor reported dead since Monday, a vacuum cleaner in its socket every evening, and a twenty-second fix. Then comes the lesson that the cheapest check comes first. The laugh is that two escalations and a spare monitor were spent on a plug. The fourth box is shaded because it is the part that earns the telling. If you write only one part carefully, write that one.

The Ticket: Start With What Came In

Begin with the request exactly as it arrived: the number, the time, the channel, and the words the requester used, quoted. "Ticket 3311, Tuesday 08:40, by e-mail: 'My keyboard is typing on its own, I think the computer is haunted.'" The quotation is not there to be laughed at. It is there because it is the only evidence the desk had. And the reader needs to stand in the technician's shoes with the same evidence and the same first assumption. A story that paraphrases the request into something more sensible has removed the reason the desk went wrong.

Add the desk's first move and its first assumption, briefly, because that is where the story's tension lives. "We assumed a failing keyboard and booked a replacement." The reader now knows what the desk thought and can enjoy being wrong alongside it. One or two sentences; the ticket is the setup, not the story. If the setup needs a paragraph, the story is probably about a process. A process story is a fine thing, but it has a different shape and usually a report attached.

Keep the requester's wording respectful by keeping it accurate. People describe what they see, and "haunted" is an honest word for a keyboard that types when nobody is touching it. Quoting it without comment is a courtesy to the requester and a gift to the story.

The Twist: What Was Actually Going On

The twist is the moment the real cause appeared. And it should be told as the desk found it, not as the desk understood it afterwards. "On the Thursday, the technician noticed the keyboard typed only when the person at the next desk was typing." That is a discovery, with a who and a when. It lands because the reader has been holding the same wrong assumption since the first paragraph. Resist explaining the cause before showing the clue. The clue is the story; the cause is just the answer.

A good twist is in the system, not in the person. Consider the wireless keyboard paired to the neighbouring machine, the vacuum in the socket, the chiller on the printer's circuit, and the archive job locking the licence folder. Each is a small, physical, slightly absurd fact about how things were set up. None of them is anybody's fault. If the twist you are about to write is "it turned out she had done X", stop and look for the system behind X. There almost always is one, and it is almost always the better story.

Give the twist one sentence of consequence so the reader feels the size of it. "Two keyboards had been typing into one machine for a week, and the proofreader had been correcting her neighbour's e-mails without either of them knowing." That sentence is the laugh, arriving on its own, which is how the best laughs arrive.

The Fix, and What It Cost

Say what put it right and how long it took, then say what the whole thing cost before it was put right. "Re-pairing the keyboard took four minutes. Getting there took three visits, a replacement keyboard and most of a week in which the proofreader did not trust her own machine." The fix is usually small, and the smallness is the point. The cost is what makes the lesson land, because a lesson without a cost is advice, and advice is cheap.

Count the cost in hours and in waiting, never in money, and never in a way that could be read as a bill for the requester. Three visits is a cost to the desk. A week of a proofreader second-guessing her keyboard is a cost to the requester and to the people whose work she was checking. Both go in the story, and both point at the desk's method rather than at the person who raised the ticket. The articles on the cost of waiting cover the arithmetic for a report; the story needs only one honest sentence of it.

Include the small, permanent change the desk made afterwards, if there was one. "The desk added 'is anything wireless nearby?' to its keyboard questions." That line turns a story about one ticket into a story about a desk that learns. It is the line a new technician will remember when a keyboard next types on its own.

The Lesson, in One Sentence

The lesson is one sentence, it names a rule, and it points at where the rule lives. "Ask what else is near the desk before you replace anything, which is the question that pays in the diagnostic order." That is the whole requirement, and it is harder than it looks. Most stories have two or three possible lessons, and the writer has to choose. Choose the one the desk most needs to hear this year. If the second lesson is also worth keeping, write a second story; a story with two lessons teaches neither.

The sentence test is strict on purpose. If the lesson cannot be said in one sentence, the writer has not found it yet. A story published without its lesson is a story that will be retold for the laugh alone. In this library the sentence links to the article that owns the rule. On a working desk it names the runbook, the knowledge base article or the line in the standards page. The story is the memorable form of the rule, and the rule has to be somewhere the story can send people.

Put the lesson last, or last before the laugh. A story that states the lesson first is a lecture with an illustration. And a reader who has been told the moral before the story will not feel the twist. Let them be wrong with the desk, see the cause, and feel the cost. Then tell them in one sentence what to do about it. That is the order in which people change their minds.

The Laugh, Aimed at the System

The laugh is the gap between the effort and the cause. And it is almost always already in the story by the time the twist is written. Two escalations and a van for a plug. Three visits and a new keyboard for a pairing button. A rebuilt server and a vendor case for a service that needed restarting after the archive job. The writer's job is to let the gap show, in plain words, with no exclamation mark and no nudge. Understatement does the work: "the spare monitor returned to the stores having been out for forty minutes" is funnier than any sentence that tries to be.

The laugh is at the system, the process, the tool, the escalation chain, the eleven-page policy, or the desk itself. It is never at the person who asked for help or the junior who was sent. A good test is to imagine the requester reading the story aloud at the desk: if they would laugh, the laugh is in the right place. If they would go quiet, it is in the wrong one. Self-deprecation is the safest form. A senior technician who writes "I drove forty minutes to press a switch" has taught more than one who writes about someone else's mistake.

Not every story has a laugh, and a story should never be forced to find one. The story of the leaver's account that kept accepting meeting invitations is mildly funny. The story of the backup that had not run for a month is not. And a writer who tries to make it funny has made it worse. The lesson is the requirement. The laugh is the bonus, and bonuses are not owed.

Anonymising Properly

Anonymising a story means removing everything that would let three people in the building identify the person in it. That is a longer list than the name. The four identifiers are the name, the combination of role and department, the date, and the unique detail. Removing the name alone is a gesture. "A manager in the finance team" identifies the person if there is one. "The week of the audit" identifies the week. And "the one who always has the window open" identifies the person faster than a surname would. Replace each, do not just delete it, so the story still reads as a story.

The unique detail is the hard one, because it is often the detail that makes the story good. Take the mug on the drive tray, the heater on the power strip, and the proofreader correcting her neighbour's e-mails. Each is a true thing that only one person did. Keep the detail and change the surroundings, so that the mug stays and the department, the floor and the month go. If the detail alone identifies the person, which happens, the story cannot be told outside the desk without their agreement. The article the stories the community tells sets out what that agreement has to cover.

Inside the desk, the rules relax a little, because everyone at the desk saw the ticket, and the story is being told by the people who were there. Even so, write the page version as if it will be read by a stranger, because one day it will be. That could be a new starter, an auditor, or a manager looking for something else. The discipline is the same one that governs what not to write in a ticket. It allows nothing about a person that you would not say to them, and nothing a stranger could misuse.

The User as the Hero or the Bystander

Every story has a version in which the requester is the fool and a version in which they are the hero or the bystander. And the second is always available because it is the true one. The proofreader who reported a haunted keyboard reported exactly what she observed, in the first hour. She later noticed the pattern that the desk had missed on two visits. Written as the butt of the story she is a person who believes in ghosts. Written as the hero she is the person who solved the case. The facts are identical; the choice of sentence is the whole difference.

The rewrite is usually mechanical, and it goes in the ticket or the twist. "She insisted the cradle was faulty" becomes "she had noticed it failed only in the afternoons, and said so". "He couldn't even check the plug" becomes "he reported a dead monitor, which it was, and we sent a van before anyone checked the socket". The desk's part becomes visible, the requester's part becomes accurate, and the laugh survives, because the laugh was about the van. The desk-side version of this habit is patience without condescension. And a desk that writes its stories this way finds its replies are written this way too.

Where a requester genuinely helped, say so by name only with their consent, and otherwise say so by role. "The warehouse supervisor had been logging the failure times for a fortnight before anyone asked her" is a sentence that teaches two lessons. Those lessons are that users notice patterns, and that the desk should ask. A desk whose stories regularly feature a requester doing something clever is a desk whose requesters will keep talking to it.

Length, and the Three Formats

A war story has three lengths, and each has a job. The spoken version is forty to sixty seconds, told at the huddle or at the next desk, and it is where most stories live. The written version for the stories page or the hall-of-fame card is one hundred and fifty to two hundred and fifty words. It has five parts, one paragraph or two. The talk version, for an all-hands or a user group, is two to three minutes with a pause before the twist. It belongs to the last article in this series. Nothing in the first two formats is longer than a paragraph, and the nine-hundred-word draft is, with affection, a report.

This library uses a compressed form of the written version. 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 concrete cost and the lesson in the last line, linked to the article that owns it. It is the five parts with the laugh left to find its own way in. And it is deliberately short so that the lesson is the last thing read. The one lower down this page follows the format, as the format requires.

The raw material for the written version is the note the technician wrote at the time, which is why the working-note habit pays twice. If you run QuerySolv, internal notes on a ticket are kept apart from the public replies the requester sees. That means the note at the time can be candid about what the desk assumed and when it noticed. The story can be drawn from it a month later without anyone having to remember. In any tool, the story written from the note is more honest than the story written from memory. Memory tidies up the part where the desk was wrong.

A Worked Example, Before and After

Here is a draft of the kind Priya received, for a story at Greyfriars Press, a publisher, where the people and the firm are invented. "So Joanna in proofreading (the one who always has the radio on) was convinced her computer was haunted LOL. Typing by itself!! Turned out she'd been using a wireless keyboard that was actually paired to Mark's machine next to her, so every time he typed it came up on hers too. We'd already replaced her keyboard once. Classic." It has the twist in the second sentence, an identifying detail in the first, a requester who is the butt, no cost, no lesson, and two exclamation marks that were not needed.

The same story in five parts. Ticket 3311 arrived by e-mail on a Tuesday at 08:40 from the proofreading desk: "My keyboard is typing on its own, I think the computer is haunted." The desk assumed a failing keyboard, replaced it the same day, and closed the ticket; it was reopened on Thursday with "still doing it, and only in the afternoons". On the second visit the technician noticed the stray characters appeared only while the person at the next desk was typing, and found that the original wireless keyboard, now in a drawer, was paired to the neighbour's machine, which had been receiving two keyboards' worth of typing for a week. Re-pairing it took four minutes; getting there had taken two visits, a replacement keyboard and most of a week in which a proofreader had stopped trusting her own machine, while she, not the desk, had spotted the afternoon pattern that solved it. The lesson is to ask what else is near the desk, including anything wireless, before replacing anything, which is the question that pays in the diagnostic order.

It is two hundred words, with the requester as the one who found the clue, the radio gone, and the exclamation marks gone. There is a laugh that nobody had to write because a machine receiving two keyboards' typing for a week is funny on its own. The draft was a good story badly told. The rewrite is the same story, told in the order the desk lived it.

A Short War Story: The Story With Her Name in It at Silverline Travel

Silverline Travel's desk started a stories page with the best of intentions and put the cup-holder story on it first, written by a technician called Owen, who named the booking agent, Lucy, by first name and team, and described her as "convinced the shelf was for her tea". The page was visible to anyone with a staff sign-in, a colleague in bookings found it within a week and showed Lucy, and Lucy, who had reported the broken tray within a minute of breaking it and had apologised twice, read herself described as the joke. She did not complain; she simply stopped raising tickets, and so, over the following month, did the six people who sat around her, who took their problems to a cousin of one of them who "knew computers". The desk found out two months later from the volume report, which showed the bookings team raising a third of what its size predicted, and from the cousin, who had by then reconfigured a shared mailbox in a way that took a morning to undo. Owen rewrote the story with Lucy's agreement, with the tray at knee height as the villain and her one-minute report as the hero's part, and the desk added a rule that nothing goes on the page with a requester identifiable in it. A story with a person recognisable in it has not been anonymised, and the person who asked for help is never the butt; the rule is in why war stories matter to a help desk.

The War-Story Skeleton

The skeleton below is the written format with the blanks in the order they are filled. Fill the ticket line from the ticket itself, not from memory. Write the twist as the moment of discovery, and count the cost in hours and waiting. Write the lesson last and make it one sentence. Then run the three checks at the bottom before the story goes anywhere. A story that fails a check is rewritten or kept in the drawer.

THE WAR-STORY SKELETON — ONE STORY, FIVE PARTS
Title (the twist, not the person): ______________________________
Ticket: ________   Date told: ________   Written by: ______________

1. THE TICKET (as it came in)
   Number, time, channel: ______________________________________
   The requester's words, quoted: "____________________________"
   The desk's first assumption: _________________________________

2. THE TWIST (as it was discovered)
   Who noticed, when, and what they noticed: _____________________
   What was really going on: ____________________________________

3. THE FIX (and what it cost)
   What put it right, and how long that took: ____________________
   What it cost before then (hours, visits, waiting): ____________
   The permanent change the desk made: __________________________

4. THE LESSON (one sentence)
   ______________________________________________________________
   Where the rule lives (runbook, article, standard): ____________

5. THE LAUGH (at the system, optional)
   The gap between the effort and the cause, in one plain sentence:
   ______________________________________________________________

CHECKS BEFORE IT LEAVES THE DRAWER
   [ ] The requester is the hero or the bystander, never the butt
   [ ] Name, role-and-department, date and unique detail replaced
   [ ] Could three people in the building identify anyone?  No
   [ ] Under 250 words; the lesson is the last line before the laugh
   [ ] Ticket number checked against the ticket

Daniel's second draft of the forklift story was two hundred and ten words and opened with the ticket as the supervisor had worded it. It ended with the lesson that a device which fails at the same time every day is sharing something with whatever else happens at that time. The supervisor, who had been logging the failure times for a fortnight before anyone asked, was the hero of it. When Priya showed her the write-up, the supervisor asked for a copy. That is the test a written story should pass. The person in it wants to keep it.

Frequently Asked Questions