Restaurant Operations Management Application

The problem

A restaurant group's real numbers live in the gap between the menu and the ledger. You sell a dish; you consume flour, chicken, oil, packaging and gas. Zoho Books can tell you what you spent and what you banked, and Zoho Inventory can tell you what you purchased — but neither knows that one portion of biryani consumes 180 grams of rice and 220 grams of chicken, so neither can tell you your food cost percentage this week, which dish lost money after the last supplier price rise, or how much of your variance is theft versus wastage versus over-portioning.

The problem compounds with scale. A central kitchen produces sauces and semi-finished items and issues them to outlets, so the same ingredient is consumed twice in two places at two different valuations. Delivery aggregators pay out net of commission, promotions they funded, cancellations and adjustments — so the payout that lands in the bank never equals the order value, and someone spends a day each month working out whether the difference is legitimate. Outlets close their day with a cash count that has to reconcile against sales, card settlements and aggregator receivables.

None of this is modelled in the core suite, so it ends up in spreadsheets that are rebuilt monthly and trusted by nobody.

What ECOSIRE builds

ECOSIRE builds a restaurant operations management application inside your own Zoho environment, scoped to your menu, your outlet structure and the aggregators you actually work with. It is built to order, not downloaded.

Recipes, sub-recipes and costing

The foundation is a Zoho Creator recipe model. Every menu item has a recipe with ingredient lines, quantities and units of measure; sub-recipes — a stock, a marinade, a sauce base — are recipes in their own right that can be consumed by other recipes to any nesting depth you need. Yield and shrinkage factors are held per ingredient so a raw-to-cooked conversion is applied rather than assumed. Unit conversions (kilogram to gram, litre to millilitre, case to each) are defined once and applied everywhere.

A Deluge costing engine walks the recipe tree and computes plate cost from current ingredient costs pulled from Zoho Inventory or Zoho Books purchase data, using the valuation basis you choose — latest purchase price, weighted average, or a manually maintained standard cost. Because costing is derived rather than typed, a supplier price change immediately reveals every dish it damaged, along with the resulting gross margin at your current menu price. Menu engineering reports classify items by contribution and popularity so pricing decisions are made on numbers.

Inventory, consumption and variance

Stock is tracked per outlet and per store location — main store, kitchen line, bar — as Creator records reconciled against Zoho Inventory where you use it for purchasing and valuation. Goods receipt against purchase orders, supplier price capture, and batch or expiry tracking for items that need it are all handled.

Theoretical consumption is calculated by exploding the day's sales through the recipe tree. Physical counts are entered on a stock-count form — full or spot count, by section — and the application produces the variance report that matters: theoretical versus actual, valued at cost, per ingredient, per outlet, per period. Wastage is recorded as a first-class transaction with a reason code (spoilage, preparation error, staff meal, customer complaint, expiry) so variance can be attributed rather than shrugged at. Deluge scheduled functions post consumption journals into Zoho Books so cost of goods sold reaches the ledger without a manual journal entry.

Central kitchen and inter-outlet transfers

Production batches at the central kitchen consume raw ingredients and produce semi-finished or finished goods with a computed batch cost. Transfer requests from outlets, dispatch notes, in-transit stock and receipt confirmation with a discrepancy check are modelled explicitly, so stock is never in two places at once and never disappears between them. Inter-company transfers between separate Zoho Books organizations are supported where your outlets are separate legal entities, with the corresponding documents raised on both sides and the correct GST or VAT treatment configured in each Books organization's tax settings.

Delivery-aggregator reconciliation

Orders and payouts from delivery platforms are imported — via the platform's own API where one is available to you, or by structured file import where it is not. The reconciliation engine matches each order to its payout line and classifies every difference: commission, platform-funded promotion, merchant-funded discount, cancellation, refund, adjustment and tax withheld. Matched and unmatched lines are reported separately so your team works only the exceptions instead of the whole file. Net receivable per platform per period is posted to Zoho Books against the platform as a customer, and the bank credit is matched against it — which is what turns a month-end guessing exercise into a five-minute review. Menu-item mapping between each platform's item codes and your internal recipes means aggregator sales also drive theoretical consumption, so delivery volume is included in food-cost variance rather than excluded from it.

Daily close, sales and outlet operations

A day-close process per outlet captures sales by revenue category, payment mode breakdown, cash declared versus expected, voids and discounts with reasons, and manager sign-off. Sales data is imported from your point-of-sale system through its export or API, mapped to your revenue categories and pushed into Zoho Books as summarised sales entries rather than thousands of individual invoices. Where you use Zoho People, staff rosters and attendance stay there and are read for labour-cost reporting rather than duplicated.

Dashboards and integration surface

Management dashboards show food cost percentage against target by outlet, variance by ingredient, wastage by reason code, top loss-making dishes, aggregator commission as a share of delivery revenue, and outlet-level contribution. Zoho Flow handles cross-application automation such as low-stock alerts to purchasing and daily close reminders. Sigma widgets are used where a screen needs behaviour Creator pages do not offer natively — a recipe tree builder, a fast stock-count entry grid, a reconciliation matching board.

Who it is for

Multi-outlet restaurant and QSR groups; cloud and dark kitchens running several virtual brands from one production site; cafe and bakery chains with a central production unit; catering companies costing menus per event; food-court and franchise operators who need consolidated cost control across sites that trade independently.

How delivery works

1. Scoping call. We review your menu and recipe structure, outlet and legal-entity layout, central kitchen model, point-of-sale system, the delivery platforms you use and how they pay you, and the Zoho applications you already run. We ask for a sample recipe, a sample aggregator payout statement and a sample POS export. 2. Fixed quote. A written scope covering the recipe and costing model, inventory and variance process, transfer flows, reconciliation rules, POS integration and reporting, at a fixed price. Nothing is built until you approve it. 3. Build. ECOSIRE develops the Creator application, the Deluge costing, consumption and reconciliation engines, the Books and Inventory integrations, Sigma widgets and Flow automations. Typical build time is one working week depending on scope. 4. Install in a test environment. Deployed to a test Creator environment with your real menu, a sample month of sales and a real payout file. You run a full cycle — costing, stock count, variance, transfer, reconciliation and day close — before production. 5. Production go-live. After sign-off, deployment to your production Zoho org, loading of recipes, opening stock and supplier costs, POS and platform connections, and user role configuration per outlet. 6. Support window. A post-go-live support period for defect fixes and configuration adjustment on the terms stated in your quote.

The application sits in your own Zoho account. Deluge source, widget code and documentation are yours.