Distributor sell-out visibility: which stores the product reaches

Three questions that are answered once a month today

In the meeting, the sales team framed it as three questions. All three are answered after the distributor, in a stretch the brand cannot see; that is why the answer arrives at month end today, summarized and different depending on who reports it. Behind all three is a simple piece of data that nobody has: how many of the brand's products each store buys. A store that buys just one is already a customer, and offering it the second costs far less than winning a new store. That is the cheapest growth in the network, and today there is no way to measure it. That is why we split the problem into two figures that can be measured: how many stores carry the brand, and how many of its products each one buys out of those it could buy for its category. The underlying goal is not the report: it is growing on both.

The industry asks for the data. We propose giving it back.

The big consumer-goods brands have already solved access: they connect to each distributor's system, extract the sales and build an average for headquarters. It works for measuring, and it leaves three things out. The distributor opens its system and gets nothing in return, so the quality of the data depends on its goodwill. The salesperson, who decides what goes into each store, appears in no report. And the month's targets are still agreed by phone and checked at close. Our proposal uses the same connection point and turns it around: the data goes back to the distributor as a tool to run its own team. Connecting is in its interest, and that is what sustains the quality of the data.

An engine that reads sell-out from each distributor's system, and nothing else

We designed the platform on top of what the network already records, so nobody enters twice what already exists. The engine connects to each distributor's management system and only reads: it does not write, does not modify and does not look at other brands. Every night it takes the sales of the brand's products, translates the distributor's codes into the brand's catalog and calculates, store by store, what each one buys and what it is missing. The only thing it does not recognize, a new code, is confirmed by someone at the distributor with one tap, and it is learned. The next morning, the result is on the three screens. If a distributor has no way to connect, the engine takes a periodic export. Entry from a phone stays as a backup for the smaller ones.

The same information, on three different screens

Each screen shows only what that role needs to decide. The brand sees the whole network. Each distributor sees its account with the brand and, inside it, its own team: that is why connecting is in its interest. The salesperson sees, before heading out, whom to visit and what to offer in each store. Nobody sees another distributor's data.

Distribution coverage: the same case, now all the way to the store and the next day

From a month-end report to a network that is run every day. This is what the proposal commits to changing; the pilot supplies the figures.

• How far it seesToday, up to the distributor's warehouse. With the engine, down to the store: each sale with its customer, its salesperson and its date.
• When it arrivesToday, at month end. With the engine, the next day.
• Who reports itToday, each rep, however they want and however they can. With the engine, it comes from the distributor's system, in a single format for the whole network.
• How it is measuredToday, by cases sold to each distributor. With the engine, by stores that buy and products per store.
• The targetsToday they are agreed by phone and checked at close. With the engine they are set on the dashboard, flow down to each salesperson and can be watched as they progress.
• The distributorToday it hands over information and gets nothing back. With the engine it gets a tool to run its team.

First understand the network, then the engine, and finally the whole network

This is how we work: first understand how each distributor operates and what system it uses, because the connection depends on that; then, the software. Discovery is a deliverable in itself, and scope and price are set when it ends, with the network mapped. The pilot runs without changing how any distributor works, because the engine only reads, and it is measured against a control group. Only with that result do we decide on the rollout, in batches, to the rest of the network.

Other companies' data, with clear rules from day one

The engine reads sales, customers and salespeople from companies that are neither the brand nor Mithandir. That is why the proposal sets out from the start what each party provides, who sees it and what is not shared, and puts it in writing in an agreement with each party. Certification by an independent third party is a milestone before the network rollout, to be assessed with the brand. Mithandir does not currently hold an issued certification, and the proposal says so.

• Read-only, only what is neededThe engine reads sales of the brand's products. It does not write, does not modify and does not look at other brands. Each distributor can cut off its access whenever it wants.
• No distributor sees anotherEach one's data is kept separate, encrypted in transit and at rest, and handled under Argentina's Personal Data Protection Law (Law No. 25.326).
• It can be auditedA record is kept of who accessed which data and when, and a third party tests the security before the pilot.