At Sucuri, roughly 80% of our team sat in support and billing. We did that on purpose. We believed in solving customer problems with people, and for a long time it worked better than it had any right to.
It also taught me something that took years and a lot of payroll to see clearly. The problem with solving support with people isn't that people are bad at support. Ours were excellent. The problem is that people beget people, and what you get for the second hundred isn't what you got for the first ten.
Here's what I built instead. Three separate paths that reach a customer, every one of them crossing a single gate, over one shared memory they all read from and write back to. The rest of this article explains how it got there.
The multiplier runs backwards
Every person you add to a support organization multiplies conversations. None of them multiply learning.
Think about what happens when one of our people worked a hard ticket. They diagnosed something subtle, they found the gap our documentation never covered, and they wrote a careful answer. The customer was happy. The ticket closed. And that agent now knew something the company didn't.
For that to become organizational, somebody has to stop, write it up, put it somewhere findable, and then somebody else has to go find it. Four steps, two people minimum, and every one of those steps competes with a queue that's still filling. So the write-up doesn't happen. Not because anyone is lazy, but because the queue is a real obligation and the write-up is a theoretical one.
Now run a thousand tickets a week through that. Every single one is a chance to learn something and almost none of them get taken. Capacity scales with headcount. Memory doesn't scale at all.
I kept solving for capacity, because capacity is the thing you can count. The queue is long, so add a person, and the queue gets shorter. It works every time, which is exactly why it hides what's actually breaking. We weren't getting smarter, we were getting wider.
In fairness to my younger self, it wasn't only a framing problem. The technology wasn't there either, and we did try. We built with supervised and unsupervised machine learning (this was years before anything like today's models), and we got real value out of it for classification and for finding patterns across a large body of tickets. What we could never get was granularity. Those models could tell you a cluster of tickets belonged together. They couldn't read one ticket, understand the specific thing this specific customer had misconfigured, and produce an answer an agent would put their name on. That gap is what has closed, and it's why this design is possible now and genuinely wasn't then.
What happens if I get hit by a bus
When I rebuilt this, the question at the center of the design wasn't how to answer tickets faster. Answering was never the broken part. What happens if I get hit by a bus tomorrow?
Not as a morbid thought experiment. As a design constraint. Everyone who's been good at this job accumulates a kind of pattern recognition nobody ever writes down. They can tell what's actually wrong from the way a customer describes it, long before the diagnostics confirm it, and they know which answers we simply don't have yet. Almost none of that lives anywhere but in their head, and all of it walks out of the building on the day they do.
So the requirement was never speed. How do I institutionalize what the people here know, so it outlives any one of them, including me?
Three tiers, and you cannot tell which one answered you
Tier one runs on its own schedule, without being asked. It starts with the boring deterministic work: filtering noise, ignoring anything it has already looked at, catching the tickets that need a clarifying question rather than an answer. There is no model anywhere in that part, and there does not need to be.
Then it retrieves. It searches our own documentation and pulls back the passages that actually bear on this ticket, along with the real URLs. Pure vector math, no model. Nothing else in the system matters as much, because this is the difference between an assistant that knows things and one that invents them.
Only then does a model read the ticket, once, and draft a reply. It's grounded on what retrieval returned, on a file of verified product facts, and on every case we've ever worked. It may cite only what retrieval actually gave it, which means it can't invent a link to a page we never wrote. And the draft is a proposal. It cannot send.
Tier two only exists when somebody asks for it. If a draft looks wrong, one click puts a deeper model on the whole conversation, with the facts and the accumulated edge cases, and it comes back with one of three answers: this fits, no reply is needed, or here's a revision. The revision goes back into the same queue. It still cannot send.
Tier three is a person working the ticket directly. Billing, refunds, account actions, anything that needs judgment rather than recall. That's where the hard problems are supposed to go, not where the automation dumps what it couldn't handle.
The diagnosis has already happened and a grounded draft is already sitting there, so the first thing an operator does is make a decision rather than start an investigation. When the expensive part of a ticket is composition, you batch. When it's a judgment call, you stop batching, because a judgment takes a moment and you can make it whenever you've got one.
If it's working, a customer can't tell which tier answered them.
Every decision is a measurement
Every approval, every rejection, and every request for a deeper look gets written down. Not summarized. Recorded, one row per decision, permanently.
That turns something that used to be a feeling into something countable. I could never really answer how good our answers were, and I ran the place. I had spot checks, escalations, and whoever complained loudest. A vibe with anecdotes attached.
When somebody has to render an explicit verdict on every proposed reply, the quality of those proposals becomes a number. What fraction was good enough to send as written. What fraction needed revision. What fraction was wrong enough to throw away. Those point at causes rather than symptoms, too. A rejection is evidence that some specific fact was missing, or some rule was wrong, or some page doesn't exist yet.
It's the capture problem again, applied to quality. Measurement that costs you extra work doesn't happen, and measurement that falls out of the work you're already doing happens every time.
You do not install this
You tune this thing, you don't release it. The tuning is most of the work.
On day one it has the documentation, which is nothing like knowing how customers actually describe their problems, and no history at all. The drafts it produced in the early weeks were confidently wrong in ways that would have embarrassed us if a single one had reached a customer. None of them could, because it was propose-only from the first hour (that constraint has never lifted). Propose-only is what made the tuning period survivable. You're going to be wrong a great deal at the start, and the only question that matters is who pays for it.
What changed over the next few months was the corpus, not the model. Every rejected draft became an edge case with a written explanation of what was wrong with it. Every missing product fact got written into the file both tiers answer from. Same model as week one. The system around it knows an enormous amount more.
So this only becomes genuinely effective once you've got a material body of past cases worked hand in hand with it. Not an archive of old tickets. Cases somebody worked while the system watched and while a person corrected it, over and over. If you aren't willing to spend those months, don't start, because the cost of skipping them gets paid by your customers instead of by you.
Nothing here talks to a customer without a person approving that exact message. Here's what that looks like across a whole week, because the proportions surprise people who assume a system like this is mostly AI. Every box below fires on a clock without being asked.
Take the person out of that sequence and you don't get a faster system. You get one that's confidently wrong at machine speed, and support is precisely where being confidently wrong is expensive.
Orientation is the part that accumulates
In the military we talk about the OODA loop. Observe, orient, decide, act, and then straight back to observe. Most people remember it as a speed idea, which is the part Boyd cared about least. He spent the bulk of his effort on orientation, the step where you interpret what you just observed against everything you already know. Two people can observe an identical thing and orient completely differently, and the better-oriented one wins even when they're slower.
Support is an OODA loop. A ticket arrives. That's observe. Somebody works out what's actually going on. That's orient. They choose a response and send it, and the customer's reply starts the cycle over.
We were never losing on speed. Our people observed and oriented and decided quickly, and they were good at it. We were losing because orientation never accumulated. Every one of them built their own, privately, and it walked out the door with them. We observed constantly and never got better at orienting.
The grounding layer here is the orientation function. I've deliberately put a human approval into the act step, which slows the loop down, and that isn't an argument against Boyd. He never argued for acting fast on poor orientation, which is just losing more efficiently.
Orientation, unlike capacity, doesn't have to be bought twice. In a people organization a correction has to be transmitted. You find out an answer was wrong, and the fix has to reach everyone who might give it. You write it in a channel, mention it in a standup, put it in the onboarding doc. Some of it lands. New people arrive and you transmit it again. You pay for that correction forever, and the bill grows with headcount. Here you pay once. Somebody fixes the file and it's fixed, for the next ticket, at three in the morning, at any volume. It doesn't need re-teaching and it doesn't resign.
That's the whole thing. Not that the system handles more volume than people could, but that the cost of getting better stopped being proportional to how many people you have.
I spent a long time believing that caring about customers meant putting more people in front of them. I was wrong. Caring about customers means the tenth person to ask a question gets a better answer than the first one did, and people alone were never going to give me that.