How We Turned 14 Bakery Locations' Worth of Ignored POS Data Into a Profit Engine

Client: Under NDA — regional bakery & café chain | Industry: Food & Beverage / Multi-Location Retail | Locations: 14 (across 3 cities) | Annual Revenue: ~$9.4M | Team Size: 180+ staff across all locations | Timeline: ~7 months

---

At a Glance

---

The Business Was Growing. The Data Was Rotting.

The chain had been around for nine years. Fourteen locations, three cities, 180+ staff. A loyal customer base. A genuine reputation for their product. Healthy footfall.

By every surface metric, things looked fine.

But underneath, the owners were running the entire operation on instinct. Not because they were careless — they genuinely had no other option. The data existed. It was all there, technically. Every sale logged by the POS system. Every inventory delivery recorded in a spreadsheet somewhere. Every shift rota filed and then forgotten. But none of it talked to each other, none of it was visible in any useful way, and none of it was being used to make decisions.

The founder told us early on: "We know what we sold yesterday. We have no idea why."

---

What Was Going Wrong

Every location was a silo. They ran three different POS systems across the 14 locations — a mix of whatever was available when each new site opened. None of them exported data in the same format. The head office got weekly summary PDFs from each location manager, printed from the POS and emailed in. A bookkeeper manually typed the numbers into a master Excel sheet every Monday. By Wednesday, the data was already stale. By the weekend when it actually mattered, it was useless.

Nobody knew which items were actually making money. The menu had 74 items. They knew which ones sold the most. But revenue and profit are different things. A croissant sells for $4.50 and costs $0.40 to make. A specialty hot chocolate sells for $6.50 but costs $3.20 in ingredients, plus it takes 4 minutes of skilled prep time at peak hour. They'd been pushing the hot chocolate because customers loved it and it "felt premium." Nobody had done the math. When we finally did — that item was actively hurting profitability at 7 of 14 locations during morning rush.

Ordering was based on habit, not demand. Each location manager placed inventory orders every Monday based on what they'd used the week before and what "felt right" for the week ahead. No forecasting. No awareness of local events, school holidays, or weather patterns. The result: chronic overordering of short-shelf-life items (day-old croissants going in the bin), chronic underordering of fast-movers around local events. Food waste across the chain ran at roughly $41,000 a month — a number nobody had actually calculated until we did.

Staffing was guesswork at scale. Rota decisions were made by location managers individually, each using their own judgment about how busy a given shift would be. There was no shared data on peak hours across locations, no awareness of how school term dates, local events, or even rainfall affected footfall. Some locations were consistently overstaffed on Tuesday mornings. Others were understaffed every Saturday until 11am, when the queue would build up and the reviews would dip.

Location performance was invisible. Corporate had a rough sense of which locations were "doing well" based on monthly revenue. But they couldn't tell you whether a location was underperforming because of the neighbourhood, the manager, the product mix, the staffing pattern, the pricing, or something entirely fixable. Two of their locations had been "underperformers" for two years. No one knew if they should be shut down, given more support, or just had an easily solvable problem.

One of the co-founders said it plainly: "I've been making decisions about a $9M business with the same information a single-location owner had in year one."

---

What We Built

Not a dashboard. Not a reporting tool. A full-stack data intelligence system: ingest everything, clean it, model it, surface the insights that matter, and then automate the actions that follow from those insights.

Step 1: Unified Data Ingestion from Three POS Systems

The three POS systems in use were Lightspeed (6 locations), Square (5 locations), and a legacy system called Revel (3 older sites). Each had different data models, different export formats, different API capabilities.

Lightspeed had a decent REST API. Square's API was well-documented and reliable. Revel's API was old, partially broken, and the vendor's support response time was measured in weeks. For Revel, we built a hybrid: automated CSV export at end-of-day via a script installed on each site's back-office machine, pushed to an S3 bucket, picked up by our ingestion pipeline.

We pulled transaction data, item-level sales, voids, refunds, discounts, staff clock-in/clock-out records, and table/counter timing where available. We also integrated four separate inventory tracking tools (each location group had its own preference), supplier delivery records (from PDFs — we built a document parser), and staff rota data from the Excel files each manager emailed weekly.

The normalization layer was the real work. A "flat white" on the Lightspeed system at the Shoreditch location had a different SKU than the same item at the Camden Square location because someone had set them up independently three years apart. We ended up with 847 item variants across the chain that mapped to 74 canonical menu items. We built the matching logic using fuzzy text matching plus price bracketing plus category heuristics — a human reviewed and confirmed the output, and it took about 12 hours of a manager's time, not 200.

Everything landed in a single data warehouse. Full history from the earliest available export — in some cases going back 5 years.

Step 2: Menu Profitability Intelligence

This was the insight that hit hardest.

For each of the 74 menu items, we built a true contribution margin model: selling price minus ingredient cost minus allocated prep time at average labour rate minus packaging minus wastage rate. Not theoretical costs — actual costs pulled from delivery invoices, weighted by how ingredient prices had moved over the trailing 6 months.

We tracked this per-item, per-location, per-time-slot. Because a flat white at 7am, made by a barista being paid standard rate, in a location with low rent, is a different margin proposition than the same item at 6pm in a high-rent site where a senior shift lead is making it while three other orders are queued.

