Practical Guidance

Communication infrastructure is the technology that allows organisations and the people they serve to communicate reliably at scale. It can include SMS, WhatsApp, voice, interactive voice response, USSD, email, chatbots, call centres and the systems that connect these channels to programme data and operational teams.

The important word is infrastructure. Sending a message is relatively easy. Building a system that allows thousands or millions of people to receive information, ask questions, register for services, provide feedback and receive a meaningful response is much more complicated.

Good communication infrastructure should work across different devices, languages, literacy levels and levels of connectivity. It should allow organisations to communicate at scale without losing the ability to listen and respond to individuals. It should also connect communication to existing systems such as CRM platforms, case management tools, service databases and operational workflows.

For organisations working directly with communities, communication is increasingly part of service delivery itself. People may use the same channel to register, ask for help, report a problem, receive an update or confirm that a service has been delivered.

The best systems therefore do more than send messages. They create a reliable connection between an organisation and the people it serves.

WhatsApp can be a powerful communication channel because it is already part of everyday life for billions of people. Organisations do not need to convince communities to download a completely new application or learn an unfamiliar system. In many contexts, the channel is already there.

Organisations can use WhatsApp for one-way communication such as alerts, service updates and public information, but its real value often comes from two-way interaction. People can ask questions, register for services, complete surveys, submit feedback, receive personalised information or speak with a member of staff.

At scale, this usually requires more than a standard WhatsApp account. Organisations need a structured system behind the channel that can manage consent, contacts, automation, conversations, escalation and reporting. Some questions can be answered automatically, while others should be handed to a person. Sensitive cases may require completely different workflows.

WhatsApp should also not be treated as the only channel. Not everyone has a smartphone, sufficient data or reliable internet access. Good programme design may combine WhatsApp with SMS, voice, USSD or other channels so that people are not excluded because of the technology they use.

The goal is not simply to be on WhatsApp. It is to make communication easier while ensuring organisations can listen, respond and act on what they hear.

Two-way communication means moving beyond simply telling people what an organisation wants them to know. It creates a way for people to respond, ask questions, challenge information, report problems and influence the services intended for them.

This sounds obvious, but communication from large organisations can easily become one-directional. A message is sent, a notice is published or an information campaign is launched, but there may be no simple way for the people receiving that information to respond.

Two-way systems change that relationship. Someone receiving information about a payment may be able to ask why it has not arrived. A person registering for a service might correct inaccurate information. A community experiencing a new problem might report it before it appears in formal monitoring systems.

The technology can be relatively simple. Two-way communication might use SMS, WhatsApp, voice, a call centre, email or USSD. What matters is what happens after someone responds.

Collecting feedback without having the capacity to act on it can create frustration rather than trust. Organisations therefore need clear workflows for triage, escalation, response times and accountability.

When designed well, two-way communication becomes more than a communications function. It becomes part of service delivery, programme management and decision-making.

AI chatbots can help organisations respond to large numbers of questions quickly while still providing information that is relevant to the person asking. They can operate through channels people already use, including WhatsApp, web chat and other messaging platforms, and can provide support across different languages and at any time of day.

The real opportunity is not simply replacing a traditional chatbot with generative AI. Older chatbots often depend on fixed menus and predefined responses. Generative AI can make conversations more natural, understand questions expressed in different ways and retrieve answers from a much larger body of trusted information.

That flexibility also creates risk. Organisations should be very clear about what an AI system is allowed to answer, what information it can access and when a conversation needs to be handed to a person. A chatbot should not invent programme rules, make decisions it has not been authorised to make or provide confident answers when reliable information is unavailable.

Good systems therefore combine AI with trusted information sources, clear safeguards and human escalation. They should also allow organisations to understand what people are asking.

Used well, AI can help organisations respond faster and at greater scale. The goal should not be to remove people from communication. It should be to make human support more available where it matters most.

Digital cash and financial assistance can give people greater choice over how they meet their own needs. Depending on the programme and context, funds may be delivered through bank accounts, mobile money, payment cards, vouchers, cash collection points or digital wallets.

Behind a payment is a much larger process. Organisations may need to register participants, determine eligibility, collect the minimum information required and select an appropriate method for delivering funds. They then need to move money securely, confirm that it reached the intended recipient, manage failed transactions and reconcile what was distributed.

Access is just as important as delivery. Receiving money in a digital account is of limited value if someone cannot actually use it. Programmes therefore need to consider where people can spend funds, whether they can withdraw cash, what fees they will pay and what identification or connectivity may be required.

Different payment rails solve different parts of this problem. Mobile money may work extremely well in one country and have little coverage in another. Banks provide strong infrastructure but may exclude people without accounts. Digital wallets and newer payment technologies can create additional options, but still need practical connections to local economies.

