Root-Cause Analysis (RCA)
A structured method for tracing a recurring class of tickets back to the underlying defect that causes them, so the fix removes future contacts instead of resolving each one by hand.
Root-cause analysis treats a batch of similar tickets as symptoms of a single underlying defect — a confusing screen, a broken workflow, a billing edge case — and works backward to the thing that, if fixed, would stop the tickets from arriving. The techniques are borrowed from manufacturing: the "5 Whys," popularized in the Toyota Production System, where you keep asking why until you hit something systemic rather than symptomatic, and the Ishikawa (fishbone) diagram for sorting candidate causes. In support the raw material is your own contact data, tagged and clustered by reason.
The discipline that makes it useful is the one ITIL draws between incident and problem management: resolving the customer in front of you is incident work; eliminating the reason the next hundred customers will write in is problem work. That means translating a ticket cluster into the language of whoever owns the fix — product, engineering, billing, docs — and handing it over with enough evidence to get prioritized. The deliverable isn't a closed ticket; it's a change somewhere upstream and a measurable drop in that contact reason.
What it hides: a polished RCA write-up is easy to mistake for a solved problem. The analysis is the cheap part — the fix has to ship, and someone outside support usually has to ship it. RCA also tends to stop at the first convenient cause ("user error," a named team) when the real driver is a design or process choice one level deeper. If your recurring contact reasons don't actually shrink quarter over quarter, you're producing documents, not removing tickets.