Founder POV: Where Margin Leaks in Hospitality Operations
A practical field guide to the operational layers where hospitality margin is either protected or lost.
Founder, Hops
This article is adapted from a LinkedIn post by Robbie Francis, Founder of Hops.
A field guide for multi-site hospitality operators who are tired of being told they have a margin problem without being shown exactly where it lives.
The 8 Layers between Supplier and Stock
If you're running a multi-site restaurant group or hospitality operation, you've sat in a review meeting and stared at a gross profit number that doesn't make sense.
You've ordered the right things
I've spent over 20 years in hospitality operations. I've worked with hundreds of operators: from single-site independents to 50-site groups, Michelin-starred restaurants to QSR chains, hotels to food halls. I've founded two technology businesses in this space.
And the single most consistent thing I see: operations who know they have a margin problem, but have never been shown exactly where it lives.
This article is my attempt to fix that.
In Hops, we call the procurement and supply chain layer of your operation
Source covers the full journey from your first supplier relationship to the moment stock is officially in your system and feeding your actual GP. Within that journey, there are 8 distinct places where margin either gets controlled or spirals.
Most restaurant management systems treat each step as an isolated feature: a purchasing module here, an inventory module there. What they miss is that Source is a connected operational flow. A breakdown at step 1 compounds by the time you reach step 8.
Throughout, you’ll see me
Also known as: Approval workflows, purchase approval, spend controls
The misconception is that authorisations are about approvals, but they're really about context.
A sous chef can't place orders because they haven't done 50 Friday nights yet. They don't know that on a Friday you're doing 300 covers, or that a particular supplier cuts off at 3pm. They don't have the operational knowledge to order correctly yet, and so authorisations are the mechanism that protects your margin until they do.
Most multi-site operators authorise payments, not orders.
By the time an invoice lands in accounts and someone hits approve, the goods have already arrived and been used.
And if someone ordered 1,000kg of peppers instead of 100? You're still paying. Your COGS just went up, and nobody caught it before it happened.
Authorising payments is hygiene. The only real lever to control food spend is pre-procurement.
In Hops, every user has an authorisation level set against their account. Unlike most platforms that offer a handful of fixed approval tiers, Hops lets you define as many levels as your business needs (from fully restricted right through to unlimited), giving you complete flexibility to mirror your actual management structure.
Plus, escalation is dynamic. If an approver doesn't action an order within the defined timeframe, the system automatically escalates to the next available person in the department.
Nobody in the department? It goes to site level.
Approvals can be actioned via the Hops app or a deep link email: no login required, done in 60 seconds from anywhere.
The guard rails grow with your team:
A sous chef might start at a £300 limit
Those limits increase as trust and experience grow.
The only lever you can pull to control food costs is before the order goes out.
Also known as: Purchase orders, ordering module, procurement
Restaurant procurement is never a neat process. You've got your WhatsApp mushroom supplier, your national drinks wholesaler portal, your dry goods email, your central kitchen PDF. Across your supplier estate, you're constantly adapting to their systems, not the other way around.
In Hops, we separate two types of ordering:
Supplier POs
Ordering without context is guessing, and guessing drives ordering mistakes.
If your team can't see current stock levels, typical weekly usage, when items were last counted and price per gram across every supplier at the point of ordering, they're making decisions blind. That's how you end up with 3 weeks of oil in the storeroom, an inflated COGS and a GP variance you can't explain.
We call this
We're also building the full ordering hierarchy:
Predictive sales → order by ingredient → shopping list → supplier PO.
And the rule applies before any order is placed: if it comes through the back door, it must exist digitally.
Ordering without context is just guessing.
Also known as: Vendor management, supplier database, supplier master
Across a multi-site operation, you might have 30, 40, 50 supplier relationships, each with their own cut-off times, delivery schedules, minimum orders, credit terms and contact hierarchies. Centralised supplier management means all of that lives in one place, visible to anyone who needs it, across every site.
Without a centralised view of spend across your supplier estate, you have zero leverage in price negotiations. No visibility means supplier price changes slip through unnoticed, eroding your food cost percentage week after week.
The fragmentation has a daily cost most operators don't notice until it compounds:
Chefs juggling supplier info across WhatsApp and spreadsheets
In Hops, you can see cut-off times, delivery schedules, order minimums, compliance documents and full contact hierarchies. When a delivery goes wrong, you're not hunting for a number: it's there.
When you can see consolidated spend by supplier, by site, by ingredient across your entire estate, you have the cold hard facts to push back on supplier price changes and negotiate better terms.
If you can't see it, you can't manage it.
Also known as: Product catalogue, item master, stock items
There are 2 distinct concepts that most inventory management systems collapse into one:
How you buy it
A Supplier Product is what you order from a specific supplier. An Inventory Item is what you use in recipes and count during stock takes.
You might buy oil in 25L drums, use it in millilitres and count it in 2L decanted bottles. Your system needs to handle all 3 independently.
When supplier products are plugged directly into recipes (the shortcut most procurement systems take), you create a problem that looks clean on day 1 and becomes expensive 6 months later.
Switch suppliers? That supplier product now sits inside 40 recipes. So chefs don't switch, even when a better price exists elsewhere, because nobody wants to spend 16 hours reworking the system. And so you keep paying more than you need to, indefinitely.
Multi-site group buying carrots from 3 different suppliers? You've got 3 versions of the same ingredient, each with different pricing, each touching different parts of your recipe library. Your theoretical GP becomes meaningless.
In Hops:
You order a
Changing supplier is a single click: set the new supplier product as default, and Hops instantly recalculates the GP of every dish that ingredient touches. 3 suppliers all selling carrots? They all feed into 1 Inventory Item: Carrots. Multi-site groups can source locally while maintaining one global recipe.
The source might change. The ingredient shouldn't.
Also known as: Goods receipt, GRN, delivery confirmation, goods in
In most hospitality operations and most restaurant management systems, a delivery is a single event. Stock turns up, someone logs it, it goes into the system. Done.
That single-step approach is where hundreds of thousands of pounds disappear every year.
Between 2-4% of all food and beverage deliveries have something wrong with them: shortages, substitutions, wrong quantities, damaged goods, incorrect pricing.
For a £10M operator, 3% of supplier spend is £300,000 a year, leaking silently because most operations log a delivery and move on without separating what arrived from what they're being charged.
There's also the specific risk of
In Hops, we split deliveries into two deliberate stages:
Arrived
Most platforms treat these as one action. We treat them as two, because they are two completely different questions.
Arrived answers: did the right quantity turn up?
If your supplier promised £10/kg and the invoice says £12/kg, Processed Into Stock is where you catch it, before finance pays it.
In Hops, manual deliveries are restricted to specific users and every one generates a fully auditable Goods Received Note.
The separation also creates accountability. Goods-in confirms what arrived. A GM reviews the pricing and closes it into stock. Different responsibilities, different access levels, two distinct moments.
Confirming it arrived and confirming the price are two different jobs.
Also known as: Stock valuation, ingredient costing, average cost
Most systems value stock at the last delivered price. If your supplier throws in a free case of Coke, your stock valuation is suddenly wrong: the last price was £0, which makes your cost of goods sold meaningless.
Average weighted cost takes into account the volume and price of everything bought within the period. If you bought 100 cases of Coke at £1 each, and then received 1 free case on top, the weighted cost correctly calculates your true cost per unit across all 101 cases. That's the number that accurately reflects what you actually paid.
Using last delivered price or simple average cost creates inaccurate stock valuations that ripple through your GP reporting. 2 sites buying the same ingredient at different prices, London paying more than Manchester for example, will show different GP percentages for the same recipe. Without accurate weighted cost, you can't tell whether that variance is a buying problem, a waste problem or a recipe vs actual variance.
In Hops, average weighted cost is calculated automatically at the point of processing a delivery into stock, taking into account every purchase within the stock period, weighted by volume. This gives you an accurate cost of goods sold per ingredient, per department, per site. Finance gets clean numbers. Operations gets a true picture of where GP is actually going.
The cost that matters is what you actually paid, across everything you bought.
Also known as: Returns processing, supplier credits, purchase adjustments
A credit note is the formal record of a discrepancy between what you ordered, what arrived and what you were charged. In hospitality, they're generated when a delivery is short, damaged, substituted or incorrectly priced...and they represent the mechanism by which you claim back money from a supplier.
Most operators know what a credit note is. Far fewer have a consistent process for creating, tracking and chasing them. They get raised verbally, scribbled on a delivery note or logged in a spreadsheet that nobody looks at. By the time month end arrives, half of them have been forgotten.
Credit notes that aren't chased recover nothing. The operators who protect their gross margin are the ones who close the loop the same day, because the longer a delivery discrepancy sits unresolved, the less likely it is to ever be recovered.
This is where the 2-4% delivery discrepancy figure becomes real money. The identification happened at Arrived. Tightening procurement discipline here is where the leakage actually stops.
When a delivery is wrong (short, damaged, substituted or incorrectly priced), operators choose one of 4 paths:
Keep order open
We keep it to 4 options deliberately: more than that and decision paralysis sets in.
Hops automates the full loop: creates the credit note, emails the supplier to claim it and pushes it directly to your accounting platform so finance has full visibility.Credit notes are fully auditable and traceable: tied to the original purchase order, flagged against the relevant supplier contact and visible across your procurement reporting. Nothing gets swallowed into your COGS unchallenged.
Identifying the delivery discrepancy is only half the job.
Also known as: Approval management, workflow automation
Every layer above only works if the right people are approving the right things at the right time. Your procurement structure is only as good as the people who can act on it, and in hospitality operations, decisions don't wait for office hours.
If approvals are sitting in someone's inbox because they're on the floor or away from their desk, one of two things happens: orders get delayed and miss supplier cut-off times, or they get waved through without proper review. Both create stock variances and ordering mistakes that show up in your GP weeks later.
Dynamic escalation means nothing gets stuck. Purchase order approvals happen via push notification or a deep link email: no login required, reviewed and actioned in 60 seconds wherever you are.
The structure scales with your team: clear approval hierarchy, limits that grow with experience, guard rails that come off as they're earned.
Structure is how operational maturity gets built.
0.5% here
Stack every layer of
The exact figure will be different for every operation...But the layers are the same. And every one of them is fixable.
I started writing this series because I kept having the same conversation with talented operators who had been sold hospitality technology that didn't understand how their operation worked and forced them into rigid procurement workflows.
My mission with this content, and with Hops, is simple: to give hospitality operators the knowledge and the tools to actually control their margin and run a profitable operation.
If you want to go deeper on any of the concepts in this article, everything is covered in the
And if you're running a multi-site hospitality operation and any of this resonated,
— Robbie Francis, Founder & CTO, Hops®
At Hops, we're architecting an agile, flexible platform that breaks the industry mold - we adapt to how operators actually work, not force them into rigid systems. Our platform seamlessly connects purchasing, inventory management, financial control and accounting into one intelligent ecosystem.
About Robbie Francis
Robbie Francis is the Founder of Hops. He has spent years building and implementing hospitality technology with operators, focused on simplifying back-of-house operations across inventory and finance.
Follow Robbie on LinkedIn: linkedin.com/in/robbiefrancis
Tags
Mentions