Back of House: Complete Guide for Restaurant Operators

What Back of House Actually Means

Back of house refers to every part of a restaurant that guests do not see: the kitchen, storage areas, receiving docks, staff facilities, and the offices where ordering, invoicing, and reporting happen. The BOH team typically includes head chefs, sous chefs, prep cooks, line cooks, dishwashers, stock room staff, and receiving managers.

For job seekers and HR teams, the BOH vs front of house (FOH) distinction is mainly about roles. For operators managing multiple sites, back of house means something more specific: it is the part of the business where food cost is made or lost, where supplier relationships are managed, where waste accumulates silently, and where operational data either flows cleanly or does not flow at all.

The distinction matters because most BOH technology, and most BOH guides, are written for single-site operators. The challenges facing a 10-location restaurant group - consistent recipe standards, centralised purchasing, multi-site stock visibility, group-level financial reporting - are an order of magnitude more complex than those at one venue.

The BOH Control Loop: Six Stages That Must Connect

Back of house operations are not a collection of independent tasks. They are a loop. Each stage depends on the accuracy of the stage before it. One weak link corrupts everything downstream.

1. Procurement - Raising and approving purchase orders to approved suppliers at agreed prices. In a multi-site group, this means centralised purchasing controls so individual locations cannot order outside approved supplier lists, and so quantity variance across sites is visible before it becomes a cost problem.

2. Receiving - Matching physical deliveries against purchase orders and invoices. This is where discrepancies are caught or missed. A receiving process that requires desktop access for exception handling will fail in practice - kitchen staff receiving on a mobile cannot resolve invoice queries that require admin privileges. One UK hospitality group with four venues identified this exact failure mode: when invoices were flagged as needing more information, store-level staff could not action them without a laptop, creating a bottleneck that undermined the entire receiving process.

3. Inventory - Tracking actual stock levels across each location, against theoretical levels derived from recipes and sales data. Stock counts are the mechanism by which operators verify that what should be in the kitchen is actually there. When stock data is not trusted, operators run manual parallel processes - double the labour, none of the benefit.

4. Production - The conversion of raw ingredients into finished dishes, tracked through recipe-linked production events. Production tracking connects stock movements to recipe usage, which is how theoretical food cost is calculated.

5. Costing - Calculating actual food cost against theoretical food cost, by dish, by category, and by location. Recipe costing is the financial backbone of BOH management. When recipe costs fail to update automatically - because of supplier price changes or recipe modifications - the costing data becomes unreliable. A Melbourne multi-concept hospitality group found that when their recipe cost auto-update failed, approximately 70% of their recipes showed incorrect costs, which in turn corrupted their stock take values.

6. Reporting - Aggregating BOH data into group-level operational and financial insight: food cost percentage by location, actual versus theoretical variance, wastage by category, and GP% by menu section.

Where BOH Operations Break at Scale

Most single-site BOH processes do not translate to multi-site groups without structural rethinking. These are the failure modes that appear most consistently.

Inconsistent receiving across locations. At one site, a competent receiving manager can catch short deliveries, substitutions, and price discrepancies. Across ten sites, the same process requires standardised workflows, mobile-first interfaces, and exception escalation that does not create bottlenecks. If receiving confirmation requires desktop access or admin-level permissions for any step, the process will be bypassed in practice.

Parallel manual systems. When operators do not trust the data in their BOH software - because stock counts are inaccurate, or recipe costs are outdated, or purchase orders are not matched to invoices reliably - they keep a parallel manual process running. A growing multi-site group that had invested in BOH software reported their team had stopped using it for stock counts and returned to their existing manual process because the system had increased rather than reduced their workload.

Fragmented BOH views. Multi-site groups need filtered visibility at every level: location managers need to see their own site's stock and costs; group operations managers need to see across all sites; the central kitchen needs to track production and transfers separately from branch inventory. One UK enterprise group specifically flagged this for wastage: different BOH staff at each location needed filtered waste lists, not one global list that every site had to manage.

No group-level aggregation. BOH data that exists at the location level but cannot be aggregated into group-level insight has limited operational value. A Hong Kong bakehouse and central kitchen operator identified two connected gaps: their central kitchen had no revenue visibility against its own COGS, and there was no way to run bulk stock count creation across all branches simultaneously.

Managing a Central Kitchen as Part of BOH

For restaurant groups operating a central kitchen (CK), BOH complexity increases significantly. The CK functions simultaneously as a production facility, an internal supplier to branches, and a cost centre that needs its own financial reporting.

A well-functioning central kitchen BOH operation requires recipe cost cascades so that CK-produced items carry the correct transfer cost into branch recipe costings; formal requisition and transfer workflows so stock movements are recorded rather than managed informally; and CK-level financial reporting so operators can see the CK's actual production costs versus theoretical targets.

A GCC multi-concept restaurant group described their required transfer flow explicitly: Central Store / CK to Transfer / Requisition Raised to Approved UOM Displayed Only to Branch Receipt to Stock Movement Recorded by Location to Inventory Updated. Every step in that chain must be handled in the system, not on WhatsApp.

The Role of Technology in BOH Management

BOH technology ranges from basic point-of-sale systems with inventory add-ons to purpose-built back-of-house platforms covering the full procurement-to-reporting stack. The capabilities that separate purpose-built hospitality BOH platforms from generic inventory software include:

• Supplier catalogue management - approved supplier lists, agreed pricing, and unit of measure standardisation per location
• Mobile receiving with offline capability - receiving that works on a phone without requiring admin access for exceptions
• Recipe-linked inventory - stock counts that draw directly from recipe structures so theoretical usage can be calculated from actual sales
• Multi-site stock count management - the ability to create, assign, and complete stock counts across all locations simultaneously
• Expiry and wastage tracking - logging of waste by category, quantity, and root cause with near-expiry visibility
• Group-level reporting - dashboards that aggregate food cost percentage, GP% by category, and actual versus theoretical variance across all locations

Supy's inventory management platform is built specifically for multi-location restaurant groups, covering the full BOH stack from purchase orders and receiving through to recipe costing and group-level financial reporting. For operators ready to connect the BOH control loop across their group, book a demo with Supy.

Building a BOH Management System That Scales

The operators who manage BOH effectively across multiple sites have three things in common: they trust their data, they have visibility across the group, and they have standardised the processes at each location so that group-level aggregation is meaningful.

Getting there requires more than software. It requires a clear decision about what the BOH control loop looks like for your specific operation - how purchasing is centralised, how receiving is standardised, how stock counts are structured, and how recipe costing connects to production. Software can enforce and automate those standards once they are defined, but it cannot substitute for the operational thinking.

The starting point for most groups is identifying where the current loop breaks. Is it in receiving - where exceptions fall out of the digital process? In inventory - where stock count data is not trusted? In costing - where recipe costs are not kept current? Or in reporting - where location-level data cannot be aggregated meaningfully across the group?

Fix the weakest link first. A reliable BOH operation is built from the ground up, one stage at a time, until the full control loop is running without manual workarounds. That is when BOH technology stops being an overhead and starts being the most valuable operational asset a multi-site restaurant group has.