Retail Merchandising Field Service Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the per client configuration scope blow up so often?

The brief says an app for the reps and a dashboard for the office. The system that actually has to exist serves fourteen clients who each define a completed call differently. One accepts ninety percent survey completion. One requires a signature at the service desk before the rep leaves. One rejects any call without a before photo of every bay touched. Those are contract terms, not preferences, and each is a rule the software must carry and be tested against.

This is specific to merchandising because you are a third party. A brand field team has one definition of done because it runs one programme. An agency inherits a definition of done from every contract it wins, and the sales team keeps winning contracts while the build is in flight. A scope written around three clients becomes eleven by pilot, because nobody tells engineering that a new client signed in month two.

The fix is structural, not managerial. Model the completion definition as configuration from the first sprint: required photo set, geofence tolerance, mandatory survey fields, minimum duration, signature requirement, rate card. Adding client twelve then becomes a configuration record and half a day of testing rather than a development ticket. Read any quote carefully on this point. If client rules are priced as features, your scope will grow at exactly the speed of your sales team, and the budget will not.

What goes wrong when you migrate visit history and photo archives?

Merchandising history is mostly media, and media is the part every migration plan underestimates. A few hundred reps capturing a dozen photos per call generate an archive measured in terabytes. Exports out of Repsly, Natural Insight or Movista typically hand you structured survey data quickly and photos as a list of links, and those links stop resolving when the subscription lapses. Agencies discover this in the month after cancellation, which is also the month a client raises a dispute about a call from last quarter.

The second failure is quieter. Survey answers export as flat columns, so the question set that produced them is lost. When a client asks in November why the compliance score for a store moved in June, you need the survey version in force in June, not the current one. Without it you are comparing two different questionnaires and calling the difference a trend.

Do three things before you sign anything with a new platform. Decide the retention window from your contracts and your dispute history, which for most agencies means twenty four months of media rather than everything. Pull the media yourself while the old subscription is still live, hash each file on arrival so nobody can later claim substitution, and store originals rather than the resized versions the old portal served. And carry forward the survey definitions with their versions, so historical answers stay interpretable.

Why do payroll, client feeds and retailer portals break after launch?

Three integrations matter here and each breaks in its own way. Payroll is the unforgiving one, because reps are commonly paid per completed call plus mileage, and a rounding difference or a mishandled exception becomes a wage complaint within one cycle. Any exception logic that lives in the app must produce the same number the payroll file produces, and that agreement has to be tested against a full period before go live, not sampled.

Client data feeds break because clients change them. A category team redesigns its reporting template, or moves from a file drop to an interface, and your nightly feed starts failing at four in the morning into an inbox nobody reads. The failure mode is not the error, it is the silence: three weeks of missing data discovered by the client.

Retailer portals break because most of them were never meant to be integrated with at all. Check in at the service desk, badge requirements, and store level receiving windows are frequently published as a document rather than a service, so what you build is a maintained data set, not a connection, and someone has to own keeping it current.

The concrete fixes are unglamorous. Version every client feed and keep the previous version running for a stated period after a change. Alert on absence, not just on error, so a feed that stops producing raises a flag the same morning. And name an owner inside your operations team for the retailer rules data, because engineering cannot know that a banner changed its receiving hours.

What happens when proof of visit does not survive a client audit?

A category manager suspects calls are being claimed from the car park and asks you to prove eleven visits. If your evidence is a single coordinate stored against the record and a photo with no binding, you will lose, and you will lose the ones you actually completed alongside any you did not.

The gaps are consistent. A single location fix with no accuracy radius cannot distinguish a rep inside the store from one at the kerb. Photo metadata can be stripped or rewritten after capture, so an image alone proves nothing about when or where it was taken. Mock location applications are real in this industry and rarely discussed openly. Duration inferred from sync time is meaningless when the device syncs in the truck an hour later. And supervisors legitimately correct data after the fact, so an audit trail that cannot show what was edited and by whom makes every record look tampered with.

Build evidence as several independent signals captured together. Geofence entry and exit events with the accuracy radius recorded. Photos bound to time and place at the moment of capture with a hash written on the device. Device attestation so a spoofing application is detected rather than trusted. Duration measured on device. A visible edit trail. Done this way the audit ends in an afternoon, and it protects honest reps as much as it protects the invoice. Done badly it becomes surveillance theatre the field team learns to route around.

Should you build custom or configure what you already own?

For a large share of readers, configuring the incumbent is the right answer and we would say so on a sales call. If you are a brand field team of thirty running one programme with one reporting standard, Repsly, Natural Insight or FORM is exactly the shape of your problem. You will be live in weeks on a subscription, and a custom build would be a maintenance obligation with no matching benefit.

The same holds for an agency under roughly sixty reps with two or three clients whose requirements are broadly similar. Your configuration pain is not yet large enough to justify capital, and most of what hurts at that size is process discipline rather than software. Tighten the required photo set, enforce it in the tool you have, and revisit in a year.

The build case appears when the commercial side, not the field side, outgrows the product. Concretely: more than roughly a hundred and fifty reps across clients with materially different rate cards and completion definitions, month end billing assembled in a spreadsheet, recurring disputes you lose for lack of binding evidence, and client onboarding measured in weeks of manual setup while your sales team waits. If none of those are true, keep the subscription and spend the money on supervision.

How do hidden costs get into the quote?

The rep application is the visible cost and rarely the surprising one. What lands later usually falls into five buckets. Device reality is the first: the fleet is mid range Android hardware of mixed ages with full storage, so compression policy, purge rules and low memory behaviour are engineering work that no proposal itemises. Media infrastructure is the second, because storage and egress for terabytes of photos is a recurring operating line, not a one off, and it grows every month you trade.

Supervisor tooling is the third and it is almost always left out. The review queue, the exceptions workflow, the ability to reopen a call and record why, and the reporting a district manager needs are all separate from the rep app and represent real build effort. Client onboarding is the fourth: if each new client needs a configuration, a feed, a report template and a test cycle, that is a repeatable cost you should price per client rather than absorb.

The fifth is app distribution and management. App store accounts, enterprise distribution, forced update policy and device management enrolment sound like administration until a release has to reach four hundred devices in stores by Monday morning. Ask for these five to be named and costed in the proposal. A quote that omits them is not cheaper, it is less complete.

What separates a build that works from one that fails here?

The builds that work close the money loop in phase one. Scheduling and capture alone produce a nicer version of what you already have. Scheduling, capture, an exceptions queue and an invoice generated from approved calls changes how the business runs, and it is what pays for the project. If the first release stops short of billing, the spreadsheet survives and so does the leakage.

They also pilot in genuinely hard conditions. One district, real reps, the worst connectivity stores you serve, the oldest devices in the fleet, with the old process still running alongside for two to three weeks. Every serious defect in this category, sync loss, storage exhaustion, geofence accuracy in a steel building, is invisible in an office demonstration and obvious in a warehouse club.

They treat the field team as a stakeholder rather than a user population. Reps who lose a morning of work once will start keeping paper as a backup, and once that habit forms your data is permanently incomplete. Ship the offline behaviour first, prove it, then add features.

Finally, they settle ownership before kickoff. You should hold the repository, the app store accounts and the cloud infrastructure, with the unrestricted right to hire anyone else to continue. At Digital Heroes the client owns everything from the first commit. In merchandising the software is part of what clients evaluate when awarding contracts, so it belongs on your side of the table, not your developer's.