Guide
Meeting People Where They Are: A Connectivity Playbook for Public Sector
This is a practical playbook for teams that need efficient and easily accessible options for reaching people in difficult connectivity environments.
Time to read:
Meeting People Where They Are: A Connectivity Playbook for Public Sector
When a crisis hits, people don’t care which telecom provider you’re using or how your call routing works. They care that they can easily get the help they need when they dial a number, send a message, or tap “call” in WhatsApp.
But making that happen is harder than it sounds for humanitarian organisations. The helpline in the capital might have fibre. The Gender-Based Violence (GBV) hotline in a provincial town might have patchy 3G and frequent power outages. A remote clinic might have a single mobile tower and a Starlink dish that only works when fuel is available.
At Twilio, connectivity is a core part of crisis readiness: putting the right communication channels in place before emergencies hit, so teams can move fast when they do. This blog is a practical playbook for humanitarian and public sector programme teams who need real, efficient, and easily accessible options for reaching people in difficult connectivity environments.
We’ll share actionable advice you can use for:
Voice helplines and hotlines
SMS two‑way communication
WhatsApp messaging and calling
USSD for feature phones and zero‑data users
And we’ll do this using real‑world scenarios such as a remote GBV helpline in DRC, cash assistance communications, and early warning systems.
The goal is simple: help you meet people where they are, with the infrastructure you actually have.
How to choose: A simple connectivity checklist
When you plan a new hotline, SMS line, or digital service, you can use a simple checklist to pick the right patterns.
1. Understand your users
What devices do they primarily use?
Feature phones only?
Mix of feature phones and smartphones?
Strong or weak WhatsApp usage?
How reliable are:
Regular voice calls?
SMS?
Data / internet?
What are the cost considerations?
Is incoming voice free?
Are outgoing calls or data prohibitively expensive?
2. Understand your options per country
For each country, you’ll want to gather whether:
Twilio can provide:
Local voice numbers?
2‑way SMS numbers?
A WhatsApp sender via a Business Account?
Are there local partners who can provide:
SIP trunks (for voice) that can connect to Twilio?
2‑way SMS numbers with webhooks?
USSD quick codes?
Work with your ICT or digital team and local partners to build this reference list once; reuse it across programmes.
3. Select your primary channels and fallbacks
Choose primary channels that match how people already communicate:
Urban youth: WhatsApp and voice
Rural farmers: USSD and call‑back voice
Cash recipients: SMS and optional WhatsApp for those who have it
Design fallbacks for when your first choice fails:
Local PBX behaviour if your satellite link goes down
SMS or USSD if WhatsApp access is disrupted
Simple IVR or voicemail if agents are temporarily unavailable
4. Centralise the human response
Whatever mix of connectivity you use at the edge, you’ll want to aim for:
One main agent interface (such as Twilio Flex)
One place where you configure routing and workflows
One place where you collect metrics and evidence
That way, as you scale across countries and crises, you don’t fragment your teams.
Start with patterns, not platforms
The good news? You don’t need to become a telecom engineer to design robust communication channels. But you do need a way to think in simple, repeatable patterns:
Where does the phone number or sender “live”?
With Twilio, a local carrier, another SMS provider, or as a SIM in a phone?Do we need any physical equipment in‑country?
GSM gateways, small servers, Android phones, satellite kits?How do we connect that to the place where agents actually work?
For example, Twilio Flex as your central contact centre interface.
Once you recognise the patterns, you can mix and match them with countries and use cases, instead of starting from zero each time.
Let’s start with voice.
Voice: Six practical ways to make a hotline work
Voice is still the most trusted channel in many crises, especially for sensitive topics such as GBV, child protection, and mental health. But the way you get a working phone number into your contact centre depends heavily on the country.
In practice, most hotlines fall into one of six patterns. The voice ladder diagram groups them like the diagram below:
On the left, cloud‑first options using Twilio or cloud carriers, with no in‑country hardware
In the middle, a thin edge with a simple in‑country device with a local SIM
On the right, thick edge patterns, where local equipment can keep calls going even when the internet fails
Caption: Six voice connectivity patterns, from cloud‑first to thick edge. As you move right, complexity and cost increase, but so does resilience in low‑connectivity environments.
As you move from left to right, each pattern gives you more resilience in difficult environments, but also adds complexity and cost. The aim is to stay as far left as your context allows, and only move right when you truly need to.
Pattern 1: Twilio local number (pure cloud)
These are best for national or regional helplines in countries with good infrastructure such as UK‑style contexts and regional hubs. They’re also helpful for situations where you buy a local or toll‑free Twilio phone number.
The first steps to get started:
You buy a number from Twilio.
When someone calls that number, Twilio will receive the call directly. Then Twilio will run your call logic, including your IVR menus, language selection, routing by topic, etc. A task is then created in Twilio Flex, and an available agent will answer using a browser headset .
Locally, you’ll just need access to the internet for your agents (whether they are in-country or elsewhere). You won’t need any in-country telephony hardware.
What you deploy locally:
No in‑country telephony hardware
Just internet for your agents (who could be in‑country or elsewhere)
This is your default pattern wherever Twilio can provide numbers and the internet is stable.
Pattern 2: Local SIP carrier (cloud bridge)
Best for:
Countries where Twilio can’t provide phone numbers, but strong local SIP/VoIP carriers exist
Urban or national helplines with decent internet connectivity
How it works:
You lease a local phone number (geographic or toll‑free) from a local phone company.
That company delivers calls to Twilio over the internet using a standard protocol (SIP).
Twilio receives the calls and routes them into your Flex contact centre, just like in Pattern 1
What you deploy locally:
No physical hardware is strictly required, just an agreement with a carrier that can deliver calls over SIP to Twilio.
Think of this as: “We keep our local carrier, but Twilio runs the contact centre.”
Pattern 3: Local carrier via PBX (cloud bridge)
Sometimes local carriers can’t connect directly to Twilio, but they can connect to a PBX (a phone server), either in the cloud or on‑premise.
Best for:
Contexts where you must use a particular local carrier that can’t talk to Twilio directly
Organisations that already run a PBX and are comfortable managing it
How it works:
You lease a local phone number from a carrier.
The carrier delivers calls to your PBX (e.g. FreePBX, Asterisk) via SIP.
Your PBX forwards those calls to Twilio over another SIP connection.
Twilio hands them to Flex; agents answer as normal.
Locally, you’ll need to deploy a PBX instance either on-premise or in the cloud that you control or outsource. And no extra hardware is needed if your PBX is cloud-hosted.
Here, the PBX acts as a translation layer between the local carrier’s world and Twilio.
Pattern 4: Local mobile SIM (thin edge)
With pattern 4, we move into more constrained environments. This pattern is best for more populated areas such as capital cities or larger towns where Twilio doesn’t provide voice numbers, but mobile networks are strong. Also, where you want the hotline number to look and feel like a “normal” mobile number. It also helps for situations where having a mobile identity improves an organisation’s trust or reach.
Best for:
Capital cities or larger towns where:
Twilio doesn’t provide voice numbers, but mobile networks are strong
You want the hotline number to look and feel like a normal mobile number
Situations where having a mobile identity improves trust or reach
To get started, you’ll need to buy a normal local prepaid or postpaid SIM card from a mobile operator. You’ll insert it into a GSM gateway, a small device that turns mobile calls into internet-based calls. When someone calls the SIM’s number, the GSM gateway will convert the call to SIP and send it to Twilio over the internet. Twilio will then deliver it to Flex and agents will answer the call in their browsers.
How it works:
You buy a normal local prepaid or postpaid SIM card from a mobile operator.
You insert it into a GSM gateway, a small device that turns mobile calls into internet‑based calls.
When someone calls the SIM’s number, the GSM gateway converts the call to SIP and sends it to Twilio over the internet.
Twilio delivers it to Flex; agents answer the call in their browsers.
What you deploy locally:
A GSM gateway in a location with:
Good mobile signal, and
Some form of internet (fixed or mobile data)
Choose this when you want a familiar local mobile number, but you can still rely on the internet most of the time.
Pattern 5: Local mobile SIM (thick edge)
Best for:
Provincial towns or field offices where:
GSM voice is reasonably reliable, but
Internet is patchy or goes down often
GBV, protection, or health hotlines where it’s unacceptable for the number to “just stop working” when the link to the outside world fails
This is your core thick edge pattern: Local equipment provides a fallback so calls can still be handled locally if the internet link to Twilio is down.
How it works:
You deploy three components on‑site:
GSM gateway + local mobile SIM
A normal local mobile number in a GSM gateway device.
This is the hotline number people dial.
Small PBX (phone server)
For example, Asterisk or FreePBX running on a Raspberry Pi or small Linux box.
Receives calls from the GSM gateway and decides what to do with them.
Internet connection
Whatever you can get: fibre, DSL, 4G router, etc.
Used when available to connect the PBX to Twilio and Flex.
There are two operating modes: when the internet is UP or when it is DOWN.
When the internet is up, the caller will dial the local mobile hotline number (the SIM in the GSM gateway). The call flow will go as follows:
Caller dials the local mobile hotline number (the SIM in the GSM gateway).
Call flow:
Caller → Mobile network → GSM gateway → Local PBX → Internet → Twilio → FlexTwilio creates a voice task in Flex; any available agent (in the capital, in another country, or working from home) answers via their browser.
When the internet is down, the caller will still dial the same local mobile number. The GSM gateway will pass the call to the PBX as usual, but the PBX will see that the internet/Twilio path is unavailable. Instead of failing the call, the PBX will handle it locally. It can then do one of three things:
Caller still dials the same local mobile number.
The GSM gateway passes the call to the PBX as usual, but the PBX sees that the internet / Twilio path is unavailable.
Instead of failing the call, the PBX handles it locally. For example, it can:
Play a simple recorded message (e.g. “We’re currently offline; if this is an emergency, contact…”
Ring one or more local SIP phones or softphones in the office/clinic
Send the caller to a basic voicemail that staff can check later
From the caller’s point of view, the number always does something useful, even if during outages, the service is simpler than normal.
But there can be concurrency constraints. Each GSM SIM gives you one concurrent call. If you use one SIM as the hotline number in a single-slot gateway, you can only have one live call at a time on that number, whether it’s being routed to Flex or handled locally.
To increase concurrency at the edge, you need:
A GSM gateway with multiple channels/SIMs, and
Either several published numbers, or a carrier‑side hunt group that distributes calls across those SIMs.
What you deploy locally
1× GSM gateway + local SIM (or multi‑SIM gateway if you want more capacity)
1× Raspberry Pi or small server running a PBX
Internet connection (when available)
(Optional) local SIP phones / softphones for use during outages
For services that need live conversations on the inbound call, this is the core thick‑edge pattern.
If you prefer a “we’ll call you back” model, you can adapt this into a multi‑SIM callback design (see “Multi‑SIM callback thick edge” below).
Pattern 6: Local mobile SIM (thick edge + satellite)
Pattern 6 is best for exceptionally remote clinics or protection sites in places such as South Sudan or rural Ethiopia. These locations have no practical terrestrial internet, so you need to bring your own connectivity (like Starlink). If you’re looking for the resilience of pattern 5, but the only internet link is satellite, this is the option for your organisation
Best for:
Very remote clinics or protection sites in places like South Sudan or rural Ethiopia
Locations with no practical terrestrial internet, where you must bring your own connectivity (e.g. Starlink)
Scenarios where you want all the resilience of Pattern 5, but the only internet link is satellite
This is the satellite version of Pattern 5: the same thick‑edge idea, but the PBX reaches Twilio over a satellite link rather than standard broadband.
Pattern 6 works by using the same building blocks as pattern 5:
GSM gateway + local SIM: the hotline number people dial
Small PBX: Asterisk / FreePBX on a Raspberry Pi or small server
Satellite internet kit: Starlink dish, router, power supply
Again, there are two modes: when the satellite link is UP and when it is DOWN.
Caller dials the local mobile hotline.
Call flow:
Caller → Mobile network → GSM gateway → Local PBX → Satellite link → Twilio → FlexFlex agents anywhere with internet can answer as usual via WebRTC.
When the satellite link is DOWN
Caller still dials the same number.
The PBX detects that it cannot reach Twilio.
It handles the call locally (recording a message, ringing local phones, or providing a basic menu), just like in Pattern 5.
This also presents concurrency constraints. The satellite link does not remove GSM limitations: Each SIM/channel in the GSM gateway still supports only one concurrent call. If you publish a single mobile number (one SIM) as a hotline, you can still only handle one live inbound call at a time on that number. To support more simultaneous callers, you’ll need multiple SIMs/channels in the gateway, and either multiple published numbers or operator-side features that fan calls across them.
Concurrency constraints:
The satellite link does not remove GSM limitations:
Each SIM/channel in the GSM gateway still supports only one concurrent call.
If you publish a single mobile number (one SIM) as the hotline:
You can still only handle one live inbound call at a time on that number.
To support more simultaneous callers, you need:
Multiple SIMs/channels in the gateway, and
Either multiple published numbers or operator‑side features that fan calls across them.
What you deploy locally:
1× GSM gateway + SIM (or multi‑SIM gateway)
1× Raspberry Pi or small PBX server
1× satellite internet kit (e.g. Starlink)
(Optional) local SIP phones / softphones and power backup
This is the top of the ladder with the highest complexity and cost, but it lets a GBV, protection, or health hotline operate from a village that has only mobile coverage and a satellite terminal.
You can also run it in a callback‑centric way using the same Multi‑SIM Callback Thick Edge variant described below.
Optional variant: Multi‑SIM callback thick edge
(One published number, multiple SIMs for callbacks)
This callback pattern is an optional variation of the thick‑edge setup in Patterns 5 and 6. It uses the same GSM gateway and PBX hardware, but changes how you handle inbound calls: Every call becomes a callback request, and outbound calls fan out over multiple SIMs.
For some services (especially GBV and psychosocial support) it can be better to treat the hotline as a “request a call back” line rather than a live conversation line. You still use the thick‑edge hardware, but you tune it for short inbound calls and structured callbacks, with multiple SIMs to increase how many callbacks you can place in parallel.
You can use this in the following situations:
You want a single, memorable number for people to call
You don’t want callers sitting on hold or paying for long calls
You’re comfortable that all real conversations will be outbound from you
You’d like to place several callbacks at the same time using multiple SIMs
To deploy this, you’ll need some hardware on-site for each location: a multi-slot GSM gateway, a Raspberry Pi or small server running a PBX, and three to four local mobile SIMs, and an internet connection (terrestrial or satellite, like in patterns 5 and 6).
Hardware on site (per location)
1× multi‑slot GSM gateway (e.g. 4 SIM slots)
1× Raspberry Pi or small server running a PBX
3–4× local mobile SIMs
1× internet connection (terrestrial or satellite, as in Pattern 5/6)
How does the pattern work?
For a single published intake number, you’ll first want to choose one SIM (SIM A) in the GSM gateway as your public hotline number.
Choose one SIM (SIM A) in the GSM gateway as your public hotline number.
When someone calls SIM A:
The PBX answers immediately.
Plays a short message such as:
“All our agents are busy right now. Please say your name and the reason for your call. We will call you back as soon as possible.”Optionally records a short voicemail (e.g. 30–60 seconds).
Hangs up.
Automatic callback task in Flex
When the call ends, the PBX:
Captures the caller’s phone number.
Captures a reference to the voicemail recording (if used).
Sends these, along with any other details (language, site, topic), to a simple HTTP endpoint on your backend or a Twilio Function.
That backend uses the Twilio API to create a callback task in Flex
The result? Every answered call to the published number becomes a structured callback request in your central contact centre.
However, there are a few concurrency constraints, both inbound and outbound.
Inbound, these constraints include:
As long as you publish only one hotline number (SIM A), you can still only have one intake call in progress at a time on that number
Voicemail and callback makes much better use of that one slot (everyone who gets through is queued for a callback), but it does not allow multiple simultaneous callers on that same MSISDN
Outbound constraints include:
You can place as many simultaneous callbacks as you have SIM channels configured for outbound (e.g. three parallel calls with SIM B/C/D in a four‑slot gateway)
This is where the multi‑SIM design really increases your capacity
To handle very high influxes of calls, you can publish two to four intake numbers (with each on its own SIM or channel), and/or combine this with USSD/SMS “request a callback” options so people aren’t all competing for that single voice line.
Publish 2–4 intake numbers (each on its own SIM/channel), and/or
Combine this with USSD/SMS “request a callback” options so people aren’t all competing for that single voice line.
This variant is a good fit when your priority is dignified, low‑cost access and structured follow‑up, and when it’s acceptable that the first call is short and purely for requesting support, rather than a live counselling session.
Further Reading
SMS: Four options when data is scarce
SMS remains critical for several use cases, including cash assistance programmes (enrollment, payment notifications, FAQs), appointment reminders and follow-ups, broadcast alerts to specific groups, and simple two-way feedback and complaints.
But the right SMS pattern depends on three questions:
Do you need outbound only, or two‑way?
Is Twilio’s SMS connectivity strong enough in that country?
Do you need a true local SIM identity?
There are four main patterns we see for SMS in humanitarian settings. The SMS diagram shows them from left to right:
Twilio 2‑Way SMS Number (cloud‑first)
Twilio Sender ID (outbound‑only)
External Cloud SMS Provider (bridge to Flex)
Local SIM + Android (SMS edge device)
As you move from left to right, you gain more local control and the ability to work around weak cloud SMS routes, but you also take on more complexity and operational work. Start with Twilio’s own SMS capabilities where they’re strong, and move right only when you need additional coverage or a true local SIM identity.
SMS option 1: Twilio 2‑way SMS number
Option 1 is best for:
Countries where Twilio can provide reliable 2‑way SMS
Low‑ to medium‑volume two‑way interactions such as cash assistance queries, feedback, and hotline overflow.
How it works:
You get a local or international SMS‑capable number from Twilio.
People send SMS to that number.
Twilio turns each conversation into a messaging task in Flex.
Agents reply in Flex; users receive standard SMS messages.
As for what you deploy locally? Nothing.
If Twilio has good SMS coverage, this is the simplest and cleanest option.
SMS Option 2: Twilio Sender ID (Outbound‑Only)
Best for:
One‑way alerts (e.g. “your cash transfer is ready”, “distribution time changed”, “flood warning”)
Countries where Twilio supports SMS sender IDs, but not full 2‑way SMS numbers
How it works:
Instead of a phone number, you send from a Sender ID like [NGOName].
Your system uses Twilio’s SMS API to send messages; recipients see them as coming from that ID.
People cannot reply directly to that Sender ID.
Locally, you don’t need to deploy anything for Option 2.
This is ideal for high‑volume broadcasts. If you need two‑way communication, you’ll pair this with another channel such as voice, WhatsApp, or a separate SMS number.
SMS Option 3: External Cloud SMS Provider (Bridge to Flex)
If Twilio’s SMS coverage is limited in a specific country, but another cloud provider has strong 2‑way SMS, you can still centralise your agents in Flex.
Best for:
Countries where a local/regional SMS provider has better routes than Twilio
Teams that want to keep using Flex, even if SMS traffic goes through another provider
With this option: lease a 2‑way SMS number from a cloud SMS provider
That provider sends an HTTP webhook to your backend whenever an SMS is received.
Your backend uses the Twilio API to create or update a messaging conversation in Flex.
When an agent replies in Flex, your backend will send the message out through the external provider’s SMS API.
What you deploy locally: nothing physical, just a small bridging service, which can be built with Twilio Functions or your own server.
This lets you choose the best SMS carrier per country, while keeping a single agent interface.
SMS Option 4: Local SIM and Android (SMS Edge Device)
Sometimes the only reliable SMS route is a local SIM on a specific mobile network, especially in rural or politically sensitive environments.
Best for:
Countries where cloud SMS is filtered, unreliable, or too expensive
Contexts where people trust and expect a normal local mobile number
Rural cash assistance lines and feedback mechanisms
How it works:
You put a local SIM card into an Android phone or tablet.
You install an app such as Telerivet, which turns the phone into an SMS gateway.
When someone texts the SIM number, the phone will receive the SMS and the app will forward the message data to a cloud service. Your backend (or a Twilio Function) will read these messages and will create messaging tasks in Flex.
When agents reply in Flex, the phone will send SMS back to the user using the SIM.
What you deploy locally:
At least one Android device per SIM, kept charged and connected occasionally (via mobile data or Wi‑Fi)
Someone to manage airtime, charging, and basic troubleshooting.
This pattern gives you a true local identity and control, at the cost of managing a small fleet of devices.
Further Reading
Twilio Programmable Messaging (including SMS)
When voice lines are overwhelmed or users need to communicate silently for safety, messaging becomes the primary option. Just like voice, your SMS strategy depends entirely on the local environment.
WhatsApp: Messaging and calling where data exists
In many countries, WhatsApp is now the default channel for everyday communication. For urban youth, displaced people with smartphones, or diaspora communities, “contact us” often means “message us on WhatsApp.”
Twilio makes WhatsApp work with Flex for both messaging and voice calls.
WhatsApp Messaging
With WhatsApp Messaging, there are two main ways conversations start.
1. User‑initiated (Inbound)
Best for:
Helplines and support services where users reach out first
GBV or protection lines where text feels safer than voice
Ongoing casework where users may message at any time
How it works:
A user will send a message to your WhatsApp Business number.
Twilio will then receive it and create a messaging task in Flex.
An agent replies in Flex, and the user will see responses in their WhatsApp chat.
Everything lives in a single conversation thread per user.
2. Business‑initiated (Outbound with Templates)
Best for:
Proactive follow‑ups (“How are you doing after your last counselling session?”)
Cash and voucher assistance notifications and check‑ins
Reminders for appointments, distributions, or document submission
How it works:
Your system or an agent starts a WhatsApp conversation to whatsapp:+1234567890.
For the first message, if more than 24 hours have passed since the user last messaged you, you must use an approved WhatsApp template and have prior consent.
Once the user replies, there is a 24‑hour window where agents can send free‑form messages.
This balances user protection and privacy with the ability for organisations to re‑engage people who want to be contacted.
WhatsApp Voice Calls
WhatsApp isn’t just text. People can tap “call” inside WhatsApp and reach you via internet voice (VoIP).
User‑Initiated WhatsApp Calls
Best for:
Users with data but limited or expensive regular voice minutes
Services where users are already interacting with your WhatsApp number
How it works:
The user will tap the call button in your WhatsApp chat.
A VoIP call then will come into Twilio’s voice platform, and your voice workflow will create a voice task in Flex.
An agent will answer via WebRTC (browser audio).
From the agent’s point of view, it’s simply another voice call in their queue.
Business‑Initiated WhatsApp Calls
Best for:
Call‑backs to people who prefer WhatsApp
Situations where normal voice calls would be too expensive or unreliable
How it works:
An agent in Flex will click to call whatsapp: +number.
Twilio places a WhatsApp VoIP call to the user’s app.
When the user answers, the call is bridged to the agent’s browser.
Availability of outbound WhatsApp calls depends on Meta’s policies and the countries involved, so you’ll need to check current coverage.
Further Reading
USSD: Reaching People with Feature Phones and No Data
For many rural communities, USSD is the most reliable way to access digital services.
USSD is the menu‑based interface you reach by dialling codes like *123#. It works:
On any mobile phone, even basic “feature phones”
Without a data plan
With simple numeric menus
USSD for Intake and Registration
What it looks like for a user:
They dial a short code, for example *123*4#.
On screen, they see a menu such as:
Choose language
Request help
Report incident
They reply with a number.
They go through a series of short screens to provide basic information.
When they finish, the session ends; nothing is stored on the phone.
To provide it, you will need to:
Lease a USSD short code from a mobile operator or an aggregator
You will then build the USSD menu in a USSD application platform (for example, Telerivet is one example).
The app will then collect information such as language, type of need, consent, callback number).
USSD is particularly strong for the following use cases:
Early warning systems and incident reporting in rural areas
Cash assistance registration for people with basic phones
Quick triage (“do you need information, a call‑back, or to report an urgent risk?”)
Pattern: USSD for intake, Twilio Flex for follow‑up
One powerful pattern combines USSD with voice calls handled in Flex. Here’s how to approach this pattern:
Step 1: User completes a USSD menu
They dial the short code, choose their language and the reason for contact, and select “Request a call back” or “Report an issue”.
The USSD app captures their phone number and key answers (e.g. category of issue, location).
Step 2: USSD app triggers a callback request
When the user submits the form, the USSD platform sends a simple HTTP request to your Twilio Function or backend system, including:
Phone number
Language
Type of need / topic
Any other short details
Step 3: Twilio places a call and routes to Flex
Twilio uses Programmable Voice to dial the user’s phone.
At the same time, Twilio creates an outbound voice task in Flex, assigned to a relevant queue (e.g. GBV counsellors, cash assistance team).
An agent answers, is connected to the user, and sees the context gathered via USSD.
From the user’s perspective:
They only needed a short code, no data, no app.
They get a human conversation shortly after completing the menu.
From your perspective:
All live conversations are still managed in Flex, with full reporting.
USSD is simply the front door that makes your service reachable to people with the least connectivity.
Further Reading
Two-way Communication for Humanitarian Operations with USSD in Twilio Flex.
How to choose: A simple connectivity checklist
When you plan a new hotline, SMS line, or digital service, you can use a simple checklist to pick the right patterns.
1. Understand your users
What devices do they primarily use?
Feature phones only?
Mix of feature phones and smartphones?
Strong or weak WhatsApp usage?
How reliable are:
Regular voice calls?
SMS?
Data / internet?
What are the cost considerations?
Is incoming voice free?
Are outgoing calls or data prohibitively expensive?
2. Understand your options per country
For each country, you’ll want to gather whether:
Twilio can provide:
Local voice numbers?
2‑way SMS numbers?
A WhatsApp sender via a Business Account?
Are there local partners who can provide:
SIP trunks (for voice) that can connect to Twilio?
2‑way SMS numbers with webhooks?
USSD short codes?
Work with your ICT or digital team and local partners to build this reference list once; reuse it across programmes.
3. Select your primary channels and fallbacks
Choose primary channels that match how people already communicate:
Urban youth: WhatsApp and voice
Rural farmers: USSD and call‑back voice
Cash recipients: SMS and optional WhatsApp for those who have it
Design fallbacks for when your first choice fails:
Local PBX behaviour if your satellite link goes down
SMS or USSD if WhatsApp access is disrupted
Simple IVR or voicemail if agents are temporarily unavailable
4. Centralise the human response
Whatever mix of connectivity you use at the edge, you’ll want to aim for:
One main agent interface (such as Twilio Flex)
One place where you configure routing and workflows
One place where you collect metrics and evidence
That way, as you scale across countries and crises, you don’t fragment your teams.
Putting Patterns into Practice
Crisis readiness isn’t only about having a playbook for messaging and hotlines, it’s about making sure those channels actually work where people are:
In cities with fibre and smartphones
In provincial towns with patchy 3G
In remote villages with one mobile tower and no data coverage
You can design services that continue to function when things go wrong by combining connectivity patterns like:
Cloud numbers, local carriers, GSM gateways, and on‑site PBXs for voice
Twilio SMS, external SMS providers, or local SIM proxies for SMS
WhatsApp messaging and calling where data exists
USSD front‑doors for feature phones and no‑data contexts
If you’re planning a new hotline, cash assistance programme, or early warning system and need help mapping these patterns to your specific countries, Twilio can work with your teams with the following areas:
Assess the connectivity landscape
Choose the right mix of voice, SMS, WhatsApp, and USSD while accounting for constraints
Design resilient architectures that keep you operating through outages
Pilot in one location and scale as you learn
With the right connectivity design, you can truly meet people where they are, and stay ready to support them when crises come.
If you’re part of a humanitarian organisation, government agency, or community group and want to put these connectivity patterns into practice, Twilio can support you.
We offer tools, funding, and technical guidance through programmes like Twilio Impact Access to help you prepare, respond, and recover, while keeping people connected on the channels that work for them.
