Odoo for restaurant and QSR chains where the product melts, spoils, and gets remade daily.

Why Restaurant Operations Aren't Just Retail POS

It is tempting to treat a restaurant chain as a variant of the retail POS problem already well covered in Odoo POS for Bangladesh Retail Chains, and a meaningful part of the setup genuinely is shared: multi-outlet stock locations, offline-capable POS, session reconciliation. But a restaurant sells a manufactured product assembled fresh per order from perishable ingredients, not a pre-packaged SKU picked off a shelf, and that difference cascades into requirements retail POS never has to solve: a menu item's true cost changes as ingredient prices move, an order needs to be routed to the correct kitchen station and prepared correctly before it can be "sold" in any meaningful sense, and a meaningful share of revenue for many Bangladesh chains now arrives through a delivery aggregator's own tablet, entirely outside the POS.

Bangladesh's QSR and casual dining sector has grown quickly across both home-grown chains and international franchises, typically operating 5 to 40 branches concentrated in Dhaka, Chattogram, and increasingly divisional cities, and the operational maturity gap between a single restaurant and a chain running a shared menu, shared costing, and a central kitchen across a dozen locations is exactly where a properly configured Odoo build earns its cost.

Recipe-Based Costing with BOMs

The single most valuable and most commonly skipped configuration in a Bangladesh restaurant Odoo build is recipe-based costing using the Manufacturing module's Bill of Materials, the same underlying mechanism a factory uses to define a production recipe, applied here to a plate rather than a manufactured product. Each menu item is set up under Manufacturing > Products > Bills of Materials with every ingredient and its exact quantity per serving listed as a component line, a chicken burger's BOM including its specific gram weight of chicken, bun, sauce, and garnish, priced against each ingredient's current purchase cost.

The payoff is that food cost percentage, the ingredient cost of a menu item as a percentage of its selling price, recalculates automatically whenever ingredient purchase prices change, rather than sitting static from whatever costing exercise was last done, often months earlier. Bangladesh restaurant chains face genuinely volatile input costs, chicken, cooking oil, and seasonal vegetable prices move meaningfully within a single quarter, and a chain pricing its menu based on a stale cost assumption can be running several points of margin worse than management believes without any single number in the system flagging it. A live, BOM-driven food cost view, refreshed under Manufacturing > Reporting > Cost Structure, turns this from an annual surprise into an ongoing, monitored metric.

Kitchen Display and Order Routing

Odoo POS includes a Kitchen Display (Preparation Display) capability that routes an order, or specific line items within an order, directly to a screen at the relevant kitchen station, grill, fry station, cold prep, beverages, configured under Point of Sale > Configuration > Point of Sale by assigning preparation categories to product types. Kitchen staff mark each item in-progress and ready directly on the station screen, and that status is visible back at the counter or to delivery packing staff in real time, which meaningfully reduces the two classic failure modes of the paper kitchen order ticket (KOT) system still common in Bangladesh restaurants: a ticket physically lost during a peak rush, and a front-counter staff member with no reliable way to know an order's actual prep status without walking back to the kitchen to ask.

For chains with multiple prep stations per branch, correctly mapping product categories to the right station screen is the configuration detail that determines whether this actually speeds up service or just digitizes the same confusion: a burger's bun toasting, patty grilling, and sauce assembly may need to route to different physical stations within the same kitchen, and getting that routing wrong at setup creates exactly the kind of cross-station confusion the KDS was meant to eliminate.

Kitchen Station	KDS Routing Basis	Common Bangladesh QSR Example
Grill/Fry	Product category tag	Burger patties, fried chicken, fries
Cold prep	Product category tag	Salads, sandwich assembly, cold sides
Beverages	Product category tag	Soft drinks, shakes, hot beverages
Packing/Dispatch	Order-complete trigger	Final assembly for dine-in tray or delivery bag

Multi-Branch Central Kitchen Models

A meaningful share of Bangladesh QSR chains beyond a handful of branches run a central kitchen or commissary model: a single facility prepares semi-finished components, marinated chicken, pre-made sauces, portioned dough, par-cooked items, in bulk, then distributes them to individual branches, where branch kitchens complete final cooking and assembly. This is genuinely a manufacturing and logistics flow, not just a recipe, and modeling it correctly in Odoo requires treating the central kitchen as its own stock location running its own manufacturing orders (converting raw ingredients into semi-finished goods under a first-stage BOM), followed by internal stock transfers moving those semi-finished items from the central kitchen location to each branch's stock location.

