The Stories the Community Tells, and Telling Yours

Friday, 09:30, at Tollgate Foods, in the canteen. The monthly all-hands is reaching the five-minute slot the desk was given three months ago and has used twice. Ravi stands up with no slides and tells the room about the label printer in the packing office. He tells them about the ticket that said "dead" and the technician who drove across the site with a spare. And he tells them about the wall socket that had been switched off since a chiller went in. He does not name the technician, who is sitting two tables away and is Ben, or the packing office, which laughs anyway because it knows. He ends with one sentence: "So now we ask about the wall socket on the phone, and if we ever ask you, that is why." Afterwards three people come up to the desk's table to say they have one of those. Two of them have never raised a ticket.

Sharing a story beyond the desk means telling a war story to an audience that was not there. That can be the rest of the organisation, by newsletter or all-hands. Or it can be the wider community of support people, at a user group, a meetup or an online forum for the trade. The rules are the ones the earlier articles set, with one addition. Outside the desk, consent comes before the story and nothing identifies a person or exposes a security detail. This article is part of our Helpdesk War Stories & the Ticket Hall of Fame series, and it is the last article in the library. Every story in it is fictional, as the series says. The community it describes is drawn in general terms because the venues change and the rules do not.

It covers why stories should leave the desk at all, then the internal newsletter slot and the all-hands slot. Next comes the shape of a short talk for a user group or a meetup. Then come consent and anonymisation outside the desk, which are stricter than inside it. The article covers the story about the desk's own mistake, which is the one worth telling first, and the brand effect, without overclaiming it. The stories the community tells back and what never leaves the building follow. The article ends with a short war story and the story-sharing consent checklist to copy, in that order.

Why Stories Should Leave the Desk

Most of a desk's work is invisible to the people it serves. A story is the cheapest way yet found to make a piece of it visible without a chart. The article on making the invisible work visible argues for a monthly note that reports what did not break. A story does the same job with a face and a laugh, and it is read by people who would not open the note. A room that has heard the label printer story knows three things it did not know before. The desk drives across the site for a plug. It has stopped doing so. And it tells the truth about itself in public. Each of those is worth more to the desk's reputation than a satisfaction score.

The second reason is the community, which is the loose collection of other desks, other support people and the groups where they meet. Every desk has the same six classics and believes it is the only one. The first time a technician hears another desk's plug story at a meetup, they understand that the lesson is universal and the embarrassment is not. What comes back is a format, a lesson, and the comfort of a shared trade. What goes out should be a story that costs nobody at home anything.

The third reason is the desk itself. A story told outside the desk has to be told cleanly, with no in-jokes, no names and the lesson stated plainly. The discipline of preparing it improves every story on the board. Ravi's five minutes in the canteen took an hour to prepare, most of it spent cutting. That hour is where the story found its one sentence.

The Internal Newsletter Slot

The newsletter slot is one story a month, one hundred and fifty words, under a fixed heading. It is written for people who did not raise the ticket and would not read a report. The five parts are all there, compressed: the ticket as worded, the twist, the fix and its cost, the lesson, the laugh. The lesson is turned round to face the reader. So the plug story ends with "we now check the wall socket by phone, so if we ask you to look behind the desk, that is why". It never ends with anything resembling "please check your plugs before calling". The story is a courtesy to the reader, and it earns the right to a request only by never making one.

The desk's own mistakes go first. It is worth having the first three months' stories all be about the desk, because that sets the pattern before any story about a requester is attempted. A newsletter that opens its story slot with "the time we sent a van for a plug" tells the whole organisation that the desk laughs at itself. From then on every story is read in that light. One that opens with a story about a user, however kindly told, has told the organisation something else, and will spend a year undoing it. The voice is the desk's usual voice, which the language of the desk describes. A story slot in a different voice from the ticket replies reads as an advertisement.

Put the story beside the thing it teaches. If the newsletter also carries a "before you call" line, the plug story goes next to it, and the reader connects the two without being asked to. Where the desk keeps a knowledge base article for users on the same subject, the story links to it. That is the only link a story slot should ever carry. Nobody has ever followed a link from a story to a policy.

