Skip to main content

​
Billing Calculator: presale cost estimation

Open Billing → Pricing Calculator (/billing/calculator) when a prospect — or your own finance team — needs a number before a single message, video minute, or partner invoice exists. Every widget on the page is a read-only preview: nothing is charged, no wallet is debited, no payout is issued. You model a workload, read the projected cost, and hand it off. This guide is the presale walkthrough: pick the right lane, run one worked example per lane, compare the estimates side by side, export them for finance sign-off, and back-test the numbers once traffic is live. For the widget-by-widget field reference and the API parity behind each one, see Pricing calculator.

​
1. Three lanes of the calculator

The calculator page composes five widgets, but presale conversations split into three lanes. Know which lane your buyer is in before you start entering numbers: Two supporting widgets round the page out. The channel cost estimate (top of page) prices monthly messaging against your live per-country operator rate card — SMS resolves to a real number; voice, email, RCS, Viber, and WhatsApp honestly show “Rate unavailable — contact sales” rather than a fabricated one. The volume savings widget prices a hypothetical monthly volume through your volume-tier ladder and returns the effective per-unit rate — run it wherever your presale volume sits near a tier boundary, because the tiered rate can come out meaningfully below the list-rate estimate. Every lane prices from the same rules the wallet bills under, so an estimate you run presale is reconcilable against the ledger once the workload goes live.

​
2. Presale estimate walkthrough

Walk each relevant lane the same way — pick the lane, enter the monthly volume, read the per-unit breakdown:
  1. Pick the lane. Jump to the widget that matches the prospect’s workload type: RTC simulator for video rooms, AI estimates for agent-driven workloads, the reseller preview for partner programs.
  2. Enter the monthly volume. For RTC that’s participants × minutes per room × rooms per month. For AI it’s message count, voice minutes, and expected resolved outcomes. For reseller it’s per-sub-account revenue and carrier cost plus the partner’s revenue-share percentage. Use the prospect’s own forecast — the estimate is only as honest as the volume you type in.
  3. Read the per-unit breakdown. Every lane returns more than a headline total: the RTC lane reports participant-minutes and a blended per-participant-minute rate (the one number to compare provider-to-provider); the AI lane splits the estimate into per-axis line items; the reseller lane itemizes by sub-account. Quote the per-unit number in the presale conversation and the total in the budget conversation.

​
3. Worked example per lane

Run these three on the page today; the numbers below are what each lane’s default inputs model.

​
Lane A — RTC video minutes

A support desk plans 100 rooms per month, 30 minutes each, averaging 5 participants in HD:
  1. Open the RTC cost simulator and set Resolution tier to HD (up to 720p) — the tier rates come from a static rate card (audio-only, SD, HD, Full HD), one bundled rate per tier with recording, captions, signaling, and one RTMP destination already included.
  2. Enter 5 participants, 30 minutes per room, 100 rooms per month, and run the forecast.
  3. Read the breakdown: 5 × 30 × 100 = 15,000 participant-minutes per month. At the HD bundled rate of 0.0055perparticipant−minute,theprojectedmonthlybillis∗∗0.0055 per participant-minute, the projected monthly bill is **82.50** with no surprise line items — extras only appear if you add extra RTMP destinations, recording storage, or a dedicated SFU cluster.

​
Lane B — AI tokens / agent usage

A prospects expects 10,000 AI messages, 500 voice minutes, and 200 resolved outcomes per month:
  1. Open AIaaS usage under AI & marketplace pricing estimates, type the three counters, and estimate. The lane prices per message, per voice minute, and per resolved outcome — no platform or seat fee — and returns each axis as its own line item so finance can see which of the three drives the total.
  2. If the workload is outcome-priced, open Pay-per-resolution metering instead: type 1,000 resolutions at 0.005perresolution∗∗andthereturnedestimateis∗∗0.005 per resolution** and the returned estimate is **5.00 — a simple count × rate projection. Toggling billing off returns the same metered count with a “no charge” badge, so you can model what a resolution pipeline costs once metering goes live on the account.
  3. If the prospect publishes an agent or tool listing rather than consuming one, open Marketplace rev-share: 5,000 invocations at 0.02percall∗∗pricesa∗∗0.02 per call** prices a **100.00 gross charge; at a 20% platform fee the platform fee is 20.00andthe∗∗builder′snetpayoutis20.00 and the **builder's net payout is 80.00**. The preview also says whether that payout is above or below the payout threshold — below threshold rolls over instead of paying out.

​
Lane C — Reseller payout preview

A white-label partner program runs three sub-accounts for one period, with a negotiated 20% revenue share:
  1. Enter each sub-account’s revenue and carrier cost, set the channel, the partner id, the revenue-share percentage (20%), and the statement period, then estimate.
  2. Read the headline rows: gross revenue 6,300∗∗,costofgoods∗∗6,300**, cost of goods **4,600, net margin **1,700∗∗.Theaggregatepartnersharecomesoutofthataggregatenetmargin:201,700**. The aggregate partner share comes out of that aggregate net margin: 20% × 1,700 = 340.00∗∗,leaving∗∗340.00**, leaving **1,360 platform-retained.
  3. Read the per-sub-account line table. Sub-account C runs a loss for the period, and the split is applied per line with a zero floor — a loss line contributes a zero partner share rather than dragging the payout negative. The statement shapes what is owed; it computes no transfer and pays nothing out.

​
4. Compare lanes side by side

Presale proposals often span more than one lane — run each lane with the same month’s assumptions and lay the results next to each other before committing any of them to a proposal:
  • Per-unit first. Compare the RTC blended per-participant-minute rate against other providers, the AI per-axis rates against model-list pricing, and the reseller partner share as a percent of net margin. Per-unit numbers travel across workloads; totals don’t.
  • Then totals. Roll the lanes into one projected monthly number: for the examples above that’s 82.50(RTC)plustheAIaxistotals,withthepartnerpayout(82.50 (RTC) plus the AI axis totals, with the partner payout (340.00 in the example) shaped separately as a cost of the program, not a usage charge.
  • Screenshot or share. The messaging lane’s Share estimate button encodes the current configuration into a URL a teammate can open to see the same inputs; the other lanes are screenshot-ready result panels. Attach either to the proposal so the numbers survive the hand-off.

​
5. Export the estimate for finance sign-off

Finance needs a defensible number, not a dashboard screenshot. Two rules keep the estimate sign-off-ready:
  1. Use the per-unit breakdown, not the total. The RTC blended rate and the per-axis AI totals are the numbers that survive a volume adjustment — if the prospect later halves their volume, finance can recompute from the breakdown without re-opening the dashboard.
  2. Run the volume tier before you quote the total. If the messaging lane’s list-rate estimate is part of the proposal, run that same volume through the volume savings widget first. Above 500K messages per month the messaging lane deliberately swaps the estimate for a volume-discount contact card, because list rates stop being a meaningful anchor at that scale — if your prospect is anywhere near a tier boundary, quote from the tier-adjusted effective rate in Volume tiers and revenue recognition, not the back-of-envelope multiply.
Because every lane prices on the same rules billing uses, the export is a projection, not a promise: the final invoice follows actual delivery and any negotiated overrides on the account.

​
6. Back-test once traffic is live

The calculator models traffic you haven’t sent yet. Once the workload has run for a few weeks, close the loop with the What-if pricing simulator (/billing/simulator): it replays your recorded usage from the last 1–90 days through a candidate rate card, so you can back-test whether the presale rate is still the right one now that real traffic exists. The full walkthrough is in What-if pricing simulator — and the month-end close that follows (statements, volume tiers, recognition) is in Volume tiers and revenue recognition.