We crossed 100 paying customers in January. It felt like a milestone worth marking — not with a press release, but with an honest audit of what we've learned.
What follows compresses two years of customer conversations into the patterns that actually matter, including the nine deployments that failed.
Who our customers are
The breakdown by sector:
| Segment | Share |
|---|---|
| Healthcare and clinics | 26% |
| Professional services and consulting | 22% |
| Hospitality and restaurants | 18% |
| Education and training | 16% |
| Logistics and local services | 12% |
| Other | 6% |
By company size: under 50 employees (38%), 50–200 (41%), 200–1000 (17%), over 1000 (4%).
The size distribution surprised us. We expected to be a mid-market product. We're used more heavily by small businesses than we anticipated — because small businesses feel the pain of repetitive customer calls most acutely.
An eight-person clinic with 80 appointment calls a day has a problem a 200-person hospital could throw a receptionist at. They can't. AIVA is their receptionist. It's why the clinics page ended up being one of the first things we built.
The use case breakdown is more revealing still: 71% use AIVA primarily for appointment booking, 63% for Q&A (hours, prices, services, availability), and 42% for both.
Those numbers are why we rebuilt our positioning around Q&A and booking as a single system — because that's what customers actually needed from us, not what we'd assumed.
The one thing every successful customer has in common
I've been thinking about how to say this clearly, because I've now seen it enough times to be confident it's real.
Every customer who succeeded fast gave AIVA access to their actual systems.
This sounds obvious. It isn't, in practice. Most businesses' first instinct when deploying an AI agent is to give it a FAQ document and a service list — essentially the same information that's on their website. AIVA works with this. It answers questions. It's useful.
But the customers who went from "useful" to "transformative" — the ones who cut booking call volume by 80%, freed their front desk entirely, stopped missing calls after hours — all connected AIVA to live systems. Their booking calendar. Their patient management system.
Their appointment database. The full list of what connects is on the integrations page, and it's the first thing we now ask about in onboarding.
The difference is stark. A customer asking "do you have slots on Friday?" gets either a generic answer or a real one. The generic answer — "yes, we're usually open Fridays" — is technically accurate and completely useless.
The real answer — "Friday has 11 AM and 3 PM available, shall I book one?" — completes the transaction. Same question. Entirely different outcome, determined solely by whether the agent has access to live availability.
AIVA is only as good as the systems it has access to. Every "AI is overhyped" story I've heard from a failed deployment traces back to an AI that was given information instead of access.
What failed, and why
We've had nine customers churn. They break into three categories, and none of the causes were technical.
FAQ-only deployments (4 customers). Described above. AIVA became a slightly better search engine for their website content — not worth the setup cost for what it delivered. The fix is always the same: connect it to your booking system or calendar. We now push much harder on this during onboarding rather than letting a customer discover it in month three.
Wrong escalation configuration (3 customers). These teams set the escalation threshold too low — the agent routed everything to a human at the first sign of complexity. The result was no meaningful reduction in workload, which is a rational reason to cancel.
AIVA's value is absorbing repetitive volume so humans can focus on conversations that need them; escalating the simple things adds a system without removing any work. This failure was common enough that we wrote up the full escalation framework as its own post.
Insufficient tuning time (2 customers). Both churned in weeks two and three. AIVA needs a calibration period — typically two to four weeks:
- where you watch real conversations
- adjust edge cases
- teach it your specific services and booking rules
These two expected day-one performance without that investment. Their feedback was that AIVA "didn't understand their customers." It didn't, yet. Customers who stayed through calibration saw performance improve sharply by week four.
That last category is the one we hold ourselves responsible for. Two to four weeks isn't a caveat buried in the docs — it's the actual shape of the product, and we now say so before anyone signs up.
How long setup really takes and our piloting guide exist because of these two churns.
The surprise
The finding I didn't expect: the strongest predictor of a successful deployment isn't company size, sector, or technical sophistication. It's whether the person setting it up actually talks to their own customers.
The businesses that succeeded fastest were led by owners or managers who had personally handled booking calls or customer questions. They knew exactly what customers said, how they phrased things, and what caused confusion. They configured AIVA from real understanding rather than assumption.
The ones that struggled were often managed by people who hadn't done that legwork. Their mental model of a customer enquiry was a clean FAQ lookup. Real customers ask "do you have anything tomorrow morning?" — not "query availability for date: tomorrow." An agent configured by someone who doesn't know the difference will reflect that gap precisely.
This is essentially the jobs-to-be-done observation applied to configuration: the useful unit isn't the question, it's the situation the caller is in when they ask it.
The practical version — how to write FAQ content that survives contact with real phrasing — is in how to train an AI agent on your FAQs.
What we got wrong about ourselves
Three of our own assumptions didn't survive the first hundred.
We thought we were a mid-market product. We priced, positioned, and staffed for 50–200 employee companies. 38% of our customers are smaller than that, and they're the ones for whom the product is least optional. A mid-market buyer is comparing us to hiring someone. A six-person clinic is comparing us to nothing, because nothing was affordable.
We thought language would be a differentiator we'd have to explain. It turned out to be the thing customers noticed first and mentioned unprompted — usually not as "you support Marathi" but as "my patients stopped hanging up."
We thought onboarding was a support cost. It's the product. Every churn in the list above is an onboarding failure wearing a different hat: FAQ-only setups are onboarding not insisting on system access, escalation misconfiguration is onboarding not setting a sane default, and premature abandonment is onboarding not setting expectations.
We'd been treating the first two weeks as the cost of acquiring a customer rather than as the thing that determines whether there is one.
What we changed because of all this
Three things, concretely. Onboarding now leads with system access rather than content upload. Escalation defaults ship deliberately looser than most customers' instinct, with a two-week review built into the plan. And we publish the calibration period honestly rather than promising day-one performance.
The larger version of this analysis, across a much bigger sample, is in what 4 million conversations taught us.
You can watch the same patterns on your own traffic in the analytics dashboard — or start free with ₹500 of credit and connect a calendar on day one, which is the whole lesson in a sentence.