Home › Topics › Handoffs & Coverage Transitions › The Cracks

Where Tickets Fall Between the Cracks: The Five Moments

Friday, 14:00, at Meridian Parts. Dev on the goods-in dock phones the desk about the label printer. Marta, who runs the desk, finds ticket 7718 and reads the history while he waits. Opened on Monday of last week at 09:00 by Priya, on the early shift. Picked up on Tuesday by Omar. Moved to Facilities that afternoon, because the socket on the dock was dead. Worked by Lena in Facilities on Thursday, who fixed the socket and sent it to the team lead because the printer still would not print. Reassigned by the lead to Raj on Friday. Raj ordered a part on Monday and went on leave on Wednesday. Every entry is correct. Every handoff is recorded. Dev has heard nothing since the automatic acknowledgment nine days ago, and the dock has been hand-writing labels since.

A handoff is the moment responsibility for a ticket moves from one person to another, or from one time to another. A crack is the interval that opens at a handoff. It falls between the moment one person stops being responsible and the moment the next person starts. During that interval, nobody is responsible. Tickets do not fall through the cracks between people. People are fine. Tickets fall through the cracks between moments, and there are five such moments on almost every desk. This article is part of our Handoffs & Coverage Transitions series, and it is the map of the five.

It covers what a crack is and why it is an interval rather than a place. We cover the four things that have to cross every handoff for the crack to close. Then come the five moments in turn: the end of a shift, leave, a transfer between departments, an escalation and a reassignment inside the team. We cover how each opens a crack and what closes it. Next come all five on one ticket's timeline, with a picture and a table, then why careful people leave gaps anyway. A short war story follows, then the crack map, a one-page template for finding the cracks on your own desk, in that order.

A Crack Is an Interval, Not a Place

A crack is a stretch of time, and it has a start and an end. It starts when the person who had the ticket stops acting on it, and it ends when somebody else starts. In between, the ticket sits in a queue, with a status, an owner and a priority, and every one of those fields may be correct. The queue does not have a column for "is anybody actually doing this". If it did, the column would be blank for the whole of the crack. That is the only thing that is wrong with the ticket during it.

This is why the search for the culprit never finds one. Priya did not drop 7718; her shift ended. Omar did not drop it; the socket was not his to fix. Lena did not drop it; she fixed her part and sent it on. The lead did not drop it; he gave it to the right person. Raj did not drop it; he ordered the part and then went on leave he had booked in the spring. Each person did a reasonable thing and then stopped being responsible. The next person did not start for a while. The sum of the whiles was nine days.

A crack is different from a hidden ticket, and the fixes are different. A hidden ticket is one that no standing view shows, filed in a drawer nobody opens. The drawers and the daily sweep that opens them are in Keeping Tickets From Hiding. A ticket in a crack can be perfectly visible. 7718 was in Raj's open list all week, in plain sight, with Raj's name on it. Nobody was looking at Raj's list, because Raj was the one who looked at Raj's list.

The length of the crack is the cost, and the requester pays it. The desk experiences a crack as nothing, because nothing happens during it. Dev experienced it as nine days of hand-written labels and a growing suspicion that the desk had lost his ticket. It had not. It had merely stopped, five times, and restarted four.

The Four Things That Must Cross

A handoff closes its crack when four things reach the next person, and it leaves a crack open when any of them does not. The first is ownership: the next person knows the ticket is now theirs, which is not the same as the owner field saying so. The second is context: what has been done, what has been tried, and what the requester has been told. The third is the next action: the one thing that should happen next, and by when. The fourth is the requester's expectation: what the requester has been promised, so that the promise survives the change of hands.

Ownership fails to cross more often than the other three put together. The field changes; the person does not find out. Most tools send a notification when a ticket is assigned, and a notification is an e-mail, and the technician it reaches has sixty others. The field says Raj. Raj, on Friday afternoon, was under a desk in accounts with his phone in his bag. The ticket was his for two working days before he knew.

