What To Do After KoboToolbox

Let us start with the part nobody in this market should be coy about: KoboToolbox is very good, it is free, and if it is working for your data collection you should keep using it.

We say this as people who build a competing form builder. Kobo is the default field collection tool across humanitarian and development work for sound reasons — mature offline support, the XLSForm standard, a large practitioner community, no licence cost. Displacing it on collection alone is not a serious proposition, and vendors who pitch you a “better Kobo” are selling you a migration you do not need.

The interesting question is different: what happens to the data after Kobo?

The gap, described precisely

Kobo answers: what did we collect, from whom, where and when. It gives you submissions, basic summaries and exports.

It does not answer:

• What is our current value for indicator 2.1.3, against its target for this quarter?
• Which submissions across which four forms contribute to that indicator, and how are they aggregated?
• Where does this indicator sit in our results framework, and which output does it evidence?
• What is the disaggregated picture by sex, ward and disability status, for the six indicators the funder asks about?
• What do we send the donor in their template, on the fifteenth of next month?

These are results management questions, not collection questions, and there is no reason to expect a collection tool to answer them.

What happens instead is universal. Someone exports to Excel. A workbook grows, one tab per form, one tab per indicator, a summary tab with formulas pointing at the others. It works for one funder and one year. Then a second funder needs a different cut, a colleague leaves, a column shifts by one, and by year three nobody is entirely sure which tab produced the figure in last quarter’s report.

That workbook is not a failure of discipline. It is the correct improvisation in the absence of a layer that should exist.

What the missing layer has to do

Five things. The list is short and the order matters.

1. Define indicators independently of forms. An indicator is an organisational object with a definition, a unit, a baseline, a target, a collection frequency, a data source and a means of verification. It outlives any individual form and is usually fed by several. Defining indicators inside forms is what makes them un-aggregatable later.

2. Link collection to indicators explicitly. A question on a form should be attachable to an indicator with a stated aggregation — a count of submissions, a sum of a numeric answer, or a distinct count of a value. Once that link exists, the indicator updates as data arrives rather than through a monthly re-export.

3. Carry the framework. Indicators attach to results, and results sit at levels — impact, outcome, output, activity — with narratives and assumptions. This is what turns a list of numbers into a logframe you can submit.

4. Track targets against actuals by period. Not a single end-of-project target. Period targets, period actuals, and the variance visible when it is still actionable.

5. Report without re-keying. The reporting layer should read from the same indicator records everyone else uses. Every manual transcription step is a place where two documents start disagreeing.

Three routes, honestly compared

Stay on Kobo and formalise the spreadsheet. Viable for a small organisation with one or two funders. Make it survivable: one workbook, version-controlled, one owner, indicator definitions written down in the workbook itself. Cost: staff time and key-person risk. Do not let anyone tell you this is unacceptable — for a five-person organisation it often is the right answer.

Keep Kobo, add a results layer above it. Collection stays where your enumerators are trained; a results system holds indicators, framework and reporting, fed from Kobo via export or API. Advantage: no retraining and no migration. Disadvantage: two systems, and the join between them is real work that somebody owns.

Consolidate collection and results in one system. One place for forms, submissions, indicators, framework and reporting. Advantage: the join disappears, and indicator values update as submissions arrive. Disadvantage: you migrate your forms and retrain field teams, and you should not do that lightly.

There is no universally correct answer. The wrong move is to make no decision and let the workbook decide for you.

If you do consolidate, migrate properly

Two things we have learned doing this repeatedly.

XLSForm gets you most of the way, not all of it. The XLSForm standard means your question text, types and choice lists are portable, and importing them is minutes of work rather than days of retyping. What generally does not survive an import between tools is the conditional logic — the relevant expressions — and repeat groups. Budget for rebuilding those and testing them, and pilot the rebuilt form on the actual device your enumerators use before anyone goes to the field.

Do not migrate mid-round. Finish the survey round on the system you started it on. Splitting one round across two systems creates a reconciliation problem that outlasts whatever you were trying to gain.

The honest summary

Kobo is not the problem, and replacing it is not automatically the solution. The gap is the layer above collection, and most organisations are filling it with a spreadsheet that works until it does not.

Whether you fill it by adding a system above Kobo or by consolidating into one, decide it deliberately — before the workbook has three years of institutional memory in it and nobody left who knows which tab is authoritative.

---

Monival imports XLSForm files from ODK and KoboToolbox — questions and choice lists come across; repeat groups and conditional logic need rebuilding. Indicators are defined at organisation level and can be fed from form questions as counts, sums or distinct counts against a target, with disaggregation. The results framework explainer covers how the layer above collection is meant to work.