A closed ticket is not a fixed cause.
Every support operation has them: the payroll variant that fails on the last working day, the interface that needs a nudge every Monday, the lock that has to be cleared whenever a particular job overruns. Each occurrence is resolved quickly, politely and within SLA — and each returns on schedule.
On paper, this operation looks healthy. Response times hold, satisfaction scores hold, the queue clears. The metrics measure the speed of the treadmill, not whether anyone is getting off it.
Closing tickets is not the same as fixing causes. Measure your support by what stops coming back.
Why the same incident returns
The fix matches the ticket, not the cause
A ticket describes a symptom: a failed posting, a stuck IDoc, a wrong result. The fastest resolution addresses exactly that symptom — repost, reprocess, correct — and the condition that produced it is never on the ticket at all.
The cause lives outside the queue’s jurisdiction
Recurring incidents disproportionately trace to master data quality, process behavior upstream, integration timing or aging custom code. All of these belong to someone — and rarely to the person holding the ticket.
Nobody reads the tickets sideways
Individually, each occurrence is minor. The pattern only exists across tickets — same transaction, same calendar position, same requester — and most operations have no routine in which anyone looks across the history at all.
The incentives reward the treadmill
SLA regimes pay for fast closure, and a recurrence is, perversely, another chance to close a ticket quickly. Nothing in the standard metric set loses points when the same incident returns for the ninth time.
What a recurring-incident review looks for
- Clusters — incidents grouping by module, transaction, interface or job chain rather than spreading evenly.
- Calendar shapes — failures that follow month-end, payroll runs, or specific weekdays; a schedule is a signature.
- Repeat requesters — the same users or departments raising the same class of issue, which usually marks a process or enablement gap, not a user problem.
- Fixes applied more than twice — any resolution note that has been pasted before is a cause running unfixed.
From ticket queue to run improvement
The mechanism is not sophisticated; it is simply a different unit of work. Instead of asking “is the queue clear?”, the operation periodically asks “what are our top recurrences, and which of them have we retired?” — and staffs a small, steady slice of capacity against that question.
Cluster the history→Name the top recurrences→Fix the cause, wherever it lives→Retire the ticket for good
The economics compound quietly. Every retired recurrence returns its capacity to the pool forever — which is why mature AMS engagements get cheaper to run over time while immature ones only get busier.
VISCAP perspective
The queue tells you what happened today. The history tells you what will happen next month.
When we take over a running SAP estate, the ticket history is the first thing we read — not to audit the previous team, but because six months of tickets is an involuntary confession of where the real problems live. The top five recurrences are usually visible within a day, and retiring them is the fastest trust we can build.
Ask your support a different question
Not “are we inside SLA?” — you almost certainly are. Ask instead: which incident that used to recur no longer exists? If the answer is a list, you have run improvement. If the answer is a pause, you have a treadmill with excellent response times.