Support Ticket Triage and Answer Suggestion

Every support queue does the same three things: understand the message, find who or what should handle it, and — for the recurring questions — answer it from a known-good template. Aito v2 does all three as queries over your ticket history: the incoming text is evidence, the historical resolutions are the training data, and there is no model to deploy between them.

Suggest an answer from resolved history

prompts is the message history; answered questions carry the resolved answer. The reliable way to suggest a reply is retrieval: rank the answered history by relevance to the incoming message with BM25 search, and surface the closest resolved tickets and the answer they were given.

{
  "from": "prompts",
  "search": { "field": "prompt", "text": "refund" },
  "select": ["prompt", "answer", "$highlight"],
  "limit": 3
}

{ "offset": 0, "total": 10, "hits": [
  { "answer": 40, "prompt": "What is the refund processing time?" },
  { "answer": 1, "prompt": "The refund process took too long." },
  { "answer": 1, "prompt": "The refund process took too long." } ] }

The top three do not agree, and their order means little. Six of the ten matches tie on the same score ($score 3.95): a one-word query gives BM25 nothing to separate them, so the three returned are just the first of the tie. The first carries answer 40, the refund-timing template. The other two carry answer 1, the order-placing template, which the history attached to the complaint "The refund process took too long." Across all six tied matches, answer 1 appears four times and answer 40 twice.

So do not take the top hit as the suggestion when the leaders tie. Search with more of the incoming message and the scores separate: "text": "refund time" returns one match, "What is the refund processing time?", with answer 40. Then suggest that answer, with the supporting tickets attached for the agent to confirm.

Retrieval is the right tool here rather than predict "answer". With dozens of distinct answers and only a few example questions each, direct classification has too little per-answer signal to beat the prior; ranked similarity over the resolved history does not need that per-class density. Use predict for the low-cardinality routing decisions below (type, category, assignee), and retrieval for the open-ended "which known answer".

Classify the message

Route by predicted type or category — plain single-label classification from text:

{
  "from": "prompts",
  "where": { "prompt": { "$match": "the app crashes when I pay" } },
  "predict": "type",
  "select": ["$value", "$p", "$why"],
  "limit": 2
}

$why cites which tokens drove the classification — visible reasoning for the agent who reviews the queue.

Search the history

The same text column is BM25-searchable for agent-assist ("show me similar past tickets"), with full boolean syntax:

{
  "from": "prompts",
  "where": { "prompt": { "$search": "(refund OR return) -subscription" } },
  "select": ["prompt", "type"],
  "limit": 5
}

Why Aito for this

Cold-start friendly. Answer suggestions come straight from the resolved history — even a single similar past ticket is retrievable, and every new resolution improves the next suggestion without a retraining cycle.
Right tool per job. predict for the low-cardinality routing calls (type, category, assignee) where each class has plenty of examples; ranked search retrieval for the open-ended "which known answer" over a large, thinly-exemplified answer set.
Explainable classification — $why on every predict, and $highlight on every retrieval, so the agent sees the tokens behind each suggestion.

← All v2 use cases