Good payment design therefore starts with people and context, not with the technology. The best payment rail is the one that delivers funds safely, reliably and with the fewest unnecessary barriers.

Stablecoins are digital assets designed to maintain a relatively stable value, usually by being linked to a currency such as the US dollar. They can provide another way for organisations to move value quickly across borders and into digital wallets without requiring every participant to be connected to the same bank or mobile money network.

This can be useful in situations where financial infrastructure is fragmented, expensive or difficult to access. Potential applications include humanitarian cash assistance, social protection, migrant support, community savings, cross-border programmes and other forms of financial inclusion.

But sending a stablecoin is only one part of the system. People still need practical ways to use the value they receive. Programmes therefore require reliable on-ramps and off-ramps that allow money to move between traditional financial systems, digital assets, local currency and cash-out networks.

Identity requirements, regulation, liquidity, fees and access all matter.

Stablecoins also do not remove the need for good programme design. Organisations still need to manage registration, risk, privacy, reconciliation and support when something goes wrong.

Their value is not that blockchain suddenly replaces existing financial systems. It is that stablecoins can provide another payment rail, particularly where existing options are slow, expensive or exclusionary.

USSD is a mobile technology that allows people to interact with a service by entering short codes on a phone, usually through a simple text-based menu. Unlike a mobile app or web service, USSD does not require a smartphone or an internet connection.

That makes it useful in places where connectivity is limited, data is expensive or large numbers of people still rely on basic mobile phones.

Organisations can use USSD for registration, surveys, information services, referrals, feedback and simple transactions. Someone might dial a short code, choose a language, answer a series of questions and receive confirmation without installing an application.

Its simplicity is also one of its strengths. There is very little for the user to learn and it can work across a wide range of mobile devices. At the same time, USSD has limitations. Sessions are usually short, menus need to remain simple and it is not suited to long or complex conversations.

The best use of USSD is therefore often as one part of a wider communication system. It can provide a low-bandwidth entry point into a service, while SMS, voice, WhatsApp or a call centre provide additional support when needed.

The important principle is inclusion. Organisations should not assume that everyone has access to a smartphone, affordable data or reliable connectivity.

Poor connectivity does not mean communication has to stop. It means organisations need to design around the communication infrastructure people can actually access.

In many communities, a smartphone may be available but reliable mobile data is not. In others, people may share phones, use basic handsets or move between areas with very different levels of network coverage. A service built only around an app or web portal can therefore exclude exactly the people an organisation is trying to reach.

The practical answer is usually a combination of channels. SMS can deliver short information without mobile data. USSD can support registration, menus and simple interactions on basic phones. Voice and interactive voice response can reach people with lower literacy levels. WhatsApp can provide richer two-way communication when data is available. Call centres can support situations that require a person.

Good systems should also allow people to move between these channels without starting again each time.

Organisations need to think beyond connectivity itself. Charging phones, language, literacy, network coverage, handset ownership and the cost of communication can all determine whether a service is genuinely accessible.

The goal should be to design for the least connected person who needs the service, not only for the technology that is easiest for the organisation to deploy.

A digital wallet allows a person or organisation to hold, receive and transfer value electronically. Depending on the system, that value might be traditional currency, mobile money, a stablecoin or another digital asset.

Digital wallets can create more flexibility in how funds are delivered. Instead of every payment being tied to a single bank, card provider or cash distribution point, value can potentially be sent directly to a wallet controlled by an individual, household or group.

The important question is not simply whether a wallet can receive money. It is whether people can actually use what is inside it.

A useful wallet therefore needs connections to the wider financial system. People may need to convert funds into local currency, send money to another person, make a payment directly or withdraw cash. Organisations also need ways to fund wallets, manage distributions and reconcile transactions.

Identity and control are equally important. Some services may use individual wallets linked to verified users. Others may use household or group wallets, including savings groups where several people share responsibility for approving transactions.

Digital wallets can reduce reliance on a single financial provider and give people more choice over how they receive and use funds. But a wallet is not financial inclusion by itself. It becomes useful when it connects people to real services, markets and practical ways to use their money.

Digital payments can require organisations to handle sensitive information about people who may already face significant risks. Names, identity documents, household information, location, eligibility and transaction history can all become part of a payment process.

The challenge is allowing organisations to deliver services and meet regulatory requirements without collecting or sharing more personal data than they actually need.

Privacy-preserving payment systems are designed around that principle. Instead of sharing someone’s full identity or personal information every time a transaction takes place, newer technologies can confirm that certain conditions have been met without exposing all of the underlying data.

Zero-knowledge proofs are one example. They can allow someone to prove that they are eligible, verified or authorised without revealing the information used to establish that fact.

