Rate negotiations on communications platforms usually end the same way: a vendor slide deck claims a number, the buyer has no way to check it against their own send pattern, and the first invoice answers the question after the contract is signed. On Devotel Orbit, that check is a shipped dashboard surface. Billing → What-if pricing simulator (/billing/simulator) takes your own recorded traffic, prices it under a candidate rate card you type, and returns the projected spend next to what you actually paid — before any commitment changes hands.
The problem — committed-rate conversations end on a slide, not a measurement
Messaging rates look simple on a price list and behave very differently in a real mix. Blended SMS spend depends on the destination split, on segmentation, and on whether your volume sits above or below a tier break. WhatsApp spend depends on template category and on which routes carry the traffic. A quoted rate is one number; your invoice is the sum of thousands of per-destination resolutions. Comparing a candidate rate card to your current one by hand means exporting usage, rebuilding the pricing logic in a spreadsheet, and hoping the rounding matches — or taking the other party's spreadsheet on faith.
The failure mode is the same on both sides of the table. A tenant evaluating a cheaper route cannot tell whether the promised saving survives their destination mix. A procurement lead negotiating a committed rate cannot verify the vendor's projected annual spend until the first month closes. The conversation ends on a claim, not a measured delta.
What ships — the simulator page
The simulator lives at Billing → What-if pricing simulator (/billing/simulator) with the page title What-if pricing simulator and the description "Replay your recent messaging traffic against a candidate rate card and see the projected spend before you commit to a rate change." The page is gated to the owner, admin, and billing roles because it surfaces real per-channel spend — the same role gate as the sibling /billing/usage drill-down and the billing API controllers behind it.
The simulator is read-only. It moves no money, writes no usage record, and triggers no billing event. It is a preview surface in the same posture as the volume-tier preview: an estimate you can run as many times as you like before you decide anything.
How it works — window, candidate rates, projected vs actual
Three inputs, one result table:
- Pick the traffic window. The simulator replays your last 24 hours, 7 days, 30 days, or 90 days — the look-back range is one to ninety days. The default is 30 days.
- Edit the candidate. A slider nudges every channel at once by a percentage (up to ±50%). For finer control, type a per-channel rate — SMS, MMS, WhatsApp, RCS, Viber, email, voice — and that channel is pinned to your typed rate while the rest follow the global adjustment. The full channel coverage is addressed in the FAQ below.
- Read the delta. The result table lists each channel with message volume, current spend, the blended rate you actually paid, your candidate rate, the projected spend, and the signed change. A headline summary shows current spend, projected spend, and the projected savings or increase with a percentage badge.
Behind the page, the what-if pricing preview endpoint aggregates your own usage events into per-destination lanes — each lane is one channel, one destination country, and one direction — and then resolves each lane through the same rate resolver that prices your invoice. Your candidate card is replayed through that resolver per lane, so a route that only wins on a handful of destinations, or a tier break that only matters at high volume, shows up in the projection rather than being averaged away. The per-channel slider is applied against that lane-accurate baseline, so re-projecting is instant, and a hand-typed channel rate is replayed per lane for an exact answer.
Tenant-owned loop — ground vendor negotiations on your own traffic
The FinOps playbook already recommends the simulator as the reconciliation step of the committed-rate conversation: export the projection, put it next to the vendor's spreadsheet, and argue from a measured delta. What it did not have until now is a dedicated walkthrough, which is what this post is. The point of the surface is the posture: it is your account, your recorded traffic, your candidate card, and a resolver you can audit — not a tool the other party operates.
Typical loop for a renewal or a route change:
- Open
/billing/simulatorand settle on a window that covers a representative cycle (most teams use 30 or 90 days). - Model the proposed card — nudge the global slider for a flat discount, or set per-channel rates that match the proposal.
- Record the projected delta with the window and the candidate values, so the discussion is anchored on a reproducible input set.
- Bring the projection into the negotiation, or run the reverse exercise on a counter-offer before accepting.
Worked scenarios
Comparing WhatsApp with SMS on the last 90 days. A retail sender splits traffic between WhatsApp templates and SMS fallback, and wants to know which channel should carry the next campaign wave. Set the window to 90 days so a full promotional cycle is inside the replay. Type a candidate rate per channel and isolate the channel-only comparison: either compare the blended WhatsApp line against your SMS line as-is, or pin one channel to a proposed rate to see how the mix shifts. Because lanes are replated per destination, the comparison holds even when your traffic spans destinations with very different SMS and WhatsApp prices. The result row tells you the channel's current spend, blended rate, candidate rate, projected spend, and signed change — the conversation moves from "WhatsApp is usually cheaper" to "on our ninety-day mix, it is a specific number."
Moving 40% of volume to a cheaper route. A sender with a second carrier route for the same channel wants the saving before rebalancing traffic. Start from your observed blended rate on that channel, apply the proposed discount on the candidate rate field (or use the global slider when the channel is the only line in play), and read the projected delta. When the discount applies to the entire channel, the slider is enough; when it applies to only part of the volume, estimate the split by weighting the delta between the current and candidate rates — the table gives you both numbers on the same row, so the arithmetic is a two-cell check. The point is that the lane-accurate baseline under the slider means the approximation is anchored on your actual destination mix, not on a flat average.
Tenant controls and role gates
The page is gated to owner, admin, and billing — a tenant decides which roles can see spend, and the simulator honours that decision rather than exposing the surface to every workspace member. The gate is enforced on the page (RoleGuard) and on the underlying billing API registration, so a viewer without the billing role cannot reach the projection by calling the endpoint directly. Your billing admin decides whether to run the replay; the tenant owns the loop end to end.
FAQ
How far back does the replay window go? One to ninety days. The page offers 24h, 7d, 30d, and 90d chips; the endpoint accepts any whole-day window in that range and defaults to thirty.
Which channels does the simulator cover? Any event recorded as a billable per-unit traffic meter — every *_sent metering event (SMS, MMS, WhatsApp, RCS, Viber, email, and the other BYO-credential messaging channels) plus voice minutes. Non-usage meters such as recording, embeddings, and agent-conversation counters are deliberately excluded, because a per-unit candidate rate cannot meaningfully reprice them.
How does the replay interact with volume tiers and MCCMNC overrides? The candidate card is layered on top of the same resolver your invoice uses. Your tenant's volume-tier ladder sits above the base rate, and the projection respects the tier you actually occupy, so a discount is measured against your true marginal rate rather than the list rate. Your MCCMNC override rows (per-country route identifiers) resolve exactly as they do when the invoice is computed — an override lane gets the override's base rate on the current side and your candidate rate on the projected side, and the delta is exact for that lane rather than blended.
Does the projection equal the final invoice? It prices every recorded event through the same resolver, so the lane-level arithmetic is identical to the invoice. Final invoices can still vary with delivery outcomes and with any negotiated overrides agreed after the preview runs, so the page carries that disclaimer explicitly — bring the projection to a conversation, then confirm the committed card in the billing surface before switching.
---
If the simulator projects a saving worth pursuing, the committed-rate conversation starts from a measured delta — not from a slide.