Emerging-Topic Detection & Early Warning

The Problem

Contact centres are brilliant at handling expected volume and hopeless at spotting the unexpected early. When something unusual happens in the real world — a regional power outage, severe weather, a website outage, a product recall, a confusing bill run — it shows up as a wave of calls about a topic that wasn't there yesterday. But the operation typically only notices when the wave has already hit: queues balloon, wait times spike, agents get overwhelmed, and CSAT tanks.

By the time a human notices the pattern in a dashboard and raises it, an hour of frustrated callers has already gone through. The information needed to react early was there in the call reasons all along — nobody (and no system) was watching for it in real time.

The AI Use Case

The idea is simple to state: have AI continuously read the reason for every call, categorise it, and raise a flag the moment a genuinely new topic starts spiking out of the blue — then alert the team that can actually do something about it.

It combines three things AI is good at and humans can't do at scale in real time:

• Understanding what each caller actually wants, in their own words
• Categorising millions of interactions into consistent, comparable topics
• Spotting the anomaly — a topic that is both new and accelerating, not just normal daily noise

How It Works — Step by Step

  ┌──────────────────────────────────────────────────────────┐
  │  1. INGEST every interaction                               │
  │     transcripts / intents / IVR reason capture             │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  2. CATEGORISE with AI                                      │
  │     LLM assigns each call to a reason category             │
  │     (known categories + "new / uncategorised")             │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  3. BASELINE — what's normal for this topic, this          │
  │     time of day / week / season?                           │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  4. DETECT ANOMALY — is a topic BOTH:                       │
  │     (a) new or rare historically, AND                      │
  │     (b) rising sharply vs its baseline?                     │
  └───────────────┬──────────────────────────┬────────────────┘
          no       │                          │ yes
                   ▼                          ▼
        ┌────────────────────┐    ┌──────────────────────────┐
        │  keep monitoring    │    │  5. ALERT the right team  │
        │  (no action)        │    │  with topic, volume,      │
        └────────────────────┘    │  trend, sample calls      │
                                   └──────────────────────────┘

1. Ingest every interaction

Feed the system a live stream of what customers are contacting about — call transcripts, recognised intents, IVR reason capture, and chat messages. The richer and more real-time the feed, the earlier the warning.

2. Categorise with AI

An LLM reads each interaction and assigns it a reason category. Crucially, it isn't limited to a fixed list — it can recognise when something doesn't fit existing categories and label it as new or emerging. This is the difference between old keyword-based tagging (which can only find what you told it to look for) and AI categorisation (which can surface the thing you never anticipated). This builds directly on the idea of using an LLM to review 100% of interactions.

3. Establish what "normal" looks like

You can't spot an anomaly without a baseline. The system learns the normal volume for each topic by time of day, day of week, and season — so it knows that "billing questions rise every month-end" is expected, but "power outage" mentions at 10x their usual near-zero level is not.

4. Detect the genuine anomaly

This is the heart of it. An alert should only fire when a topic is both new/rare AND accelerating. That double test is what stops the system crying wolf:

• New or rare — the topic barely registered historically (so it's genuinely "out of the blue"), or is a brand-new category the AI just created.
• Rising sharply — its volume is climbing fast relative to its own baseline, not just ticking along.

A steady, known topic that's slightly up doesn't fire. A brand-new topic with two mentions doesn't fire. A new topic going from near-zero to a steep upward curve in 20 minutes — that fires.

5. Alert the right team, with context

An alert is only useful if it reaches someone who can act and tells them enough to act fast. A good alert includes the topic, current volume and trend, the region or segment affected, and a few representative call snippets so the team can instantly grasp what's happening. It routes to the relevant owner — operations for staffing, comms for messaging, the relevant product/ops team for the underlying issue.

Worked Example: A Regional Power Outage

Here's how it plays out in practice:

1. 08:40 — A power outage hits a city. A handful of customers start calling about services being down.
2. 08:45 — The AI categorises these calls. They don't fit neatly into existing reasons, so they cluster under a new emerging topic: "service down / no power in area."
3. 08:55 — The topic was near-zero historically but has gone from 2 to 40 calls in ten minutes, concentrated in one region. It trips both tests: new and accelerating.
4. 08:56 — An alert fires to the operations and comms teams: topic, the sharp trend line, the affected region, and three sample calls.
5. 09:00 — Before the queue has even peaked, ops flexes staffing and comms publishes a proactive message (IVR announcement, website banner, SMS) acknowledging the outage — deflecting a chunk of the incoming calls entirely.

Without the system, the same event is a nasty surprise discovered at 09:30 when the queue is already on fire. With it, you're ahead of the wave by half an hour — which in contact centre terms is the difference between a managed event and a bad day.

The Value

• Earlier response — react in minutes, not after the queue explodes.
• Proactive deflection — a timely "we know, we're on it" message stops many of the calls from ever reaching an agent.
• Protected experience — customers hit a calm, informed operation instead of a 30-minute wait.
• Better staffing decisions — ops gets a head start to flex resources.
• Cross-team signal — the contact centre becomes an early-warning sensor for the whole business, not just a place that absorbs the fallout.

What You Need to Build It

• A real-time interaction feed — transcripts, intents, or IVR reason capture, streamed rather than batched.
• An LLM categorisation step — to assign reasons and detect genuinely new topics.
• A baseline / anomaly model — to know what normal looks like per topic and detect the new-and-accelerating pattern.
• An alerting and routing layer — to notify the right team with enough context to act.
• Tuning discipline — thresholds calibrated so alerts are trusted, not muted. This is a classic case for continuous improvement.

Where This Fits

This is the proactive, sensing end of the AI-in-the-contact-centre spectrum — closely related to proactive service at the digital front door and part of the broader shift covered in 15 ways AI can transform your contact centre. It turns the contact centre from a passive absorber of surprises into an early-warning system for the whole organisation.

Explore More AI Use Cases

This is the first in a growing series of practical AI use cases for contact centres. Browse the full set on The AI Use Cases hub — new ones added over time. Got one you'd like to see covered? Get in touch.