Technology alone does not solve the privacy problem. Organisations still need to decide what information is necessary, who can access it, how long it should be retained and what happens if systems are compromised.

Privacy therefore needs to be designed into the service from the beginning rather than added later as a security feature.

The goal should be simple. Collect the minimum information needed to deliver a service safely and accountably, and avoid creating unnecessary digital records simply because the technology makes it possible.

Digital identity is a way of establishing who someone is, or confirming that they meet a particular requirement, using digital systems. This can range from basic registration information to formal identity verification required by a bank, payment provider or regulator.

KYC, or Know Your Customer, is part of this process. Financial institutions and payment providers use KYC to verify customers and manage risks such as fraud, money laundering and sanctions compliance.

The difficulty is that people who are financially excluded, displaced or living in underserved communities do not always have the documentation traditional financial systems expect. People may have lost identification, live in places without reliable civil registration or have information recorded differently across systems.

Requiring documentation that people cannot realistically provide can turn compliance into another barrier to access.

Good service design therefore starts by understanding what level of verification is actually required. Not every interaction needs the same level of identity. Registering to receive information is different from opening a financial account or receiving a large payment.

A useful system should apply the appropriate level of verification to the activity rather than collecting maximum information from everyone.

Digital identity can improve security and reduce duplication, but it should not become an end in itself. The purpose is to help people access services safely.

Organisations already collect enormous amounts of information through surveys, communication channels, call centres, service systems, programme data and external sources. The problem is often not the absence of data. It is turning that information into something people can act on quickly enough to make a difference.

AI can help by identifying patterns across large amounts of information, summarising what people are reporting and highlighting changes that might otherwise be difficult to see.

Thousands of messages, calls or survey responses can potentially reveal emerging concerns about health, livelihoods, food, displacement, public services or access long before those concerns become obvious in formal reports.

This can strengthen early warning, but AI should not be confused with certainty or prediction. Social systems, crises and human behaviour are complex. A model can identify patterns or signals, but it cannot remove uncertainty or replace local knowledge and human judgement.

The most useful systems combine different sources of information. Community feedback can sit alongside operational data, environmental information, market data or formal reporting.

There is also an important feedback loop. Organisations should not only use AI to analyse people. They should use what they learn to communicate back, adjust services and improve decisions.

The real value is not producing another dashboard. It is helping people make better decisions while there is still time to act.

Organisations collect feedback in many ways. People call helpdesks, respond to surveys, send WhatsApp messages, speak with staff, use complaints mechanisms and interact with services every day.

The challenge is often not collecting feedback. It is making sure that information reaches the people who can act on it.

Too often, community feedback becomes another dataset. It is counted, categorised and reported, but remains disconnected from operational decisions. A dashboard might show that hundreds of people are asking the same question while the underlying problem continues unchanged.

A useful feedback system needs a clear path from listening to action. Information should be structured so teams can identify recurring problems, urgent cases and changes over time. Individual cases may need to be referred immediately, while larger patterns can inform programme design, communications or service delivery.

Technology can help by bringing information from different channels into one place. Feedback received through WhatsApp, SMS, call centres, surveys or other channels should not sit in separate systems if they relate to the same service.

Closing the loop matters just as much. When people provide feedback, they should be able to see that someone listened and, where possible, understand what changed.

Listening is not accountability by itself. Accountability begins when what people say has a meaningful influence on what an organisation does next.

Communication channels become much more useful when they are connected to the systems organisations already use to manage services and relationships.

A WhatsApp message may begin as a simple conversation but quickly become part of something larger. Someone may be registering for a service, reporting a problem, asking about a payment or updating their information.

If that conversation remains trapped inside a messaging platform, staff may need to copy information manually into another system, creating extra work and increasing the risk of errors.

Integrations allow information to move between communication channels and systems such as CRM platforms, case management tools, programme databases, helpdesks and workflow systems.

A new WhatsApp conversation might create or update a contact record. A survey response might update a database. A failed payment could automatically trigger a message explaining what happens next.

This does not mean every system should share every piece of information. Organisations still need clear rules about what data moves between platforms, who can access it and why it is needed.

The aim is interoperability rather than building one enormous system that tries to do everything.

When systems work together, staff spend less time moving information manually and people are less likely to be asked for the same information repeatedly.

Many organisations already use Monday.com to manage projects, tasks, cases and operational workflows. The challenge is that communication with the people they serve often happens somewhere else, through WhatsApp, SMS, email or call centres.

When those systems are disconnected, staff end up copying information between platforms, updating records manually and trying to keep track of conversations across several places.

Connecting Monday.com to communication channels can turn those conversations into part of the organisation’s normal workflow.

