Triage that routes on evidence, not on keywords

Most support automation is a keyword rule with a nice interface. The failure mode is quiet: the angry enterprise customer whose message did not contain the word urgent waits in the same queue as everyone else.

Book Enterprise DemoSee pricing

The situation

A B2B platform team handles 400 tickets a week across email, in-app chat, and a shared Slack Connect channel with its largest accounts. Severity drives the SLA clock, and the SLA is contractual. Getting severity wrong in either direction is expensive: too low breaches an agreement, too high wakes an engineer at 3 a.m. for a cosmetic bug.

  • Severity by keyword match

    The current rule promotes anything containing down, urgent, or broken. A message reading 'our nightly sync has produced no rows since Tuesday and finance closes tomorrow' contains none of those words and sits in the general queue for nine hours.

  • Routing that ignores the contract

    Triage happens before anyone checks which plan the account is on. An enterprise customer with a four-hour SLA and a free-tier user filing the same complaint are treated identically until a human notices.

  • Whole tickets pasted into a model

    Teams that do use AI for triage typically send the full thread — customer name, email, and any log excerpt the customer attached, which routinely includes tokens and internal hostnames — to whichever model the vendor chose.

  • Automation that makes commitments

    A well-meaning auto-reply that says a fix is coming this week is a customer-visible promise nobody approved. It is the one class of automated message that can create an obligation.

The workflow

Every step names the control that applies to it. The steps marked Human are the points where the workflow stops and waits for a person — by design, not because the automation is incomplete.

WhatsApp → CRM → Approval → Google Sheets

  1. 01 / 07System

    Collect from every channel into one thread

    Email, in-app chat, and the shared Slack channel resolve to a single ticket keyed on account and subject, so the same incident reported by three people at one customer does not become three severities.

    One ticket per incident, keyed on account

  2. 02 / 07System

    Redact before inference

    Names, email addresses, phone numbers, and anything matching a token or key pattern are replaced with typed placeholders before the model sees the text. The mapping stays in your tenancy, so the reply can be rehydrated without the model ever holding the original.

    Typed redaction, mapping never leaves the tenancy

  3. 03 / 07System

    AI proposes severity with its reasoning

    The model returns a severity, the phrase that drove it, and a confidence. Because it reads meaning rather than keywords, 'no rows since Tuesday and finance closes tomorrow' surfaces as a business-impacting failure with its justification attached.

    Severity plus cited evidence, never a bare label

  4. 04 / 07System

    Apply entitlement and SLA

    Reads the account's plan, contractual response window, and named support contacts, then combines them with the proposed severity. Entitlement is applied deterministically after inference, so a model error cannot silently downgrade a contractual SLA.

    Contract data applied after inference, not by the model

  5. 05 / 07Human

    On-call engineer confirms anything page-worthy

    Severity 1 and 2 require a human to accept ownership before a page fires. The engineer sees the redacted thread, the proposed severity with its cited evidence, the account entitlement, and similar recent tickets.

    Human accepts ownership before any page

  6. 06 / 07Human

    Approve the customer-visible acknowledgement

    The draft reply confirms receipt and states the applicable response window. It never asserts a cause, a fix, or a date. Anything beyond acknowledgement is written by the owner, because a commitment is not an automatable act.

    Acknowledgement only; commitments are written by a person

  7. 07 / 07System

    Record the decision chain

    Writes the proposed severity, the final severity, who changed it and why, the entitlement applied, and the acknowledgement sent. Over a quarter this becomes the dataset that shows where triage is actually miscalibrated.

    Proposed versus final severity retained for review

Controls

Step-level controls stop a single action. These apply to the workflow as a whole, which is what makes the difference between a logic error and an incident.

  • Automated messages cannot make commitments

    The workflow may acknowledge and state a contractual window. Cause, fix, and date are outside what any automated reply is permitted to assert, so no automation can create an obligation your engineers did not agree to.

  • Redaction happens before the model call

    Not after, and not as a post-processing filter on the response. The prompt that leaves your tenancy contains typed placeholders, so a customer's pasted access token is not in it.

  • Proposed and final severity are both kept

    Every human override is retained with its reason, which turns triage quality into something measurable. The pattern that a model consistently under-rates data-integrity issues becomes visible rather than anecdotal.

  • SLA is arithmetic, not inference

    Response windows come from contract data through a deterministic rule. The model influences severity and nothing else, so the contractual clock is never the output of a probabilistic step.

The shape of the change

Each row states what the controls make possible or impossible, rather than a measured saving. The change is structural: the same work, with the risky path closed off.

  • Business-impacting tickets missed by keyword rules

    WasFound when the customer escalates

    Surfaced with cited evidence

  • Customer identifiers sent to a model

    WasWhole thread

    Typed placeholders

  • Pages fired without a named owner

    WasWhoever is on rotation

    None

Other workflows

The same controls apply across every use case. Only the steps and the thresholds change.