Ask a sales leader why inbound is slow and you will hear a headcount answer. Not enough SDRs, the team is buried, we are hiring in Q3.
Then watch what an SDR actually does for an hour. They open a message, work out what kind of message it is, decide whether it is real, look up the company, decide who should own it, and paste a reply from a doc. Four of those five steps have a correct answer that does not depend on the person doing them.
That is not a staffing shortage. That is a person standing in for a system nobody built, and it is expensive in a way that is easy to miss, because a busy person looks like progress.
Who this is for: anyone whose inbound goes to a shared inbox, gets read by a human first, and gets answered in hours rather than minutes.
The claim
Speed is worth more than quality, well past the point most teams stop believing it.
A reply that arrives while someone is still on your site is doing something a better-written reply an hour later cannot do. The interest is gone by then. Every meaningful inbound improvement I have shipped came from collapsing the delay, not from improving the message.
That is why the headcount instinct backfires. Hiring adds throughput to a queue. It does not remove the queue.
The mechanics
Four parts, in order. The order matters more than the tooling.
1. Classify, and admit uncertainty. Every inbound message gets sorted into a real category, not “lead” or “not lead.” At Alpha Apex the categories were things like candidate, search opportunity, consulting, capital raise, partner outreach. This is genuinely ambiguous work and it is what a language model is actually good at.
Get a confidence score out of it and use it. A classifier that says 0.94 and one that says 0.51 should not produce the same behaviour. Most of the value of a classifier is knowing when to stop trusting it, and a low-confidence item going to a human is a success, not a failure.
2. Route with rules, not with the model. Once you know what something is, where it goes is a business decision with a correct answer. Encode it.
This is the line people get wrong most often. Handing routing to an LLM buys you unpredictability and pays you nothing, because there was no ambiguity left to resolve. Classification is fuzzy, so use a model. Routing is a rule, so use code.
3. Draft the reply, do not send it blind. Generate a tailored first response using what the classifier found. Whether it goes out automatically depends on how reversible it is. A “thanks, here is the link to book time” is cheap to get wrong. A pricing answer is not.
4. Notify with the context and the actions attached. The Slack message should carry what the lead said, what the system concluded, and buttons for the two or three things a human might want to do. If a rep has to open a CRM to act, they will do it later, and later is the problem you started with.
Add global error handling before you turn any of it on. The worst failure in an inbound system is silent: a lead that vanishes and never pages anyone costs more than a crash, because nobody learns about it.
What changes
At Alpha Apex this gave the team back more than six hours a day and revenue grew 45% over three months. The messages were not better. They were early.
The second-order effect was the one nobody predicted. Once the routing was explicit, the disagreements about who owned what stopped being personal. The rule was in a file. You could argue with the file.
What I would do differently
I built the classifier before I had agreement on the categories, and paid for it twice. The taxonomy is the actual design work. The model is the easy part, and changing categories later means re-labelling everything you have already processed.
I also let the first version auto-send too much. The rollback was fine, but the trust cost took longer to repair than the code did. Start with drafts and a human confirming, then remove the confirmation where the action turns out to be cheap. Going that direction is easy. The other direction is not.