Paste one customer message, keep or edit the department rules, and run. The result is one team label plus a probability for each category. It is not a drafted reply.
Default rules
Billing covers payments, duplicate charges, invoices, and refunds. Technical covers errors, outages, and broken features. Sales covers questions before a purchase. Other is the path for anything that does not fit, including messages you do not want forced into a team.
The clear example sends this request. Probabilities are not part of the request. They come back from a run.
{
"state": {
"message": "I paid twice for order 4821. Could you refund the extra payment?"
},
"questions": {
"department": {
"type": "choice",
"instructions": "Choose the team that should handle this customer request.",
"criteria": {
"billing": "Payments, duplicate charges, invoices, and refunds",
"technical": "Errors, outages, and broken product features",
"sales": "Questions before purchasing a product or plan",
"other": "Requests outside the categories above"
}
}
}
}Write rules that match the decision
Overlapping categories. Say which team wins. “Refund plus an outage” can be billing if the refund is the action, or technical if the outage is the action. Put that priority in the descriptions. The model only sees the text you write there.
Two requests in one ticket. This page is a single choice. It will not return both billing and technical. If you need both, split the message or add another question after the first run. Do not describe a single-label result as multi-label tagging.
Not enough to route. Keep “other” as a real bucket. Forcing a team because the form required an answer is how a vague note becomes a confident misroute.
Recorded calls
One call each on 2026-09-29 to the official Space convaiinnovations/laya-demo, playground endpoint, state {"message": "..."} and the question shown on that tool. The model field came back as laya. latency_ms is the Space response field, not this website's end-to-end time and not the upstream GPU figure. A later call can differ. These six calls are not an accuracy score.
A clear refund request
I paid twice for order 4821. Could you refund the extra payment?
Human reference. Billing. A reviewer would send this to the team that handles payments and refunds.
This call returned. billing. Model field laya. Space-reported latency 112.9 ms. Input tokens 84. Confidence 0.6371. Date 2026-09-29. Space convaiinnovations/laya-demo.
- billing: 0.8777
- other: 0.0498
- sales: 0.0434
- technical: 0.0291
The label matches the human reference on this one message. That is not a measured accuracy rate for the template.
A crash and a duplicate charge
The app crashes when I open invoices, and I was also charged twice. Can someone fix the crash and refund the extra charge?
Human reference. Both technical and billing. The question asks for one team. A reviewer could defend billing because of the refund, while the crash still needs technical help.
This call returned. billing. Model field laya. Space-reported latency 123.2 ms. Input tokens 96. Confidence 0.2999. Date 2026-09-29. Space convaiinnovations/laya-demo.
- billing: 0.5944
- technical: 0.3036
- other: 0.0656
- sales: 0.0364
A single choice cannot hold two requests. Technical still received 0.3036. The low confidence figure is distribution concentration, not a calibrated chance that billing is correct.
A negation about a refund
Please do not refund order 4821. The second charge was intentional and covers next month.
Human reference. The payment topic still belongs with billing, but the customer is refusing a refund. Billing here must not be read as 'refund requested'.
This call returned. billing. Model field laya. Space-reported latency 103.5 ms. Input tokens 87. Confidence 0.4063. Date 2026-09-29. Space convaiinnovations/laya-demo.
- billing: 0.7556
- other: 0.0923
- sales: 0.0826
- technical: 0.0696
This call does not show that the model understood 'do not refund'. The billing description mentions refunds, so the word refund can pull the label. Add a separate yes/no question if you need the intent, and review negations before acting.
Limits and next step
- Long text is blocked when the rough English budget is exceeded. The site does not silently truncate.
- The interface is English. Non-English routing on the Space is not validated here.
- A probability is a prediction. There is no site-wide cutoff that means “safe to refund”.
Copy the decision rules from the tool if you want to keep them. Account save and CSV batch are not built. The playground shows the JSON and the raw response. Feedback is a different label set on the customer feedback classifier.
Questions
- Does this pick more than one department?
- No. The default question is a single choice. A ticket that asks for a fix and a refund still gets one label. After a first run you can add an urgency score and a yes/no refund question. Those are extra questions, not multi-label tagging.
- What if the categories overlap?
- Write the boundary into the description. If a refund that mentions an outage should go to billing, say that in the billing description and say the technical category is for faults with no payment request.
- What if the message says not to refund?
- A recorded call on 29 Sep 2026 still labeled a “do not refund” note as billing, because the text is about a payment. That label does not mean the model understood the negation. Add a separate yes/no question and review it.