Request for Proposal (RFP)
Business messaging services: SMS and WhatsApp
Key information
| Issuing organisation | …………………… |
|---|
| RFP reference | …………………… |
|---|
| Issue date | …………………… |
|---|
| Deadline for questions | …………………… |
|---|
| Proposal submission deadline | …………………… |
|---|
| Expected award date | …………………… |
|---|
| Contact for questions and submissions | …………………… |
|---|
1. Introduction and purpose
The organisation, an enterprise, invites qualified providers to submit proposals for SMS and WhatsApp services as described in this document. The purpose is to select a provider that offers reliable delivery, regulatory compliance, strong security and clear, competitive pricing.
2. Definitions
- The Organisation: the issuing organisation named above.
- Bidder: a provider that submits a proposal in response to this RFP.
- DLR (delivery report): the operator's confirmation of a message's delivery status.
- Sender ID: the name or number shown to the recipient as the sender.
- BSP: a WhatsApp Business Solution Provider authorised by Meta.
- SLA: the service levels the Bidder commits to.
- TPS: throughput in messages per second.
- Direct connection: a route connected to the mobile operator without an intermediate aggregator.
- M / D: Mandatory requirement / Desirable requirement.
3. Scope of work
| Channel | Expected monthly volume |
|---|
| SMS (A2P text messages) | To be confirmed |
| WhatsApp Business Platform | To be confirmed |
Countries in scope: ……………………
Integration methods required: REST API and Webhooks.
Mandatory certifications and compliance: ISO/IEC 27001.
4. Instructions to bidders
- Submit a technical proposal and a financial proposal as separate documents.
- Proposals must remain valid for 90 days from the submission deadline.
- Proposals may be submitted in Arabic or English. If both versions are provided, state which one prevails.
- Send questions in writing to the contact above before the questions deadline. Answers may be shared with all bidders without naming the sender.
- State for every requirement in section 6 whether you are Compliant, Partially compliant or Not compliant, with an explanation and evidence (Annex B).
- All information in this RFP and in the proposals is confidential and may be used only for this process.
- Bidders bear all costs of preparing and submitting their proposals.
- The Organisation may accept or reject any proposal, request clarifications, or cancel this RFP without obligation.
5. Timeline
| Milestone | Date |
|---|
| Issue date | …………………… |
| Deadline for questions | …………………… |
| Proposal submission deadline | …………………… |
| Proof of concept (shortlisted bidders) | …………………… |
| Expected award date | …………………… |
6. Technical and commercial requirements
6.1 Coverage, routes and sender IDs
| No. | Requirement | M/D |
|---|
| 6.1.1 | For each country in scope (as listed in the scope of work), list the mobile operators you reach and state for each whether the route is a direct operator connection or passes through a third-party aggregator. | M |
| 6.1.2 | Describe sender ID registration in each country: requirements, documents, typical lead time, fees, and whether you file the registration on the organisation's behalf. | M |
| 6.1.3 | State which sender types are supported per country (alphanumeric, long numbers, short codes) and name any country where only numeric senders are delivered. | D |
| 6.1.4 | State your status with Meta (WhatsApp Business Solution Provider or Tech Provider), who owns the WhatsApp Business Account, and the support you give for display name approval, business verification and template approval. | M |
| 6.1.5 | Confirm full Arabic and Unicode support: right-to-left rendering, correct segment counting for Unicode messages, and mixed Arabic and English content. | M |
6.2 Delivery quality, latency and failover
| No. | Requirement | M/D |
|---|
| 6.2.1 | Provide delivery rate and delivery report (DLR) statistics for the last six months for the main countries in scope, and explain how they are measured. | M |
| 6.2.2 | State the typical and 95th-percentile time from API submission to handset delivery, and from handset delivery to the delivery report callback. | M |
| 6.2.3 | Describe automatic route failover: alternative routes per country, how quickly traffic is rerouted when a route degrades, and how the organisation is informed. | M |
| 6.2.4 | Describe channel fallback (for example WhatsApp or RCS to SMS when a message is not delivered) and how duplicate messages are prevented. | D |
| 6.2.5 | State the throughput (messages per second) committed for the organisation's account, how bursts are handled and how messages are queued. | M |
| 6.2.6 | Explain how one-time passwords and transactional messages are prioritised over bulk marketing traffic. | D |
6.3 Regulatory compliance and consent
| No. | Requirement | M/D |
|---|
| 6.3.1 | Describe how you comply with the telecom regulations and anti-spam rules of each country in scope, including promotional sending hours and opt-out wording. | M |
| 6.3.2 | Explain consent and opt-out handling: STOP keywords, opt-out lists shared across channels, and an audit trail available to the organisation. | M |
| 6.3.3 | Describe how you support the WhatsApp Business Messaging Policy, template categories (marketing, utility, authentication) and quality rating management. | M |
| 6.3.4 | Describe content controls and fraud protection, including protection of one-time password flows against SMS pumping (artificially inflated traffic). | M |
| 6.3.5 | State where message content, logs and personal data are stored and processed (country and data centre), the retention periods, and the options for in-country hosting. | M |
| 6.3.6 | Provide your data processing agreement and the list of sub-processors. | D |
6.4 Information security and certifications
| No. | Requirement | M/D |
|---|
| 6.4.1 | Provide valid certificates or reports for: ISO/IEC 27001. State the scope, the issuing body and the expiry date of each. | M |
| 6.4.2 | Describe encryption in transit and at rest, key management, and access controls (single sign-on, two-factor authentication, role-based access, IP allow-listing). | M |
| 6.4.3 | Describe your security incident management process and how and when the organisation is notified of an incident affecting its data. | M |
| 6.4.4 | State how often independent penetration tests are carried out and share a summary of the latest results. | D |
| 6.4.5 | Describe business continuity and disaster recovery arrangements, with recovery time (RTO) and recovery point (RPO) objectives. | D |
6.5 Service levels (SLA)
| No. | Requirement | M/D |
|---|
| 6.5.1 | State the monthly platform availability you commit to, how it is measured, and any exclusions. | M |
| 6.5.2 | Describe the service credits that apply when committed service levels are not met. | M |
| 6.5.3 | Complete the SLA checklist in Annex A with your committed value for each item. | M |
| 6.5.4 | Provide your availability history for the last 12 months and the address of your public status page. | D |
6.6 Support and onboarding
| No. | Requirement | M/D |
|---|
| 6.6.1 | Describe support channels (phone, email, chat, ticketing), hours of cover and languages, including Arabic and English. | M |
| 6.6.2 | State response and resolution times for each priority level (P1 to P4). | M |
| 6.6.3 | Provide the escalation matrix with named roles and contact details. | M |
| 6.6.4 | State whether a dedicated account manager and technical onboarding are included in the price. | D |
| 6.6.5 | Describe the onboarding plan: timeline, sender ID and template preparation, testing and training. | D |
6.7 Pricing schedule and commercial terms
| No. | Requirement | M/D |
|---|
| 6.7.1 | Complete the pricing schedule below for every channel and country in scope, stating the currency and how long the prices remain valid. | M |
| 6.7.2 | Explain exactly what is billed: submitted or delivered messages, per segment for SMS, and per message by template category for WhatsApp. | M |
| 6.7.3 | List every other fee: set-up, monthly platform fees, sender ID registration, dedicated numbers, short codes and support plans. | M |
| 6.7.4 | Describe volume tiers, minimum commitments, and how operator price changes are passed on, including the notice period. | D |
| 6.7.5 | State payment terms, prepaid and postpaid options, and invoicing frequency. | D |
| Channel | Country | Billing unit | Unit price | Monthly volume | Minimum commitment | Set-up / monthly fees |
|---|
| SMS | | Per SMS segment | | | | |
| WhatsApp | | Per message, by template category | | | | |
Currency: ………… Prices valid until: ………… Taxes: state whether prices include VAT.
6.8 API, integration and AI agents
| No. | Requirement | M/D |
|---|
| 6.8.1 | Provide the REST API documentation, the authentication method, available SDKs and rate limits. | M |
| 6.8.2 | Describe webhooks for delivery reports, inbound messages and opt-outs: retries, request signing and ordering. | M |
| 6.8.3 | Provide a test (sandbox) environment and state its limits. | D |
6.9 Reporting and analytics
| No. | Requirement | M/D |
|---|
| 6.9.1 | Describe real-time and historical reports: delivery status per message, per country and per operator, with error codes. | M |
| 6.9.2 | State how long message logs and reports are kept and how they can be exported (CSV, API). | M |
| 6.9.3 | Describe campaign analytics: clicks, replies, conversions and opt-outs. | D |
| 6.9.4 | State whether usage and cost reports can be split by department, sub-account or cost centre. | D |
6.10 Exit, portability and data return
| No. | Requirement | M/D |
|---|
| 6.10.1 | Describe exit assistance: notice period, transition support and any costs. | M |
| 6.10.2 | Confirm that sender IDs registered for the organisation, phone numbers, short codes, WhatsApp Business Accounts and approved templates remain the organisation's and can be transferred. | M |
| 6.10.3 | Describe the export of contacts, opt-out lists, templates and message logs in a standard format. | M |
| 6.10.4 | Confirm deletion of the organisation's data at the end of the contract, with written confirmation. | M |
6.11 Proof of concept
| No. | Requirement | M/D |
|---|
| 6.11.1 | Agree to a proof of concept before award, following the test plan in Annex C, at no cost to the organisation or at a stated cost. | M |
| 6.11.2 | Provide test credit, sender IDs or test numbers, and technical contacts for the duration of the test. | M |
7. Evaluation criteria and weights
Proposals that fail a mandatory (M) requirement may be excluded. Compliant proposals are scored from 0 to 5 on each criterion: 0 not offered, 1 weak, 2 partly meets, 3 meets, 4 exceeds, 5 excellent. The weighted total is out of 100.
| Criterion | Weight |
|---|
| Price and commercial terms | 30% |
| Coverage and delivery quality | 25% |
| Compliance and security | 20% |
| Support and service levels | 15% |
| Features and integration | 10% |
Annex A. Service level checklist
This checklist lists the service levels to be stated in the proposal. It is not a contract: the binding terms are agreed in the final service agreement.
| Item | Suggested target | Bidder's committed value |
|---|
| Platform availability (uptime) | At least 99.9% per calendar month, excluding announced maintenance | |
| API response time | 95th percentile under 500 ms, measured monthly | |
| Committed throughput | Messages per second stated per account, with burst capacity | |
| Delivery report latency | 95th percentile of reports returned within a stated number of seconds per country | |
| One-time password delivery time | 95th percentile delivered within a stated number of seconds on priority routes | |
| Support response times | P1: 15 minutes, 24/7 · P2: 1 hour · P3: 4 business hours · P4: next business day | |
| Incident communication and root cause analysis | Status updates during P1 incidents; written root cause analysis within 5 business days | |
| Service credits | Tiered credits on the monthly invoice when availability falls below the commitment | |
| Planned maintenance | At least 5 business days' notice, outside local business hours | |
| Escalation matrix | Named roles and contacts for each escalation level, kept up to date | |
| Monthly service report | Availability, delivery, latency and support figures against each target | |
| Disaster recovery | Stated recovery time (RTO) and recovery point (RPO) objectives, tested at least yearly | |
| Security incident notification | Without undue delay and within the period required by applicable law | |
| Data return and deletion on exit | Export in a standard format, then deletion with written confirmation | |
Annex B. Compliance response form
For each requirement number in section 6, state: Compliant / Partially compliant / Not compliant, your explanation, and the reference of any supporting document. A response sheet with every requirement is provided with this RFP.
Annex C. Proof of concept test plan
- Test numbers: at least two handsets on every mobile operator in each country in scope, prepaid and postpaid where possible.
- Delivery rate and DLR accuracy: compare the delivery reports with what the handsets actually received.
- Latency: time from submission to handset and to delivery report, per operator.
- Sender ID display: the registered sender name appears unchanged, with no number substitution.
- Arabic and Unicode: right-to-left rendering, emoji, and long multi-part messages arrive in one piece.
- Opt-out handling: a STOP reply is processed and the number is excluded from the next send.
- Failover: behaviour when a route or channel is unavailable, including fallback to SMS.
- One-time passwords: delivery time at peak hours.
- Record every result in the evaluation scorecard. Suggested duration: 5 to 10 business days.
Template for information only, not legal advice. Have counsel review before use.
