How I cut support handling time from 2 hours to 20 minutes a day

When I joined my current team, every agent started the day the same way. Open the inbox, read each message, work out what it was about, tag it, decide who should handle it, and only then start helping a customer. Measured honestly, that sorting took about two hours per agent per day. Today it takes about twenty minutes. This post is how that happened, including the version that did not work.

Where the two hours actually went

I did not start with a tool. I spent a week sitting next to the team and timing the loop. The two hours were not one task, they were four small ones repeated hundreds of times:

• Reading a message to understand the intent (delivery, billing, complaint, VIP, something else).
• Deciding the priority, usually by gut feel and by who had shouted loudest.
• Copying the details into the CRM and choosing an owner.
• Posting a note in the right Slack channel so the right team knew.

None of these needs a senior person. All of them need consistency, and that is exactly where people drift when the inbox is full.

The design: classify, gate, route

The workflow has three stages, and the order matters.

1. Classify. Each incoming message, whether it arrives from Slack, WhatsApp or email, goes to Claude with a short instruction and a fixed list of allowed labels. The model returns structured output: intent, priority, team, and a confidence score.
2. Gate. Before anything is written anywhere, a set of checks runs. Is the confidence at or above 0.90? Does the message contain personal data that must not be copied into a public channel? Is it a duplicate of a ticket that is already open? If any check fails, the message does not continue.
3. Route. Messages that pass create a ticket in HubSpot with an owner and a deadline, and the team channel in Slack gets a one-line summary with a link.

Messages that fail the gate go to a short human review queue. A person looks at them, fixes the label, and they continue down the same path. I have written more about the gate itself in the quality gate post and about the plumbing in the HubSpot, n8n and Claude walkthrough.

A worked example

An illustrative message arrives on WhatsApp Business:

my order 4821 was not collected, I'm waiting at the door

What the classifier sees is the message text, the channel, and the customer's tier from the CRM. It returns something like this:

• intent: delivery, not_collected
• priority: high
• team: delivery
• confidence: 0.94

The gate passes it: confidence is above the bar, there is no phone number or address that needs masking in the Slack post, and no open ticket exists for that order. A ticket is created in HubSpot, owned by the on-shift delivery agent, with a deadline measured in minutes rather than hours. The delivery channel in Slack shows the ticket link and a one-line summary. The customer gets a reply that was checked against the same rules as every other outbound message.

Compare that to a vaguer message: "hi, still waiting, any update?" The classifier cannot know which order or which problem, so confidence is low. That one goes to the human queue, where a person asks one clarifying question. This is the right outcome. The point of the gate is that the system knows when it is guessing.

What went wrong the first time

My first version had no gate. It classified and routed everything, and it was right most of the time, which turned out to be the dangerous part. Agents stopped checking it. Then a handful of wrong routings, mostly short or ambiguous messages, ended up in the wrong team's channel, and trust dropped faster than the time savings had built up.

Three changes fixed it:

• A confidence threshold, so ambiguous messages stop instead of being guessed.
• A duplicate check, because customers write twice when they are anxious and double tickets create double work.
• A daily QA sample of twenty routed items, scored by a person and fed back into the label instructions.

The result was a system the team was willing to rely on, which matters more than a headline accuracy figure.

Trade-offs I would be honest about

• The human queue is not free. Someone has to clear it every day. If it grows, the threshold is too high or the labels are too fine.
• A stricter threshold means fewer wrong routes and more manual work. I tune it by looking at what the QA sample finds, not by feel.
• Labels need an owner. If nobody maintains the list of intents, the classifier slowly drifts away from how the business actually talks.
• None of this replaces judgement on hard cases. It removes the sorting so agents spend their time on the conversations that need them.

Today the workflow handles routing for a stream of 100 to 200 messages a day, described in the Slack dispatch post, and the sorting that used to take two hours takes about twenty minutes.

What I would build for your team

I would start by timing the loop, not by choosing a tool. A week next to your agents tells me where the minutes go and which labels you actually need. Then I would build the smallest version with the gate already in it, run it beside the manual process for a short period, and compare the numbers in writing. You keep the dashboard, the runbook and the QA routine, so it does not depend on me being in the room.

Email: kodirovrukhillo@gmail.com