Services
Ticket routing with SLA control for BRO Barbershop
AI sorts every customer message by category and priority, assigns an owner and raises the alarm on its own when a reply is overdue.
- Client
- BRO Barbershop, a chain of 4 barbershops
- Format
- Practice case
- Stack
- n8n, OpenAI GPT-5-mini, Gmail
- P1–P4priorities with response times from 15 min to a day
- 3escalation levels: owner, team lead, director
- 54automated tests of the logic before launch
The problem
In this case, BRO Barbershop is a chain of 4 barbershops. Customers write to a shared inbox about 400 times a month, and 65% of messages are routine: bookings, prices, opening hours. NPS has dropped from 56 to 38, and about 30 bookings a month are lost because the customer never got a reply.
All messages land in one queue. A complaint about a burn after a haircut sits next to a question about beard trim prices, and the difference only shows once someone opens the email. Nobody owns the ticket, response time is not tracked, and nobody finds out when a customer has waited too long.
The solution
One n8n workflow with two tracks.
Ticket intake. A new Gmail message → an AI classifier (GPT-5-mini with step-by-step reasoning) picks the category, priority P1–P4 and owner and briefly explains why → code validates the model’s answer → the ticket goes into Google Sheets and the owner gets a Telegram message.
SLA Watcher. Every 5 minutes n8n checks open tickets. If the response time has passed, an escalation chain starts: a reminder to the owner → team leads after 30 minutes → an email to the director with full context after 60 minutes. Each level fires only once.
AI suggests, code decides. The model is good at reading tone and context, but it can be wrong. So the rules that must never be broken live in code, not in the prompt: legal or medical risk is always P1, complaints and VIP customers are never below P2, and response time and owner come from a fixed table. If the AI fails, the ticket is not lost: it gets P2 and a flag for manual review. The email text is isolated from the instructions, so the model never follows commands hidden in a message.
| Priority | Response time | Example |
|---|---|---|
| P1 | 15 min | burn after a treatment, a lawyer is mentioned |
| P2 | 60 min | complaint, same-day booking, VIP |
| P3 | 4 hours | booking for later dates |
| P4 | 24 hours | prices, hours, thank-you notes |
Quality checks
The logic is covered by 54 automated tests: email parsing, priority rules, SLA, owners, duplicate escalations, date formats, time zones and AI failure. To test the tests themselves, the code was deliberately broken in 21 ways, and the tests caught all 21. A time zone test found a real bug in the deadline calculation, which was fixed before launch.
The business outcomes (NPS recovery, fewer lost bookings) are pilot goals. Only several weeks of real use can confirm them.
How the work went
How work on this project went, from understanding the problem to launch and improvements.
- 01
Discovery
Worked through the case inputs: about 400 messages a month, 65% routine, NPS down from 56 to 38 and about 30 lost bookings a month.
- 02
Solution design
Built a P1–P4 priority table with response times and owners, decided which rules live in code rather than in the AI, and set up a 3-level escalation chain.
- 03
Build
Built two tracks in n8n: ticket intake with an AI classifier, and an SLA Watcher that checks open tickets every 5 minutes.
- 04
Testing
54 automated tests of the logic and 21 deliberate code breaks the tests had to catch. A time zone test found a real bug in the deadline calculation.
- 05
Launch
Ran the workflow on test emails: tickets are logged in Google Sheets and owners get the priority explained in Telegram.
- 06
Optimisation
The time zone bug was fixed before launch. Next comes a pilot of a few weeks to check NPS and lost bookings on real data.
Screenshots
Owner alert explaining the priority
Ticket log in Google Sheets