Running an AI support desk
Inbound mail into tickets, a model that classifies rather than replies, and the traps that turn a support desk into a machine talking to machines.
A support desk is three moving parts: something that receives mail, something that turns it into a conversation, and something that decides whether to interrupt you. Adding a language model helps with the third and makes the second more dangerous, because a bad classification can now lose a customer''s message rather than just misfile it.
The architecture that survives keeps receipt and triage separate. Get the message safely into a conversation first. Classify afterwards. If the model fails, you still have the ticket.
Use the model as a classifier, not an author. Ask for a small fixed set of categories and a priority, returned as structured output you can act on mechanically. Label, prioritise, alert on the urgent ones. The value is not the intelligence, it is that everything arrives sorted.
Threading is where implementations fail. Getting the first message in is easy. Keeping the reply attached to the same conversation needs more than one signal, and deduplication needs to be explicit, because webhooks get retried and one email becomes three tickets.
Machine mail is the recurring embarrassment. Notification senders, delivery reports and your own outbound copies will all open tickets unless deliberately excluded, and the obvious filter misses most of them. A desk that answers a no-reply address is a desk arguing with a robot on your behalf.
And behind all of it sits deliverability, which fails silently in both directions and is the first thing to check when something "is not arriving".
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.