WhatsApp BSP Procurement 2026: RFP Scorecard & Exit Clauses

Most WhatsApp BSP regret is manufactured at procurement time, not discovered later. The lock-in clause nobody read, the per-seat fee that crept in after onboarding, the per-message markup that only became visible when month-3 invoices stopped matching the demo-day spreadsheet — every one of those was sitting in the proposal the day you signed. This guide is the buyer-side methodology for enterprise teams in India choosing a BSP in 2026: a weighted RFP scorecard, the pricing-forensics questions that expose hidden markup, a DPDP-grade security review, a contract red-flag table, and the exit clauses you must draft before you enter. It is deliberately not a vendor ranking — for that, see our provider roundup — and not a migration runbook either, which lives in the BSP migration guide. This is the process that makes both of those easier.

Why BSP procurement is not normal SaaS buying

Three structural differences break the standard SaaS playbook. First, there is a layer you don't contract with directly: Meta. Your WhatsApp Business Account (WABA), phone number, templates and quality rating live with Meta, and Meta's per-message charges flow through whatever pricing wrapper the BSP builds. A BSP can obscure that layer or expose it — and that single design choice drives most of your five-year cost.

Second, the economics are per-message, not per-seat. A CRM that costs 10% more is a budgeting nuisance; a BSP that adds ₹0.25 of invisible markup to every message is a tax on your growth that compounds with volume. Procurement teams trained on seat-based SaaS routinely under-scrutinise the per-unit line.

Third, switching costs are asymmetric and contract-defined. Meta lets a WABA move between BSPs, but whether your contacts, opt-in records, conversation history and flow logic move with you is decided entirely by the contract you sign today. The vendor knows this. Your RFP has to know it too.

The weighted RFP scorecard

Score every shortlisted BSP on the same eight criteria with declared weights. Make vendors answer in writing — written answers become contractual representations; demo-call answers evaporate.

Pricing forensics: questions that expose hidden markup

Per-message economics hide in four places. Put these questions in the RFP verbatim and require numeric answers:

1. "State your markup over Meta's charge for each conversation category — marketing, utility, authentication, service — as a separate line." A BSP that quotes one blended "per-message rate" without splitting out the Meta component is bundling its margin into a number you cannot benchmark. Illustrative math: at 50,000 messages a month, a hidden markup of ₹0.15–0.40 per message buried in a bundled rate is ₹7,500–20,000 a month — ₹90,000 to ₹2.4 lakh a year — that never appears as a "platform fee" on any invoice (illustrative; verify rates current as of 2026).

2. "List every fee that can change during the term, and the escalation mechanism." Platform-fee escalators, annual "uplifts", and re-rating clauses triggered by volume changes belong in daylight.

3. "Is any component mandatory-bundled?" Onboarding packages, minimum monthly commits, compulsory support tiers and seat minimums are markup wearing a different coat.

4. "What is the per-seat or per-agent cost at 5, 25 and 100 users?" Per-seat creep is the quiet second tax: the pilot with 3 agents is cheap; the rollout with 60 is not. If the model decision itself is unclear, our Client Pay vs SaaS Pay decode explains the two clean ways a BSP can charge — and run your own volumes through the WABA cost calculator before you score anyone.

Security and compliance review: the DPDP processor checklist

Under India's DPDP regime your BSP is a data processor acting on your instructions, and the obligations only bind if they are in the contract (verify the current rules and timelines as of 2026 with counsel). Require each of these as drafted clauses, not policy-page links:

Purpose limitation — customer data is processed only to deliver the contracted service; no secondary use, no model-training on your conversations without explicit written consent. Sub-processor disclosure — a named list (cloud hosts, analytics, support tooling), with notice before any addition. Breach-notice SLA — a defined clock measured in hours, to a named contact, with enough detail for you to meet your own notification duties. Data deletion on exit — certified deletion within a stated window after contract end, covering backups. Audit rights — at minimum, the right to receive security-assessment summaries; ideally, the right to audit on notice.

