A pure pay-as-you-go model has one obvious failure mode, and we thought about it before we shipped anything else: what happens when the balance hits zero. Not in the abstract — specifically, what happens if it hits zero while a call is actually live, or right at the start of your busiest hour. A phone line that goes silent mid-sentence because of a billing edge case isn't a minor bug. It's the kind of thing that could cost a business exactly the call it most needed to answer. So we designed auto-recharge around avoiding that scenario, not just handling it gracefully after the fact.
The problem with waiting until zero
The naive version of prepaid billing checks your balance, and when it hits zero, stops serving. For most software, that's a fine failure mode — you get logged out, you top up, you log back in. For a phone line or a live chat, it's not fine. A call in progress doesn't pause cleanly. If your balance ran out mid-call, the caller would just experience AIVA going dead.
Think about who's actually on the other end of that call when it happens. It's not you, checking a dashboard — it's a customer, mid-sentence, trying to book something or ask a question, with no idea their business's prepaid balance is the reason the line just went quiet. There's no good way to recover from that in the moment. The caller doesn't get an error message explaining what happened; they just get silence, and the most likely next thing they do is hang up and call — or not call — someone else. That's the specific scenario we built backward from when designing this: not "how do we bill fairly," which is a separate question, but "how do we make sure billing mechanics are never the reason a real customer's call drops."
Why auto-recharge is proactive, not reactive
Auto-recharge doesn't wait for zero. It watches your balance continuously and triggers a top-up once it drops under a threshold you set, using your saved payment method — the same kind of tokenized, recurring-payment authorization that powers subscription billing generally — and your chosen pack size: ₹500, ₹2,000, ₹5,000, or a custom amount. The recharge happens with headroom still in the balance, which means the account should never actually reach a genuine zero in normal operation. By the time a live call is being answered, there's already a comfortable buffer sitting behind it, and the next top-up has already fired well before that buffer runs down.
The goal isn't to handle running out of credit well. It's to make sure the account is never actually running on empty in the first place.
A worked example of setting a threshold that actually protects you
Say a clinic runs about ₹300 a day in typical AIVA spend, blended across voice, chat, and SMS. If that clinic sets its auto-recharge threshold at ₹500 with a ₹2,000 pack, the recharge fires when the balance drops to ₹500 — still enough for roughly a day and a half of normal usage before the new ₹2,000 lands, and the new pack itself covers roughly six to seven more days at that burn rate before the next trigger. That's a threshold with real buffer in it: even a busier-than-usual day between the trigger and the top-up landing is unlikely to actually exhaust it.
Compare that to a threshold set too close to zero — say ₹50, on the assumption that "as long as it's above zero, it's fine." At the same ₹300-a-day burn rate, ₹50 of buffer is a few hours, not a day and a half. A single unusually busy morning, or a brief delay in the recharge processing, could plausibly close that gap before the top-up lands. The threshold isn't just a technical setting — it's the actual size of the safety margin between "recharge triggered" and "balance genuinely empty," and it's worth setting deliberately rather than defaulting to the smallest number that seems technically sufficient.
Why one shared balance makes this simpler
Because voice, web chat, and SMS all draw from the same balance rather than three separate ones, auto-recharge only has to watch a single number, not coordinate three separate thresholds across channels. That matters in practice: a business that suddenly gets a burst of web chat traffic from a marketing push, on top of its normal call volume, doesn't need three independent recharge events firing out of sync — the one balance drops faster than usual, crosses the one threshold, and one recharge event covers whatever combination of channels caused the draw-down. The simplicity of one balance and one threshold is part of what makes auto-recharge reliable rather than something you have to actively manage across channels.
What this looks like in practice
You set your threshold and your recharge pack size once, attach a payment method, and the balance manages itself from there. You'll get a notification when an auto-recharge fires, so it's never a silent deduction — you always know when and how much was added and why. If you'd rather manage it manually, auto-recharge is optional; you can top up on your own schedule instead. But for any business running AIVA on a live phone line, we'd recommend turning it on, for the same reason you wouldn't want a physical phone line to just stop working because nobody happened to notice the bill was due.
Picking a pack size that matches your burn rate
The threshold decides when a recharge fires; the pack size decides how much lands each time, and the two should be chosen together, not independently. A low-volume business recharging a ₹5,000 pack might go weeks between triggers, which is fine, but ties up more balance sitting idle than it needs to. A high-volume business set to auto-recharge in ₹500 increments might find itself triggering a recharge every day or two, which works but means more frequent card activity than necessary. Matching the pack size roughly to a week or two of typical usage tends to be the comfortable middle ground for most businesses — frequent enough that you're not sitting on a large idle balance, infrequent enough that recharges aren't firing so often they become background noise you stop paying attention to. If your volume is seasonal, it's worth revisiting this sizing around your known busy stretches rather than setting it once and forgetting it — the same logic covered in how usage-based pricing handles seasonal swings applies directly to how you'd want to size a pack ahead of a predictable spike.
What we'd still ask you to watch
Auto-recharge protects against the balance running dry unexpectedly. It doesn't protect against a payment method that's expired or a card that declines — that failure mode is on you to catch, and we'll flag it clearly on the dashboard the moment a recharge attempt fails, rather than let it fail silently and hope you notice before the balance runs low. It's worth treating that flag the way you'd treat any other billing alert that touches something customer-facing: check it the day it appears, not the next time you happen to open the dashboard.
If you've moved past self-serve entirely
Auto-recharge is specifically a self-serve mechanism, built around a prepaid balance. If your business has grown into custom pricing and invoicing, this whole system becomes unnecessary — there's no balance left to run dry, since billing runs on a negotiated cycle instead. For everyone still on standard pricing, though, auto-recharge is the piece of infrastructure that makes a prepaid balance safe to rely on for something as immediate as a live phone line.
The honest summary: a pay-as-you-go balance only works if running out is rare and never happens at the worst possible moment. Auto-recharge is the piece of infrastructure built specifically to make sure of that — and it costs nothing extra to turn on, whether you're testing it against your free credit for the first time or running it on an account that's been live for years.