A mobile field-intelligence platform that converted store visits, product observations, pricing, placement and competitor context into central management visibility for major consumer brands.
The solution was delivered through a partner relationship, with INESSOFT responsible for substantial application development and frequent direct technical interaction with client stakeholders. Recognised organisations supported through this work included Dairybelle, Tiger Brands, Blue Ribbon, SAB Miller, GSK and others. They are not represented here as direct INESSOFT contracting clients.
From 2012, INESSOFT developed commercial field-intelligence software alongside its game portfolio. Field agents travelled to retail stores and used a BlackBerry application to capture structured observations: the store and visit context, whether specified products and brands were present, where they were positioned, what prices were displayed and how competing products appeared. The records were synchronised to a central server and exposed through a Microsoft Silverlight reporting application. Brand and management teams could then analyse execution at store level instead of relying only on national sales totals, delayed spreadsheets or anecdotal field feedback.
FMCG performance is shaped by what happens inside individual stores. A product may be listed nationally but absent from a specific outlet, priced incorrectly, poorly placed, outperformed by a competitor or missing a planned promotion. Management therefore needed evidence from many distributed field visits, collected consistently enough to compare stores, territories, products, brands and time periods.
The system had to make complex market-audit capture practical for agents standing in busy retail environments. It needed controlled products, brands, competitors, stores, questions and response types while remaining fast enough for repeated daily use. It also had to survive mobile connectivity limitations, preserve visit context and transform thousands of observations into management reporting that answered real commercial questions.
The hardest part was not the form or dashboard in isolation; it was preserving meaning from the shelf to the report. A price without product, pack size, store and date is weak evidence. A placement observation without controlled categories is difficult to compare. A field application can collect large volumes of data while still producing poor intelligence if users are rushed, reference data is stale or synchronisation failures are invisible. The project crossed mobile UX, offline-tolerant workflow, data modelling, central services and analytical reporting at a time when the mobile development ecosystem was far less mature.
INESSOFT developed a structured BlackBerry field application, central synchronisation and data services, an operational database and a Silverlight management reporting interface. Campaign and reference data defined the stores, products, brands, competitors and questions relevant to each field programme. Agents selected the correct visit context, captured controlled observations and submitted records when connectivity allowed. Central validation made submissions comparable, while reporting allowed management to filter and compare product presence, pricing, placement and competitive conditions by store, region, campaign and time.
The platform gave participating brands store-level visibility into market execution and competitor conditions that were otherwise difficult to consolidate. It created a stable commercial software stream for INESSOFT and established an important engineering pattern that remains relevant today: mobile capture at the point of work, controlled reference data, resilient synchronisation, central SQL records and role-appropriate management reporting.
This is a content-based reconstruction, not a client screenshot. It shows the kinds of live inputs, controlled states, modules and evidence the delivered system had to bring together.
A client or campaign manager defines the stores, products, brands, competitors and observations required.
Reference and assignment data is distributed to the relevant field users.
An agent arrives at a store and opens the correct visit on the BlackBerry application.
The application presents only the questions and product structures relevant to that campaign and outlet.
Exact client throughput, time-saving and financial figures are not published for this system. The case study therefore limits itself to implemented controls, workflow changes and verifiable system capabilities rather than manufacturing a percentage improvement for marketing purposes.
Each layer had a specific operational responsibility. This made failures easier to diagnose and prevented one screen, service or database field from becoming the accidental owner of the entire process.
Controlled stores, territories, products, pack sizes, brands, competitors, questions and valid response options.
Connected each field user to the appropriate campaign, store and observation requirements.
Presented a guided mobile workflow designed for speed, repeat use and controlled responses in a retail environment.
Allowed an agent to complete meaningful work without depending on uninterrupted connectivity at every screen.
Transferred completed or partial visit records to the central platform and made successful submission a separate concern from capture.
Stored visits, agents, stores, products, prices, placement observations, competitor context and timestamps.
Applied controlled reference data and consistency checks before observations were trusted for comparison.
Provided management filters, comparisons and views around the decisions the field programme was intended to support.
Allowed products, stores, questions and client requirements to evolve without rebuilding the mobile application for every adjustment.
A case study is useful only when the flow can be understood. The sequence below shows where users, devices, databases or external systems entered the process and how responsibility moved.
A client or campaign manager defines the stores, products, brands, competitors and observations required.
Reference and assignment data is distributed to the relevant field users.
An agent arrives at a store and opens the correct visit on the BlackBerry application.
The application presents only the questions and product structures relevant to that campaign and outlet.
The agent captures presence, pricing, placement, competitor and exception information while inspecting the store.
The device validates required context and retains the visit locally where connectivity is not yet suitable for submission.
Completed records are synchronised to the central server when a connection is available.
Central services validate the records against controlled products, stores and campaign rules.
The operational database consolidates observations from many agents and locations.
Management users filter and compare results through the Silverlight reporting application.
The resulting evidence supports decisions about pricing, distribution, merchandising, field follow-up and competitor response.
These were not isolated feature requests. Each module supported a specific part of the operational lifecycle and shared the same data, state and accountability model.
Associated field agents with the correct geography, campaign and work context.
Provided a consistent identity for each outlet and a controlled start and end to field activity.
Defined exactly which products, pack variants, brands and competitors could be compared.
Recorded whether the expected product was present, absent or otherwise not observable.
Collected retail pricing with the product, store, date and campaign context required for analysis.
Captured shelf, display or promotional execution through controlled questions rather than unstructured narrative alone.
Linked competing products and brands to the same visit so management could compare execution conditions.
Allowed field users to explain unusual conditions without replacing structured data with free text.
Queued and transmitted records separately from the field capture sequence.
Surfaced incomplete, contradictory or out-of-scope observations before management reporting.
Allowed users to filter by store, territory, product, brand, competitor, campaign and time.
Converted individual visits into market-execution patterns and competitor insight.
The important work was often deciding what not to combine, automate or assume. These decisions made the resulting system easier to support and more honest about its boundaries.
The mobile sequence prioritised speed and context because an agent could not be expected to operate an office-style survey in a busy aisle.
Products, brands, pack sizes, stores and response options were modelled explicitly so reports compared like with like.
A temporary connection problem should delay submission, not invalidate the field work already performed.
The BlackBerry application focused on reliable evidence capture while the Silverlight platform handled management filtering and comparison.
A price or observation was useful only when linked to the correct store, product, agent, campaign and time.
Narrative notes supplemented structured fields rather than becoming the primary data model.
Client programmes change products, questions and stores. These concepts had to be configurable instead of compiled into each screen.
The value of the work does not depend on falsely presenting partner-delivered brand projects as direct contracts.
The project was broken into phases that reduced the highest-risk uncertainty first. This prevented a broad implementation from hiding an unproven data or workflow assumption.
Identify what the client needed to compare and define the store, product, brand, competitor and visit relationships required to answer it.
Build and test the BlackBerry sequence around real agent behaviour, repeated visits and constrained input time.
Create a dependable transfer path, central database and clear handling of incomplete or failed submissions.
Build Silverlight views around actionable questions rather than presenting raw tables as business intelligence.
Move changing products, stores and questions into administration so new work did not require a new application architecture.
Use field and management feedback to shorten capture, improve validation and remove report ambiguity.
The controls below reflect the kinds of failure that could produce wrong records, unsafe assumptions, hidden exceptions or a system users would bypass.
Used controlled choices, required context and campaign-specific forms rather than relying primarily on narrative notes.
Separated local visit completion from successful central synchronisation.
Maintained controlled product, pack, brand and competitor structures.
Centralised reference data so changes could be distributed and governed.
Kept the field sequence focused on the commercial questions that justified the visit.
Retained store, date, campaign and product context and applied central validation before comparison.
Allowed notes and exception context without weakening the structured dataset.
Public material identifies the partner-delivered nature of the work while preserving the actual engineering contribution.
These lessons came from operating the system under real users, data, commercial constraints and support pressure. They now influence how INESSOFT scopes new platforms and internal operational systems.
The field form and dashboard mattered, but the real asset was the controlled relationship between stores, products, brands, competitors, visits and time.
Management insight is constrained by what the agent can capture consistently. Reporting requirements therefore have to influence the mobile workflow from the beginning.
The mobile client, synchronisation service, central database and analytical interface each solved a different failure mode and could evolve independently.
A system serving field teams must preserve work when the network is unreliable. Connectivity is part of the operating environment, not an assumption.
The relationship demonstrated how a specialist development company can serve major brands through a trusted intermediary while still interacting closely with end users and stakeholders.
BlackBerry and Silverlight are obsolete platforms, but the pattern of guided mobile capture, API or sync services, SQL storage and browser reporting remains current.
The exact sector or technology may differ. The closer match is usually the workflow shape, source data, failure modes and operational responsibility.
FMCG brands and distributors needing store-level execution intelligence.
Retail-audit teams collecting comparable observations across many locations.
Field-sales organisations replacing paper forms or disconnected spreadsheets.
Inspection and compliance teams working in variable-connectivity environments.
Businesses requiring mobile evidence capture linked to central management reporting.
Buyers assessing INESSOFT's commercial software history before Leobot and its current industrial work.
The case study provides evidence. The service pages define the current delivery boundary, first-step artefacts, exclusions and technical scope for a new engagement.
Coordinate mobile teams, customer sites, appointments, job evidence and service history from one system.
Adapt an operational workflow for practical use on phones, tablets or shared shopfloor devices.
Answer recurring management questions from an existing SQL database with governed reports, filters and exports.
Replace spreadsheet-and-email administration with a focused internal system built around your own rules, records and approvals.
Give managers a near-live view of current status, exceptions, queues and operational priorities.
Schedule trusted reports, files and exception summaries so people stop rebuilding and distributing them manually.
Technology is listed for precision, but the system boundary and operating process determined the architecture.
No. The work was delivered through a partner relationship. INESSOFT performed substantial development and often interacted directly with client stakeholders, but the brands are not presented as direct contracting clients.
It converted distributed store visits into structured evidence about product presence, pricing, placement and competitor conditions that could be filtered and compared centrally.
A free-text note may be useful to one manager, but it is difficult to compare across hundreds of stores. Controlled product, brand, store and response data made the observations analytically useful.
The specific platforms are historical, but the architecture remains current: mobile field capture, offline tolerance, central services, governed SQL data and role-based reporting.
Yes. A current implementation would usually use a responsive or native mobile application, APIs, SQL storage, modern authentication and browser-based dashboards while preserving the same operational responsibilities.
The project established that good reporting starts in the field workflow, that reference data is central to comparability and that operational software must be designed around the real environment in which evidence is created.
A curated national platform that turned promotional-model profiles, location and service data, searchable discovery pages, shortlists, PDFs and enquiries into one structured demand-and-supply system.
A browser-based operations portal that brought customer sites, jobs, inspections, evidence, reports and service history into one controlled workflow.
A long-running electronics commerce and operations platform that grew from surplus imported components into a technical catalogue, fulfilment system, internal-tool ecosystem and commercial engineering asset.
Bring one real artefact: a report, spreadsheet, machine signal, job record, certificate, import file, device or system error. INESSOFT can map the current process and define a credible first phase.
