A pregnant woman in rural Bihar receives a phone call. She did not request it. The call plays a short audio message — in her language, in a voice she finds warm and trustworthy — about what to expect in her seventh month of pregnancy. The message covers warning signs, nutrition, and when to visit the health centre. It lasts about ninety seconds. Next week, she will receive another call, timed to her eighth month.
This is how it works. And the challenge was never the technology. It was the design.
How it works
The programme is an automated phone call service. A pregnant woman is registered in the system with her phone number and expected due date. From that point, the system sends her a weekly audio message timed to her gestational stage. The messages continue through pregnancy and into the first year of the child’s life — covering breastfeeding, immunisation, complementary feeding, and danger signs.
The calls are outbound. The woman does not need to dial a number, download an app, or have internet access. She needs a phone that can receive calls. In rural India, that phone is often shared — used by the household, not owned by the woman individually. The call design accounts for this: messages are structured so that whoever answers the phone can learn something relevant.
Why this is harder than it sounds
Building it was an exercise in design under constraint.
Language. India has hundreds of languages and dialects. The audio messages need to be in the language the woman actually speaks — not Hindi, not English, but the specific dialect of her district. Each message is recorded separately for each language variant. The content is the same; the voice and phrasing are local.
Timing. The value of the message depends entirely on when it arrives. A warning about pre-eclampsia is useful at 28 weeks. At 12 weeks, it is premature and frightening. At 40 weeks, it is too late. The gestational-week matching is the core of the system’s clinical value.
Completion. An outbound call that goes unanswered is worthless. The system needs retry logic — call back at a different time of day, try again the next day. The call completion rate is the operational metric that determines whether the programme reaches anyone at all.
Trust. An unsolicited phone call from an unknown number is, in most contexts, spam. The calls need to be introduced through the health system — ideally by a frontline health worker during a registration visit — so the woman expects the call and does not hang up.
The scale
The programme became one of the largest mobile maternal health services in the world. It operated across multiple Indian states, delivering millions of calls per week. The scale was possible because the per-unit cost was low: each call cost a fraction of a rupee in airtime, and the content was recorded once and delivered millions of times.
The programme was evaluated through large-scale randomised trials. The evidence showed improvements in health knowledge and reported health behaviours among women who received the programme’s calls compared to those who did not. The effect sizes were modest — which is expected for an information intervention operating through a phone speaker — but at the scale of millions of women, even modest effects translate into meaningful population-level change.
What we carry from this
This work taught us three things about working at scale.
First, the design has to be as simple as the user’s environment. The woman receiving the call may be illiterate, may not own the phone, may live in a household where her health decisions are made by someone else. Every design choice — language, timing, retry logic, message length — has to account for this.
Second, the operational metric matters more than the outcome metric during implementation. Call completion rate is not a health outcome. But if the calls are not completed, there is no health outcome to measure. The boring operational work of improving call delivery by two percentage points is what makes the programme real.
Third, scale changes the nature of the evidence question. At small scale, you ask: does this work? At large scale, you ask: does this work well enough, cheaply enough, reliably enough, to justify the system costs? The answer to the second question is harder to get and more important to have.