The All-Hands Slot

The all-hands slot is three to five minutes, standing, with no slides, in front of people who are mostly waiting for the next item. Tell one story in the five parts with a pause before the twist and the lesson in one sentence at the end. Thank whoever in the room helped if they have agreed to be thanked. The ideal is a story in which someone in the room is the hero, named with their consent. A room that hears the desk thank a colleague in public learns more about the desk than any story about a plug. The desk's own mistake is the second best, and the safest when there is nobody to thank.

Prepare it as a script and then do not read it. Write the five parts in one hundred and fifty words. Say it aloud three times, and cut everything that made you stumble. Then stand up with the ticket number on a card in your pocket and nothing else. The lesson sentence is the only part that must be said exactly as written, because it is the part people will repeat. What they repeat is what the desk is known for. Ravi's sentence about the wall socket was repeated back to him by someone in finance four months later, slightly wrong, which is what success sounds like.

Decline the slot when the only story available is one that cannot pass the checks below, and say so to whoever offered it. "We don't have one this month that we can tell without naming someone" earns the desk credit with the only audience that matters for consent. That is the people who might one day be in a story. A skipped slot costs nothing. A story told to a room with the wrong person in it costs a department.

The Shape of a Short Talk

A talk for a user group, a meetup or an online gathering of support people is longer, ten to fifteen minutes. It has a shape that the single story does not: three stories, each with one lesson, and the third one about the speaker. The first story is a classic, because the room will recognise it and relax. The second is the desk's most mysterious, because the room will lean in. The third is the desk's own mistake, told in the first person. The room will trust everything that came before it once they hear it. End with the three lessons on one slide or said aloud, and stop. A fourth story is one too many, and a fourth lesson is three too many.

Outside the organisation, the anonymisation is total. The organisation is "a mid-sized distributor" or "a clinic". The department is a role. The system is "the booking system". The vendor is never named. A story about a vendor's fault told at a meetup is a public complaint with the speaker's employer attached. The story loses nothing by this. The room is there for the plug and the lesson, and nobody in it needs to know whose plug.

Consent and Anonymisation Outside the Desk

Inside the desk the rule is that the requester is never the butt. Outside the desk the rule is that nobody who could be identified has not agreed. The two are different tests. A story can be perfectly kind and still identify someone. "The warehouse supervisor who logged the failure times" is a description that fits one person in a company of two hundred. The anonymising method is in writing a war story well. Replace the name, the role-and-department pair, the date and the unique detail. Ask whether three people in the building could still work out who it was. If they could, the story needs that person's agreement before it goes anywhere, and the agreement is to the words, not to the idea.

Consent means showing the person the exact text or the exact script, in advance, and asking a question they can say no to. "Would you be happy for me to tell this at the all-hands, like this?" with the words attached is consent. "I'm going to mention the printer thing on Friday, that's fine isn't it?" in a corridor is not. The difference will matter on the day the person hears a detail they did not expect. Record the agreement in writing, in the ticket if the story has one, because consent remembered is consent disputed. Most people say yes, and a surprising number ask whether they can be named.

The organisation's consent matters once the story leaves the building, and it is usually the lead's or a manager's call rather than a formal process. Anything that describes how a system is configured, how a control works or how a mistake was exploited stays inside. The security side of that line is in the desk's own security habits. The test for a public telling is about what a stranger could learn from the story. Could they learn something about the organisation that it would not put on its own website? If the answer is anything other than a clear no, the story stays home.

The Story About the Desk's Own Mistake

The story about the desk's own mistake is the most powerful story the desk owns. It is the one to tell first in every venue, because it buys the trust that every later story spends. A room that has heard the desk say "we got this wrong, it cost this, and here is what we changed" believes the desk when it later says "and here is a thing you can check before calling". The desk has shown that it applies the same honesty to itself. A room that has only ever heard the desk's successes applies a discount to all of them. The mechanism is the same one that makes a failure handled well raise trust above where it started, which service recovery moments explains for the single ticket.

