The operating problem
In early commercial work, INESSOFT contributed to a partner-delivered FMCG field-intelligence system used to capture store-level observations for recognised South African brands. Field agents visited retail locations with BlackBerry devices, recorded product presence, pricing, placement and competitor information, and synchronised the results to a central server. Management users reviewed the data through a Silverlight reporting interface.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 03 Jul 2026 · Last reviewed 03 Jul 2026The visit is the primary business record
A field observation must be tied to who visited, which store, when the visit occurred, which campaign or questionnaire applied and which products were expected. Without that context, a price or presence value cannot be compared reliably.
- Use stable store and product identifiers.
- Record visit, agent and questionnaire version.
- Preserve incomplete or aborted visits rather than merging them into clean results.
Standardisation makes comparison possible
Free text is useful for unusual observations but weak for national reporting. Presence, facings, price, promotion and competitor status need controlled options and units. The capture interface should guide consistency without preventing evidence of unexpected conditions.
- Use structured fields for recurring comparisons.
- Define units and acceptable ranges.
- Allow notes and images as supporting context rather than the only record.
Offline-aware design changes the workflow
Field agents cannot depend on continuous connectivity. Data must be captured locally, queued safely and synchronised later without duplication or silent loss. The user needs to understand whether a visit is saved locally, sent, accepted or rejected.
- Assign stable local identifiers before synchronisation.
- Make retry idempotent and visible.
- Preserve validation feedback when the server rejects a record.
Questionnaires and campaigns evolve
Brands change products, priorities and promotional questions. Hard-coding every form creates deployment friction and historical ambiguity. A configurable questionnaire model can vary required fields while preserving which version produced each answer.
- Version form definitions and option sets.
- Do not reinterpret old answers using new rules.
- Test configuration changes against device and reporting compatibility.
Management needs comparison, not raw form exports
The reporting layer should answer operational questions: Which stores have the product? Where is competitor pricing lower? Which regions show weak execution? Which visits are missing or suspicious? Raw rows are necessary for audit but insufficient for action.
- Design reports around territory, brand, product, store and time.
- Allow drill-down to the visit evidence behind summaries.
- Expose coverage and data-quality gaps alongside performance.
Data quality is partly an operating problem
Software can validate ranges and required fields, but rushed or poorly trained capture still produces weak evidence. Management must define sampling expectations, supervision and review. The system should identify outliers and incomplete coverage so operational controls can improve.
- Track agent and questionnaire completion patterns.
- Flag impossible prices, repeated values and unusual timing.
- Use review feedback to improve forms and field training.
The architecture pattern extends beyond FMCG
The same pattern applies to inspections, maintenance, audits, surveys and distributed service work: prepare reference data, capture evidence on-site, synchronise safely, validate centrally and report by accountable dimensions. The domain changes, but the operational concerns remain similar.
- Keep reference data and field transactions distinct.
- Model evidence, exceptions and review status explicitly.
- Optimise the mobile experience for the actual environment and device.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
Agents have dependable connectivity and low visit volume.
A responsive web flow may be sufficient.
Keep the architecture simple but preserve transaction identity and validation.
Visits occur in low-connectivity environments.
Offline queueing and sync state are core requirements.
Design local persistence, retry and reconciliation before reporting.
Management wants market comparisons across stores and time.
Reference data and controlled fields are essential.
Define dimensions, units and questionnaire versioning.
Capture volume grows but trust falls.
Quality controls and field operations need attention.
Add validation, outlier review and agent-level quality visibility.
Evidence that the current approach is becoming risky.
- Store and product names are captured as uncontrolled text.
- The device shows saved even though data has not reached the server.
- Questionnaire changes overwrite the meaning of historical answers.
- Management receives spreadsheets but cannot trace values to visits.
- Missing visits are excluded from reports without showing coverage gaps.
What to clarify before commissioning work.
- Define visit, store, product, agent and campaign identity.
- Standardise recurring measurements, options and units.
- Design offline persistence and idempotent synchronisation.
- Version questionnaires and reference data.
- Build reports around actual management comparisons.
- Expose coverage, validation and outlier quality indicators.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Were the named FMCG organisations direct INESSOFT clients?
The work was delivered through a partner relationship. INESSOFT contributed software engineering and often interacted with operational stakeholders, but the engagement context should be presented accurately.
Why was offline support important?
Store visits could not assume dependable connectivity. Agents needed to complete work safely and synchronise later without losing or duplicating observations.
Can the same design support inspections or audits?
Yes. The reference data, configurable forms, evidence capture, synchronisation and central review pattern transfers well to many distributed field processes.
What makes field data useful to management?
Consistent identity, comparable measurements, known coverage, traceable visit evidence and reports designed around decisions rather than raw form exports.