Retail Merchandising Field Service Software: Why You Cannot Prove the Store Visit You Just Invoiced

Why a merchandising business lives or dies on proof of the store call

A rep is in aisle nine of a big box store at 7:20am doing a planogram reset for a beverage client. The store has a steel roof and concrete walls and there is no usable signal past the front registers. She works the reset, takes twelve photos, counts facings, notes that two SKUs are out of stock in the back room, and taps through a 40 question survey. The app spins. She finishes the call, drives to the next store, and at some point the queued data syncs, or does not. Three weeks later the client's category manager disputes eleven calls on the invoice because the before photos are missing.

That dispute is the entire business. A third party merchandising agency does not sell labour, it sells verified completed work, and the invoice is only as good as the evidence attached to it. Everything else in the operation, scheduling, routing, surveys, training, exists to produce a defensible record that a call happened, at that store, at that time, to that standard. When the evidence is weak, the agency eats the call. When it is weak often, the contract does not renew.

The tooling landscape reflects a different assumption. Movista, Repsly, Natural Insight and FORM are all built around a field team executing a programme and reporting on it. They do that well. What they are not built around is an agency with fourteen clients, each with its own rate card, its own definition of a completed call, its own required photo set, its own reporting template and its own dispute process. In our delivery experience the agencies that outgrow these products almost always outgrow them on the commercial side first, not the field side. The rep app is fine. The billing, the client specific validation rules and the reporting are what get done in spreadsheets at the end of every month.

Problem 1: the visit is a billing event and the tools treat it as a survey

In a product built for a brand field team, a completed visit is a form submission. In an agency, a completed visit is a line on an invoice with a rate that depends on the client, the store banner, the call type, whether it ran long, whether a second rep was required, and whether the client's completion criteria were met. Miss any of those conditions and the call is either unbilled or disputed.

The gap shows up as month end work. Somebody exports visit data, cross references it to a rate card in Excel, applies the exceptions manually, and produces an invoice, usually a week later than they should. Then a client queries it and the reconciliation starts over. That process is where agency margin quietly disappears, because unbilled or written off calls are almost never counted and almost never fixed.

A custom build makes the completed call the billable unit from the start. Each client has a completion definition expressed as rules, for example a call is billable when the required photo set is present, the geofence check passed, the survey has no mandatory blanks and the duration exceeds a minimum. Calls that fail land in an exceptions queue with a reason before anyone invoices, not after a client complains. Approved calls roll into an invoice automatically at the client's rate card. This one change moves billing from a week of month end work to a review queue, and it is normally what pays for the build.

Problem 2: offline is not a feature, it is the architecture

Reps work in back rooms, walk in coolers, warehouse clubs and rural stores where connectivity ranges from poor to absent. Any product that treats offline as a cached form is going to lose data, and losing a rep's morning is the fastest way to lose the rep.

Doing it properly means the app holds a full local database, queues photos separately from structured data so a 40 photo call does not block the survey sync, resumes uploads that were cut off mid transfer, and resolves conflicts deterministically when a route changed while the device was offline. It also means designing for the phone the reps actually carry, which in this industry is frequently a mid range Android device that is three years old with a full storage volume. We have shipped in this category and the storage management alone, deciding what to compress, what to keep and when to purge synced media, is a real piece of engineering nobody budgets for.

Problem 3: proof of visit is contested, so it has to be built like evidence

Clients audit. When a category manager suspects a rep is claiming calls from a car park, the agency needs an answer better than a checkbox. That means several independent signals captured together rather than one that can be argued with.

A geofence entry and exit event with accuracy radius recorded, not just a single point. Photos with capture time and location bound at the moment of capture, since image metadata can be stripped or edited later, and a hash recorded on device so nobody can claim the file was substituted. A device attestation so a rep cannot use a mock location app, which is a real problem in this industry and one that agencies rarely discuss openly. Duration measured on device, not inferred from sync time. And an audit trail that shows what was edited after the fact and by whom, because supervisors do legitimately correct data and that correction must be visible.

Handled well, this ends disputes fast, and it also protects good reps from accusations. Handled badly, it becomes surveillance theatre that the field team learns to work around.