Context fails to cross when the handoff is a field change with no note. In that case, the next person opens a ticket whose last entry is the previous owner's private shorthand. "Socket dead, moved" is a complete record for Omar and a riddle for Lena. The next action fails to cross when nobody writes one. The receiver has to reconstruct it from the history. That takes long enough that the ticket goes back to the pile to wait for a quieter moment. (There is no quieter moment. There has never been one.) And the requester's expectation fails to cross almost every time, because it was never written down. Priya told Dev on Monday "I'll get someone down there today", and no field on the ticket held that sentence.

Write all four into the handoff, every time, and the crack closes on its own. That is the whole discipline of this series, and the five moments below are the five places it has to be applied.

Moment One: The End of a Shift

The end of a shift is a handoff from one person to another along the clock. It happens every working day on every desk with more than one person's hours in it. The early shift ends at 15:00; the late shift started at 13:00 and is already busy. The overlap, where it exists, is spent on whatever is loudest. A desk that works a single day shift still has the handoff, from today's person to tomorrow's, with a night in the middle. On a one-person desk the handoff is from yourself to yourself, and tomorrow-you remembers less than you think.

The crack opens on the promises. Priya told Dev "today", and then Priya's day ended. The late shift did not know a promise had been made, because the only place it existed was in a phone call. Tickets with an active promise, a reply due, a callback agreed, a visit arranged, are the ones a shift end drops. They are precisely the ones the requester is watching the clock on.

What closes it is a handover: a written note of what is promised, what is in flight and what to watch, read by the next person at a fixed time. "It's all in the queue" is not a handover; it is a description of where the queue is. The five-minute ritual, the handover note, and what to do when the next person is not in yet are in The Shift Handover. The short version is that the promise must exist somewhere other than the head of the person going home.

Moment Two: Leave, Planned and Not

Leave is a handoff from a person to an absence, and it is the widest crack on the desk because it is the longest. A shift end is sixteen hours. Leave is two weeks. A ticket that stays assigned to someone on leave will do nothing for the length of the leave. And it will do it visibly, with a name on it, in a list nobody opens because the name's owner is the person who opened it.

The crack opens in the week before, when the person going away looks at their open tickets. They make a quiet judgement about each one: "that can wait till I'm back". Some can. Most cannot, and the judgement is being made by the one person with an interest in it being yes. Raj's part was due on Thursday. Raj left on Wednesday. The part arrived and sat in goods-in beside the printer it was for. Nobody on the desk knew to look for it, because the ticket was Raj's and Raj was not there to be asked.

Unplanned leave is the same crack with no warning. Somebody is ill on a Tuesday morning, and their open list is exactly as they left it on Monday evening, promises and all. The tickets will stay stopped until somebody opens the absent person's list and reassigns what is active. That has to be a named job for a named person by a fixed time each morning. Otherwise it is nobody's job and it does not happen.

What closes the crack is a sweep before planned leave, a reassignment rule for unplanned leave, and a cover who is briefed rather than merely named. The full routine, including the decision for each ticket between reassigning it and watching it, the out-of-office that tells the truth, and the first morning back, is in Vacation Coverage Without the Pile. The rule underneath it is short. No ticket owned by an absent person should need anything before they are back.

Moment Three: Transfer Between Departments

A transfer moves a ticket from one department's queue to another's because the work belongs there. And it is the most ordinary handoff on the desk. The socket is Facilities' problem; the account is the directory team's; the invoice question is finance's. Transfers should happen freely and often. The crack is not in the move. It is in the arrival.

The crack opens because a transferred ticket lands unassigned, in a queue whose readers did not ask for it, with a note written for the sender's benefit. Facilities received 7718 at 16:00 on Tuesday as an unowned ticket at the bottom of a list of things that were theirs. Nobody in Facilities knew Priya had promised Dev anything. The ticket waited until Thursday morning, when Lena read the unassigned view from the bottom. She did this because she had been told to, and nobody had been told to on Wednesday.

Transfers also open a second crack of their own: the move to a department that decides it is not theirs. The ticket comes back, or goes on to a third team, and each bounce is a fresh arrival with a fresh wait. Two bounces and a ticket has spent a week being correctly declined by everyone. The requester, during this, receives automatic notifications saying the ticket has been updated, which is true and tells them nothing they can act on.