At the branch, the final menu item's BOM then consumes the received semi-finished component alongside any branch-added fresh ingredients, giving the chain a two-stage costing view: central kitchen production cost and efficiency, and each branch's final assembly cost and consumption accuracy against what it was allocated. This structure also surfaces a genuinely useful operational signal that paper-based commissary systems rarely catch cleanly: a branch consistently consuming more semi-finished stock than its recorded sales volume justifies, which often points to portion control drift, waste, or in some cases inventory leakage at that specific branch.

The Delivery Aggregator Reality

Foodpanda and Pathao Food are now a significant revenue channel for Bangladesh restaurant chains in Dhaka and Chattogram, commonly 20 to 40 percent of total order volume for urban QSR brands, and it needs to be said plainly rather than glossed over in a sales pitch: there is no seamless, officially certified native integration between these aggregators and Odoo POS. Orders arrive on the aggregator's own tablet or portal at the restaurant, a completely separate system from whatever is running the in-store POS, and no standard connector keeps them automatically synced into Odoo's sales and inventory records.

The realistic operational patterns Bangladesh chains actually run, and that an honest implementation plan should present as options rather than hide: manual re-entry of aggregator orders into Odoo POS as a distinct payment method or sales channel, which preserves accurate inventory depletion and sales reporting at the cost of staff time during a busy delivery period; or a custom, unofficial integration built against whatever API access the aggregator currently exposes, which can automate the sync but requires ongoing maintenance since aggregator platform APIs change without much advance notice to integration partners, and a chain relying on a custom integration needs a support relationship in place that can react when it breaks, not treat it as a one-time build. Chains under-resourcing this reconciliation step commonly end up with an inventory system that looks accurate for in-store and phone orders but silently drifts on aggregator volume, since aggregator sales are consuming real ingredient stock that never gets recorded as a proper Odoo sale.

Wastage and Portion Control

Perishable ingredient wastage, spoilage, over-preparation, and portion inconsistency between shifts is a persistent margin leak in restaurant operations that a BOM-driven costing system, on its own, only partially addresses: the BOM tells you what a menu item should cost if made exactly to recipe, not what actually happened on the floor. Odoo's inventory adjustment and scrap functionality under Inventory > Operations > Scrap, used disciplined and recorded daily rather than only during periodic stock counts, gives a chain a documented wastage trail by branch and by ingredient, which is the only way to distinguish genuine unavoidable spoilage from a portion control problem at a specific branch or shift.

Comparing actual ingredient consumption (drawn from BOM-driven theoretical usage against sales volume) to actual purchased and received stock at each branch, a variance report achievable once BOMs and inventory transactions are both properly maintained, is one of the highest-value recurring reports a multi-branch chain can run, and it is functionally impossible to produce reliably without the underlying recipe costing and inventory discipline this section and the recipe costing section above both depend on.

Shift Staffing and Tips

Restaurant and QSR staffing runs on rotating shifts with a meaningfully different pay structure than office HR: hourly or shift-based wages for counter and kitchen staff, service charge or tip pooling arrangements common in casual dining formats, and high staff turnover that makes fast onboarding of new POS users a recurring, not one-time, operational need. Odoo's Employee and Payroll setup, covered in general terms in Odoo HR & Payroll Bangladesh, needs to be configured for shift-based schedules and, where the chain runs a service charge pooling model, a defined distribution rule calculated from POS service charge collection and disbursed through payroll, rather than handled as an informal cash split at shift end that leaves no auditable record.

Reporting That Actually Drives Margin

Beyond individual branch sales, the reports that actually move a restaurant chain's profitability are: food cost percentage by menu item and by branch (since the same item can show different actual cost at different branches due to portion drift or local ingredient sourcing differences), sales mix trend (which items are gaining or losing share of total orders, directly informing menu engineering decisions), central kitchen consumption variance by branch, and channel mix between dine-in, takeaway, and aggregator delivery, since each channel carries a different effective margin once commission and packaging costs are accounted for. The KPI dashboard approach in Odoo Dashboards & KPI Bangladesh applies directly to building a single operations screen combining these views for a multi-branch chain's leadership team.

Menu Engineering with Real Cost Data

Once recipe BOMs and sales mix reporting are both live, a chain gains the ability to do genuine menu engineering, classifying each menu item by its combination of sales volume and profit margin, rather than deciding what to promote or discontinue based on gut feel or which items a franchise owner personally prefers. The classic framework sorts items into four groups: high volume and high margin (promote these aggressively), high volume but low margin (candidates for a modest price increase or a recipe cost reduction), low volume but high margin (worth a marketing push since the item is profitable but underexposed), and low volume with low margin (usually the first candidates for menu removal, since they consume kitchen complexity and inventory carrying cost disproportionate to what they contribute).

