RetailMax Spain had sales, stock, and customer data scattered across five different systems, with no single unified view. Here's what we built on Microsoft Fabric — and what it actually cost, no gloss.
RetailMax is a retail chain with 87 physical stores in Spain and an active online channel. As with most operations of this size, each department had solved its own problem in isolation — and no one had the full picture.
Bar length is proportional to data volume. In-store POS accounts for 83% of the total — the first data point that changes any capacity plan.
What they needed wasn't another report. It was the ability to answer, in real time, three questions that used to take days to resolve: How are sales performing by store and by channel? Where is stock running out before it's too late? Which customers are drifting away, and why?
The same path we follow with any client this size: first know what it will really cost and how much capacity is needed, then build it on real data, and finally leave it running with a monitoring plan in place — not just a good-looking dashboard on delivery day.
Before writing a single line of pipeline code, we sized Fabric capacity against RetailMax's actual data volume — not a generic pricing sheet. The result is delivered to the client in writing, with the real monthly cost, before any decision is made.
SKU F8 · 8 CU · €1,256/month · 797 GB estimatedA medallion architecture (Bronze → Silver → Gold) on Fabric, with quality validation at every layer, feeding a Direct Lake semantic model — Power BI reads production data without waiting on a refresh. On top of that, four dashboards and AI-assisted visuals that surface patterns without anyone having to go looking for them.
6 nightly loads · 00:30–06:00 · validation at every stepFabric's native monitoring app tracks consumption, storage, and saturation in near real time. We're upfront with the client about what it doesn't do out of the box — it doesn't generate automatic alerts on its own — and we set up a review cadence with a named owner.
Daily · weekly · monthly reviewFour dashboards in production, each answering one of the questions that used to take days to resolve. Real screenshots from the live platform — click to enlarge.
In compliance with our information security policies and the confidentiality commitments made to the client, the company name, along with the data and databases shown in this case study, have been modified and anonymized. The nature and magnitude of the results faithfully reflect the work performed.
Sales by store, region, and category, with year-over-year comparison that doesn't depend on a date filter.
Real screenshot · click to enlargeStockouts visible by store and category, with the decomposition tree showing where the risk is concentrated.
Real screenshot · click to enlargeChannel comparison built on average ticket by category — the metric that actually proved reliable, after ruling out a margin metric that wasn't.
Real screenshot · click to enlarge2,840 customers segmented, with AI flagging which profiles are churning — the Referral channel and the 30–44 age group carry the highest risk.
Real screenshot · click to enlargeThe difference between a report and a business view: the latter flags the problem before you ask.
The Referral channel has a 13.5% inactivity rate — the channel that acquires the most customers also loses the most.
Customers aged 30–44 account for 12.7% of churn risk, the most exposed age segment.
The share of VIP customers ranges from 5.8% in Madrid to 13.4% in the Valencian Community and the Balearic Islands — same chain, very different behavior by region.
Beyond the dashboard, each department received an insights report ready to share with leadership — no one had to interpret a chart first.
Performance by store, region, and category, with the year-over-year comparison explained in figures.
Stockouts by store and SKU, prioritized by category and impact on lost sales.
Online vs. physical store, with average ticket as the reliable comparison metric.
2,840 customers segmented, with churn risk factors explained by AI.
None of the figures in this section are a contractual promise. They are estimated ranges, based on typical optimization patterns for medallion architectures on Fabric, applied to RetailMax's actual data profile.
| Lever | Why it applies | Estimated |
|---|---|---|
| Incremental load for POS | POS accounts for 83% of the volume and is currently reprocessed in full every night. | 15–30% nightly CU |
| Automated reframe | Replaces the manual trigger after each load with an automatic one. | Improves freshness |
| Spark autoscale | Avoids over-provisioning capacity on lower-volume nights. | 5–15% compute |
| Partition pruning | Reduces the volume scanned per query as historical data grows. | 10–20% notebook runtime |
The actual savings depend on the implementation and on usage patterns once in production — and scaling capacity (F8 → F16) only makes sense when consumption data calls for it, never ahead of demand.
If your sales, stock, or customer data is scattered across more systems than you can count from memory, you probably recognize the starting point. Let's talk about what your case would need — starting, as we did with RetailMax, by finding out what it really costs before building anything.
Email us →