The problem
A ticket would get closed as "can't reproduce", and a few weeks later the same customer would open it again with the same problem. Each time it came back, the customer was less patient.
How I measured it
# closed tickets by resolution code
awk -F, 'NR>1 {r[$4]++} END {for (k in r) print r[k], k}' closed-tickets.csv | sort -rn
# how many "cannot reproduce" closures were reopened within 60 days
awk -F, 'NR>1 && $4=="cannot_reproduce" && $6!="" && ($6-$5) < 60*86400 {n++} END {print n}' closed-tickets.csv
"Can't reproduce" closures came back far more often than any other kind.
Why it kept happening
"Can't reproduce" meant different things to different people. Sometimes it meant we'd rebuilt the customer's setup carefully. Sometimes it meant we'd tried once on a default install. The ticket didn't say which.
The process change
Before closing as "can't reproduce", the ticket needed reproduction notes:
- Environment used: versions, OS, locale, config that differs from default.
- Steps tried, exactly.
- What we didn't have from the customer to make it closer.
And a lab snapshot of the environment, so the next attempt didn't start from nothing:
vim-cmd vmsvc/snapshot.create <vmid> "ticket-4821-repro" "env matched to customer" 0 0
If the notes showed we hadn't matched their setup, the ticket stayed open and went back to the customer with specific questions.
What I learnt
"Can't reproduce" usually meant "haven't reproduced yet". Writing down what we tried made the gap visible, and often the gap was the answer.
What I do now
- Require reproduction notes before closing anything as not reproducible.
- Snapshot the environment you tried, so the next attempt builds on it.
- Track reopens by resolution code. It shows which closures aren't really closed.
stage 1 looks at what your tickets keep reopening → see the engagements