People assume the channel order — voice, then SMS, then the web widget — was a technology roadmap: build the easy thing first, work up to the hard thing. It was the opposite. We built the hardest channel first on purpose, and the order after that followed from what customers actually needed next, not from what was easiest to ship. It's a decision we still get second-guessed on, usually by people who assume a chat widget would have gotten us to revenue faster. It probably would have. We don't think it would have gotten us to a better product.
Voice first, because it was the hardest and the most universal
Every business we talked to in year one had the same problem, described the same way: the phone rings, and either nobody's there to answer it, or the person who is there is doing something else — with a patient, with a customer, mid-haircut. A missed call is the most visible, most immediately felt form of lost revenue a small business has. There's no interpretation required. You can literally see the call log, count the rings that went unanswered, and know exactly what that cost.
Voice was also, deliberately, the hardest thing to build, and we knew that going in. Real-time speech recognition, sub-200ms response latency, natural-sounding replies in the customer's own language, all while actually reasoning about a booking or a question — that's a much harder problem than anything text-based, where you can take a comfortable second or two to think without a caller noticing an awkward silence. We built it first because if we could solve real-time multilingual conversation under a latency budget that unforgiving, everything else we built afterward would inherit that same conversation engine and be comparatively easier. We were paying down the hardest debt first, on purpose, rather than leaving it for a future version of the team that would have less patience for solving it properly.
It also meant our first product had to work in twelve languages essentially out of the gate, because a voice product that only spoke English wasn't actually solving the missed-call problem for most of the businesses we were talking to. That constraint made voice even harder to ship first — and made everything we built after it easier, because the language infrastructure was already load-bearing.
SMS second, because it closed the loop voice couldn't
Voice solves the moment someone calls. It doesn't solve the customer who doesn't want to call at all, or the one who called, got a booking, and needs a reminder two days later without picking up the phone again. SMS was the natural next channel because it's the same core conversation engine, applied asynchronously, to the customers voice was structurally unable to reach.
SMS wasn't a new problem. It was voice's unfinished sentence — the part of the conversation that happens after the call ends.
It was also, honestly, a smaller engineering lift than the widget would have been. No embed script, no rendering surface, no compatibility testing across a hundred different customer websites. Once the reasoning engine existed, adapting it to text messages was weeks of work, not months — though "weeks, not months" undersold how much still had to be solved specifically for text. Getting the SMS engine to survive real-world gaps in delivery and carrier reliability was its own hard problem, just a narrower one than building a second voice pipeline from scratch would have been. By the time we shipped SMS, the same channel was also carrying the text commands customers use to check a booking status or ask for a reschedule without ever picking up the phone — a natural extension once the channel existed, not something we'd planned from day one.
The widget third, on purpose, not by accident
We could have built the web chat widget first. It's the obvious AI product — every SaaS company's homepage has one, and it demos beautifully in a way a phone call over a conference room speaker never quite does. We didn't, for two reasons, and the pressure to reverse the order was real enough that it's worth being honest about.
First, most of our early customers — clinics, salons, local service businesses — weren't bottlenecked on website traffic. Their bottleneck was the phone. A beautiful chat widget on a site that gets forty visits a week solves a smaller problem than a phone line that rings sixty times a day. We had at least one early conversation, in the first few months, where the argument for leading with the widget instead of voice was made seriously — it's a faster build, it's a better demo, it's what people expect an "AI startup" to show first. We turned it down because a great demo that doesn't match where a clinic or salon actually loses business isn't actually the more valuable thing to build, even if it looks more impressive in a five-minute pitch.
Second, the widget is a genuinely different engineering problem, not conversation engineering but embedding engineering. It has to render correctly on WordPress, Squarespace, and hand-rolled HTML alike, without breaking a customer's existing CSS or JavaScript, and it has to decide intelligently when it's actually useful to appear rather than popping up the instant someone lands on a page. That's real work, and it deserved dedicated attention rather than being squeezed in third to a roadmap that was really about voice. When we did build it, getting the embed down to three lines of code took real iteration precisely because we'd waited until it could get that focus.
The honest cost of this ordering is that it wasn't free for everyone. A handful of early prospects in year one were e-commerce and content-heavy businesses whose actual bottleneck was website inquiries, not phone volume — for them, "voice first" meant waiting for the channel that would have helped them least first. We told them plainly that the widget wasn't ready and gave a rough sense of when it would be, rather than rushing a thin version just to have something to offer. Some waited. A few went with something else in the meantime. We think that was the right trade even knowing it cost us a few early customers, because shipping a rushed widget to avoid losing them would have meant every customer after them inheriting a worse version of the product we eventually wanted to build.
Why the order wasn't obvious at the time
None of this was as clean in the moment as it reads now. Roadmap arguments rarely resolve in a single meeting, and this one didn't either — it came up again every few months for the better part of a year, usually whenever a competitor announced a chat product or a prospect asked why we didn't have one yet. Each time, the answer held up the same way: look at where the calls are actually coming from, and the phone was still the channel carrying the most volume and the most visible pain for the businesses we were serving. The order stopped being a live debate once SMS shipped and it became obvious how much of its value came from reusing voice's reasoning engine rather than starting over — that was the moment "hardest first" stopped being a bet and started being a strategy we could point to.
What the order taught us
The lesson we'd repeat to any team building a multi-channel product: don't order your roadmap by what's easiest to ship or what demos best in a pitch meeting. Order it by where the pain is most acute, and let the hardest problem you solve first become the foundation the rest of the product stands on. Voice forced us to build a genuinely good conversation engine under real constraints — latency, language, accuracy, all at once. SMS and the widget didn't have to rebuild that. They just had to show up wearing it, which is also why the three channels feel like one system to a customer rather than three products that happen to share a login.
If you're weighing which channel to turn on first for your own business, the honest answer is: match the order to your actual bottleneck, not ours. Try voice on a real call, see what the widget looks like on your own site, or start free and turn on whichever channel is actually costing you customers today.