The Lessons Behind the Laughs: Six Rules Every Story Teaches
Thursday, 16:00, at Stonebridge Insurance. Hannah, who runs the desk, has a year of hall-of-fame cards spread across the meeting-room table, twenty-three of them. She is sorting them into piles for the annual retelling. She expected a dozen piles. She has six. The plug, the chiller on the printer's circuit, the forty-minute drive and the monitor turned down are one pile. The caller who sounded like the director and the password that was the word password are another. The corridor request that became a missed tender is a third. By the time the cards are sorted, every one of the year's stories is sitting under one of six lessons. Hannah has written the six on the whiteboard, where they will stay.
A lesson, in the war-story sense, is the one-sentence rule a story exists to carry. A lesson index is the short list of a desk's recurring lessons, each with the stories that teach it and the document that owns the rule. This article is about the six lessons that sit behind most of the stories in this series, and most of the stories on most desks. It is part of our Helpdesk War Stories & the Ticket Hall of Fame series. This is the last series in this library. It links the rest of the library rather than re-teaching any of it. Every lesson below is owned by an earlier article. The job here is to show which story carries which rule and send you to the owner. The stories are fictional, as the series says.
It covers why so many stories teach so few lessons. Next come the six, one section each, with the stories that carry them and the article that owns each. Then it covers the story as the memorable form of the rule and building your own lesson index from a year of cards. A short war story and the lesson index to copy follow, in that order.
Why So Many Stories Teach So Few Lessons
Stories vary because symptoms vary, and lessons repeat because the human shortcuts behind the symptoms do not. A dead monitor, a dead printer and a dead screen are three stories and one shortcut. The shortcut is assuming the expensive cause before checking the cheap one. A keyboard that types by itself, a scanner that fails on Tuesdays and a screen that is dark on Mondays are three stories. They share one unasked question: what changed. Sort a year of any desk's stories and the piles are the shortcuts. There are never many, because people take the same shortcuts under the same pressures everywhere.
Six lessons cover most desks. They are the cheapest check first, ask what changed, verify before you reset, log the hallway request, the two-minute rule, and disable first. The first three are about diagnosis and identity, and they produce the classics. The second three are about the desk's own habits, and they produce the stories a desk tells about itself. Your desk may have a seventh, and the section on building your own index says how to find it. But it is worth being suspicious of an eighth. A desk with twelve lessons has not finished sorting.
Each section below gives the lesson in one sentence, the stories that carry it, and the article that owns the rule in full. The owner is where the method lives; this article is where the stories point at it. If you only read one thing per section, read its last sentence and follow the link.
Cheapest Check First
The rule is that the checks that take seconds and cost nothing come before the checks that take an hour and cost a part. That holds whether or not the cheap check is the one you privately believe in. One story that carries it is the plug at Acme, where two escalations and a spare monitor were spent on a vacuum cleaner's socket. Another is the printer that was off at Northgate Retail, where the wall switch had gone with a new chiller. Then there is the forty-minute drive at Ashgrove Housing, where a van and most of a day were spent on a power strip's rocker switch. And there is every desk's own version, which arrives in a new technician's first month on schedule. All four are in the classics every desk has, and all four end with the same sentence.
The story adds what the rule cannot, which is the van. "Check the socket" is a line in a runbook. "We sent a van before anyone checked the socket" is a thing that happened to someone the new technician has met. The second one is the one that makes a hand reach for the phone instead of the keys. The shame-free form of the story matters too. The person who skipped the check is telling it, the requester reported what they saw, and the laugh is at the van. The lesson is that the cheapest check comes first, on the phone, before the spare and before the van. The lesson is owned by the diagnostic order.
Ask What Changed, Including Who
The rule is that a thing which worked yesterday and does not work today has had something changed near it. The first question is what, followed closely by who. One story is the monitor turned down at Harbourview Clinic, where the weekend locum had set the screen for a dim room. Another is the Tuesday scanner at Bellweather Logistics, where the loading-bay door was propped open for the recycling collection and the cradle sat in the sun. There is also the heater on the power strip. And there is the haunted keyboard at Greyfriars Press. There, the thing that had changed was a wireless keyboard in a drawer, paired to the next desk. In each, the desk looked at the device for days and at the room for a minute. The minute was the one that counted.
"Including who" is the half of the question most desks forget, and it is the half that solves the Monday-morning stories. A desk, a chair or a machine that more than one person uses has more than one person's settings. The person reporting the fault is usually not the person who made the change. That is why they cannot answer "what did you change" and can answer "who else sits here". The same question, asked of a system rather than a desk, is the first question of change management. The article what change management is for explains why a desk that records its own changes can answer it in a minute. The lesson is to ask what changed, including who, before touching the device. The lesson is owned by the diagnostic order, under the question that pays.
Verify Before You Reset
The rule is that the desk confirms who it is talking to, the same way every time, before it touches an account. Knowing a password, a job title or a manager's name proves nothing about who is on the phone. One story is the password that was the word password at Bluewater Bank, where Dana verified a caller who had just told her his password and then found eleven more accounts like his. Another is the voice that was the director, which goes like this. At Harbourview Clinic a caller at 17:55 on a Friday sounded exactly like the practice manager and was plainly in a hurry. She asked a technician called Jonah to reset her password so she could finish the week's returns. Jonah ran the verification standard anyway, step by step, while she sighed. It was the practice manager. A month later, a wave of convincing phone calls hit the clinic asking for resets in several senior names. The practice manager sent the desk a note saying she now understood why he had made her wait. The lesson is to verify every caller the same way before any reset. The lesson is owned by verifying identity before a reset.
This lesson is the one the stories must tell most carefully. That is because the story of a reset done without verification can drift into detail that helps the wrong reader. Tell the story of the technician who verified and was thanked, or of the one who verified and found the process fault behind the call. Never tell the story of how someone got past the desk, with the steps. The defender's side of every security story is the only side this library tells. The rule is in the desk's own security habits.
Log the Hallway Request
The rule is that a request made in a corridor, by message or over a shoulder becomes a ticket on the spot. The technician logs it and hands back a number. That is because a request that is not a ticket is a promise, and promises are kept by memory. The story is the corridor request at Redbrook Engineering. A design engineer called Priya stopped Aisha by the lift and asked for the plotter driver on the new workstation "when you get a sec". Aisha said yes and meant it. The request lived in her head for four days during which two outages and a leaver happened. Then the drawings for a tender could not be plotted on the morning they were due and went out as screen prints. Priya had asked once, politely, in the way the building had taught her to ask. The desk had said yes and written nothing down.
The story carries a cost the rule cannot: the tender, the morning, the engineer who had done the right thing by asking and been failed by a nod. It also carries the fix in a form people remember. The technician now says "let me log that so it doesn't get lost" while still standing by the lift. The technician sends the number before the lift arrives. The lesson is that the hallway request is logged on the spot by the technician, with a number handed back. The lesson is owned by the hallway request handled well.
Remember: a story earns its place by the lesson it carries, and every lesson has an owner. When a story is told, say the lesson in one sentence and name where the rule lives. A story with no owner for its lesson is a rule the desk has not written down yet.
The Two-Minute Rule
The rule is that an add-on at a desk-side visit may be done on the spot only if it is genuinely two minutes of work. Everything must be in hand and nothing waiting on it. Even then, it is logged as a ticket. The story is the shared calendar at Meridian Parts. Daniel, finishing a monitor swap in the sales office, was asked "while you're here, can you just add me to the regional calendar". He said yes because it sounded like a tick in a box. He spent thirty-eight minutes in a permissions tangle involving two calendars with the same name. Meanwhile, a warehouse manager waited beside a scanner that would not scan. The salesperson's request was reasonable and small. It was not two minutes, and nothing about it could have been known to be two minutes before it started.
The story teaches the limit rather than the rule, which is what makes it worth telling. Everyone agrees that a two-minute job may be done on the spot. The story is about how a two-minute job is recognised. The answer is certainty rather than hope, which the owner article sets out in a decision card. The lesson is that an add-on is done now only when it is certainly two minutes, and is logged either way. The lesson is owned by the two-minute rule and its limits.
Disable First
The rule is that when a person leaves, the desk disables their sign-in at the agreed minute before anything else on the leaver's list. Everything which destroys information happens last, after a hold. One story is the ghost in the meeting room, told at the end of this article. Another is the auto-reply at Ashgrove Housing. A housing officer's mailbox kept answering tenants for three months after she left, inviting them to call a desk phone that had been reassigned. That was because the offboarding ticket had been closed when the laptop came back and nobody had checked the account. Tenants did what the auto-reply told them. The desk had done most of the checklist and skipped the first line.
The ghost stories are funny in the telling and are the least funny in the review. That is why the lesson has to be said aloud every time rather than left to the laugh. A leaver's account that stays enabled is a door the desk forgot to lock. The story about the meeting room that kept being booked is the memorable form of a rule. An auditor will one day ask about that rule in a less amusing tone. The lesson is to disable the account first, at the agreed minute, and only then do the rest of the list. The lesson is owned by the offboarding checklist, with the reasoning in why offboarding is a security ticket first.
The Story as the Memorable Form of the Rule
A rule and a story are the same knowledge in two forms, and the desk needs both because each does something the other cannot. The rule is precise, findable and dull. It lives in a runbook or a standard and says exactly what to do. It is read by people who already suspect it applies. The story is vivid, remembered and imprecise. It lives in people and says what happened when the rule was skipped. It is recalled by people who have not yet realised the rule applies. The story gets the technician to the rule. The rule tells them what to do when they arrive.
That is why the lesson sentence after every story has to point somewhere. "Cheapest check first" told as a story makes a technician pick up the phone. The diagnostic order tells them which five questions to ask in which sequence and what to write in the ticket. A story without an owner document is a memory that cannot be looked up. A document without a story is a rule nobody will remember at 08:50 on a Monday with a queue. Pair them deliberately. Every entry in the desk's standards should have at least one story on the page. Every story on the page should name the standard it belongs to.
The pairing is also the cheapest training the desk will ever run. A new technician who reads the six rules has read a page. A new technician who has heard the six stories and been shown where each rule lives has a map of the desk's whole method. That map has a landmark at every junction. The landmarks are the part that survives a bad week. Rules are what the desk knows. Stories are how the desk remembers that it knows it.
Building Your Own Lesson Index
Build the index from the stories, not from the rulebook, because the stories tell you which rules the desk actually breaks. Take a year of hall-of-fame cards, or the stories page, or simply the ten stories the senior technician tells most often. Sort them into piles by the lesson sentence at the bottom of each. Name each pile in one sentence. Most desks get five or six piles and a couple of orphans. The orphans are usually a story with no lesson, which goes back in the drawer, or a lesson with one story. A lesson with one story waits for a second before it earns a line in the index.
Then find each pile's owner, which is the runbook, knowledge base article, standard or, if the desk uses this library, the article that owns the rule. Where a pile has no owner document, the desk has found a rule it follows by folklore alone. In that case, the right response is to write the document that week, in a page, from the stories. Where a document has no pile, the desk has found a rule nobody has a story about. That means either the rule is never broken or nobody is telling the story. It is worth asking which. If you run QuerySolv, the index itself can be a knowledge base article visible to agents only, beside the runbooks it points at. With that setup, the stories and the rules are a click apart. In any tool the index is one page, six lines, and a link per line.
Review the index once a year at the annual retelling, when the cards come down. A lesson that gained no stories in a year may have been learned, which is the best reason a line ever leaves the index. A lesson that gained five is the one the desk should be teaching in the first week. Its owner document should be read aloud at a huddle. The index is a list of the desk's weak spots, written as rules, and the stories are the evidence. Nobody has ever written a shorter honest account of a desk.
A Short War Story: The Ghost in the Meeting Room at Pennyworth Accountants
Pennyworth Accountants' desk told a story for most of a year about the ghost in the Elm meeting room. A partner called Graham had retired. His account had stayed enabled because the offboarding ticket was closed when his laptop came back. His calendar, still subscribed to the room, went on automatically accepting the monthly partners' meeting and three recurring client calls. So the room showed as booked by a man who had left. As far as the booking system knew, he was attending four meetings a month. The desk laughed about it at every huddle. A technician called Beth nominated it for "most mysterious". The card went up with "the ghost of Elm room" on it and no lesson line, because the lesson had felt too obvious to write. Eight months later a second partner retired. The same ticket was closed when the laptop came back. The account stayed enabled until the firm's annual access review found it. By that time it had been syncing the practice's shared mailbox to a phone nobody could locate. That took the desk, the security consultant and the managing partner most of a week to be satisfied about. The review asked why a desk that had told the ghost story twenty times had not changed its offboarding order. Nobody had a good answer, because the story had been filed under funny. The desk wrote the lesson on the card that afternoon and moved the disable step to the first line of the offboarding ticket. A story told for the laugh with the lesson left unsaid is entertainment. Entertainment does not change a checklist. The rule is in the offboarding checklist.
The Lesson Index
The table is the index as a desk using this library would fill it in. It has six lessons, the rule in a sentence, the stories that carry it from this series, and the article that owns it. Replace the stories column with your own as they happen and the owner column with your runbooks and standards where they exist. Beneath the table is the blank index for a desk starting from its own cards.
| Lesson | The rule in one sentence | Stories that carry it | Owned by |
|---|---|---|---|
| Cheapest check first | Checks that take seconds and cost nothing come before checks that take an hour and cost a part, on the phone, before the van | The plug; the printer that was off; the forty-minute drive | The diagnostic order |
| Ask what changed, including who | Something near a thing that worked yesterday has changed; ask what and who before touching the device | The monitor turned down; the Tuesday scanner; the haunted keyboard; the heater on the strip | The diagnostic order |
| Verify before you reset | Confirm who you are talking to the same way every time before touching any account | The password that was the word password; the voice that was the director | Verifying identity before a reset |
| Log the hallway request | A request made in a corridor becomes a ticket on the spot, logged by the technician, with the number handed back | The plotter driver and the tender | The hallway request handled well |
| The two-minute rule | An add-on is done now only when it is certainly two minutes with everything in hand, and is logged either way | The shared calendar; the cable that took twenty-six minutes | The two-minute rule and its limits |
| Disable first | Disable the leaver's sign-in at the agreed minute before anything else on the list; destroy nothing until after the hold | The ghost in the Elm room; the auto-reply that answered tenants | The offboarding checklist |
THE LESSON INDEX — ONE PAGE, REVIEWED ONCE A YEAR Desk: ______________________ Owner of the index: ______________ Built from: ____ stories / cards, sorted on ________ Lesson 1: ______________________________ The rule in one sentence: ______________________________________ Stories that carry it (ticket numbers): ________ ________ ________ Owner document (runbook / standard / article): __________________ Told to new starters in week one: [ ] Lesson 2: ______________________________ The rule in one sentence: ______________________________________ Stories that carry it (ticket numbers): ________ ________ ________ Owner document: __________________ Told to new starters in week one: [ ] Lesson 3: ______________________________ (same lines) Lesson 4 / 5 / 6: ______________________________ (same lines) ORPHANS Stories with no lesson (back to the drawer): ________ ________ Lessons with one story (wait for a second): ______________________ Lessons with no owner document (write it this week): _____________
Hannah's whiteboard had six lines on it by the end of the afternoon. Each line had a runbook name beside it by the end of the week. That was because two of the six had turned out to have no owner document at all. Those two lessons had been held together for years by the stories alone. The annual retelling took forty minutes. Every card got its last forty seconds. The one that drew the biggest laugh was the forty-minute drive, told by the person who had driven it. The lesson got said at the end, as it always does. That was the only part anyone needed to remember, and the story was how they would.
Frequently Asked Questions
Our stories sort into nine lessons, not six. Is that wrong?
What if a lesson has no runbook or standard to own it?
Should the lesson index be visible to users?
How do we handle a security story without teaching the wrong reader?
A lesson gained no stories this year. Do we remove it?
Can the same story carry two lessons in the index?
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.
