Patchy Signal on the Porch: How a Field Sales App Should Queue a Visit
Reps knock doors where the signal drops. Here is how our field sales app keeps a visit that cannot leave the phone, says so out loud, sends it in order when the signal is back, and never counts the same door twice.
Field reps work where the signal is worst: the end of a cul-de-sac, the far side of a big house, a street the towers forgot. A field sales app that treats a failed send as an error message teaches reps one thing, which is to log the door again. Now the visit is either lost or counted twice, and neither shows up until someone argues about a number.
This is how Dromo, the field sales app we build, handles a visit that cannot leave the phone.
Keep it, and say so
When a logged outcome fails to send, it goes into a queue stored on the device. The rep sees it straight away: "Waiting to send. It goes as soon as there is signal." A small count sits beside the day until the queue is empty.
The visibility is the point. A queue the rep cannot see is a queue the rep does not trust, and a rep who does not trust it taps the outcome again. Saying "waiting" out loud is what stops the second tap.
Oldest first, and stop at the first failure
When the connection returns, the queue sends by itself, oldest first. If one send fails, it stops there rather than skipping ahead, so outcomes reach the server in the order the rep logged them. Order matters on a door: "no answer" at 10:02 and "appointment set" at 10:40 mean something different in the opposite order.
The dangerous case is the timeout
A send that clearly failed before it left the phone is safe to retry. A send that left the phone and got no answer is not: the server may have recorded it and the reply was lost on the way back. Sending it again would count the same door twice, and door counts feed goals and pay.
So the queue only retries automatically what certainly never left the phone. An item whose send timed out stops and waits for the rep to choose "send anyway" or "discard", while every other lead's outcomes carry on. And a first send that times out is never quietly queued at all: the rep is told on the spot, while they are still standing at the door and know what happened.
One visit, one send, even with two copies open
Reps open apps twice. Each queued outcome carries a unique key, made once when it is queued and reused on every retry, so the server can recognise a repeat. And two open copies of the app cannot both send the same item: each one is claimed for 30 seconds before it goes.
The part that is easy, and the part that is the job
A retry loop is easy to write. A retry loop that cannot double-count someone's pay is the whole job, and sometimes the right answer is to stop and ask the person who was there.
The rest of the rep app, from the map to the door, is written up in Dromo 2.0. The product is at statistique.io/dromo.