AddThisFeature

AI Support Triage

Summarise each incoming support request and estimate how urgent it really is.

involved AI Assistants

What it adds

An automatic summary, urgency estimate, and likely problem area attached to every inbound support request, with the evidence behind each.

What your agent is told to do

5
  1. 1

    Run triage as a background job on arrival, using the app's existing queue and retry behaviour. The ticket must be visible and workable in its raw form the moment it lands, whether or not triage has finished.

  2. 2

    Produce three separate outputs — a short summary, an urgency level, and a likely problem area — and store each with the quoted source statements from the ticket that support it, so a human can check the reasoning.

  3. 3

    Define urgency in terms of business impact: who is blocked, how many, whether money or data is at risk. Compute it from what the ticket describes, not from how the writer sounds.

  4. 4

    Include an explicit unknown value in every classification, and a needs-human-review state that surfaces the ticket to a person rather than letting a low-confidence guess pass as fact.

  5. 5

    This brief owns the summary, urgency, and problem area only. Choosing the destination queue or specialist belongs to AI Ticket Routing, which consumes these outputs; do not write routing decisions here.

Edge cases it handles

8
  • Urgency and sentiment are different measurements. An angry message about a cosmetic issue is low urgency, and both must be modelled separately if sentiment is captured at all.
  • A calm, precise report of total data loss is the most urgent ticket in the queue. Politeness must never reduce priority, and this needs a deliberate test case, not an assumption.
  • A classification with no supporting quotes cannot be audited or appealed. If the model returns a level without evidence, treat the result as unknown rather than accepting it.
  • Forcing a confident label on an ambiguous ticket is worse than admitting uncertainty, because it removes the ticket from human attention. Unknown must be a first-class outcome that still gets seen.
  • Sensitive personal traits — inferred or stated — must never influence urgency. Exclude them from the context sent to the provider so they cannot be used implicitly.
  • A truncated or malformed structured response must fail the job cleanly and leave the ticket untriaged rather than persisting a half-parsed classification.
  • Ticket text is untrusted input. Instructions embedded in a customer message must never be able to change the urgency scale or the output format.
  • A flood of inbound tickets must not produce an unbounded spend. Apply a per-hour ceiling and let overflow queue for later triage rather than dropping tickets or billing without limit.

Definition of done

9
  • Every inbound ticket is workable immediately, with triage arriving asynchronously.
  • Summary, urgency, and problem area are stored separately, each with supporting quotes from the ticket.
  • Urgency reflects described impact and is unaffected by the tone of the message.
  • Unknown and needs-human-review are supported outcomes that keep the ticket visible to a person.
  • Malformed or truncated model output leaves the ticket untriaged rather than partially classified.
  • Triage volume is capped per hour and degrades to an untriaged queue when the model is unavailable.
  • Routing decisions are not made by this feature.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.