What came out was uncomfortable. Twelve items were loss-leaders at specific locations — customers ordered them, the locations were fulfilling them, and nobody had flagged it because the revenue looked fine. Seven items had high sales volume but low margin and could be repriced by a modest amount (£0.30–£0.60) without material impact on demand — we tested this against price elasticity curves we built from the historical transaction data.

Three items were retired from the menu at locations where they had high prep time and low margin. One item was promoted from a seasonal special to permanent menu because it showed the strongest margin-per-minute-of-prep in the entire catalogue. These decisions came from data. The management team made them — but for the first time, they could see exactly what they were deciding.

Step 3: Demand Forecasting and Inventory Automation

We built a demand forecasting model per location, per item category, per day-of-week and time slot. The model ingested:

• •5 years of historical sales data (where available)
• •Local school term calendars
• •Bank holiday and public event schedules
• •Hyperlocal weather data (temperature + precipitation, from a weather API)
• •Proximity to local events (concerts, sports fixtures, markets)

The forecasting model was an ensemble: a gradient boosting model for the bulk of the prediction, a seasonal decomposition overlay for recurring patterns, and a short-term correction factor based on the trailing 7-day actuals. Not unnecessarily complex — we tried simpler models first, and the accuracy gains from the ensemble were significant enough to justify it.

From the forecast, we auto-generated a weekly ordering recommendation for each location. The recommendation was presented to the location manager as a pre-filled order form — they could review it, adjust it, and submit. In the first four weeks, managers overrode the recommendations about 30% of the time. By week eight, the override rate had dropped to under 8%. The system had become more trustworthy than gut feel. We hadn't asked anyone to accept that — it just became the natural conclusion after watching the predictions land correctly.

Food waste tracking was embedded directly: every item that was recorded as discarded or written off at end-of-day fed back into the model as a signal. Locations that wasted more of a specific item saw reduced recommendations for that item the following week. The model learned location-specific demand curves, not just chain-wide averages.

Step 4: Staff Scheduling Intelligence

We built a foot traffic prediction model using the same inputs as the demand forecast (weather, events, school calendars) combined with historical transaction velocity — how many transactions per 15-minute window across each location, going back across the full available history.

The output was a suggested minimum staff count per location per shift slot, broken into three roles: front-of-house, kitchen, and a combined senior role. We didn't try to replace the manager's judgment about who specifically to schedule — that stays human. We gave them the numbers to schedule against.

We also surfaced something nobody had been tracking: shift effectiveness. Revenue-per-staff-hour, per shift, per location. This single metric made it obvious which shifts were chronically overstaffed. Three locations were consistently running 40% more staff hours than the revenue for those shifts justified. This wasn't immediately obvious from raw rotas — you had to normalise against revenue to see it.

The scheduling suggestions were integrated into a lightweight tool the managers could access on their phones. Not a full workforce management platform — a dead-simple interface: "Here's your recommended cover for next week. Adjust if needed." Average time to complete a weekly rota dropped from about 90 minutes to under 20.

Step 5: Location Performance Benchmarking

For the first time, the head office could look at a single view showing all 14 locations ranked by a composite performance score: revenue per sqm, margin percentage, staff efficiency ratio, customer return rate (estimated from loyalty card and transaction frequency data), and review score trend.

The two locations that had been considered "chronic underperformers" told completely different stories in the data.

Location 11 was genuinely underperforming because of its product mix — it had been configured with a different menu by the previous manager and was missing three high-margin items the other locations offered. The fix took two weeks: menu update, staff retraining, two items added to stock ordering. Revenue at that location increased by roughly 24% over the following 8 weeks.

Location 7 had a structural problem: its prime morning window (7–9am) was its lowest-performing time slot, despite being in a high-footfall office area. Investigation revealed the queuing experience was poor — a layout issue that meant the queue spilled onto the pavement and deterred new customers. That required a physical intervention (counter reconfiguration). But the diagnosis took one data review. Previously it had been written off as "just a quiet location."

---

Results at Six Months

The numbers above are real — pulled from the client's own POS and P&L data at the six-month mark.

Food waste fell from ~$41K/month to ~$28K/month. That's $156,000 saved in a year from one change to how they ordered ingredients.

Revenue per location averaged up 19% across the chain. Not from marketing, not from new products, not from a price hike — from putting the right items on the right menus at the right margins and staffing correctly for actual demand.

Labour cost as a percentage of revenue dropped from 38% to 31%. For a business of this size, that's roughly $630,000 in annualised labour cost saved — without any redundancies. This was purely scheduling efficiency.

The two "problem locations" both saw material improvement. One through a simple menu correction. One through a layout change that the data made obvious.

And perhaps the most significant outcome: the management team now runs a weekly data review. Forty minutes, every Monday. They look at the previous week's performance by location, flag anomalies, act on them. Before this system existed, they were making the same decisions in a three-hour monthly meeting where half the time was spent arguing about what the numbers even meant.

"We had the data for years. We just couldn't see it. Now we can, and the company looks different to us."

---

What This Kind of Project Actually Is

This isn't AI replacing anyone. None of the 180 staff were touched. The location managers still manage their locations. The founders still make the strategic calls.

What changed is the quality of information available at every level. The system observes, surfaces, and suggests. Humans decide and act.

For most non-tech businesses, this is the actual opportunity: not AI that does something dramatic, but AI that finally makes visible what the business has always been generating but never been able to use.

The data was always there. It just needed someone to build a system that knew how to listen to it.