What Happens When a Rep Loses Signal Mid-Report

A medical rep walks out of a clinic in a small town outside Nagpur, opens FieldVoice, and starts recording a visit summary. Halfway through, the network drops to nothing. This is not an edge case for us. It is closer to the median case, since a meaningful share of India's tier 2 and tier 3 clinic visits happen where connectivity is patchy at best.

Recording never depends on the network

The voice capture itself runs entirely on-device. FieldVoice records, timestamps, and locally stores the audio and any partial transcription the moment the rep taps to start, with no network call in that path at all. A dropped connection mid-sentence has zero effect on whether the report survives, because nothing about capturing it required a connection in the first place.

Processing waits, queues, and retries

Once the rep finishes and connectivity is unavailable, the report sits in a local queue rather than failing silently. The app shows it as pending, not sent, so there is no ambiguity about whether the visit got logged. When signal returns, even briefly, queued reports sync in the order they were recorded, and the language processing and CRM field extraction happen server-side once the audio arrives.

The harder problem: order and duplicates

• •Reps sometimes record a correction to an earlier report before the original has synced, so we tag each entry with a client-side sequence number, not just a server timestamp, to preserve intent
• •Two reports for the same visit, one recorded offline and one recorded again when the rep assumed the first attempt had failed, get de-duplicated by comparing audio fingerprints and visit metadata rather than trusting the rep to remember what was already logged
• •A queue that grows for days, which happens on multi-day rural circuit visits, needs to sync in the background without blocking new recordings on top of it

None of this is exotic engineering. It is the unglamorous work of treating connectivity as optional rather than assumed, which is the only design that survives contact with actual Indian field conditions. A CRM built assuming steady 4G was never going to work for the territories where FieldVoice needed to work first.