Humanitarian response often depends on a deceptively difficult question: what is happening, where, and what support is already being delivered? During Kenya’s 2024 flooding crisis, the Kenya Red Cross Society used KoboToolbox to turn that question into a repeatable data-collection and coordination workflow.
The case is important because it is not primarily about an advanced sensor or an experimental artificial-intelligence model. It is about making field information more consistent, more shareable, and more useful to people deciding where to send assistance. KoboToolbox’s offline capability allowed staff and volunteers to collect information in areas where connectivity was weak, while standardised forms and dashboards helped turn individual submissions into a wider operational picture. [1]
The field problem: fragmented information during widespread flooding
KoboToolbox reports that by May 2024 flooding in Kenya had affected more than 220,000 people, displaced more than 41,000 families, and caused 219 deaths. The flooding disrupted healthcare delivery, damaged crops and livestock, and interrupted access to education and other services. [1]
In a crisis of that scale, information arrives from many teams and departments. Search-and-rescue personnel may report locations and urgent needs. Assessment teams may collect information about displaced households. Health and WASH teams may track service gaps. Logistics staff may monitor distributions. If every group uses a different form or reporting structure, decision makers may receive several partial pictures that are difficult to compare.
The Kenya Red Cross Society’s response addressed this problem through a Flood Situation Report tool built with KoboToolbox. The tool was first deployed during the 2023 El Niño period and then used as flooding intensified in 2024. Its purpose was to capture the impacts of flooding and the response activities taking place in affected communities. [1]
Designing an offline field workflow
The tool’s offline capability was central to its usefulness. Field teams could collect information in remote areas and synchronise it when connectivity became available. This matters because the places with the greatest need are often the places where mobile data is weak, power is intermittent, roads are damaged, or network congestion is high.
Offline collection does not mean that information becomes instantly available to every decision maker. It means the field team can continue gathering structured observations instead of waiting for a connection. Once data is synchronised, it can enter the wider reporting workflow and become available for analysis and coordination.
The difference between an offline form and a paper form is not simply that one is digital. A well-designed digital form can enforce required fields, standardise terminology, reduce transcription, record time and location, and apply logic that prevents irrelevant questions from being asked. Those features can improve consistency, but they do not replace training or verification.
Custom forms and conditional questions
KoboToolbox describes how the Kenya Red Cross team customised its forms using cascading select questions and skip logic. Cascading selections narrow the available choices based on earlier answers. Skip logic hides questions that do not apply to a particular situation. Together, these functions can reduce survey fatigue and make it more likely that a field worker records the information that matters for the case at hand. [1]
For example, a responder may first select a county, then a sub-county, then a community. A later question may ask about damage to a health facility only if the respondent has indicated that a facility is present or affected. Another branch may request details about displacement, WASH needs, or food assistance only when the relevant condition has been identified.
This design improves usability, but it also requires careful governance. If a question is hidden incorrectly, important information may never be collected. If a location list is outdated, the data may be assigned to the wrong administrative area. Forms must be tested with the people who will use them in the field, not only with the team that built them.
What the tool captured
The Flood Situation Report tool collected indicators covering affected and displaced people, damage to critical infrastructure, and response activities. The infrastructure categories included schools, health facilities, and roads. The tool also supported reporting on food distribution, health and social services, shelter, and WASH activities. [1]
This breadth is operationally useful because needs rarely appear in isolation. A flooded road may delay food distribution. Damage to a health facility may increase pressure on another clinic. A displaced population may require shelter, water, sanitation, protection, and health services at the same time. A reporting system that captures only one category can miss the dependencies that shape the response.
| Field information | Why it matters to response coordination |
|---|---|
| Number of affected and displaced people | Helps estimate the scale of assistance and identify population movements |
| Damage to roads and bridges | Shows where access, evacuation, and supply routes may be constrained |
| Condition of schools and health facilities | Indicates service disruption and the need for temporary alternatives |
| Food, shelter, health, and WASH interventions | Shows what support has already been delivered and where gaps remain |
| Location and timing of observations | Helps distinguish current needs from older reports and supports prioritisation |
The purpose of collecting these indicators is not to produce a more attractive dashboard. It is to improve decisions about where assistance is needed, which activities are already underway, and which gaps remain unresolved.
From submissions to a shared picture
KoboToolbox reports that the flood reporting tool received more than 800 submissions from 43 affected communities. The Kenya Red Cross team used the data to create daily updates for stakeholders, including visualisation through the KoboToolbox API and Power BI. [1]
This creates a pipeline from field observation to coordination. A volunteer or staff member records an assessment. The data is synchronised. Standardised fields make it possible to aggregate submissions. An API makes the information available to a dashboard or another analysis system. Stakeholders then receive a more current view of impacts and response activities.
The pipeline still depends on data quality. A dashboard can display incomplete or inconsistent reports at high speed. Organisations therefore need rules for checking duplicates, confirming unusual values, tracking the age of a report, and distinguishing direct observation from information passed on by another source.
A daily update is also a point-in-time summary, not a permanent truth. Flood conditions change, populations move, roads reopen or become blocked, and new assessments may revise earlier estimates. The reporting process should make those changes visible rather than hiding them behind a single number.
Why standardisation matters
Before the Flood Situation Report tool, KoboToolbox says that data collection was fragmented, with departments gathering information independently. Fragmentation creates several problems. Different teams may use different definitions of “affected,” record locations differently, or report response activities in incompatible formats. Even when every team is working diligently, the combined information can be difficult to interpret.
A common form does not solve every coordination problem, but it provides a shared structure. It gives teams a common vocabulary and makes it easier to compare reports. It can also reduce the time needed to combine information manually and lower the risk that important observations remain in one department’s files.
The key is to standardise what needs to be comparable while allowing enough flexibility for local conditions. A flood assessment in an urban settlement may need different prompts from an assessment in a rural area or a riverine community. Form designers should avoid collecting information simply because a field is technically available. Every question should have a purpose in a decision, service, or accountability process.
The human side of digital data collection
Technology does not remove the need for local knowledge. Field workers decide whether a question makes sense in context, whether a respondent understands the wording, and whether a reported condition is plausible. Communities also need to understand how their information will be used, who can access it, and whether personal or sensitive details are being collected.
The Kenya case therefore involves more than a software configuration. It involves the development of a reporting practice that links volunteers, operational departments, analysts, and decision makers. The tool can make that practice faster and more consistent, but the organisation still needs training, supervision, feedback, and a process for correcting errors.
Offline-first systems also require a clear synchronisation policy. Teams need to know when to upload data, what happens when two people edit related records, how failed submissions are retried, and how data is protected on a device before synchronisation. These operational details determine whether the system remains dependable during a long response.
Lessons from the Kenya field deployment
The first lesson is that useful humanitarian technology can be relatively simple. The Kenya Red Cross case did not require a futuristic platform. It required a form system that could work offline, reflect the organisation’s reporting needs, and share structured information with stakeholders.
The second lesson is that form design is a technical discipline. Cascading selections, skip logic, standard terminology, and required fields can reduce errors, but only when they match the realities of field work. A form that is too long, too rigid, or poorly translated can reduce data quality even if the underlying software is reliable.
The third lesson is that interoperability matters. KoboToolbox’s API and Power BI visualisation helped connect collection with analysis and communication. Organisations should decide in advance how data will move between collection tools, dashboards, coordination rooms, and reporting products.
The fourth lesson is that an offline capability is a resilience feature, not a luxury. Connectivity gaps should be expected in remote and disaster-affected communities. A tool that allows collection to continue and synchronise later can preserve operational momentum when an always-online design would fail.
The final lesson is that better information is valuable only when it changes action. The purpose of the Flood Situation Report tool was to support targeted assistance, search and rescue, service monitoring, and coordination. The strongest measure of success is therefore whether teams could identify needs more clearly and direct response activities more effectively.
Conclusion
The Kenya Red Cross Society’s use of KoboToolbox during the flooding crisis shows how digital data collection can become part of a practical humanitarian response system. Offline forms allowed field teams to continue working in difficult connectivity conditions. Customised questions improved the relevance of what was collected. Standardised situation reporting reduced fragmentation, while API-driven dashboards helped communicate daily updates to partners.
The deployment is a reminder that disaster technology does not have to be spectacular to be consequential. A well-designed field form, a reliable synchronisation process, and a shared reporting structure can improve the connection between what communities experience and how organisations allocate assistance. The technology works best when it is built around that connection.
References
- KoboToolbox, “Data-driven climate disaster response: How the Kenya Red Cross Society is using KoboToolbox in the flooding crisis”
- KoboToolbox, Humanitarian and disaster-response solutions
- Kenya Flying Labs, “Kenya Flying Labs and Kenya Red Cross Join Forces to Combat Flooding”
- IFRC, Kenya Floods Operational Update