Closing it takes a transfer note written for a stranger and an acceptance by a named person within a stated time. It also takes a line to the requester saying what has changed for them. The sender keeps responsibility until the receiver has accepted; the field changing is not the acceptance. All of that, with the note to copy, is in Transferring a Ticket Between People or Departments.

Moment Four: Escalation

An escalation is a handoff upward, to someone with more skill or more authority, because the current owner cannot finish the ticket. It differs from the other four moments in its reason: the others move a ticket because of time. This one moves it because of ability. It belongs on the list anyway, because the crack it opens is the same shape. The crack is often the deepest, since the person being escalated to is usually the busiest person on the desk.

The crack opens on the acceptance. The lead's queue is a list of things only the lead can do, and the lead is doing one of them. Lena's escalation on Thursday at 14:00 arrived as a notification among forty. The lead got to it on Friday at 11:00, which on that desk counted as fast. During those seven working hours the ticket had two people who believed it was with somebody else: Lena, who had sent it, and the lead, who had not read it yet. Both were right. That is what a crack is.

The second way an escalation opens a crack is the dump: the ticket arrives with no note and no next action. So the lead has to start from the history. And a ticket that needs twenty minutes of reading before it can be touched will be touched later. The escalation note, the acceptance, and who owns the requester's updates while the ticket is up the ladder are the subject of The Handoff That Does Not Dump. This article's claim is narrower: an escalation is a handoff, and the four things must cross it like any other.

Moment Five: Reassignment Within the Team

A reassignment is a handoff from one person to another inside the same team, usually made by a third person, usually to balance the load. The lead looks at the queue on Friday, sees Omar has eleven and Raj has four, and moves three. It takes nine seconds. It is the quietest handoff on the desk, because the two people whose tickets changed were not in the conversation. It is the one most often done with no note at all, because the person doing it is doing it in bulk.

The crack opens because the new owner does not know. The field says Raj; the notification went to Raj's inbox; Raj's inbox is where notifications go to be read on Monday. The old owner, meanwhile, has stopped looking, because the ticket has left their list. A ticket that leaves a list has left the mind that was reading the list. For the length of the crack the ticket has an owner who does not know and a previous owner who has forgotten. It has a requester holding a promise that nobody in the new arrangement has heard of.

What closes it is a rule that a reassignment is not finished until the new owner has said so. The lead moves the ticket and tells Raj, in a sentence, with the next action and the promise: "Giving you 7718, dock label printer, Facilities fixed the socket, Dev was told Monday it'd be looked at that day, needs a part or a swap." Raj replies "got it". Until Raj has replied, the lead still owns it. In a tool where technicians claim their own tickets, the claim is the acceptance; a reassignment made by someone else needs the sentence.

The Five Moments on One Ticket

The picture below puts 7718's ten working days on a single line. The amber stretches are the time somebody owned the ticket and was acting on it: Priya, Omar, Lena, the lead briefly, then Raj. The orange stretches are the cracks, numbered one to five in the order the moments occurred. And the green mark at the end is the fix, on the Friday afternoon, after Dev phoned. Read the widths. The cracks are wider than the work.

A timeline of one ticket across ten working days, showing five handoff moments where the owner changed: a shift end, a transfer between departments, an escalation, a reassignment and a period of leave. Each handoff is followed by a gap during which nobody was acting on the ticket, and the gaps add up to about six of the ten days.
Ticket 7718: five handoffs, five cracks, and about six working days in which nobody was acting on it.

The arithmetic is the point. About four of the ten working days were spent by someone working the ticket. The fix, once Raj's part was found on the dock, took two hours. About six days were spent in cracks. The ticket was not slow because the work was hard. It was slow because it stopped five times, and each stop lasted until somebody happened to start.

The table lines the five moments up against each other. It shows who releases the ticket, who is supposed to pick it up, and how wide the crack usually runs. It shows which of the four things most often fails to cross. The width column is from my own desks rather than a survey, and yours will differ. The order, from a shift end at the narrow end to leave at the wide end, I have found the same everywhere.

