Farm data collected by people with basic phones

Yes — farm data from basic phones is collected in Nepal every season through four channels: coded SMS, USSD menus, IVR voice calls and paper forms typed up later. Coded SMS is the workhorse for agriculture data collection in Nepal, because the mobile network stores and forwards each message until an offline handset comes back into coverage.

Key Takeaways

Basic-phone farm data collection runs on four channels — coded SMS, USSD menus, IVR voice and paper-to-entry — and coded SMS is usually the backbone, because the network stores and forwards messages until each handset reaches coverage. The software is the easy half; validation discipline decides whether the data is usable.

• SMS works offline by design. The network's message centre queues messages and delivers them when the phone rejoins the network — no app, no data plan.
• Coded, fixed-order messages (crop codes, numeric answers) are the only format a parser can score reliably.
• One Devanagari character drops an SMS from 160 to 70 characters per segment — keep collection messages Latin-only.
• USSD and IVR need live coverage and an operator agreement; neither queues offline.
• Reject-and-reply beats silent failure: bounce bad messages back to the sender within seconds, with the exact fault named.
• If forms need GPS, photos or skip logic, hand enumerators smartphones and use ODK Collect or KoboToolbox instead.

What can a basic phone actually do?

A basic phone sends and receives SMS, joins USSD menu sessions, and places voice calls — nothing more. Those three channels, plus paper, cover every realistic farm data collection design in Nepal. Anything built on an app store, a browser login or a chat app silently excludes the keypad phones most field agents already carry.

USSD — Unstructured Supplementary Service Data — is the menu you get when you dial a balance-check code: live, session-based, gone the moment coverage drops. IVR — Interactive Voice Response — is a recorded voice asking questions, answered on the keypad. Both need a live network session and an operator-side gateway. A keypad phone's browser, where one exists at all, is too unreliable to build on. Plan for messages and calls only.

Why is basic-phone collection the realistic default in rural Nepal?

Patchy mid-hill coverage, shared handsets and small airtime budgets make basic phones the honest default for agriculture data collection in Nepal. SMS survives that reality because the network stores and forwards each message until the handset rejoins coverage, so a report sent from an offline village still arrives later without anyone re-entering it.

Most collection agents in hill and Terai districts carry a keypad phone, a shared handset, or a smartphone with no data balance left by Friday. Charging is intermittent. Typing Nepali on a keypad is slow, which is why short Romanised codes beat long sentences. One pattern worth knowing: the missed call. A farmer rings a number and hangs up before it connects — costs nothing — and your system logs the number and replies with the form by SMS.

Which channel fits your collection round?

Match the channel to the respondent, not to the vendor demo. Coded SMS suits weekly structured reports from many senders; USSD fits short guided menus; IVR serves low-literacy respondents by voice; paper-to-entry never fails but adds typing work. Compare offline tolerance, training time and operator agreements before you commit.

Channel	Works offline?	Literacy demand	Operator agreement?	Best for
Coded SMS	Yes — store-and-forward	Low, once codes are learned	Plain SIM: no. Bulk or short code: yes	Weekly structured reports from many senders
USSD menus	No — live session	Low, guided step by step	Yes, via the operator	Short registrations and checks
IVR voice	No — live call	None — voice prompts	Yes	Low-literacy respondents, older farmers
Paper, then entry	Yes — paper	Any	No	The universal fallback; adds typing delay
Enumerators with ODK	Yes — offline forms	Trained staff	No	GPS, photos, long multi-page forms

In practice, coded SMS with a paper fallback carries most rounds we have seen. USSD is only worth negotiating an operator agreement for when you need thousands of short guided registrations. IVR earns its keep when literacy, not coverage, is the binding constraint. Smartphone enumerators win outright when you can issue devices.

How do you design a message a farmer cannot get wrong?

Design the message format before any software. Use fixed field order, short crop and district codes, and numeric answers separated by spaces — for example RPT KSK TOM 12 PSB 145. Restrict text to Latin characters, because a single Devanagari character forces the whole SMS into 70-character Unicode segments and invites truncation.

Fix the grammar once and publish it on a laminated card. Every field is a code from a lookup table you control; nothing is free text. The parser either accepts the message and files a row, or rejects it and tells the sender exactly what was wrong. This is the same structured-data discipline small businesses apply to any record they ever want to analyse.

RPT <district> <crop> <area_ropani> <pest> <price>

RPT KSK TOM 12 PSB 145

KSK = Kaski   TOM = tomato
PSB = pest seen, 0 or 1   price = rupees per kg

How do you set up the pipeline, step by step?

Stand the pipeline up in seven steps: cut the questionnaire to reportable fields, secure a number or operator agreement, connect a gateway that writes inbound SMS to a database, add a parser with rejection replies, pilot with real senders, train with a Nepali code card, then monitor delivery reports weekly. Verify each step before the next.

1. Cut the questionnaire to five fields. One round, one theme, fixed codes. If a question cannot be answered in a code, it belongs in the seasonal survey, not the weekly message.
2. Secure the inbound number. A plain dedicated SIM receives SMS from any handset and is enough to pilot. Bulk volumes, a short code or USSD need an agreement with the mobile operators — requirements shift, so confirm the current process before promising a launch date.
3. Connect a gateway. Either a hosted messaging API, or for full control a local GSM modem running open-source gateway software — Gammu's SMS daemon, for instance, writes every inbound message into a MySQL or PostgreSQL table. Verify: send a test SMS, watch the row appear.
4. Add the parser and rejection replies. Validate field by field, and answer every rejected message with the exact fault — unknown crop code, missing price, wrong order. Silent failure is how a season of data quietly rots.
5. Pilot with ten to twenty real agents for two weeks. Log every rejected message, then rewrite the training card around what actually confused people.
6. Train and hand out cards. One laminated Nepali card per agent: the format, the codes, a worked example, a help number.
7. Monitor weekly, clean monthly. Review delivery reports and per-agent reporting rates every week, and schedule cleaning before analysis instead of a heroic rescue at season's end.

