Skip to main content
Process automation

The Ticket Queue That Routes Itself

Intake, assignment, and every client update automated around the ticketing platform they already owned. One person stopped being the router, and nobody had to write a status email again.

Client services team
Client
Process automation
Engagement
Workflow Automation
Service
On submit
Tickets reach the right person the moment the form is sent
5 stages
Points where the client is updated without anyone writing an email
0
Platforms replaced. The ticketing system stayed exactly where it was

The challenge

What we walked into

Every ticket that came in landed with one person, who read it, worked out which team it belonged to, decided who had capacity, and assigned it by hand. Nothing moved until they had done that. When they were in a meeting, tickets waited. When they were on holiday, the queue backed up for a week and clients heard nothing at all.

One person was the entire routing layer

The ticketing platform was fine. That is worth saying first, because the instinct in this situation is to blame the tool and go shopping. The tool held tickets, tracked status, and reported perfectly well. What it did not do was decide who should pick something up, and that decision had quietly become one person entire morning.

They were good at it. That was part of the problem. Because they knew which team handled which request type and who was already buried, the routing knowledge lived in their head rather than anywhere written down. The queue moved at exactly the speed of one human reading it.

The failure mode was predictable and kept happening. Any day that person was unavailable, tickets sat unassigned. Clients did not know whether their request had been received, so they emailed to ask, which produced more inbound for the same person to handle.

Routing is a decision, and decisions can be written down

We started by extracting what that person was actually doing. Not what the process document said, but the real logic: this request type always goes to that team, this kind of client goes to the senior person, anything mentioning billing gets handled separately regardless of what the client selected.

That produced a routing table. Once the rules existed as data rather than as expertise, the intake form could do the work. The form asks the questions that determine routing, and the answers drive assignment directly, so the ticket lands on the right person at submission rather than after a triage pass.

The rules stayed editable, because routing logic is never finished. Teams change, people leave, new request types appear. A rules engine that requires a developer to adjust becomes wrong within a quarter and then gets worked around.

The client hears something immediately

The moment a ticket is submitted, the client gets confirmation that it arrived, what it was logged as, and a realistic expectation of how long that type of request takes. That acknowledgement alone removed a meaningful share of the inbound email, because most of those follow-ups were people checking whether their request had vanished.

Assignment triggers the next message, and it names the person. Not a queue, not a department, a name. Being told that Natalie has your ticket and will pick it up shortly is a different experience from being told your ticket is in the queue, even when the wait is identical.

That detail took almost no engineering and changed the tone of the whole thing more than anything else we built.

Every stage speaks for itself

When work finishes and the ticket enters quality control, the client is told that too, and told what quality control means: someone is reviewing the work to check nothing was missed and that it meets the standard before it comes back.

That message was the one the team was most sceptical about and the one clients responded to best. It reframes a delay as diligence. Silence during review reads as being ignored; being told the work is under review reads as care.

When QC approves, the closing message goes out automatically, confirming the work is complete and inviting anything else. Nobody on the team writes any of these. They fire off the status the platform already tracks.

We did not touch the platform

No migration, no replacement, no retraining on new software. The team works in the same system they worked in before, and the entire build sits around it: the intake form feeding it, the routing logic assigning within it, and the messages triggered by the status changes it was already recording.

The automation itself runs on Make, which is what this client already had a subscription to. We do not have a preferred platform, and the answer has been Zapier and n8n on other engagements depending on what the team already paid for and could maintain.

That was a deliberate scope decision. A replacement would have cost several times as much, put the queue at risk during the transition, and solved a problem the platform never had. What was missing was the connective tissue, and connective tissue is much cheaper to build than a system of record.

How we went at it

  • Extracted the real routing logic from the person who had been doing it by hand
  • Turned that logic into an editable rules table instead of hard-coded branching
  • Rebuilt intake so the form captures exactly what routing needs to decide
  • Attached client messaging to the status changes the platform already tracked
  • Deliberately left the ticketing platform itself untouched

What we handed over

  • A structured intake form that drives assignment directly
  • Rules-based routing to the correct person and team on submission
  • Immediate acknowledgement with a realistic expectation for that request type
  • Assignment notification naming the person who owns the ticket
  • Quality control and completion notifications fired by status change
  • An editable rules table the team maintains without a developer

What happened next

  • Tickets stopped waiting on one person being at their desk
  • Holiday and sick days no longer backed the queue up for a week
  • Chasing emails dropped because clients knew where their ticket stood
  • Routing knowledge moved out of one head and into something maintainable

Capabilities

  • Workflow design
  • Rules-based routing
  • Automated client communication
  • Systems integration

Built on

  • Their existing ticketing platform
  • Make
  • Custom intake form
  • Webhooks and REST APIs
  • Transactional email

Find out what should actually be built.

Start with an assessment. We walk your business end to end and show you where automation and AI pay off, ranked by what they are worth.