Field sales apps in Cambodia: what to do when the signal drops
A rep on a provincial route writes the visit in the customer's shop, signal or not. What the phone has to hold, what syncs each way, and what the office actually sees.
- A rep on a provincial route makes eight to twelve visits a day: a look at the customer's shelf, an order draft, a note. The visit is written in the shop, and the shop is where the signal drops.
- 4G coverage is wide. The variable is the phone signal inside a concrete back office, so the visit is saved on the device first and synced when the bars return.
- Visits, notes, photos and draft quotes go up. The price list, customer list, assignments and stage changes come down. A conflict is kept twice and flagged for the rep, never overwritten by whichever record arrived last.
- Nothing on this page is a shipped app. It is the specification a build is written against, and a fair thing to hold any vendor to.
What does a sales rep on a provincial route actually do in a day?
Eight to twelve visits, most of them to shops that ordered last month and will order again next month. At each one the rep looks at the customer's shelf, drafts the next order, and writes down what was said, including the day the customer promised to pay. No money changes hands in the CRM. A promised payment date is a note on the visit, not a transaction.
The route is the unit of work, not the deal. A rep for a beverage distributor leaves the depot at seven with a printed customer list and a price list that was correct when it was printed, and the day runs along a road: Battambang town in the morning, the district markets after lunch, the depot by evening. Every shop on it is an account the company already has. The rep's job is to keep it.
- Eight to twelve visits, each to a shop that is already a customer. A new account on the route gets the same visit row as everyone else.
- A stock check on the customer's shelf: what is left of the last delivery, what ran out early, what has not moved. The next order is drafted from that number.
- An order draft, priced against the list the phone holds. It stays a draft until the office confirms it, because the rep cannot see the warehouse from a back room in Battambang.
- A note: a broken case, a competitor's price on the next shelf, the day the customer promised to pay for the last delivery. The promised payment date is a note. It is never a payment taken in the CRM.
- A photo of the shelf or the delivery note, when a photo settles an argument faster than a sentence.
- A reorder due date, so the account comes back onto the route before the shelf is empty rather than after.
Until now most of that lived in a notebook and a voice message to the office. The notebook is honest and unsearchable. The voice message is heard once. Neither tells the office on Monday which shops were short, which promised to pay on Friday, and which rep has not been to Pursat in three weeks. What a CRM records that a chat thread cannot covers the record itself. This page covers the phone it has to be written on.
Where does the signal actually drop, if 4G coverage is wide?
Inside the building. The national network reaches the road, the market and the front of the shop; it is the concrete back office, where the wholesaler keeps the stock and the paperwork, that kills the signal two rooms in. The risk is the building, not the grid. The visit happens in exactly the room the network does not reach.
The numbers say the network is there. Cambodia had 21.7 million mobile connections in late 2025, 121 percent of the population, and 94.0 percent of them were broadband. Internet users stood at 12.0 million, 67.3 percent of the population. Read together: nearly every rep and nearly every shopkeeper carries a phone that reaches the network from the street. None of those figures says anything about the back room. The phone signal is the variable, not the grid.
So the failure a field app has to survive is not an afternoon with no coverage. It is twenty minutes in a dead spot with a customer waiting, then a walk back to the truck where the bars return. A power cut is a different problem and a smaller one: the phone has its own battery, and the visit does not need the shop's router. What the visit needs is a place to be written while the network is absent, and a way back to the office when it is not.
What has to be written on the phone before the signal comes back?
The whole visit. The visit row, the shelf count, the order draft, the note and any photo are written locally the moment the rep taps save, stamped with the time the phone showed, and held there until the signal returns. Nothing in the visit waits on a round trip to the office. If it did, the rep would be back to the notebook by the second shop.
Take one invented visit, drawn in the figure below. The phone belongs to a rep standing in a wholesaler's back office, Battambang (no signal). At device time 14:32 the rep saves the visit row: the account, the shelf count, a draft for forty cases, a note that the customer will pay on Friday. The phone marks it saved on device and puts it in a queue. The queue holds the visit row, the note, the photo and the draft quote until the phone can reach the office server. That happens in the truck, ten minutes later, without the rep doing anything.
There is no field sales app to put in your hands today. This is the specification the build is written against. It is the same rule the inventory build holds a warehouse scan to: a local write first, the row carrying the time it happened rather than the time it reached the server, a queue the device keeps itself. A field sales app is that rule applied to a visit instead of a scan.
Two things have to be on the phone before the rep walks in, because they cannot be fetched from a dead spot. The customer list, so the visit is written against the right account rather than a name typed from memory. And the price list, so the draft is priced at this morning's prices, not last month's. What the rep cannot carry in is a live warehouse figure. A draft is a draft because the rep cannot see, from a back room, whether forty cases are available or already committed to another customer's order. Available versus committed stock: what the rep can promise is the warehouse's rule, and the office applies it when the draft comes up.
What syncs up, what syncs down, and what happens to a conflict?
Visits, notes, photos and draft quotes go up. The price list, the customer list, assignments and stage changes come down. A conflict is never settled by whichever record arrived last: both versions are kept, the row is flagged, and the rep is asked. Each direction moves on its own schedule, and the table sets them out.
The up lane carries what the rep wrote: visits, notes, photos, draft quotes. Each row keeps the device time it was written at, so a visit saved at 14:32 in a dead spot and uploaded at 14:44 from the truck is still a 14:32 visit. The down lane carries what the office decides: price list, customer list, assignments, stage changes. A price the office changed at ten is on every phone the next time each one connects, and the rep never edits a price on the road.
| Record | Direction | When it moves | What happens on conflict |
|---|---|---|---|
| Visits | Up | As soon as the phone reaches the office server | Two visits to one shop on one day are both kept. The office sees two rows, not one. |
| Notes | Up | With the visit they belong to | Appended, never merged. Two notes stay two notes. |
| Photos | Up | On wifi, or on mobile data if discovery scopes it | No conflict possible. A photo is added to the visit it was taken on. |
| Draft quotes | Up | With the visit, then confirmed in the office | If the price list moved between the draft and the upload, the draft is flagged, not repriced. |
| Price list | Down | On every connection, before the day's first visit | The office version wins. A draft written against the old list is flagged for the rep. |
| Customer list | Down | On every connection | An account edited in the office and on the phone keeps both edits, and the office resolves them. |
| Assignments | Down | When a manager reassigns an account | The office decides who owns an account. A visit by the previous rep is kept, with that rep's name on it. |
| Stage changes | Down | When the office moves a deal, for example from order draft to delivered | The office stage wins. The phone shows the new stage and does not argue. |
The conflict the figure draws is the common one. Price changed in the office 14:10, draft quote on the phone 14:32: both kept, flagged for the rep. The office raised a price at 14:10. The rep, twenty minutes later and two rooms from the signal, drafted forty cases at the price the phone still held. When the draft comes up, the system does not reprice it, because the customer was told a number. It does not accept it either, because that number is now wrong. It keeps both, flags the row, and the rep calls the customer before the draft becomes an order. What carries across when the order draft becomes the order, and then an invoice is the next handoff, and it starts only after that flag is cleared.
How does the office see where the reps were?
Through the visit rows, each carrying an account and a device time, not through a GPS trail. A rep who called on nine shops on Tuesday has nine dated rows on Tuesday, and the office reads the route off the rows. The row says what the office needs: that the shop was visited, what was on the shelf, what was drafted, and when the reorder is due.
That is what a distribution pipeline is. The figure below draws three pipeline shapes, one per audience: B2B sales, distribution sales and project sales. The B2B rail runs Lead, Qualified, Quote sent, Negotiation, then forks to Won and Lost (reason kept). The Project rail passes gates between Bid, Proposal and Award, then three milestones (Milestone 1, Milestone 2, Milestone 3), each labelled invoiced by Accounting, not here. This page reads only the middle rail, the Distribution loop: Account, Visit, Order draft, Delivered, Reorder due, and the last arrow closes back on Visit. The label on that arrow is the whole argument: the deal is the account.
A GPS trail answers a different question, and a worse one. It says where a phone was, which is not the same as whether the shop was served, and it needs a live connection to report, which is the one thing the back office does not have. A visit row is written with no signal and survives it. It is a sales record rather than a surveillance record, which matters for the rep who has to want to write it. The office sees the route as a list of accounts visited, each with a time the phone set, a shelf count and a draft, and it sees the gaps: the account with no visit row for three weeks, which is the reorder about to be missed. That reading is what a CRM system for B2B, distribution and project-based sales is built to give the office, and the phone app is how the rows get there.
Is this a CRM feature or a separate app?
A separate app on the phone, writing to the same CRM record. The office works in the CRM on a browser, at a desk, with a signal. The rep works in an app built for one thumb, a bright shop and no signal. What makes them one system is that the visit row the rep writes is the row the office reads, not an export of it.
Two routes reach that, and the route decides how much of this page is configuration and how much is code. Built on Odoo CRM, the office side is ordinary and mobile access is a PWA or the store apps (Odoo documentation, checked 14 September 2026). Whether a visit can be written in a dead spot and queued is a question to put to whoever configures it, in discovery, not a box already ticked. Purpose-built, the app is written against the specification above: a field-rep app built to ship in the App Store and Play Store, with the offline-first sync between the app and the CRM scoped as its own piece of work, because the sync is where the difficulty lives.
| Question | Answer | Where it is written down |
|---|---|---|
| What a build promises | A visit written on the device at device time, a queue the phone keeps itself, an up lane and a down lane, and a conflict kept twice and flagged for the rep. | This page, and the scope document a fixed price is quoted from. |
| What exists today | No field sales app to hand you. The CRM build exists as a service; the phone app is a specification, not a shipped handheld. | The caption under the first figure above. |
| What is scoped in discovery | Which fields a visit carries. Whether photos wait for wifi. Who may change a price. How long a phone may hold unsynced rows before the office is told. Whether the rep sees available stock as of the last sync. | The discovery document, before any price is fixed. |
Ask any vendor the same three rows. A vendor with an app in the store can fill the middle row, which this page cannot. Ask for the first and third rows anyway. A store listing says an app exists. It does not say what the app writes when the signal is gone, or what it does to a draft when the price moved while the rep was in the back room.
What is different about offline at a counter versus offline on the road?
The counter loses ten seconds; the road loses the whole visit. A till drops the line mid-payment, on a router shared with the CCTV, and the question is what happens to one interrupted KHQR payment. A rep's phone has no signal for the twenty minutes the visit takes, and the question is whether the visit exists at all.
The two problems look alike and are solved differently, which is why they get separate pages. At a counter, money moves. A KHQR code is issued by a bank, and the confirmation that the customer paid has to travel back from that bank, so no till can settle a payment with no path to the network; what an offline-first till guarantees is that the sale is written locally and reconciles against the bank's record later. On the road, no money moves in the CRM. The rep records a promise to pay, not a payment, so there is no bank to wait for and no half-finished transaction to reconcile: the visit is complete when it is written. What the road has instead is the price list conflict above, which a counter never sees because the till already holds the price. What happens to a POS when the connection drops is the counter's page, with the aeroplane-mode test to run on any till.
Frequently asked questions
- Does the rep need mobile data during the visit?
- No. The visit is written to the phone and queued. The phone needs a connection at some point in the day: before the visit to pull the price list and the customer list, and after it to push the visit up. A rep who synced at the depot in the morning and again from the truck after each shop has done everything the app needs. A rep with no connection until evening has a day's visits in the queue, and they all arrive stamped with the time each was written.
- Can the rep take a payment in the app?
- No, and a field sales app that offers it is doing accounting's job in the wrong place. The rep writes a promised payment date as a note on the visit. When the money arrives, by KHQR, by bank transfer or in cash at the depot, it is recorded against the invoice in the accounting system, which is the only place a payment belongs. The CRM sees the invoice as paid because the accounting system says so, not because the rep typed it.
- Can the rep see stock before promising it?
- The rep sees the available figure as of the last sync, and the screen should say so. Available is on-hand minus what is already committed to other orders, which is why it is the number a rep can promise and on-hand is not. It is still a morning number by the afternoon, so the draft stays a draft until the office confirms it against the warehouse at that moment. A draft of forty cases against thirty available is a flag for the office, not a failure on the phone.
- Does the office see where the rep is right now?
- No. The office sees visit rows, each with an account and the time the phone set when the rep saved it. That is a record of shops served, not a live position, and it is written in the dead spot where a live position could not be reported anyway. If what a manager actually wants to know is that Pursat was skipped this week, the rows say it directly: an account on the route with no visit row against it.
- What happens when a shop messages the rep on Telegram instead of waiting for the visit?
- The reply still happens in the chat, on the rep's phone, the same as today. What a build covers is capturing that message into the account's record, so the next visit row shows it was answered and the office can see the shop asked for something between visits. That capture is a scope of its own, and how Telegram and Facebook leads land in one lead record without leaving the chat sets out what it involves and what to ask a vendor who says they integrate with Telegram.
Where to go next
A CRM system for B2B, distribution and project-based sales is the build this app writes into, with both routes on one page. CRM in Cambodia: what it records, and when Excel stops working is the record itself, visit rows included. From a won deal to a GDT-filed invoice follows the order draft after the office confirms it. Eight CRM tools compared on seven questions sets the packaged options side by side, read off their own pages on a stated date. What happens to a POS when the connection drops is the counter's version of this problem.