Can AI Safely Route Support Tickets? A Perplexity Decider Example

Graphic: Perplexity. Official documentation artwork; not a screenshot of a tested ticket-routing system.

A support ticket says the customer was charged twice, the parcel has not arrived and they need help before an event. Sending it to “shipping” might look plausible. It might also hide the billing problem and the urgency. AI routing becomes useful when it handles this ambiguity visibly, rather than simply replacing a person with a category label.

This is an invented support scenario, not a client case or a test of Perplexity Decider. It illustrates a narrower question: what would a team need to establish before letting a model choose the next queue?

A decision model supplies evidence for a route

On October 16, Vercel announced Perplexity Decider V1.2 and Decider Flash V1.2 on AI Gateway. Vercel describes models that answer defined Boolean, Choice and Score questions over inputs including text, records and images. These are vendor-described capabilities, not evidence that a particular support process is accurate or safe.

In a routing application, classification means assigning an input to a defined category. The application must supply categories with useful boundaries. “Billing” and “shipping” are inadequate if a ticket can need both. A separate urgency question can be clearer than forcing every concern into one exclusive choice.

Routing is the rule that selects the next destination. The model’s proposed category is one input to that rule. Customer status, an existing open case and a mandatory escalation policy may legitimately override it.

A probability is not a permission

A numerical confidence output can look more dependable than a sentence. However, it does not establish how often the model is right on your tickets. Before using a threshold, examine whether the reported probabilities correspond to observed correctness on representative, independently labelled examples.

Include difficult cases: short messages, several issues in one ticket, missing order details, unfamiliar product names and the languages customers actually use. Resolve disagreements between human reviewers rather than treating an inconsistent label set as unquestionable truth. Keep the evaluation examples separate from the examples used to refine the routing instructions.

Count failures by consequence, not only by their average frequency. A routine delivery question sent to the wrong queue and an urgent account-security report missed entirely should not cancel each other out in a single accuracy score. An apparently strong overall result can conceal poor handling of an important minority of cases.

Design a useful “not sure” path

For the fictional mixed ticket, the system could propose billing and delivery concerns, preserve the original message and request human triage. That is a design proposal, not a claimed Decider response. The reviewer needs the relevant evidence, the proposed destination and the reason the case was escalated—not merely a confidence number.

A human-in-the-loop step is meaningful only when the person can understand and change the decision. Define who owns the escalation queue, how urgent work reaches them and what happens when nobody is available. Otherwise “send for review” can become a polite name for losing the ticket.

Keep triage separate from business actions

Suggesting a queue does not authorize a refund, close an account or promise a delivery date. Start with a mode that records proposed routes alongside ordinary triage. Compare them before allowing selected low-risk decisions to affect live work. Preserve a straightforward manual route when the service fails or the input falls outside the agreed scope.

Use synthetic or appropriately approved, minimized examples while evaluating. Verify the actual provider route, retention terms, access controls and logs before sending customer information. A gateway’s general privacy features do not establish that every model route has the same conditions. No customer data was submitted for this article.

Measure the help, not just the classification

Look for fewer avoidable transfers, correct urgent escalations and faster useful handling—not merely fewer human clicks. Review overrides and unresolved tickets, and compare compatible ticket groups. A policy change or a surge in one kind of enquiry can alter the mix without the model improving.

The broader guide to where human approval helps explains the control boundary. For an evaluation plan, use checks before an AI system can act. Decider makes this a timely example; the responsibility for the routing system still belongs to the team operating it.