Two years ago, RB2B had 2,800 accounts. Today we have 42,000. Our support ticket volume has stayed flat at around 1,000 per month the entire time.
If our ticket-to-account ratio had held steady from where we started, we'd be handling somewhere north of 7,000 tickets a month right now. We're not. That's a gap of roughly 6,000 tickets per month that simply don't exist.
I want to be precise about what caused that, because the easy answer is wrong.
The easy answer is that we have a good AI support agent. We do — we run Fin, and it handles a meaningful share of what comes in. But Fin didn't create that gap. You can't resolve your way out of 6,000 missing tickets. Those tickets never arrived. That's a different problem, and it requires a different kind of thinking.
Support volume is a product signal, not a support problem
The shift in how we approached this came from accepting an uncomfortable premise: if enough people are asking the same question, that's not a support issue, it's a product issue. The question is a symptom. The friction that produced the question is the actual problem.
This sounds obvious when you say it out loud. In practice, it's easy to optimise for resolution speed and miss the point entirely. Fast resolutions are good. Fewer reasons to contact support in the first place is better.
Every recurring ticket pattern we investigated pointed back to something in the product or the onboarding experience that wasn't working clearly enough. Fixing those things at the source removed whole categories of tickets permanently.
Getting help to people before they have to go looking for it
The second piece was documentation — but not documentation in the traditional sense of a help centre that exists somewhere and hopefully surfaces in a Google search when someone is frustrated enough to go looking.
Contextual help, placed inside the product at the moment someone is most likely to need it, works differently. It's the difference between answering a question and intercepting it. People don't need to know the help centre exists. The relevant content finds them.
This is harder to build than a help centre. It requires knowing where in the product people get stuck, and why, and then making editorial decisions about what to surface and when. But the conversion from "confused user" to "person who figured it out without contacting support" is significantly higher when the help is already there.
Getting ahead of the questions entirely
The third lever was proactive education — onboarding sequences, in-app guidance, content that anticipates the questions new users reliably have before those questions become tickets.
The goal here is not to improve the support experience. It's to make support irrelevant for a larger share of the user base. Customers who understand what they're doing, and why, and what to expect, generate fewer tickets. They also tend to stick around longer and get more value from the product. The incentives align.
What AI actually does well
None of this is an argument against AI in support. Fin is genuinely good, and having a capable agent handling the volume that does come in matters. For the tickets that arrive, fast and accurate resolution is important.
But an AI support agent is a safety net. Safety nets are valuable. They're not a strategy for not falling.
The real work is upstream: removing the friction, delivering the right information at the right moment, and building the kind of onboarding experience that gets ahead of confusion before it becomes a cost. If you do that well, the AI has less to do — and that's exactly the outcome you're aiming for.
