Resolution Agent

Automatic categorisation

Incoming requests are read and categorised as they arrive, from the language of the request rather than a dropdown the customer had to guess at — including the awkward ones that turn out to span more than one issue.

  • Categories applied on arrival, in real time
  • Read from the request, not chosen by the customer
  • Requests spanning several issues handled properly
  • The foundation routing and reporting depend on

Watch the full tour

Verify your work email once and every research paper, case study and product tour on ascendo.ai opens, right here, without leaving the page.

  • Takes about 30 seconds
  • Work email only, no spam

Everything downstream inherits this

Categorisation looks like housekeeping and it is not. Routing runs on it, prioritisation runs on it, and every trend report is a count of it. When the category is wrong, everything built on it is confidently wrong.

The usual method guarantees that. The customer picks from a dropdown without having diagnosed their problem, which is why “Other” is the largest category in most systems. A person reading every request is accurate and does not scale.

A five-row table of capabilities that depend on the issue category — routing, prioritisation, trend reports, driver ranking and root cause work — with what each produces when the category is wrong.
Nothing in this table fails loudly. Each one keeps producing an answer, and the answer is confidently wrong.

Categorising as the request arrives

Real time matters here: routing has to happen before anyone reads it.

  1. Step 1

    Read the request

    The category comes from what the request says, in whatever words the customer used, rather than from a field they filled in first.

  2. Step 2

    Apply the issue type

    Classification happens as the request lands, so routing has something reliable immediately rather than after a triage pass.

  3. Step 3

    Handle more than one issue

    Requests routinely span several things. Each is recognised rather than filed under whichever came first.

  4. Step 4

    Stay consistent at volume

    The same request is categorised the same way at nine in the morning or mid-spike, which makes the numbers comparable.

Four stages: the request read in the customer’s own words, an issue type applied as it lands, more than one issue recognised in a single message, and the same request classified consistently under load.
Classification happens before anybody reads the request, because routing cannot wait for a triage pass.

Why this is foundational rather than incremental

Four other capabilities are counting these labels.

This is the foundation, not a feature

Routing, trend analysis, driver ranking and root cause work are all downstream of the category. Getting it right is what makes the reporting mean anything.

Read, not selected

A dropdown measures what the customer guessed. A category read from the request measures what they asked, and the difference shows in the size of your “Other” bucket.

Multi-issue requests are the normal case

People rarely ask exactly one thing. One category per request loses the second half of every message containing two, and nobody notices.

An intake view listing four requests with the category the customer selected beside the one read from the message, including a request carrying two issues where the customer selected only one.
Row two contains a fault report and a billing query; the dropdown could only hold one of them, and the second half was quietly lost.

Why the usual approaches fall short

Two produce unreliable data and two produce it too late.

A category dropdown on the form

Asks the customer to classify a problem they have not diagnosed.

Keyword rules

Fire on words rather than meaning. The rule set grows forever and nobody wants to own it.

Manual triage

Accurate, and it spends capacity producing labels rather than resolutions.

Categorising later, in reporting

Produces a retrospective number and does nothing for the routing decision.

Two columns comparing a category dropdown, keyword rules, manual triage and categorising later in reporting with classification read from the request at intake.
Two of the alternatives produce data that is unreliable, and two produce it after the routing decision has already been made.

What things are called

Categorisation, intent and abstraction level are three separate decisions.

Categorisation
Assigning an issue type to a request from its content.
Intent
What the customer is trying to achieve, which is read before a category is applied.
Multi-issue request
A single message containing more than one thing to be handled.
Abstraction level
How coarse or fine the categories are, set separately from the categorisation itself.
Driver
A category ranked by the volume or impact it is generating.

Frequently Asked Questions

Accurate enough to act on, and not something to take on faith. Run it against requests your team has already triaged and compare. Where the two differ, one of them was wrong, and finding out which is a useful exercise whichever way it goes.

Where this fits

Ticket intent tour

What is read before a category is applied, and why the reading matters more than the label.

Category abstraction levels

How coarse or fine to set the categories, and what that does to your reporting.

TopDrivers

The ranked view built on these categories, by volume and by impact.

More Resolution Agent tours

All tours

Voice of the Customer

Compare it against your own triage

Send us a week of requests your team has already categorised. Where the two disagree is where your reporting is currently wrong.

Talk to us