01 · The Sentinel Spire · Support · Machine learning
Support Ticket Triage Assistant
Outcome
A working prototype that labels, prioritises and routes incoming support tickets, and explains each decision.
Status and role
- Status
- Working prototype on demo data. Fictional project for this template.
- Context
- Hackathon project
Stack
- Backend
- Python
- FastAPI
- Uvicorn
- SQLite
- Machine learning
- scikit-learn (logistic regression)
- sentence-transformers
- pandas
- Frontend
- React
- Vite
- Tailwind CSS
- TanStack Query
Links
The problem
A small support team shares one inbox. Every ticket has to be read before anyone knows whether it is a billing question, a broken login or a feature request, and the urgent ones wait behind the routine ones while that happens.
A plain keyword filter is easy to explain but misses anything phrased differently; a classifier alone catches more but cannot say why, and the team would not trust a queue it cannot question. The aim was a router that is right most of the time and always shows its reasons.
What I built
API layer
A FastAPI service with one endpoint per intake channel and a single response shape, so the queue view never has to care where a ticket came from.
Signal engines
Keyword rules live in a plain configuration file the support lead can edit. The classifier is a logistic regression over sentence embeddings, small enough to retrain in a minute.
Queue view
A React app lists tickets by queue and priority. Opening one shows the marked phrases behind every label, so a wrong decision is easy to spot and correct.
Intake
Tickets arrive from the help form and the support inbox.
- Help form
Clean
Signatures, quoted replies and tracking footers are stripped so only the customer's words are scored.
Signals
Each source scores the ticket on its own.
- Keyword rules
- Sentence-embedding classifier
- Account plan and history
Decide
Rules set the base labels; the classifier adds labels it is confident about; the plan sets the response target.
Route
The ticket lands in its queue with its labels, its priority and the phrases that decided them.
The hard part
Rules first, model second
The classifier can add a label but not remove one the rules set. A confident but wrong model cannot hide an urgent ticket.
Corrections become training data
When an agent moves a ticket to another queue, the move is stored and used in the next retraining run.
Local inference
Ticket text never leaves the server. The embedding model runs on the same machine as the API.
Result
Tested against a hand-labelled demo set of support tickets written for this project.
Fictional project: no real accuracy figures exist, so none are given.
Limits and next steps
Limitations
- English only.
- No integration with a real help desk; tickets are imported from files.
- The classifier needs a few hundred labelled tickets before it adds much over the rules.
Next steps
- Connect to a help-desk API.
- Add a confidence threshold below which tickets go to a human first.
- Track how often agents re-route tickets.