Why we build for solo operators and enterprises alike

The requirements diverge later than you'd think

The assumption behind picking an end of the market is that the two want different things. Below the surface, they mostly don't. Both need the agent to understand a caller with an accent and a bad line. Both need it to stop guessing when it doesn't know. Both need it to hand off cleanly to a person, and both need to see afterwards what was said.

Where they genuinely diverge is narrower than the received wisdom suggests, and it is mostly organisational rather than functional:

• Volume, which is a capacity question rather than a design one.
• Approval and audit trails — who is allowed to change a live agent, and what evidence exists that they did.
• Integration depth. A solo operator has a calendar; a carrier has four systems of record that disagree with each other.
• Procurement, security review and contractual paperwork, none of which touches the product.

Setup help on every plan

We put a forward-deployed engineer on every account, not just enterprise ones — it's included on every plan. Partly because a first agent that works is the whole product experience, and partly because sitting inside a customer's workflow is the fastest way to find what our documentation failed to explain.

The second reason is the real one. Documentation is written by people who already understand the system, which makes it structurally incapable of revealing its own gaps. Watching someone configure their first agent surfaces those gaps in about twenty minutes, and they are never where you expected.

It is also a hedge against a specific failure. A voice agent that is 80% configured does nothing useful — it doesn't half-answer calls, it just isn't switched on. So the gap between signing up and having something running is the point where most of the value is won or lost, and leaving that gap to a documentation site is leaving the outcome to chance.

The small accounts find the bugs

Smaller teams configure things in ways we didn't anticipate and tell us immediately when something is confusing. Much of what enterprise customers experience as polish came from that feedback.

There is a structural reason for this, not just a cultural one. A solo operator configures their own agent, hits a confusing screen, and messages us that afternoon in their own words. In a larger organisation the person hitting the confusing screen is often three steps removed from the person who talks to us, and by the time it arrives it has been translated into a feature request that describes a solution rather than the problem.

Volume matters too. Smaller accounts do far more first-time setups per month than enterprise accounts do, so they cross the roughest ground much more often. Nearly every improvement to onboarding in the last year came from that end of the market.

What enterprises push on instead

The pressure from the other end is different in kind. It is rarely about whether something works and almost always about whether you can prove it, control it, and contain it when it goes wrong.

That pressure produced things the whole product now has: proper audit trails on configuration changes, sane permissions, defined retention, explicit failure paths on anything touching an external system. A solo operator would never have asked for any of it, and every one of them makes the product better for that operator too.

So the two ends are not a tax on each other. One end finds the things that are confusing; the other finds the things that are unprovable. Serving only one leaves you blind to a whole category of defect.

Where it does cost us

Being honest about the downside: it makes some decisions slower. A feature that would obviously suit one end has to be checked against the other, and "obviously" turns out to be doing a lot of work in that sentence. Some things ship later than they would have.

It also puts real constraints on the interface. Every setting that a large team wants exposed is a setting a solo operator has to walk past, and the temptation to solve that with an advanced-options drawer is constant — which is how products end up with two of everything.

We think it is worth it, on a simple test: the product is honest at both ends. It is hard to ship something that only works at scale when a one-van operation will be configuring it next week, and hard to ship something that can't be audited when someone's security review is next month. Both of those pressures keep us from shipping something that merely demonstrates well.