Anyone who has tried to answer a simple question across a consumer-goods business knows the real problem is not analytics. It is reconciliation. Ask which stores were visited last week, what was on shelf when the rep arrived, what got ordered, when it was delivered, and what actually sold through, and you are immediately negotiating between five systems that were never designed to speak to each other. The field sales app has its own idea of an outlet. The ordering system has another, keyed differently. The route planner knows addresses but not assortment. The shelf-scan tool produces images and labels with no link to the invoice that follows. By the time a human stitches these together in a spreadsheet, the week is over and the answer is stale.
This is the unglamorous truth of route to market: the data exists, but it is fragmented across the very systems that created it. Each tool was bought to solve one job well, and each one modelled the world in whatever shape made that single job convenient. The cost of that convenience is paid later, every time anyone tries to reason across the whole journey from warehouse to shelf.
Our engineering bet is that the durable advantage is not any single feature. It is the data model underneath all of them. FMCG Cloud runs its six product categories, Field Sales, Retail Execution, B2B Ordering, Route and Delivery, Revenue Growth AI, and Shelf Intelligence, on one shared data layer we call ConnectX. The premise is simple to state and hard to do: an outlet is the same outlet whether a rep is standing in front of it, a truck is routed to it, an order is placed for it, or a camera scans its shelf. A product is the same product whether it is a line on an invoice, a facing in a planogram, or a SKU in a suggested order. When those identities are shared rather than copied, the seams between products stop being a place where information leaks out.
Harmonising the model is where the engineering actually lives. A distributor invoice, a shelf scan, a sales order, a delivery route, and a sell-out record are wildly different artefacts. They arrive at different cadences, in different formats, with different notions of time and place. The work is in defining the canonical entities the whole platform agrees on, an outlet, a product, a visit, an order, a route, a transaction, and then mapping each incoming source onto those entities with explicit, auditable rules rather than implicit guesswork. It means resolving the same store described three different ways. It means deciding that a promotion observed on shelf and a discount applied on an invoice are two views of one event. None of this is exciting in a demo, and all of it is what makes everything above it trustworthy.
There is a governance dimension here too, not a marketing one. When outlet, order and transaction data share one model, you can reason about that data consistently, which is exactly what regimes like GDPR and CCPA expect: knowing what you hold, where it came from, and being able to honour a request about it without excavating five disconnected databases. A fragmented stack makes compliance a forensic exercise. A shared model makes it a property of the system.
The reason this matters now, rather than as a tidy architectural preference, is agents. An agent is only as good as the context it can stand on. An agent that lives inside a single tool can optimise that tool's narrow job and nothing more. A route agent that cannot see what is on shelf will route efficiently to the wrong priorities. An ordering agent blind to sell-out will keep proposing what looks reasonable on paper and wrong in reality. The shared model is what lets an agent see the whole route to market at once, and that is the difference between a clever feature and a system that genuinely reasons about the business.
This is also why agents on a shared model compound rather than plateau. Each agent both consumes the common context and contributes back to it. A shelf observation enriches what the ordering agent knows. An order pattern sharpens what the route agent plans. Sell-out signal feeds back into how revenue opportunities are surfaced. Value accrues to the model, so every agent added makes the others more capable instead of starting from zero. That compounding is impossible when every tool guards its own private version of the truth.
It is also why the marketplace is built the way it is. Specialist solutions from other builders are welcome, but every one of them classifies under the FMCG Cloud Agent Taxonomy, sixteen agent types across five families, and must earn the FMCG Verified certification before it ships. That is not bureaucracy for its own sake. It is the contract that guarantees a third-party agent reads and writes the same canonical entities as everything else, so it inherits the shared context and adds to it rather than fragmenting it again. The taxonomy is how an open ecosystem stays coherent instead of recreating the exact silos we set out to dissolve.
The honest framing is that consolidating five systems' worth of meaning into one model is slow, careful work with little to show on any given day. But it is the work that turns a collection of products into a platform, and a collection of agents, ours and the marketplace's, into something that gets smarter the more of the route to market it touches. The model is the moat. Everything else is what you build on top of it.