Beyond the contract, do two verification passes: confirm the vendor's Meta partner status independently in Meta's own partner directory rather than trusting a badge on a website (verify the current directory location as of 2026), and review token and access governance — who inside the vendor can read your messages, how system-user tokens are scoped and rotated, and whether tenant data is isolated. A vendor that cannot answer the token question crisply has not thought about it.

Reference checks and the two-week PoC

Ask references the questions vendors don't arrange: What broke in month three? How did billing accuracy hold up against the proposal? What was the real support response time during an outage? Then design a proof-of-concept that produces evidence, not impressions. Two weeks is enough if you instrument it. A PoC must prove four things:

Throughput — send a realistic burst (a few thousand messages) and measure actual delivery pace and queue behaviour, not quoted capacity. Webhook reliability — count delivery/read/reply callbacks received versus expected; missed webhooks silently corrupt every downstream workflow. Support response — raise two real tickets during the PoC, one routine and one marked urgent, and time the answers. Billing accuracy — reconcile the PoC invoice line-by-line against your own message logs and Meta's conversation counts. A vendor whose PoC invoice doesn't reconcile is showing you month three early.

Contract red flags vs safe clauses

Exit clauses: draft the divorce before the wedding

Four assets must be portable, and each needs its own sentence in the agreement. Data portability: contacts, opt-in/consent records with timestamps, approved template library, and conversation history — exportable in open formats, self-serve, throughout the term and for a stated window after it. Template ownership: approved templates belong to your WABA at Meta, but confirm contractually that the BSP will not delete or obstruct them during transition. Number portability: a WABA and its number can generally be moved between BSPs through Meta's process, but the mechanics and timelines change — verify the current Meta process as of 2026, and put a cooperation duty on the vendor ("vendor shall execute all steps required by Meta to transfer the WABA within X business days of notice"). Parallel-run rights: the explicit right to run a second provider alongside during transition, so you never face a hard cutover. The operational sequence of an actual move is covered step-by-step in the BSP migration guide — the point here is that every step in that guide is trivial or miserable depending on what you sign now.

Run the procurement on WhatsApp itself

The most underrated due-diligence trick: make WhatsApp the procurement channel and watch how each vendor performs on their own product. A five-stage lifecycle works cleanly:

1. RFI broadcast — a templated message to shortlisted vendors with the scorecard attached as a PDF. 2. Scored Q&A threads — one thread per vendor; their response speed, clarity and willingness to answer the markup question in writing all feed the scorecard. 3. PoC coordination — schedule the throughput tests and ticket drills in-thread; you are simultaneously testing their inbox, routing and notification behaviour. 4. Commercial negotiation thread — keep redlines and concessions in a written, timestamped channel. 5. Award and onboarding — the winning thread becomes the onboarding thread; the losing threads become your benchmark file for renewal time. If a BSP's own pre-sales experience on WhatsApp is slow or clumsy, you have learned something no RFP answer can hide. (For the evaluation-criteria companion to this process view, see how to evaluate a WhatsApp BSP.)

How RichAutomate answers this scorecard — and when you should pick someone else

Score us with the same sheet. On pricing transparency: the markup question has a one-line answer — there is none. ₹0 platform fee, ₹0 setup, ₹0 monthly. On Client Pay, you pay ₹0.10 per message to us and Meta's conversation charges bill to you directly through your own Meta Business Manager — you see Meta's wholesale rate, unbundled, every month. On SaaS Pay, it is ₹1.20 per marketing message and ₹0.30 per utility message all-in, one GST invoice. On exit rights: your contacts, opt-ins, templates and history are exportable, your flows are yours, and there is no lock-in term and no exit fee. On PoC: the 14-day free trial with 100 credits is the proof-of-concept — run the throughput test, raise the tickets, reconcile the invoice.

And the honest counter-case: if you need multi-country numbers under one global contract, voice and SMS bundled with WhatsApp, or a dedicated named compliance team for multi-jurisdiction regulatory work, a global CPaaS is the right answer and you should weight the scorecard accordingly and pick one. The scorecard exists so that choice is made on evidence, not on whoever ran the smoothest demo.