MomentWho releasesWho should pick upTypical crackWhat usually fails to cross
End of a shiftThe person going homeThe next shift, or tomorrow's first person inHours to a dayThe requester's expectation: promises made by phone and never written
LeaveThe person going awayA named cover, or the lead on unplanned absenceDays to weeksOwnership: tickets left assigned to the absent person
Transfer between departmentsThe sending teamWhoever reads the receiving team's unassigned viewA day to severalContext: a note written for the sender, and no acceptance
EscalationThe first-line ownerThe senior person or leadHours to daysThe next action: a dump with no note, waiting to be read
Reassignment within the teamA lead or the previous ownerThe new ownerHours to a weekendOwnership: the new owner does not know yet

Remember: a handoff is finished when the next person has confirmed they have the ticket, not when the field changes. Until then, the person who released it still owns it.

Why Good People Leave Gaps

Cracks are made by reasonable behaviour, which is why telling people to be more careful does nothing. Each person at a handoff is doing the thing their role asks. That might be finishing a shift, taking booked leave, or moving a ticket to the team that can fix it. It might be asking the lead or balancing a queue. The gap opens between two careful acts because the system has no step that joins them. A system with no step for something gets it done by whoever notices. That is a staffing plan that fails on exactly the busy days it is needed.

The tool makes the gap easy to leave because it records the handoff as a field change and treats the field change as the event. From the tool's point of view, 7718 was handed off five times and each handoff took under a second. From Dev's point of view each handoff took between half a day and three days. The field is the receipt. The handoff is the delivery.

One rule closes all five cracks, and the receiver makes it work. Nothing has been handed off until the receiver has said "I have it". Until then the sender still has it. On a shift, the receiver reads the note and says so. On leave, the cover accepts each ticket. On a transfer, the receiving team claims and acknowledges. On an escalation, the lead accepts within a stated time. On a reassignment, the new owner replies "got it". Write it into the team's working agreement as one line: "A handoff is complete when the receiver confirms; until then the sender is responsible for the requester's next update." It is a dull sentence. It is also the only sentence in this article that, on its own, would have got Dev his printer by Tuesday.

A Short War Story: The Nine-Day Printer at Tollgate Foods

At Tollgate Foods, a ticket about the allergen-label printer on the packing line passed through four pairs of hands in nine working days. An early-shift technician called Marcus promised the line supervisor a same-day visit. The late shift was never told. A transfer took it to the maintenance team, who left it unassigned for two days. A reassignment took it to a technician who found out it was his when the supervisor phoned him directly. The packing line hand-wrote allergen labels for seven of those days. A customer audit the following week picked up three illegible ones. The plant manager spent a morning with the audit team explaining why. Marcus had done nothing wrong; neither had anybody else. The desk drew its first crack map that afternoon. They found that all four cracks were on the list of five and wrote the receiver rule into the working agreement before anyone went home. A ticket that stops four times will take as long as four tickets, however quick each piece of work is.

The Crack Map

The crack map is the five moments applied to your own desk. For each one, it records who releases the ticket, who picks it up, and by when. It records what the receiver has to say to close the handoff. It records what view or check catches a ticket stuck in the crack, and who runs that check. Fill it in once with the team, in half an hour, and the blanks you cannot fill are the cracks. Most desks find two or three blank cells on the first pass. That is the map doing its job.

CRACK MAP — ONE PAGE
Desk: ______________________   Drawn by: ______________   Reviewed with team: [ ]

Rule we have agreed:
  A handoff is complete when the receiver confirms; until then the sender
  is responsible for the requester's next update.      Written down at: __________

MOMENT 1 — END OF A SHIFT
  Who releases: __________________   Who picks up: __________________
  Handover happens at: ____:____ daily   Note lives in: _______________________
  Receiver confirms by: _______________   Catches a stuck ticket: _______________
  Promised-by-phone items written where: ____________________________

MOMENT 2 — LEAVE (PLANNED)
  Pre-leave sweep done by: __________________   How many days before: ____
  Named cover: __________________   Cover confirms each ticket: [ ] yes
  Tickets left assigned to the absent person on day one: must be ____ (target: 0)

