How Dexor keeps offline field activity reports trustworthy

Field reports are only as good as the worst day in the field. A rep in a basement pharmacy with no signal, a phone that runs flat at 3 pm, a visit saved twice because the app was tapped twice in a hurry: each of these is small, and each one can compromise the accuracy of offline field activity reports, bending coverage reports or target reviews if the system quietly guesses.

Dexor does not guess. It records what happened on the phone, sends it when it can, and tells the manager plainly when something needs a second look. This post walks through the three cases people ask us about most: gaps in GPS, duplicate check-ins, and visits logged while offline.

Visits logged while offline

Reps work where coverage is weakest, so Dexor is built to work fully offline.

Everything is saved on the phone first. A call, an order, a check-in or an expense is written to the phone's own store the moment the rep saves it, with the time and place it actually happened. Nothing depends on the network being there at that moment.

Each record carries its own id from the start. The phone gives every record a unique id when it is created. When the record reaches the server, that id is how the server recognises it. If the same record arrives twice, because the connection dropped halfway through an upload and the phone tried again, the server knows it already has it and does not count it a second time. Retries are safe by design.

Nothing is deleted from the phone until the server confirms it. A record stays in the phone's outbox until the server has accepted it. If the phone’s connectivity is lost before then, the record is still on that phone; if the upload fails, it is tried again later.

Late records are accepted and labelled, not dropped. When a phone has been offline for a long time, its records still arrive and are still counted, with their original times. Dexor marks them as synced late so a manager can see the difference between a visit made at 11 am and a visit that only reached the server in the evening. The organisation can set how long a phone may work offline before it must sync, and give individual reps more time when they work in remote areas.

Changes made while the rep was away are handled openly. If a price changed, a product was withdrawn or a month was closed while the phone was offline, the record is not silently rejected. It is accepted and flagged for the manager: repriced, item no longer available, or recorded late from a closed month. Closed months stay closed; a late record never rewrites a month's sales or incentives behind anyone's back.

Anything that cannot be accepted goes to a visible list. If the server has to refuse a record, it does not disappear into endless retries. It goes to a Needs attention list that the rep and their manager can both see, with the reason and the option to fix and resend.

Duplicate check-ins and repeated visits

Duplicates usually come from good intentions: a double tap, a retry after a timeout, or a rep logging the same doctor again because they were not sure the first one saved.

• Same record, sent twice: caught automatically by the record's own id, as above. It is stored once.
• Checking in to the same stop again: the app pulls the day's check-ins from the server, so a stop the rep already checked into shows as visited even after reinstalling the app or switching to another phone. The rep is not prompted to check in twice, and the server keeps one record per check-in.
• The same doctor or chemist added twice: when a rep adds a new customer, Dexor compares it with existing records in that territory by name and specialty and shows likely matches before anything is created. Organisations that want tighter control can require a manager to approve new customers.
• Joint visits are counted once. When a manager works in the field with a rep, the visit is recorded for both of them without creating a second visit, so team totals stay honest.

Gaps in GPS

A gap in location data is not automatically a problem. Phones lose signal, batteries run down, and people stand still for long stretches. What matters is knowing why the gap happened.

Location is recorded continuously during duty hours. While a rep is on duty, the app keeps a short location reading every few seconds on the phone and sends them in batches. How often it uploads depends on what is happening: more often while the rep is moving or while a manager is watching the live map, less often while they are still, and less again on low battery. The readings are kept until they are delivered, so a period without signal does not leave a hole in the record once the phone reconnects.

Still or moving is decided from location, not motion. A phone moves in someone's hand while they stand and wait for a doctor. Dexor judges whether a rep was stationary from where they actually were over time, not from how much the phone was shaken.

Every gap carries its reason. When readings stop, Dexor records why where the phone can tell it: no coverage, location turned off, airplane mode, mobile data turned off, low battery, or the phone switched off. A manager sees "no connectivity" rather than an unexplained blank, and coverage problems are never presented as wrongdoing.

Unusual patterns are flagged by clear rules. Dexor checks each day's trail against simple, adjustable thresholds: long stops at places that are not customers, speeds no field rep could travel, location readings that look faked, visits logged with no stop nearby, and short stops near a customer with no visit logged. These checks are rules the organisation can tune, not opaque scores, and they come with the facts behind them so a manager can judge for themselves.

Battery use is kept low on purpose. The app uses the phone's lower-power location mode while the rep is stationary and full accuracy only when they move, and it batches readings so the phone wakes less often. A rep can see their own battery use for the day.

What a manager actually sees

The point of all this is a report a manager can stand behind. In practice that means:

• every visit and order shows when it happened and when it reached the server;
• late, repriced or moved records are labelled, with the original values kept;
• refused records sit in a list with a reason, not in a void;
• location gaps show their cause, and unusual patterns come with the evidence;
• nothing is counted twice, and nothing accepted is lost.

Field data will never be perfect, because field work is not. The aim is a system that is honest about what it knows, clear about what it does not, and careful never to fill the gaps with guesses.