The problem
Support ticket routing is the day-one productivity hit for any SaaS team. Tickets land in a single inbox; someone has to read them, decide which team owns them, mark the priority, tag the topic, and route to the right responder. On a busy product, that triage role consumes hours of senior engineer time per day — and the cost of a misrouting (a P1 stuck in the wrong queue overnight) is the kind of thing that turns up in postmortems.
The decision is regular. The same kind of ticket from the same kind of customer routes to the same team most of the time. Title, description, customer segment, product area, priority — all available, all correlated with the routing decision. The data already contains the answer for the next ticket; the team is just reading it manually.
How it works
A single _predict on the tickets table predicts the team, the priority, and the tag from the available fields (title, description, customer, product area). Confidence-tiered: above 95%, auto-route. Between 50% and 95%, pre-route to the suggested team and surface the alternatives. Below 50%, leave for manual triage.
The system updates from corrections. When a manual triage moves a ticket from "wrongly auto-routed to Team A" to "correct team B," the override enters the index immediately and the next similar ticket reflects the correction. No retraining schedule; just normal data flow. Tilisi's deployment runs this pattern in Freshdesk and recovered 4 hours per week of CEO time by eliminating manual routing rules.
{
"from": "tickets",
"where": {
"title": "App crashes on iOS 17",
"description": "Customer reports white screen after login",
"customer.segment": "enterprise"
},
"predict": ["team", "priority", "tag"],
"select": ["$p", "$why"],
"limit": 1
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛍 Grocery demo today. Click through to the live application and inspect the queries that produce the result. Source is on GitHub under Apache 2.0.
Frequently asked
How does this compare to keyword-rule-based ticket routing?
Keyword rules ("if title contains 'login', route to Auth team") work on the easy cases and miss the rest. The same description rephrased ("user can't get in", "session won't start", "auth flow broken") confuses keyword rules, but the predictive system reads them as the same intent through the underlying word distributions. The two are complementary: rules for clear cases, predictive for the long tail.
What if our ticket volume is low — around 100 a month?
The conditional probability machinery is data-density-sensitive but not data-volume-sensitive in the obvious way. At 100 tickets/month, after 3 months you have ~300 tickets — enough for the most common routing patterns to converge. New ticket types still take 3-5 observations to reach auto-route confidence; below that the system stays in suggest-mode. Low-volume teams get less auto-routing but the same accuracy on what they do auto-route.
Can the system handle multi-language tickets?
Yes, in two senses. First, the predictive operators work on whatever language the data is in — Aito does not require translation. Second, predictions are independent per language; a ticket in Finnish routes based on Finnish-language patterns, a ticket in English on English-language patterns. If your team handles multiple languages, the system learns the routing pattern per language automatically.
How do we handle tickets that span multiple teams?
The prediction returns top-N teams with calibrated confidences. If two teams are close (50% / 40%), the ticket can be flagged as "needs multi-team triage" with both surfaced. The application can route to a triage queue, ping both teams, or default to one with the other CC'd — application-level decision, not a prediction problem.
Does this integrate with Zendesk, Freshdesk, or Intercom?
Yes. Aito returns the prediction as JSON; any RPA tool, webhook, or direct integration with the ticketing platform can act on the prediction. Tilisi runs ticket routing on a Freshdesk + Aito stack; other deployments use UiPath as the orchestration layer.
