See the new issue before it has a tag.
By the time it has a category name, it has been running two weeks.
A new failure mode arrives in ticket bodies days before anyone creates a tag for it, and the queue dashboard shows total volume, which is flat because the new issue displaces other contacts rather than adding to them. Support finds the cluster while it is still unnamed and dates the day it started.
Fourteen queue series, one emerging issue with no tag, detection computed live in your browser, including the total volume that never moved.
The problem
Your categories describe last quarter.
Every reporting surface in a support stack is built on tags, and tags exist because a human already recognised the pattern and named it. That is the whole gap. For the two weeks between a new failure mode arriving and someone creating a category for it, the issue is invisible to every dashboard, every routing rule, and every macro, while agents handle it one ticket at a time with no playbook and no idea it is a pattern.
The insight
The queue tells you a new issue exists before anyone can name it.
A new failure mode does not announce itself in volume, because a support queue is roughly conserved: the same customers contact you, they just contact you about something else. What it does change is how the work behaves. Contacts about an unfamiliar issue cannot be closed on first contact, so resolution falls. They get handed up, so escalation rises. They take longer, so handle time rises. Those three move together, in one product area, on one day, and none of them requires knowing what the issue is. Topic clustering on ticket text finds the candidate; the changepoint on the operational metrics is what proves it is real and not a normal fluctuation in a noisy queue.
Embedding-based topic clustering over ticket text to produce candidate untagged topics, then CUSUM on day-over-day percentage changes and Bayesian Online Changepoint Detection (Adams & MacKay 2007) on topic volume, first-contact resolution, escalation rate, and handle time per product area, with Benjamini-Hochberg FDR control across every topic × area × metric combination in the run.
How it works
Four steps, no data science team
Zendesk, Intercom, Front, Salesforce Service Cloud, or a CSV export. Read-only. No workflow changes, no new tags, no agent behaviour to retrain.
Every ticket gets embedded and clustered without reference to your tags, so a topic can exist in the data before it exists in your taxonomy. Clusters are tracked across days rather than rebuilt from scratch.
Cluster volume and the operational metrics for each product area run through CUSUM and BOCD. Benjamini-Hochberg across the whole run keeps a few hundred cluster-area tests from producing daily noise.
The alert names the product area, the date, and the metrics that moved together, and links the highest-similarity tickets so a lead can read them and name the issue in ten minutes.
Who it is for
The support ops lead who owns the queue and the tag taxonomy
Support operations leaders at companies past the point where one person reads every ticket. Usually 15 to 400 agents, an established tag taxonomy that is already out of date, and a recurring meeting about why handle time went up last month.
Pricing
- –Full detection engine
- –90-day history
- –Weekly digest
- –One product area
- –Unlimited product areas
- –24-month history
- –Nightly topic clustering
- –Slack alerts with sample tickets
- –Tag-gap report
- –Self-hosted embedding option
- –Custom operational metrics
- –SSO and audit log
- –Data residency controls
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Zendesk / Intercom native reporting | Volume, resolution, and CSAT dashboards sliced by tag and group. | Everything is downstream of a tag. An issue with no tag has no row, so the reporting is structurally blind for exactly the period that matters. |
| AI triage and auto-tagging tools | Classify incoming tickets into your existing categories automatically. | Classification into a fixed taxonomy. A ticket about something new gets sorted into the nearest old bucket, which actively hides the emergence rather than surfacing it. |
| Voice-of-customer platforms | Theme extraction and sentiment across tickets, reviews, and surveys. | Built for quarterly insight decks, not daily detection. Themes are read by a researcher weeks later, and there is no statistical test that a theme actually shifted. |
| Product analytics and error monitoring | Sees the bug in the application before support does, sometimes. | Only catches failure modes that throw. Confusing copy, a broken partner flow, and a policy change that surprises people all produce tickets and zero exceptions. |
The honest failure mode: topic clusters are fuzzy and support leads have good instincts. If the clusters we surface are ones the team would have spotted in a Monday standup anyway, this is a nice report rather than a purchase. The bet is that the two-week gap is real and expensive, and that dating it with an operational changepoint rather than an anecdote is what makes it act on. There is also a plain product risk: clustering quality varies a lot with ticket length, and a queue that is mostly one-line messages may not cluster well enough to be worth anything. We should test that on real data before selling, not after.
Market
Priced against handle time, not per agent seat
A hundred-agent support organisation is a multi-million dollar annual cost, and helpdesk software is a small fraction of it. Two weeks of an unnamed issue running at elevated handle time and escalation is a real number on that cost base. Four thousand teams at the Team tier is $24M ARR, and every company with a support queue has this gap by construction.