Problem 4: scheduling has more constraints than a route optimiser knows about

The naive version is a list of stores per rep per day. The real version has to respect client mandated visit windows, store receiving hours and no merchandising periods, banner specific check in requirements at the service desk, rep skill and certification for certain resets, drive time between stores, weekly hour caps that carry employment law consequences, and the fact that a third of the schedule changes after 6am because of call offs and urgent client requests.

Off the shelf scheduling handles the first version. Agencies survive the second version through a dispatcher with a whiteboard and a phone. A build that models the constraints explicitly can reoptimise a day when a rep calls in sick and tell the dispatcher which three calls can be absorbed, which one needs a different rep because of a certification, and which one has to be rescheduled inside the client's window before it breaches a service level. That is the difference between a route tool and an operations system.

Problem 5: every client wants their own report and their own definition of done

One client wants a weekly compliance percentage by store with photos embedded. Another wants a raw data feed into their own business intelligence (BI) stack. A third wants an out of stock alert within two hours of the call, pushed into their category team's inbox. A fourth wants a portal their regional managers log into directly. None of them want your standard report.

Products solve this with export and a template engine, which works until the definitions differ. When one client counts a call complete at 90 percent survey completion and another requires 100 percent plus manager sign off at the service desk, you are no longer formatting a report, you are running two different data models. A custom build carries the completion rules, the required evidence set and the reporting shape as client configuration, so onboarding a new client is a configuration exercise measured in days rather than a new spreadsheet in the finance team's folder. For an agency in growth mode, the speed of client onboarding is the growth constraint, and this is where it sits.

What this costs and how long it takes

A first release with scheduling, an offline first rep app with photo and survey capture, geofenced proof of visit and a supervisor review queue runs $55,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding per client rate cards and automated call billing, client portals and data feeds, exception and dispute workflow, territory and route optimisation, and rep onboarding and certification tracking runs $140,000 to $350,000 phased over 6 to 12 months.

What pushes cost up in this category: the number of clients with genuinely different completion rules, since each is configuration to design and test. Native apps on both iOS and Android where the media handling has to be tuned per platform. Integration into client systems, which ranges from a simple data feed to a retailer portal with no interface at all. Payroll integration, because reps are frequently paid per call plus mileage and that calculation has to be exact. And any requirement for barcode or shelf image recognition, which is genuinely useful for out of stock detection but should be treated as its own phase.

What keeps it down: launching with your two largest clients only, one platform first if your reps are predominantly on Android, and deferring route optimisation until the visit and billing loop is proven.

Build versus buy, and when buying is the right call

Buy if you are a brand field team running one programme with one reporting standard. Repsly and Natural Insight are well built for exactly that and you will be live in weeks for a subscription. Buy if you are an agency under roughly 60 reps with two or three clients whose requirements are similar, because your configuration pain is not yet large enough to justify capital.

Build when two or more of these are true. You run more than about 150 reps across clients with materially different rate cards and completion definitions. Your month end billing is a spreadsheet exercise and you know you are writing off calls you cannot prove. Client disputes are recurring and you lose them because your evidence is a photo with no binding to place and time. Onboarding a new client takes weeks of manual setup and it is slowing your sales. Or you are competing for contracts where the client explicitly evaluates your technology, which in retail merchandising is now common and is the reason several of our clients started.

How to choose a developer for merchandising field software

Ask them to explain their offline sync model before anything else. They should describe a local database, separate queues for media and structured data, resumable uploads and a deterministic conflict rule, and they should ask what devices your reps carry. If the answer involves caching a web form, they will lose your reps' work in month one and you will not recover the trust.

Ask how they would prove a rep was physically in a store when the client disputes it. A good answer covers geofence events with accuracy, on device capture binding for photos, hashing, and mock location detection. A weak answer is a GPS coordinate stored with the record.

Ask how a new client with different completion rules gets onboarded, and whether that is configuration or code. If it is code, every client win becomes a development ticket and your growth is capped by your developer's calendar.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the app store accounts and the cloud infrastructure, and you should be free to hire anyone else to continue. At Digital Heroes the client owns everything from the first commit. In this industry the software is part of what you sell to clients, so owning it is not a technicality, it is the asset.