What this means for your support inbox
- Routine questions, like billing or order status, get sorted and answered without anyone touching them.
- Anything the system is not sure about goes to a person with the whole conversation attached.
- Your team spends its time on the tickets that need a person.
Lab prototype, not a client deployment
Measured in our own test runs on support tickets we wrote to look like a real queue.
- Of test tickets resolved without a person
- ~50%
- Typical time to a first reply in prototype runs
- <5min
- Kept with every ticket handed to a person
- Full context
The problem
Support teams get more tickets than they can answer. Each ticket needs several steps: work out what it is about, send it to the right person, write a reply, and know when a person should take over. Most automation does one of those steps well and misses the others.
We wanted to see if separate parts, each doing one step, could handle a whole ticket. We also wanted the system to know when to stop and hand a ticket to a person.
What we built
We built a prototype with four parts, one for each step. The first works out what the ticket is about. The second sends it to the right person based on skills, workload, and urgency. The third drafts a reply from a set of help articles. The fourth checks how sure the others are and hands the ticket to a person when the system is not sure.
Every ticket carries its full history from step to step, so nothing gets lost.
What we found
Because tickets reach a person with the full history attached, nobody has to ask the customer to repeat themselves.
The hand-off step mattered most. Automation you can trust knows when it is not sure and passes the ticket on cleanly.
Using this with a real support team means tuning it to that team's help articles, its mix of tickets, and when it wants a person to step in. That tuning is most of the work in a real project.
Have a support inbox like this?
Tell us what you need. We'll write back with what we'd build.