The problem
Customer escalations moved between shifts and between teams. Each time, the next person read the ticket, couldn't tell what had already been tried, and asked the customer the same questions again. Customers noticed. "I already sent that" was a line I heard a lot.
How I measured it
I didn't have fancy tooling, just a ticket export. Two numbers told the story: how often a ticket changed hands, and how often the customer was asked for something they'd already given.
# tickets.csv: id,assignee,timestamp (one row per assignment)
# handoffs per ticket, highest first
awk -F, 'NR>1 {n[$1]++} END {for (t in n) print n[t]-1, t}' tickets.csv | sort -rn | head
# comments asking for logs on tickets that already had logs attached
grep -il "please send.*log" comments/*.txt | wc -l
The tickets with the most handoffs were the ones that ran longest. No surprise, but now there was a number to point at.
Why it kept happening
The ticket held everything in date order: emails, notes, attachments. The useful part (what we know, what we've ruled out) was buried in it. Reading the whole thing took longer than asking again, so people asked again.
The process change
A handoff note at the top of the ticket, updated every time it changes hands. Four lines:
- Known: what we're sure of.
- Ruled out: what we tried and why it wasn't that.
- Waiting on: who, for what.
- Next step: the very next thing to do.
It took two minutes to write. A ticket couldn't be reassigned without it, and that was the only rule.
What I learnt
More documentation wouldn't have fixed it. What worked was a small summary in a fixed place that the next person would actually read. Four lines got read. Four pages wouldn't have.
What I do now
- Put a short, fixed-format summary at the top of any long-running issue.
- Make the summary a condition of handing over, so it can't be skipped.
- Measure handoffs. The tickets that bounce are the ones that hurt.
stage 3 works this way with your team → see the engagements