How do you verify the data before you trust it?

Verify data at three points: on arrival, in the database and back in the field. Reject malformed messages instantly with a reply SMS, enforce range checks and duplicate keys in the database, then call back a sample of senders each round to confirm reported figures match reality. Unchecked SMS data decays fast.

Arrival: the rejection reply should land within seconds — that proves the whole loop works. Database: range checks catch typos (nobody farms 999 ropani of tomato), and a duplicate key on sender plus round keeps resends from doubling rows, latest valid message wins. Field: call back five percent of senders each round. Cleaning is then a scheduled job, not a panic — the same discipline as cleaning data before a migration applies here.

What breaks in the field, and what do you check first?

Diagnose failures in a fixed order: delivery report first, encoding second, sender behaviour third. A missing row is usually a delivery problem; a garbled row is usually an encoding problem; a wrong-value row is a training problem. Each class has a different fix, so check the gateway logs before you blame the farmer.

• Row missing entirely. Delivery reports and the gateway log rule the network in or out in minutes. Then the handset: no credit, no coverage, or the draft never got sent.
• Row present but garbled. Encoding. Devanagari splits messages into 70-character segments and some gateways mangle the pieces; Latin-only formats sidestep it.
• Well-formed but wrong values. Training. Call the agent, walk the worked example again, and check the card matches the parser.
• Duplicate rows. Farmers resend when unsure. Deduplicate on sender plus round, keep the latest.
• Everything arrives on deadline day. Stagger reminders — a Thursday nudge beats a Sunday panic.

What does it cost to run, honestly?

Cost is driven by airtime and operator fees, enumerator time, and the engineering to parse and clean what arrives — in that order. Hosting a small Postgres database costs little; the ongoing spend is per-message charges agreed with mobile operators and the staff hours every round consumes. Confirm current tariffs with each operator directly.

The recurring cost people underestimate is human: training new agents each turnover, chasing non-reporters, and the callbacks. At co-op scale, a well-run shared spreadsheet plus a simple ingestion script often beats a custom dashboard nobody maintains. Decide build versus buy on who will operate it, not on features.

How do you protect farmer data?

Protect farmer data by collecting the minimum, storing it encrypted, and logging who reads it. Keep consent scripts in Nepali, strip names where a co-op code will do, restrict database access by role, and back the system up off-site. Field records about land and livelihood deserve the same care as payment data.

Practically: know exactly where your collected data lives, who can reach it, and what happens if the hosting disappears. Phone numbers plus plot details are enough to identify a household, so give the analysis layer pseudonymous codes and keep the mapping table restricted.

What mistakes do we see most often?

Mistakes cluster around format drift and silent over-collection. Teams add questions until a message no longer fits, accept free-text replies that no parser can score, and skip the pilot that would have caught it. Each failure below has cost someone a season of data; all are avoidable in a one-week pilot.

• Adding questions until every message splits into multi-part Unicode fragments.
• Accepting free-text replies the parser can never score consistently.
• Skipping rejection replies, so bad data just vanishes and nobody learns why.
• Building a dashboard before one season of paper proves which reports anyone reads.
• Ignoring delivery reports until the donor report is due.

What does a season of collection actually look like?

Picture a vegetable co-operative running weekly pest and price reports from 60 collection-point agents across three districts, all on basic phones. Agents send one coded SMS each Friday; the gateway validates and files it; a supervisor sees coverage on a dashboard by Saturday noon and phones any agent who has not reported. That rhythm holds for years.

Week nine is a validation sweep with callbacks on a five percent sample; week ten is cleaning; week eleven the season report goes to the board. Nothing in the loop needs an app, and it survives a dead tower in one ward. We build exactly this kind of system — ingestion, validation rules, reporting screen — as ordinary custom software; see our data work with a research and analytics institute.

When should you skip SMS and issue smartphones instead?

Issue smartphones the moment your forms need skip logic, GPS plots, photos or long multi-page questionnaires, because ODK Collect and KoboToolbox handle exactly that with offline submission. Basic-phone channels win on reach and running cost; they lose on question complexity. Many programmes run both: SMS for weekly indicators, Kobo tablets for seasonal surveys.

ODK's documentation describes the offline model plainly: forms fill with no network at all and submit when coverage returns. KoboToolbox's documentation covers its friendlier hosted form builder, built on the same core. And note the drift in the device market: many "basic" handsets now run cut-down Android, so check what agents actually carry before ruling ODK out.

In short: basic phones are not a limitation in agriculture data collection in Nepal — they are the network you actually have. Design coded messages, validate on arrival, call back a sample each round, and add smartphones only when the questions truly demand them.

People also search for

These guides cover the decisions around a collection system: how to structure records so analysis stays possible, how to clean field data before it reaches a database, and when custom software beats a spreadsheet or an off-the-shelf tool. Each link opens a live guide on the IT Gurkha blog, not a placeholder.

• How much data is too much to collect?
• Where is collected data actually stored?
• How do we move off spreadsheets safely?
• How do we clean messy field data?
• Should we build or buy the collection system?
• What would a field app cost to build?

Planning a collection round and want a second opinion on the design, or need the ingestion, validation and reporting built properly in accounts you own? Our team can help — start with a conversation with us, or see how we approach custom software development in Nepal.