Paddy is what we call our User Communications Platform – the framework we use for building two-way communication applications to exchange information with our users on their mobile phones.
Paddy has evolved quickly in terms of its service offering and the number of users registered on the system: PxD launched Paddy in February 2019 as an SMS service customized for operationalizing our flagship service in Kenya, MoA-INFO. In the month of its launch, Paddy was servicing approximately 250,000 farmers with advisory delivered exclusively by SMS focussed on Fall Armyworm pest management.
As of the end of 2021, PxD was running 13 of our 20 initiatives on Paddy, spanning six countries on three continents. Digital advisory systems running on Paddy serviced 2.9 million users in 2021 using text and voice-based communications channels.
What is Paddy?
Paddy is a User Communications Platform built and maintained by PxD’s tech practice which we use for building highly automated two-way communication applications. Paddy can run on a variety of protocols. For example, Paddy can run campaigns using SMS and Integrated Voice Response (IVR) and use chatbots on WhatsApp and Telegram. Multiple applications can also be connected to each other. For example, SMS and IVR applications can be combined so that user actions on one channel can trigger actions on another. For example, a user could text “CALL ME” using SMS or WhatsApp and then receive a voice call from the system.
Paddy is optimized for:
- Scale: it can support millions of users.
- Data collection: it collects detailed usage data and generates tabular data similar to that generated by SurveyCTO or ODK.
- Experimentation: it is very easy to add randomization to application logic for implementing A/B tests or RCTs.
- Customization: logic can vary based on user data, so different groups of users can be served by different application configurations and content.
- Extensibility: it can integrate functionality from external software, and external software can automate or trigger events in a Paddy application.
If you are familiar with survey tools for electronic data collection like SurveyCTO or ODK, these can give you a good mental model of the kinds of interactions that can be programmed on Paddy. Messages and questions can be programmed together with logic describing the order in which they are supposed to go out, the kinds of data they might collect from users, and rules for dealing with missing or unexpected data.
What is necessary to run Paddy?
The key to launching a new application using Paddy is the communication channel. Typically, this will be a phone number (for SMS, voice, or WhatsApp) or a bot account (for Telegram). The process for this is highly context-dependent. Different countries have different regulations, different digital cultures, and different mobile communications providers, and each channel has its own characteristics. In some cases, a significant amount of set-up time is required. For example, it can take months to register a two-way SMS short code or a voice line.
For the following channels, configuring Paddy can be achieved quickly once the infrastructure is in place:
- SMS or voice through Africa’s Talking, an aggregator providing SMS services in many African countries, and voice in a smaller subset of countries. Registration is generally fairly quick (weeks).
- Voice over SIP/PRI: In this case, a phone line is directly connected to a telco. This line is directed to a locally hosted server running Paddy. This can time to set up, and often requires separate arrangements for the server.
- SMS through Infobip, an aggregator providing SMS services around the world. Registration processes and pricing differ significantly from place to place.
- SMS through Wavy, an aggregator providing SMS services in many Latin American countries. Registration can take months.
- WhatsApp: A smartphone chat app for business communication.
- WhatsApp through Twilio: Connectivity for WhatsApp business accounts. A typical registration time is one to two months, and many regulations apply.
- Telegram is an open-source smartphone chat app similar to WhatsApp. Bots can be set up in a few hours.
For other channels and telcos, a new integration (also known as an adapter) can be developed for Paddy integration. This only needs to be done once and can be reused if multiple Paddy installations need to integrate with the same provider.
What kinds of tools can be built with Paddy?
This section gives some examples of the kinds of logic that Paddy facilitates, with an indication of the effort and resources required for implementation. The examples are given in order of increasing complexity/sophistication. The first examples listed can easily be implemented by team members with no programming experience. Later examples require deeper familiarity with the technology. Elements of this logic can be combined as desired.
Example 1: Message series
The most simple and common form of content is a linear series of messages. These have no branching logic, users receive a fixed stream of messages in response to their engagement. Content like this can be pushed to users directly (often with a leading message “Send A to receive X”, so that users receive the series only if they respond) or can be deployed via a menu (see below). This kind of content is straightforward to program and can be based on default templates.
Example 2: Menu
Another common content type is a menu. Users can choose from a set of options either by sending a letter, or one of a variety of spelling variants. If a user sends an invalid response, they are guided to send something more appropriate (this behavior is automatically added by Paddy). If necessary, behavior can be customized to provide specific logic or data as feedback to the users. Often a menu can be activated by sending a keyword to the application (“Maize” in the illustrated example). The logic for programming a menu is more involved than that of a regular message series, but code can still be adapted from existing templates.
Example 3: Basic survey
Paddy has data collection capabilities: it can understand responses in a variety of formats, and collect tabular data for chatbots. While the above examples are useful for information dissemination, they are not particularly helpful for data collection.
The illustrated interaction is based on survey code for an A/B test: half of the survey sample is asked whether they enjoyed the survey, while this question is skipped for the other half of the sample. It is easy to randomize elements this way in Paddy, and, if desirable, randomization can be deployed at the user rather than the survey level so that a given user always experiences the same version of the application.
Adding logic and randomization to a chatbot adds some complexity to the code. Team members often start with programming a series of messages and menus to get familiar with Paddy before working on more complex chatbots such as the one below. However, programming survey interactions are well within reach for team members with experience with tools like SurveyCTO/ODK, or R/STATA/Python, after a bit of training.
Example 4: LOCATION tool
An advantage of code-based implementation is that content can be auto-generated. The LOCATION tool shown below is an example of a tool that is partly auto-generated, in this case from data sourced from shapefiles defining Kenya’s administrative boundaries and their hierarchy. Kenya has around 1500 wards, so defining and maintaining a survey like the one below manually is tedious and potentially unrealistic. Another feature visible in the demo is fuzzy matching – Paddy can be configured to try and correct misspelled responses.
Many similar tools, with structures adapted from external sources of data, have been developed on Paddy. Examples are location-based seed recommendations, an agro dealer phone directory, and a search function to find relevant advice in a database of transcriptions of past push calls. Because implementation requires some data transformation and programming, such tools are generally implemented by members of the tech practice.
Example 5: Fertilizer tool
The examples so far had all their logic programmed straight into Paddy. Paddy is also able to talk to external tools. For example, APIs hosted by partner organizations. An example of a Paddy decision-support tool that uses an external tool is our fertilizer tool. This tool uses an external optimizer based on a model developed by OFRA. Paddy first makes sure it has the required data from the user (in this case location, crop, acreage, and budget), then passes that data to the external optimizer, and uses the response from the optimizer to generate the recommendation messages. This kind of tool requires a significant amount of engineering.
Other applications
The above examples are by no means exhaustive. Here are some more avenues for functionality (some of which is already in use):
- While the examples all focus on text messaging, most of this functionality is usable with voice systems. A bit more thought is required (because audio is harder to dynamically adjust than text messages), but experimentation, customization based on user data, and data collection work mostly the same for voice systems as for text/chat systems.
- It is possible to integrate other modes of interaction in addition to Paddy-bots. For example, it is possible for users to communicate with agents/agronomists directly, or to integrate other kinds of bots using more advanced natural language processing.
- A common feature is help desk functionality, where users can submit queries that go into a common queue, which is processed by system admins (e.g. agronomists). Users receive an update when their query is processed.
How is a Paddy application operated?
By default, Paddy is launched with a web interface and an operations dashboard. The web interface provides functionality for user management and scheduling outbound campaigns. The dashboard gives a live view of activity on the system. For voice applications, these interfaces are generally sufficient to be able to operate a system with little or no technical support.
An important component for operating text messaging applications is content programming. Currently, this requires some basic coding. New applications can be implemented by PxD’s tech team, with capacity building for the project team to roll out new content independently. The workflow takes some getting used to but is sufficiently accessible for someone with limited coding experience to implement and deploy application content. In the future, it is likely that there will be a web interface through which content can be added.
For applications with complex operations, support is available for automating work. For the MoA-INFO SMS application in Kenya, push messages to users are automatically scheduled every Tuesday and Friday with timing based on planting date information at the ward level, and content selection based on their crop choices. For the Ama Krushi IVR application, welcome calls with instructions for new users are automatically scheduled every day for newly profiled users. Such automation requires some engineering and thought, but can save teams a lot of time in the long run.