> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Trend Root-Cause Mining

> Find what is driving ticket volume and making the desk busy by mining recent tickets for top recurring issues and root causes across a chosen period.

<Info>
  **Category:** Reporting & Analytics · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/reporting-and-analytics/trend-rootcause-mining/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip thread-chip-native">Thread</span></span> — native, no connector required

**Role:** [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Fewer Escalations & Less Noise

**When to use:** "What's making us so busy this week/month?", "what are the top recurring issues across the desk?", or "volume is up 20% — where is it coming from?"

**Run it:** across all tickets in the period — manually on demand (a volume-driver analysis has no ticket event for a Flow to trigger on).

## Prompt

```
Answer "why is the desk busy?" with evidence: the top recurring volume drivers for the
period, each sized, explained, and illustrated with exactly ONE representative ticket.

1. Confirm the period (default: last 30 days) and pull the ticket population with split
   searches per board — and per obvious segment (client, type) when a board would cap;
   disclose caps. Do not invent ticket numbers, counts, or percentages.

2. Cluster tickets into drivers by shared signal: same issue type, same client, same
   asset/service, same alert source, or same request category. Read titles and
   summaries; do not rely on categories alone if they look inconsistently applied. If
   clustering is ambiguous, present the uncertainty.

3. Rank the top 5-8 drivers by ticket count and estimated time consumed (thread length
   and time entries as proxies). Distinguish "busy" from "many tickets": a few heavy
   escalations can outweigh dozens of password resets — weigh by effort, not count
   alone.

4. For each driver give: name, size (count and rough % of period volume), the likely
   root cause in one or two sentences, and ONE representative ticket as the example —
   never a full listing. A wall of ticket numbers is a failure mode. Root causes are
   hypotheses read from ticket text; label them as such and recommend verification
   before investment.

5. Tag each driver with its fix lane: automation candidate (intent/flow), monitoring
   retune, client training, project/RCA needed, or vendor issue. Exclude junk/NOC
   boards and auto-closed noise unless the question is specifically about alert noise;
   if noise dominates real volume, say so as its own finding.

6. Close with the 2-3 drivers most worth acting on and a methodology note (period,
   boards, clustering basis, caps).
```


## Related topics

- [Zero-Touch Opportunity Mining](/skill-library/reporting-and-analytics/zero-touch-opportunity-mining.md)
- [Intent Mining](/skill-library/automation-and-flows/intent-mining.md)
- [Printer Troubleshooting](/skill-library/troubleshooting-playbooks/printer-troubleshooting.md)