A WhatsApp message can create or update an item in Monday.com. A registration form can populate a board automatically. A new case can be assigned to a staff member. Changes in status can trigger an SMS or WhatsApp message back to the person involved.

Teams can use Monday.com to manage follow-up, escalation and accountability without requiring staff to work inside a completely separate communications platform.

This is particularly useful for organisations that already rely on Monday.com and do not want to introduce another major system simply to manage communication.

The important part is deciding what information should move between systems. Not every message needs to become a record, and sensitive information should only be shared where it is necessary and appropriate.

The goal is not to turn Monday.com into a communications platform. It is to connect the tools organisations already use with the channels people already use.

DHIS2 is widely used by governments and organisations to collect, manage and analyse health and programme data. It is particularly valuable for understanding what is happening across facilities, districts and populations.

What it does not automatically provide is a direct conversation with the people represented by that data.

Connecting DHIS2 with communication channels can help close that gap.

Information in DHIS2 can potentially trigger communication through SMS, WhatsApp or voice. A health programme might send reminders, follow-up information or alerts based on programme data. At the same time, information collected directly from communities can feed back into operational systems, giving teams a more immediate view of what people are experiencing.

This can be useful for disease surveillance, vaccination, maternal health, community health and other public service programmes where timely information matters.

Formal reporting may show what has already happened, while community communication can provide additional signals about what may be changing on the ground.

Integration still needs to be approached carefully. Health and personal data can be highly sensitive, and organisations need to be clear about what information should move between systems and what should remain separate.

The larger opportunity is not simply connecting two pieces of software. It is connecting institutional data with the experience of the people those systems are intended to serve.

KoboToolbox is widely used for data collection across non-profits, governments, research, development and emergency response. Organisations use it for assessments, registrations, surveys, monitoring and many other forms of structured data collection.

The opportunity is to connect that data collection with what happens before and after a form is submitted.

A registration completed through KoboToolbox might automatically trigger an SMS or WhatsApp confirmation. Survey participants could receive reminders before a follow-up assessment. Responses could create tasks for programme teams or identify situations that require additional attention.

Communication channels could also be used to invite people to complete surveys or provide updates after data collection has finished.

This can help organisations move away from treating data collection as a one-time interaction.

Someone who completes a registration or assessment often has reasonable questions afterwards. What happens next? Was the registration successful? When will the service begin? Who should they contact if something changes?

Connecting KoboToolbox with communication systems can help provide those answers without requiring staff to manage every interaction manually.

It can also make data collection more responsive. If particular responses indicate an urgent issue, organisations can create workflows that alert staff or begin a follow-up process.

KoboToolbox remains the structured data collection tool. Communication platforms provide the relationship around that data.

CommCare is widely used by non-profits, governments and development organisations to manage mobile data collection, case management and frontline workflows. It is particularly useful where field teams need structured information while working directly with individuals and communities.

Communication systems can extend that work beyond the field worker.

Information collected in CommCare can potentially trigger communication through channels such as SMS, WhatsApp or voice. A person registered during a visit might later receive an appointment reminder, service update or follow-up question. A case that changes status could trigger a notification, while a message received from a participant could connect back to the appropriate record or workflow.

This becomes especially useful when programmes involve repeated interaction rather than a single assessment. Health, protection, livelihoods, social services and financial assistance may all require organisations to stay connected with people over time.

CommCare can manage structured programme information while communication channels provide a way to continue the conversation between visits.

The connection can also work in the other direction. Information received through messaging or call centres can help staff identify cases that need attention or update operational workflows.

As with any integration, organisations need to be deliberate about what information moves between systems.

The goal is not to replace CommCare. It is to connect strong case management and field data systems with the communication channels people already use.

For many non-profits, Salesforce is more than a CRM. It can become the central system for managing donors, fundraising campaigns, grants, relationships and engagement over time.

The challenge is making sure those records connect to the channels through which supporters actually communicate.

Integrating Salesforce with email, SMS, WhatsApp and other communication channels can make fundraising more personal and easier to manage at scale.

A new donation can update a donor record and trigger a thank-you message. A supporter who responds to a campaign can be connected to the correct contact record. Organisations can segment communication based on previous donations, interests, geography or engagement history rather than sending the same message to everyone.

This can also help fundraising teams build longer-term relationships. Someone who first responds to an emergency appeal might later receive information about the programme they supported. A major donor may need a very different communication journey from someone making a small monthly contribution.

Salesforce can hold the relationship history while communication tools manage the interaction.

The same principle applies across multiple channels. Email may remain important, while SMS and WhatsApp can provide faster and more direct engagement where supporters have chosen to use them.

The goal is not simply to automate more fundraising messages. It is to communicate in ways that are more relevant, timely and personal while reducing the manual work required to manage those relationships.