A customer's batch job runs at 11:58 PM. It burns through the last of their included API calls at 12:14 AM and keeps going — now every call is metered overage. Your in-app banner is already updated: a tidy orange bar that says "You've exceeded your plan limit." It is perfect. It is also invisible, because nobody is logged into your dashboard at 12:14 AM.
They find out nine days later, on the invoice. The one with the $340 line item they didn't authorize and can't explain to their finance team. Now you don't have a customer with an overage — you have a support ticket, a credit request, and a Slack message that starts with "hey, is this normal?"
Full disclosure: I work for Ready, an SMS platform, so I have a horse in this race. But the timing problem here isn't a Ready problem — it's a routing problem, and it's worth thinking about even if you never touch our product.
The core issue: your best channel is the one they aren't looking at
Usage-based billing changes the stakes of a notification. In a flat-rate plan, hitting a limit means "stop" — the product blocks the action and the banner is enough, because the block itself is the message. In usage-based billing, hitting a limit means "keep going, and start charging." Nothing stops. The meter just quietly moves from included to billable.
That's the trap. The most expensive moment for your customer produces zero friction in the product. No blocked action, no error, no forced login. So the only signal is whatever channel you chose to fire — and if you chose in-app, you chose the channel that requires them to already be paying attention.
An in-app banner is a fine primary surface for a threshold warning while someone is working. It's a terrible surface for a threshold breach that happens at midnight, on a weekend, or during a cron run nobody's watching. The alert has to reach a human who isn't logged in. That's SMS, or email, or a push — and email has its own timing problems, which I'll get to.
Route by consequence, not by convenience
Not every usage event deserves a text. The fastest way to get opt-outs is to SMS someone every time they cross 50% of anything. Route by what happens next.
Here's a rough tiering that's held up across usage-based products I've seen:
| Event | Consequence to customer | Channel |
|---|---|---|
| 70% of included usage | None yet — informational | In-app banner |
| 90% of included usage | Overage imminent, upgrade decision looms | In-app + email |
| 100% crossed → now billing overage | Real money starting to accrue | SMS (+ email + in-app) |
| Overage exceeds $X threshold | Bill-shock territory | SMS, immediately |
| Hard cap hit / service degraded | Product stopped working | SMS, immediately |
The 90% moment is worth its own attention — a "you've hit 90%" text converts upgrades an idle-user banner never reaches, which I dug into separately in the idle-user gap post. But the 100%-crossed and bill-shock rows are where SMS earns its place unambiguously. Those are the events where every hour of silence adds dollars the customer will later dispute.
The timing math: when a text prevents a ticket
Let's put numbers on it. Say your overage rate is $0.02 per unit over the included allotment (pick your own; the shape holds). A customer with a runaway process is burning 500 units/hour past their cap.
- In-app banner only: discovered on next login. Median B2B SaaS login gap for a non-daily-active account is easily 2–5 days. Call it 60 hours. At 500 units/hr, that's 30,000 overage units = $600 before they even know.
- Email: arrives in seconds to minutes, but open timing is the problem — a decent chunk never open a transactional email same-day, and 40% of alert emails go unopened entirely (rough industry ranges, not a guarantee). Say average time-to-awareness is 8 hours. 4,000 units = $160.
- SMS: opened within minutes for most opted-in recipients. Time-to-awareness ~15 minutes. 125 units = $2.50, and the customer chooses to keep going or throttle.
The difference between the SMS path and the banner path isn't $597.50 in your favor — it's $597.50 you don't have to argue about later. Because in the banner scenario, that $600 becomes a credit request, and you'll refund most of it to keep the account. The support time alone eats the margin. I covered the same dynamic on the payments side in the failed-payment dunning math — off-platform beats on-platform whenever the user isn't in the product.
Why not just email everything?
Email is cheaper and it's fine for the 90% warning. The problem is specifically the urgent, money-is-accruing-now tier. Email arrival is reliable; email attention is not. A digest-batched provider can hold a message, a spam filter can quarantine it, and the recipient may simply not open a "notification" subject line for hours. When the delay itself costs money, that variance is the whole problem.
The honest version: use email for the informational and warning tiers, and reserve SMS for the events where an 8-hour open delay translates to a bill dispute. That's a two- or three-channel ladder, not an SMS-only religion. The same fallback logic applies to outages — I wrote about the SMS fallback ladder for critical alerts if you want the outage-flavored version.
The consent problem is real, and it's solvable
You cannot text a customer an overage alert unless they've consented to receive texts. This is not optional and it's not a formality — unconsented A2P traffic gets carrier-filtered anyway, so it wouldn't even land.
The clean way to handle it in usage-based SaaS:
- Capture the mobile number and SMS consent at signup or in billing settings — framed as "get alerts before you hit an overage." That framing is a benefit, not a marketing ask, so opt-in rates are high. Ready records that opt-in attestation so you have the audit trail.
- Keep it transactional. Overage and limit alerts are operational, tied to the service the customer pays for — a very different consent posture than promotional blasts. Don't muddy the number by mixing in upsell campaigns without separate consent.
- Honor STOP automatically. If someone opts out, that has to propagate so you don't text them again — Ready handles inbound STOP across campaigns automatically, but the point stands whatever tool you use.
- Respect quiet hours — mostly. This is the one genuine tension. A hard cap that stops the customer's production service at 2 AM might justify an off-hours send; a soft overage warning does not. Ready enforces quiet hours by the recipient's local time by default, and you decide which alert tiers override it. More on that tradeoff in the quiet-hours rules post.
If you send at any real volume you'll also want to think about 10DLC registration for SaaS — transactional alert traffic still needs a registered brand and campaign to route cleanly.
Wiring it up as an automation
The mechanics are straightforward once consent is in place. Your billing system already emits usage events — most metering setups fire a webhook or write to a table at each threshold. You route those events to an SMS send conditioned on the tier logic above.
A minimal implementation:
- Threshold events (
usage.100_percent,overage.exceeds_threshold,hard_cap.hit) trigger the SMS automation. - The message includes the specific number and a one-tap next step: "You've passed your monthly limit — overage billing at $0.02/unit is now active. Upgrade or set a cap: [link]. Reply STOP to opt out."
- The upgrade link goes somewhere they can act without logging into a deep dashboard flow, because the whole reason SMS worked is that they weren't logged in.
Ready's automations and API let you fire these sends off inbound webhook events, and if you run on GoHighLevel the two-way sync means a customer's reply ("wait, cap me now") lands back in your inbox as a real conversation, not a dead-end. That reply-ability matters more than people expect — bill-shock is often a conversation, not a click.
Segment cost — the part that's almost a rounding error
Here's the reassuring math. That overage alert is one short message. A 140-character transactional SMS is a single segment. On Ready's Standard tier that's $0.02 + $0.0045 carrier = $0.0245 per alert.
If 2,000 customers hit an overage threshold in a month, that's 2,000 × $0.0245 = $49. You read that right — forty-nine dollars to head off a category of dispute that routinely costs hundreds of dollars per incident in credits and support time. The alerts are not where your SMS budget goes; even a modest reduction in overage credits pays for the entire program many times over. Pricing detail lives on the ReadySMS page.
The practical takeaway
Usage-based billing quietly moved your most consequential customer moment off the screen. The breach happens when nobody's watching, the meter runs, and the invoice does the informing — badly. Route your alert tiers by consequence: banners for informational, email for warnings, and SMS for the moment real money starts accruing and for hard caps. Capture consent as a benefit at signup, keep it transactional, honor STOP, and think hard about quiet hours per tier.
If you want to try the routing without committing anything, Ready gives you 2,500 free credits and no credit card to send the first batch of alerts — sign up here and wire one threshold event to a text. Start with the bill-shock tier. It's the cheapest ticket-and-churn insurance you'll buy this quarter.