Building this analysis directly from Odoo's sales and BOM cost data, rather than a separate manually maintained spreadsheet that inevitably falls out of sync with actual current ingredient costs, is what turns menu engineering from an annual consultant-led exercise into a quarterly or even monthly internal review a chain's own management can run. For a chain with several branches showing different local sales mixes, this same analysis run per branch can also reveal genuinely different local preferences worth reflecting in branch-specific menu boards, rather than assuming one national menu mix fits every location equally.

Rolling It Out Branch by Branch

A realistic rollout sequence for a Bangladesh restaurant or QSR chain moving from disconnected billing software or a single flagship location:

• Pilot at the flagship or head-office-adjacent branch first, building out recipe BOMs for the top menu items and testing the KDS routing under a real peak-hour rush before rolling to other branches.
• Stand up the central kitchen flow before scaling to more than a handful of branches, since retrofitting a commissary structure after several branches are already running independent local prep is significantly more disruptive.
• Decide the aggregator handling approach explicitly before go-live, manual re-entry or a custom integration, rather than discovering the gap after launch when staff are already improvising a workaround.
• Roll BOM costing out to the full menu progressively, prioritizing by sales volume, rather than delaying go-live until every menu item (including rarely ordered ones) has a complete recipe cost.
• Introduce wastage tracking discipline from day one at each new branch, since retraining kitchen staff into a scrap-recording habit after go-live is markedly harder than establishing it during initial training.

Frequently asked questions

How does recipe-based costing work in Odoo for a restaurant?

Each menu item is modeled as a Bill of Materials (BOM) in Odoo's Manufacturing module, the same mechanism used for a factory's production BOM but applied to a recipe: the BOM lists every ingredient and its exact quantity per plate or per serving. When ingredient purchase prices change, which happens often in Bangladesh given vegetable, poultry, and cooking oil price volatility, the BOM's calculated cost updates and the menu item's actual food cost percentage recalculates automatically. This lets a restaurant chain see current food cost percentage per menu item at any time, rather than relying on an annual or occasional manual recipe costing exercise that goes stale within weeks of ingredient prices moving.

Does Odoo have a kitchen display system (KDS) for restaurants?

Yes. Odoo POS includes a Kitchen Display / Preparation Display feature that routes orders from the POS terminal directly to a screen at the relevant kitchen station (grill, fry, cold prep, drinks), configured under Point of Sale > Configuration > Point of Sale with preparation printers or screens assigned by product category. Kitchen staff mark items as in-progress or ready directly on the display, which the front counter or delivery staff see in real time, replacing the handwritten kitchen order ticket (KOT) system many Bangladesh restaurants still run, and reducing the specific error pattern where a paper ticket gets lost or misread during a peak rush.

How do multi-branch QSR chains handle a central kitchen in Odoo?

A central kitchen or commissary model, where semi-finished items (marinated proteins, pre-made sauces, portioned dough) are prepared centrally and distributed to branches for final cooking and assembly, is modeled in Odoo as a two-stage manufacturing and inter-location transfer flow: the central kitchen location runs its own manufacturing orders converting raw ingredients into semi-finished goods, which are then moved via internal transfer to each branch's stock location, where the branch's own recipe BOM consumes the semi-finished item alongside branch-added ingredients to produce the final menu item. This gives the chain visibility into central kitchen output, transfer timing, and each branch's actual consumption against its allocated semi-finished stock.

Can Odoo integrate directly with Foodpanda or Pathao Food?

Not natively as a certified, seamless integration. Foodpanda and Pathao Food orders arrive on their own tablet or portal at the restaurant, separate from the Odoo POS, and there is no standard, officially supported connector syncing them automatically into Odoo. Practically, most Bangladesh restaurant chains handle this by manually re-entering aggregator orders into Odoo POS as a distinct payment method/sales channel for reconciliation purposes, or by building a custom, unofficial integration against the aggregator's available API or a middleware connector where one exists, which requires ongoing maintenance since aggregator APIs change without much notice. Being upfront about this gap during planning avoids a chain being surprised post-implementation that aggregator orders still require manual handling.

What does an Odoo implementation cost for a Bangladesh restaurant or QSR chain?

For a QSR or restaurant chain with 5 to 20 branches, an Odoo implementation covering POS, kitchen display, recipe costing, and central kitchen inventory typically runs BDT 8 to 18 lakh, with BDT 3 to 8 lakh per year for support, plus hardware (POS terminals, kitchen display screens, printers) at roughly BDT 30,000 to 70,000 per branch depending on kitchen station count and screen quality. Chains wanting a custom delivery-aggregator reconciliation integration should budget separately for that development, since it sits outside standard Odoo licensing and implementation scope.