Tell it in three moves: what the desk did, what it cost, and what the desk changed. "We closed a ticket as fixed without telling the person; she found out three weeks later when it broke again; we now confirm with you before we close anything." No excuse, no context about how busy the week was, and no sentence that starts with "to be fair". The cost is stated plainly and in the requester's terms, because the audience is the requesters. The change is stated as a promise they can hold the desk to, because that is what it is.

The technician in the story is "the desk" unless they have asked to be named. The lead tells it, because a lead telling the desk's mistake in public is a lead taking the weight. There is a version of this story in which the technician is named by the lead as a lesson to others. It is the only version that does damage. The room learns that this desk names people when things go wrong, and so does every technician in it. The blameless rule does not stop at the door. It is most visible at the all-hands.

The Brand Effect, Without Overclaiming

Stories change what the organisation thinks the desk is, which is to say they change IT's internal brand. The whole argument lives in the series on that brand. The effect of a story is specific. It replaces "IT is the people who take two days to fix a printer" with "IT is the people who told us about the plug". The second is a reputation that survives a bad week. A desk that tells one honest story a month, in its own voice, for a year, is a desk whose requesters quote it back. Quoting is the only measure of a brand that costs nothing to collect.

Do not claim more than that. A story does not reduce ticket volume, raise satisfaction or save the organisation money. A desk that claims those outcomes in a report has turned a courtesy into a metric and will be asked to prove it. What a story can evidence is small and real. That includes the number of "we have one of those" conversations after the all-hands, and the requester who mentioned the newsletter story in their ticket. It includes the department that started raising tickets after a story about their own kind of problem. Collect those as anecdotes. If you run QuerySolv, the satisfaction comments that come back with resolved tickets are in the standard reports. Those comments are where a story that has landed tends to be quoted back. The arithmetic of the brand, where there is any, is in measuring the brand. A story is one of its inputs, not its proof.

The strongest brand effect is the one the desk cannot plan, which is the story told about the desk by someone else. The finance manager who tells her own team "ask them about the wall socket, they have a story" has done more for the desk than the all-hands did. She did it because the desk told the story about itself first. Stories travel in the direction of the people who were treated well in them. Tell them that way and they go further than any newsletter.

The Stories the Community Tells Back

Go to the user group or the meetup or the online gathering mostly to listen. The stories the community tells are the same six classics with different furniture. Hearing them is the most reassuring hour a desk lead can spend. The plug is universal. The ghost in the meeting room is universal. The scanner that only fails when a door is open has been told, with a different door, by a desk in every trade that has scanners. The lesson of the community's stories is that the lessons are the same everywhere. That means the desk's weak spots are the trade's weak spots and not a personal failing. That is worth knowing at four on a Friday.

Bring two things home: a lesson the desk has not written down yet, and a format the desk has not tried. The lesson goes into the index described in the lessons behind the laughs, with a note that the story came from elsewhere. The format, whether it is a talk shape, a card, a newsletter heading or a ritual, goes into the next huddle as a thing to try once. Do not bring home the story itself with its details, and never retell another desk's story as if it were yours. The person it happened to may be in the next room at the next meeting.

The community is also where a desk learns that its hall of fame is normal. It learns that its blameless rule is shared by the desks it admires. It also learns that the desks who collect foolish-user stories are, on inspection, the ones whose users have stopped calling. None of that appears in a report. All of it changes how a lead runs the next year.

What Never Leaves the Building

Some stories stay inside the desk. Some stay inside the organisation. A few are not war stories at all and stay inside the ticket. The list below is the set of things a story must not carry past the door. It is short enough to check against every story before it travels. A story that fails one line is not a bad story; it is a story for a smaller room.

• Anything that describes how a security control works, how it was bypassed, or how an account was misused, in steps.
• Any person's name, role-and-department pair, date or unique detail without that person's written agreement to the exact words.
• Any vendor, product or supplier named, or described closely enough to be identified.
• Any detail of how a system is configured, addressed or connected that is not already public.
• Any story about a ticket that is still open, or an incident whose review is not finished.
• Any story in which the requester or a junior technician is the butt, however gently.
• Any personal data from a ticket: what someone was working on, where they were, what they had said.
• Any cost stated in money, or any number presented as a benchmark rather than the cost of one story.

