Every help request gets a ticket, and the ticket remembers every change. Read those changes and you can see each choice someone made, and where they had to change their mind.
Ticketing systems keep a history of every change: category, priority, assignee, status. Each change is a decision. Reading those histories in bulk shows which decisions happen most, how long they take, and how often they're reversed, which is a strong clue to where help is needed.
Ticket audit trails expose decision events (categorise, prioritise, assign, escalate, resolve, reopen) with timestamps and actors. Reassignment and reopen rates are proxies for decision error; time between events approximates handling and wait time. Use for inventory volumes, baselines and labelled data.
Tickets are decision records
Most ticketing tools, whether for IT, HR, facilities or customer service, keep an audit trail. Every time someone changes a field, the tool records what changed, who changed it and when. Each of those changes is a decision someone made: this is a hardware problem, this is priority 2, this belongs with the network team, this is resolved.
That makes ticket logs one of the best sources for the decision inventory. You don't need to ask people how often they make a decision. The system has counted.
The decisions you can see
| Event in the log | Decision it records |
|---|---|
| Category set or changed | What kind of problem is this? |
| Priority set or changed | How urgent is it? |
| Assigned or reassigned | Who should handle it? |
| Escalated | Is this beyond me? |
| Resolved | Is it fixed? |
| Reopened | Was the earlier "resolved" wrong? |
Changes are clues
The most useful signal is a change. If a ticket's category is changed after it was first set, the first decision was probably wrong. If a ticket is reassigned three times, the routing decision was hard. If a resolved ticket is reopened, the resolution decision was premature.
So for each decision I'd calculate a change rate: how often is it revised later? A high change rate on a frequent decision is a strong candidate for help, whether that's better guidance, a clearer category list or an AI suggestion.
A worked example
These figures are illustrative. An IT service desk exports six months of ticket history: 36,000 tickets.
| Decision | Events | Changed later | Change rate |
|---|---|---|---|
| Initial category | 36,000 | 5,400 | 15% |
| Initial priority | 36,000 | 2,160 | 6% |
| First assignment | 36,000 | 7,200 | 20% |
| Resolution | 33,000 | 1,650 reopened | 5% |
First assignment stands out. One in five tickets goes to the wrong team first. If each wrong assignment adds half a day before the right team picks it up, that's 7,200 half-days of waiting over six months for the people who raised those tickets. The category change rate is related, because assignment often follows category.
That points at one decision to improve first: getting the category and assignment right the first time. The ticket history also provides the labelled examples a model would need, since the final category on each closed ticket is, in effect, the right answer.
Wait time and handling time
Timestamps let you separate how long a ticket waits from how long someone works on it. Time between creation and first assignment is mostly waiting. Time between assignment and resolution mixes waiting and work. As with approvals in What your approval logs already know, the waiting is often the larger part, and it needs a different fix from the deciding.
Things that make logs misleading
Some teams bulk-close tickets, which hides real resolution times. Some use a catch-all category, which hides real categories. Some fix things by phone and never update the ticket. I'd spend an hour with two or three people who use the tool every day before trusting any number from it.
What I'm still checking
A changed category might mean the first choice was wrong, or that new information arrived that nobody could have known at first. The log doesn't distinguish them. I'd sample 50 changed tickets and read them, to estimate what share were genuine errors before using the change rate as an error rate.
Sources
This article describes my own method. It uses no external facts or figures; all results in the example are illustrative.