I sit on the other side of a lot of onboarding calls, and the pattern is consistent: the businesses that get the most useful signal out of their free trial credit are testing specific things, in a specific order. The ones that get the least useful signal set AIVA up, ask it one or two easy questions themselves, and decide within a day. Here's what I actually tell people to test before deciding whether to recharge.
Feed it your real questions, not generic ones
The single biggest predictor of a good trial is whether someone loaded AIVA with the actual, specific questions your customers ask — your real hours, your real cancellation policy, your real pricing, the odd edge-case question your front desk gets asked every week. A generic FAQ test tells you AIVA works in general. It doesn't tell you AIVA works for you.
Test in the language your customers actually use
AIVA handles 12 Indian languages, but that only helps you if you actually test in the ones your callers use. If a meaningful share of your customers are more comfortable in Gujarati or Hindi than English, don't run your whole trial in English and assume it translates. Have someone call in the language your customers actually call in — ideally more than one person, since accents and phrasing vary even within the same language, and a single tester's speech pattern isn't a representative sample of your actual callers.
Run the full booking loop, not just the conversation
A clean-sounding conversation isn't the same as a correct booking. Actually complete a reschedule, a cancellation, a new appointment — and check that it landed correctly wherever your calendar or booking system lives, whether that's Google Calendar or Calendly. This is the step people skip most often, and it's the one most likely to surface a setup issue.
Test the SMS side of the booking loop too
If you're using appointment reminders or confirmations, don't stop at testing the voice or chat booking — test what happens by text as well. Reply to a confirmation SMS with a reschedule or cancel request the way a real customer would, and confirm it actually updates the booking rather than just being acknowledged and ignored. We've written a full breakdown of what these SMS commands can actually do if you want to know the full range before you test it — status checks, reschedules, and refund requests can all run through plain text replies, which only matters if you've actually confirmed it works for your setup.
Try to break it, on purpose
Real callers interrupt, go off-topic, ask three questions in one breath, mumble, call from a noisy car. Don't test AIVA under lab conditions and assume real calls will be as clean. Talk over it. Change the subject mid-sentence. Ask something it has no business knowing. You want to find the rough edges during the trial, not during a real customer's call.
Every AIVA deployment escalates to a human for three things by default: real emotional distress, anything compliance- or security-sensitive, and any explicit request to speak to a person. Test at least one of these on purpose during your trial and confirm two things: that it actually escalated, and that the right person on your team actually got notified.
An escalation that silently fails is worse than no escalation logic at all, because it looks like it's working right up until the day it doesn't.
Test the human handoff itself, not just the trigger
It's not enough to confirm that a conversation escalated — check what actually happens on your team's side of that handoff. Does the notification arrive somewhere someone will actually see it in time, not buried in a channel nobody checks on a Saturday? Does it include enough context that whoever picks it up isn't starting cold, asking the customer to repeat everything they just told AIVA? During the trial, deliberately route an escalation to whichever person or team would handle it for real, and ask them directly whether what they received was actually useful. We've written more on how escalation rules work if you want to understand the mechanics before deciding how to configure them for your business.
Read the transcripts, not just the summary
The analytics dashboard gives you a resolution rate and usage numbers, and both are useful, but pull up a handful of actual call transcripts and chat logs too. A high resolution rate can hide a conversation that technically closed without actually satisfying the caller. You'll catch that in a transcript faster than in a percentage.
Test during your actual busy hours
A trial run entirely during a quiet Tuesday afternoon tells you how AIVA handles a quiet Tuesday afternoon. If you have a predictable rush — evenings, weekends, a particular season — get at least some real trial volume during it before you decide. This matters more than it sounds like it should: a system that handles one call at a time cleanly can behave differently once several calls, chats, and texts are all landing within the same few minutes, which is exactly the condition your busiest hour creates and a quiet afternoon never will.
A simple week to structure the trial around
If you're not sure where to start, this is roughly the order I'd suggest to most businesses: spend day one loading your real FAQs, hours, policies, and connecting your calendar or booking system. Spend days two and three making internal test calls and chats yourselves — the break-it-on-purpose testing above, plus a full booking loop end to end. From day four onward, start routing real customer traffic through it, ideally starting with your lower-stakes channel first if you have one, and make a point of catching at least one genuinely busy shift before day seven. Read transcripts daily rather than waiting until the end of the week — catching a setup gap on day two is a five-minute fix; catching the same gap on day seven after fifty real conversations have gone through it is a bigger cleanup.
If you're testing across more than one location or line
For a business with multiple locations or phone lines, resist the temptation to run the whole trial through a single "main" number and assume the result generalizes. Each location tends to have its own real FAQ edge cases — different hours, different staff names, sometimes different pricing — and a trial that only tests one location's questions will look cleaner than the real multi-location rollout turns out to be. If you're in this position, it's worth at least sampling real traffic from a second location before deciding, even if the full rollout comes later.
Then do the math on the credit itself
Voice runs ₹4 a minute, web chat ₹2 a conversation, SMS ₹1 a message, all from the same balance. Once you know roughly how your ₹500 free credit got spent across those three, you can work out what a full month would actually cost at your real volume, which is a much better basis for the recharge decision than "it seemed fine." The pricing page has the recharge pack sizes if you're ready to move past the free credit once the numbers check out.
None of this takes long. It just takes doing it on purpose, instead of letting the trial happen passively and hoping the credit runs out before you have to decide. Starting the trial itself takes a few minutes; testing it properly is the part worth being deliberate about.