Worked scenario · B2B trade and distribution
Monthly revenue lands twelve days too late.
A 45-person trade and distribution SME, €12M in revenue, 3,000 active SKUs. An ERP, a CRM, an online shop, and a dozen spreadsheets holding the three together. Here is a full engagement, from the audit through to the assistant.
The company
- Size
- 45 staff, including 8 in sales and 3 in customer service
- Business
- B2B distribution, 3,000 active SKUs, 1,200 trade customers
- Revenue
- €12M across four channels: key accounts, e-commerce, resellers, shop
- Tools in place
- A commercial management ERP, a CRM, an online shop, a dozen shared spreadsheets
- What is missing
- No consolidated view, and nobody owns the product master data
The starting point
Monthly revenue is presented to the management committee on the 12th of the following month. It is assembled by hand by the financial controller: export the ERP, export the shop, glue the two together in a spreadsheet, strip the duplicates, arbitrate the doubtful cases. Two days of work every month, for a figure nobody really disputes but nobody can recompute.
Meanwhile, decisions are made on gut feel. A channel slips and it takes six weeks to notice. A SKU runs out and the salesperson learns it at the same time as the customer. And when two people quote two different figures in a meeting, the discussion is about the figure instead of the decision.
None of this is a tool problem. The ERP does its job, so does the shop. The problem is that they don't talk to each other, and that nobody has ever written down what “revenue” means in this company.
What the audit puts on the table
- 01
Nine data sources actually in use, where management had named four. The other five are spreadsheets that became critical without anyone deciding so.
- 02
Four definitions of revenue coexist: with or without year-end rebates, at order or at invoice, shipping included or not, returns deducted or not. None is wrong, they simply answer different questions.
- 03
Product master data exists twice, in the ERP and in the shop, with different codes for 340 SKUs. Any consolidation without prior reconciliation produces wrong figures.
- 04
The ERP exposes its database read-only, the shop a decent API, the CRM a limited but sufficient one. Technically, nothing blocks.
- 05
Stock is not historised: today's state is known, the state three weeks ago is not. Anticipating a stockout is impossible until that history exists.
What gets built, week by week
- Weeks 1-2
Connectors and ingestion
Three connectors: ERP database read-only, shop API, CRM API. Incremental, idempotent ingestion with retry on failure. By the end of the second week, raw data from all three systems lands in the same place every night, with nobody exporting anything.
- Weeks 3-4
Warehouse, model and reconciliation
A historised PostgreSQL warehouse, and a model that names the objects of the business: customer, product, order, order line, channel. The 340 duplicate SKUs are reconciled, the mapping table is handed over and stays maintainable by your teams. Stock starts being historised from this point on.
- Week 5
The definition of revenue, written down
Half a day with management and financial control to settle it: what counts as revenue, what does not, and on what date it is recognised. The rule is written, implemented once in the warehouse, and everything else follows from it. It is the shortest session of the engagement and the most profitable.
- Weeks 6-7
Dashboards and alerts
Revenue by channel, by customer, by product family, compared with the previous month and year. Average basket, orders, margin where it is available. And alerts: a SKU dropping below its threshold, a channel down more than 15% over seven days, a major customer who has not ordered within their usual cycle.
- Weeks 8-10
The assistant, on a written scope
Around thirty questions covered, each backed by a calculation defined in the warehouse: revenue over a period, channel comparison, top customers, order status, stock for a SKU. The assistant computes nothing itself: it picks the right query, runs it, and shows under the answer what ran and how long it took. Outside its scope, it says so.
What it changes
Monthly revenue
Available on the 12th of the following month
Available every morning, final close at D+1
Producing the reporting
About 2 days a month, by hand
Nothing left to produce. The controller checks instead.
Definitions of revenue in circulation
Four
One, written down and implemented once
Stockouts
Discovered when the customer calls
Flagged around 3 days ahead, with the replenishment in flight
Numbers questions to financial control
Several a day, by email
Asked directly to the assistant, with the source shown
These orders of magnitude are what this kind of engagement produces when the conditions below are met. They are not contractual commitments: the pricing for your own situation comes out of the audit.
What it costs, and how long it takes
Audit: €3,500, two weeks. Data foundation and dashboards: €22,000, six weeks. Assistant: €12,000, three weeks that partly overlap the previous ones. Around €37,500 over ten weeks, decided in three steps: you only commit to the foundation after reading the audit, and to the assistant after seeing the foundation run. A monthly operating fee applies once in production. You own the code and the credentials.
What would make this scenario fail at your company
A closed ERP
If your ERP exposes neither an API nor database access, and the vendor charges for every extraction, the maths changes entirely. It is the first thing the audit checks, before any talk of architecture.
Nobody to settle the definitions
The week 5 session assumes somebody has the authority to say what revenue is. If the question goes up and never comes back down, the engagement stops there - and it is right to stop.
Master data with no owner
We can reconcile what exists once. If nobody keeps the product master data afterwards, the duplicates come back within six months and the figures become arguable again.
Wanting the assistant straight away
An assistant wired to unprepared data answers fast, confidently, and wrong. In this scenario it arrives in week 8 because the seven weeks before it give it something true to read.
The building blocks involved
The data audit
Two weeks at most, a fixed price, and a document that belongs to you. It is the only honest way to know what your data allows before committing a budget to it.
The data foundation
Four to eight weeks for your data to live in one place, historised and reliable. Delivered in usable stages, not in one go six months out.
The AI assistant
An assistant that answers your business questions in plain language, on figures that come out of your own database. It arrives once the foundation is reliable, never before.
The other scenarios
Manufacturing and after-sales
Four people in after-sales spend their days answering the same six questions: lead time, order status, part compatibility, warranty, documentation, scheduling a visit.
Hotels and restaurants
Occupancy, RevPAR and average spend live in three tools that don't talk to each other, and booking requests that arrive outside opening hours get lost.
Does this starting point sound familiar?
Thirty minutes are enough to know whether your situation looks like this one and what would change in the pricing. If it has nothing to do with it, we will tell you.