Written by: JJ Tan, Founder, Jelly
Key Takeaways
- Inconsistent margins across UK multi-site groups usually come from execution gaps, manual spreadsheets and delayed reports, not flawed menu strategy.
- Contribution margin per dish in pounds, rather than food-cost percentage, gives a clearer picture of true profitability across locations.
- Central recipe locking, automated invoice capture and POS-linked live GP data prevent pricing drift and cut 10–20 hours of weekly admin.
- Quarterly reviews using real-time Jelly dashboards replace slow accountant reports and keep every site within group margin guardrails while preserving local flexibility.
- See how Jelly standardises profitability across 2–5 sites in under a week.
Prerequisites for Rolling Out a Standardised Margin System
Confirm you have the following in place at every site before you start the seven steps.
- Supplier invoices, either via email forwarding or physical copies for photo capture
- Costed or draft recipes for your core menu
- A supported POS system (Square, EPOS Now, Lightspeed or Toast) with admin credentials, which connects directly to Jelly for real-time sales data
- Xero for accounting integration
Why Contribution Margin Creates Consistent Profit Across Sites
Contribution margin per dish, defined as selling price minus direct variable cost, shows the pounds available to cover labour, rent and profit. Food-cost percentage alone can mislead. A dish with a 39% food cost percentage can outperform a 24% dish in real profit terms when its contribution margin in pounds is higher.
Repositioning based on contribution margin rather than food cost percentage can lift category contribution. For a 2–5 site group, applying that discipline consistently across locations, instead of site by site, compounds the benefit.
The outcomes of a standardised system include daily margin visibility, faster supplier negotiations backed by hard data, a significant reduction in weekly admin, and preserved site autonomy within defined guardrails. The seven steps below build that system, starting with the margin targets that every subsequent step will measure against.
Step 1: Set Group Margin Targets and Track Theoretical vs Actual
Objective: Establish a single set of margin targets that every site reports against, and start tracking the gap between expected and actual margins.
Required inputs: Current menu prices, recipe costs and recent P&L data from each site.
Action: Set a group target GP percentage, for example 68–72%, that defines what margins should be. Then set a maximum acceptable theoretical-versus-actual food cost variance to measure how closely each site hits that target in practice. Well-run multi-site operations often target a theoretical-vs-actual variance of 2–3 percentage points. A larger gap can signal stale recipe costs, high spoilage or consistent over-portioning.
Successful output: A shared target document or a Jelly dashboard configuration that shows each site’s GP target, variance threshold and review cadence.
Step 2: Build a Locked Central Recipe Master for Every Site
Objective: Create one authoritative recipe library that every site uses, so spreadsheet drift and ad hoc changes stop eroding margins.
Required inputs: Ingredient lists from scanned invoices, portion weights and any site-specific yield adjustments.
Action: In Jelly’s Cookbook, build each dish by clicking on ingredients already populated from scanned invoices. Jelly handles unit conversions and wastage percentages automatically. What previously took 28 minutes per dish in a spreadsheet takes approximately 3 minutes in Jelly.
Before you move to invoice automation, confirm that your recipe foundation is complete. Incomplete recipes cause invoice line items to remain unmatched and create phantom variance that confuses later reports.
Checklist before moving to Step 3:
- All core menu dishes costed in the central Cookbook
- Portion weights and wastage percentages confirmed per dish
- Delivery menu variants duplicated with commission overhead factored in
- Site-specific ingredient substitutions recorded as deliberate overrides
Successful output: A locked central recipe master where live ingredient prices update dish costs automatically as new invoices arrive.
Step 3: Connect Invoices for Automated Capture and Price Alerts
Objective: Replace manual invoice entry with automated line-item capture across all sites and surface supplier price changes as soon as they occur.
Required inputs: Supplier invoice email addresses or physical invoices for photo capture at each site.
Action: Each site forwards supplier invoices to its dedicated Jelly email address, or staff photograph invoices into the app. Jelly digitises every line item, including quantity, SKU, price and tax, and flags any price movement through the Price Alert feature. Jelly also pushes digitised invoices directly to Xero, which reduces bookkeeping time by about 90%.
Successful output: A real-time Insights Dashboard that shows total spend by supplier across all sites, with instant alerts when any ingredient price rises or falls. Price alerts and invoice automation help operators negotiate with suppliers and protect margins across dine-in and delivery channels.
Step 4: Link POS Systems so Sales Data Feeds Live GP
Objective: Connect each site’s POS so that sales data flows into Jelly automatically and live GP calculations no longer rely on manual exports.
Required inputs: Admin credentials for each site’s POS account, such as Square, EPOS Now, Lightspeed or Toast, which integrate directly with Jelly.
Action: In Jelly, go to Integrations, sign in to the relevant POS, grant permissions and select which categories, such as food and beverages, to sync. The process takes about five minutes per site. After connection, map each POS item to its corresponding Jelly dish. Only items sold since the integration was connected appear for mapping, which keeps the process clean.
Successful output: Item-level sales data flows into Jelly in real time. The Flash Report then calculates GP margin from both cost data from invoices and revenue data from POS at the same time. Connecting a POS removes 2–5 hours of weekly work per site.
Step 5: Build Site Dashboards Using One Shared KPI Framework
Objective: Give each site its own performance view while every site reports against the same KPIs, so group comparison stays meaningful.
Required inputs: At least four weeks of POS sales data per site that covers a representative trading period. Fewer than four weeks risks reacting to noise or distorted windows such as holidays.
Action: Use Jelly’s Sales Mix report to see which dishes are most popular and most profitable at each site. To ensure every site reports against identical performance dimensions, and to make cross-site comparison meaningful and margin drift visible, apply the same five-KPI set group-wide.
- GP percentage per site, shown in the Flash Report
- Contribution margin per dish in pounds
- Theoretical-versus-actual food cost variance
- Price alert response rate, which tracks how quickly the site acted on a supplier price change
- Sales mix shift, which shows which dish categories are growing or declining
Successful output: Each site manager and the central operations team can view the same KPI set, with site-level drill-down available. Menu engineering using a margin-times-popularity matrix, which classifies dishes as star, plow-horse, puzzle or dog, allows high-contribution items to be retained and promoted even when their ingredient cost percentage appears higher.
Step 6: Put Guardrails Around New Dishes and Price Changes
Objective: Allow sites to propose new dishes or local price adjustments while still protecting group margin targets.
Required inputs: Agreed minimum contribution margin thresholds per category and a defined approval chain, such as executive chef, operations manager or finance lead.
Action: Define the floor GP percentage for each menu category. Any new dish or price change proposed at site level must be costed in Jelly’s Cookbook before it goes live. This makes the GP impact visible before the decision is made. Centralised pricing governance sets guardrails such as floor and target prices, approval tiers and margin thresholds, so local teams can adjust for competitive situations within those boundaries.
Successful output: No dish reaches a site menu without a costed recipe in Jelly. Local flexibility remains, and margin erosion from uncosted specials disappears.
Step 7: Run Quarterly Margin Reviews Using Live Jelly Data
Objective: Embed a repeatable review cycle that relies on live Jelly data instead of retrospective accountant reports.
Required inputs: Jelly Flash Reports, Price Alert history and Sales Mix data for the preceding quarter at each site.
Action: Each quarter, review the following across all sites, starting with overall margin performance and then drilling into the operational drivers.
- GP percentage trend per site versus group target, which shows whether margins are holding
- Theoretical-versus-actual variance per site, and investigation of any site above 2 percentage points, which reveals execution gaps even when overall GP looks acceptable
- Top price alerts actioned and credits recovered from suppliers, confirming that cost increases were either negotiated down or passed through to pricing
- Sales mix shifts and any dishes reclassified from star to plow-horse or dog
- Recipe costs refreshed to reflect current invoice prices
Successful output: A documented quarterly review that replaces the delayed monthly accountant report as the primary profitability governance tool. A weekly stock count on the same day each week, combined with current costed recipes, allows operators to catch and act on widening variance while there is still time in the period to correct it, unlike monthly counting which delays insight by about four weeks.
Walk through this quarterly review cycle with your group’s data to see how it works in practice.
Troubleshooting Margin and Data Issues Across Sites
Missing invoice data at one site: Check whether the site is forwarding invoices to its dedicated Jelly email address or photographing them promptly. Assign a named team member per site as the invoice owner. Jelly flags gaps in supplier data automatically.
Inconsistent recipe units across sites: Return to the central Cookbook and standardise units at the recipe level. Jelly handles unit conversion automatically once the base unit is set. The issue usually comes from a legacy spreadsheet unit that carried over during setup.
Regional price differences distorting group variance: Multi-location operations are more exposed to data integrity failures because purchasing is often centralised while receiving occurs at location level, which causes variance to appear selectively at some sites but not others. Run variance reports at site level instead of as a blended group figure. Record deliberate regional price overrides in Jelly so they stay visible and reviewable rather than silent.
A supplier renames an SKU: A supplier catalogue update that renamed an SKU caused recipe components to become unmatched, creating a phantom variance that compounded for three weeks in a four-location group. When Jelly flags an unmatched ingredient after a new invoice, remap it to the correct recipe component immediately.
Success Metrics and Advanced Multi-Site Tips
Once the seven steps are running, a 2–5 site group can track clear, measurable outcomes that show whether the system is working.
- 10–20 hours of weekly admin eliminated through invoice automation and faster recipe costing
- GP percentage improvement of about 2 percentage points within the first three months
- Food cost reduction of about 3% in the first three months
- Faster supplier negotiations backed by Price Alert data rather than estimates
- Theoretical-versus-actual variance brought within the 2-percentage-point target at each site
For groups scaling to a new site, onboard the new location into the existing Jelly Cookbook and invoice workflow from day one. The central recipe master and KPI set transfer immediately, so the new site inherits group standards rather than building from scratch. For delivery menus, duplicate existing dishes in Jelly and factor in the delivery commission overhead to create a separate, accurately costed delivery menu. This is the method Sushi Revolution uses to set separate target gross profits on dine-in and delivery menus, accounting for 30% delivery commissions.
Frequently Asked Questions
Who owns the central recipe master?
Ownership typically sits with the executive chef or head of operations, with view access granted to site managers and finance leads. In Jelly, management has direct access to the platform and can see live dish costs and GP margins without relying on the kitchen team to report them. This removes friction between operations and finance that arises when margin data depends on manual chef input.
How long does a full rollout take across 2–5 sites?
The onboarding described in the seven steps above typically completes within the first week. Suppliers begin sending invoices to a dedicated Jelly email address, or staff photograph invoices into the app within 24 hours. POS connections take about five minutes per site. Building the full central recipe Cookbook for a core menu of 30–50 dishes usually takes a few hours rather than days because ingredient data is already populated from scanned invoices.
What happens when a supplier changes a price?
Jelly’s Price Alert feature flags every price increase or decrease as soon as a new invoice is processed, showing which ingredient changed, by how much and from which supplier. Dish costs and GP margins update automatically in real time. This gives chefs and operations managers the concrete evidence they need to contact a supplier, negotiate better rates or request a credit note, instead of discovering margin erosion weeks later in an accountant’s report.
How do we handle regional price differences between sites?
The recommended approach is to set group-wide contribution margin targets as the standard, then record any deliberate regional price overrides explicitly in Jelly rather than allowing them to drift silently. Running variance reports at site level, instead of as a blended group figure, surfaces which sites are genuinely paying more for an ingredient and whether that difference is justified by local supplier relationships or market conditions. Intentional local variation is manageable, while unrecorded variation is where margin erosion compounds.
Does Jelly work if our sites use different POS systems?
Yes. Jelly integrates natively with Square, EPOS Now, Lightspeed and Toast via real-time API, so if different sites in your group use different supported POS systems, each site connects independently through the same five-minute setup flow. The item-level sales data from each POS feeds into the same Jelly KPI framework, so group-level GP dashboards remain consistent regardless of which POS each site runs. These integration partners complement Jelly by providing the sales data that powers accurate, real-time margin tracking.
Conclusion: A Repeatable System for Multi-Site Menu Profitability
Inconsistent margins across 2–5 sites are not inevitable. They usually come from manual processes, delayed data and the absence of a shared execution framework. The seven steps above replace that fragility with a repeatable system that combines central recipe locking, automated invoice capture, POS-linked live margins and quarterly reviews grounded in real data.
This system does not remove local flexibility. It makes local variation deliberate and visible, so every site operates within group margin guardrails while keeping the autonomy to respond to its own market.
Jelly acts as the automation layer that connects invoices, recipes, POS data and GP dashboards in one platform at £129 per site per month, with a one-week onboarding.
Book a demo and see how Jelly can standardise menu profitability across your sites within a week.