The list is also the reason fictional stories exist. Every story in this library is invented. That is how a library read by strangers can tell the ghost story, the password story and the forty-minute drive without a single consent form. A desk telling its own stories outside its own walls has no such licence. The checklist at the end of this article is the form the licence takes.

A Short War Story: The Cold Store Tablet at Coppermill Brewing

Coppermill Brewing's desk started a newsletter slot and used its second month on the cold store tablet, a story the desk loved. The night shift's stock-count tablet had died at around two every morning for a fortnight. The desk had replaced the battery, then the tablet. It then found that the night shift carried it into the cold store for the count, where the battery gave up in the cold. The desk also found that a shift lead called Marta had worked that out herself and written it in a ticket the desk had not read properly. The write-up, by a technician called Joel, said the night shift "kept killing the tablet" and did not mention Marta's ticket. Marta read it on her break and took it as the desk telling the brewery that her shift was careless. That was the opposite of what had happened. The night shift stopped raising tickets for two months and took their problems to a day-shift technician's personal phone. The volume report showed the brewing floor raising almost nothing at night. The technician in question asked why he was getting messages at three in the morning. Together, those told the desk what had happened. The lead apologised to Marta in person. Joel rewrote the story with her agreement and her name, as the person who had found the cause. The rewrite ran in the next newsletter with a line about the desk having missed her ticket. The night shift came back within a fortnight, and Marta was the first "user who helped most" card on the board. Outside the desk, consent comes before the story and the person who found the cause is the hero of it. The rule is in writing a war story well.

The Story-Sharing Consent Checklist

The checklist below is run once per story per venue, before the story leaves the desk. It is kept with the story on the page so that the next person to retell it can see what was agreed. The first block is about people, the second about the organisation, the third about the telling. A story with an unticked box in the first two blocks does not go. A story with an unticked box in the third is rewritten first.

STORY-SHARING CONSENT CHECKLIST — ONE STORY, ONE VENUE
Story: ______________________________   Ticket: ________
Venue:  [ ] newsletter   [ ] all-hands   [ ] talk / community   [ ] forum post
Prepared by: ______________   Approved by (lead): ______________   Date: ________

PEOPLE
  [ ] Every person identifiable in the story is listed here:
      ______________   ______________   ______________
  [ ] Each has read the exact words or script, not a summary
  [ ] Each has agreed in writing (in the ticket or by message), and the
      agreement names the venue
  [ ] Anyone who did not agree has been replaced by a role and the unique
      detail changed, and three people in the building could not identify them
  [ ] No requester or junior technician is the butt of the story

ORGANISATION
  [ ] No security control, bypass or misuse is described in steps
  [ ] No vendor, product or supplier is named or identifiable
  [ ] No configuration, address or connection detail is given
  [ ] The ticket is closed and any incident review is finished
  [ ] For a venue outside the organisation: the lead has agreed it may leave
  [ ] No personal data from the ticket appears

THE TELLING
  [ ] The five parts are present and in order
  [ ] The lesson is one sentence, said last, and points at where the rule lives
  [ ] The desk's own part in what went wrong is stated plainly
  [ ] No cost in money; no number presented as a benchmark
  [ ] Length fits the venue:  150 words / 3-5 minutes / 10-15 minutes
  [ ] This checklist is filed with the story on the page

Ravi's label printer story had passed the checklist in an hour, mostly because it was about the desk. Another reason was that the only person in it who could be identified was Ben. Ben had said yes and then asked whether he could tell it himself next time. He did, at the following all-hands, in four minutes, and ended with the same sentence about the wall socket. The room laughed in the same place. That is the whole of the method, and the last thing this library has to say. Find the story, keep the lesson, tell it about yourself first, and ask before you tell it about anyone else.

Frequently Asked Questions