MOMENT 2 — LEAVE (UNPLANNED)
  Who opens the absent person's list: __________________   By: ____:____
  Active tickets reassigned to: __________________   Requester told: [ ] yes

MOMENT 3 — TRANSFER BETWEEN DEPARTMENTS
  Transfer note required: [ ] yes   Written for: a reader who knows nothing
  Receiving team accepts within: ______   Accepted by (role): ________________
  Sender keeps it until accepted: [ ] agreed   Requester told of the move: [ ] yes
  Catches a stuck transfer: the receiving team's unassigned view, read by ________

MOMENT 4 — ESCALATION
  Escalated to: __________________   Accepts within: ______
  Requester updates while escalated are owned by: __________________
  Catches a stuck escalation: _______________________________

MOMENT 5 — REASSIGNMENT WITHIN THE TEAM
  Who may reassign: __________________   New owner told how: ________________
  New owner confirms with: "________"   Until then owned by: ________________
  Catches a stuck reassignment: _______________________________

BLANK CELLS ON THIS SHEET (these are the cracks)
  1. __________________________   Fix: ______________________   Owner: ________
  2. __________________________   Fix: ______________________   Owner: ________
  3. __________________________   Fix: ______________________   Owner: ________
  Next review: __________

Two cells matter more than the rest. One is the "receiver confirms" line under every moment, because it is the one rule that closes all five cracks. The other is the "catches a stuck ticket" line. The confirmation rule will be skipped on busy days, and the check is what finds the ticket when it is. How to count what the checks find, month by month, is the last article of this series; the four between take one moment each.

Dev got his printer on the Friday, two hours after he phoned. The part had been sitting on the dock since the previous Thursday, four metres from the printer, in a box with Raj's name on it. Nothing on the ticket was wrong. Nothing on the ticket is ever wrong. That is the whole trouble with cracks. The record of a ticket that stopped five times looks exactly like the record of a ticket that was worked for ten days.

Frequently Asked Questions

Is a crack the same thing as a ticket going stale?
No, though a crack produces staleness. A stale ticket is one with no update for longer than the follow-up interval, whoever owns it. A crack is specifically the gap at a handoff, between one person stopping and the next starting. A ticket can go stale with one owner who simply did not get to it. A ticket in a crack has had a change of hands and nobody on the receiving side has started.
Our tool sends a notification on every assignment. Isn't that the confirmation?
It is a notification, not a confirmation. The notification proves the tool sent an e-mail; the confirmation is the receiver saying they have the ticket. Treat the two as different events, and keep the sender responsible until the second one happens. On most desks the e-mail is read hours or days after it arrives, and on a busy afternoon it is not read at all.
We are a two-person desk. Do we really have five handoff moments?
You have at least three: the end of the day, leave, and transfers to other teams in the organisation. Escalation and reassignment may not happen between two people, or may happen informally across a desk. Fill in the crack map anyway. The two-person desk's widest crack is usually leave, because there is only one cover and the cover is also the whole of the rest of the desk.
How long is a crack allowed to be before it counts as a problem?
Set a limit per moment and write it in the map. A shift handoff should close at the start of the next shift. A reassignment should close the same working day, and a transfer within one working day. An escalation should close within whatever time the escalation path promises. A leave handoff should close on the day the leave starts. A crack longer than its limit is a finding for the monthly check, not a fault in the person who happened to be on either side of it.
Who should be responsible for the requester's update while a ticket is in a crack?
The sender, until the receiver confirms. That is the point of the rule: there is never a moment when nobody owes the requester the next update. If the sender has gone home or on leave, the responsibility passes to whoever runs the handover or the absence check that morning. That is why both need a named person and a fixed time.
Does any of this change if our tool has automatic routing or round-robin assignment?
The moments are the same; only the sender changes. An automatic assignment is a reassignment made by a rule rather than a lead, and the new owner still has to find out. Most tools that assign automatically also notify, and the notification has the same weakness as any other. Keep the confirmation step, and have the daily check include tickets assigned by the rule that have had no action since.

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.