How a 30-Location Pide Chain Centralizes Menu Operations

"Pide Sarayı" opened as a single shop on Ankara's Tunalı Avenue in 1987. Today it stretches across 30 branches from Eskişehir to Konya, and owner Hakan Bey faces a familiar problem: minced-lamb pide costs 95₺ in Tunalı but 75₺ in Eskişehir, while the description, allergens, and photos must stay identical everywhere. When November's "chestnut sherbet" promo launches, all 30 stores must show it simultaneously — not one at 03:00 and another the next afternoon. This article walks through the parent-child restaurant_id model, the regional override layer, and the nightly push pipeline thMenu uses for chains. It's a concrete answer to the "franchise menu management software" search query.

Parent-Child Restaurant Model

In thMenu, multi-location chains hinge on the parent_restaurant_id column. For Pide Sarayı, the Tunalı branch is flagged as "parent," while the other 29 branches point at it as children. Categories, products, allergens, and images are inherited from the parent. Each child stores only its deltas in a price_override table: { restaurant_id: 'eskisehir-1', product_id: 'minced-pide', price: 75 }.

When a guest scans the QR code, the menu API resolves overrides via a safe subquery on the branch's restaurant_id (not a JOIN — D1 quirk). The Tunalı QR shows 95₺, the Eskişehir QR shows 75₺. Same SKU, same description, same image. Operationally, the chain edits one product in one place.

Regional Override Layer

Branches cluster: 5 Central Anatolia shops buy from one supplier, 8 Marmara shops from another. Writing per-branch overrides would explode the table, so we introduce a region_id layer. A "Marmara" region is created, the 8 shops attach to it, and the override row reads { region_id: 'marmara', product_id: 'lahmacun', price: 65 }. All Marmara branches inherit it.

Resolution order is shop > region > parent. If Bursa sets its own override, that wins; otherwise the Marmara price applies; otherwise the parent price. With three tiers, 85% of Pide Sarayı's 30 branches are managed at the region layer, dramatically cutting daily admin work.

The 03:00 Push: November Promo Flow

Hakan Bey prepares the "chestnut sherbet + warm soup" promo in late October. From a single admin panel he adds it to the parent restaurant and clicks "push to all children." The system stamps it with scheduled_at = 2026-11-01T03:00:00Z. At that moment a cron fires, invalidates each branch's edge cache, and writes the new menu to KV. By 05:00 every guest scan shows the promo.

This is where POS-based pricing breaks down: pushing 30 POS terminals manually is human-error bait. Menu-based pricing makes the menu DB the single source of truth; the POS reads it. After this architectural change, Pide Sarayı dropped menu-mismatch incidents from 12 per month to zero.

FAQ

What if one branch wants to leave the parent menu? Set its parent_restaurant_id to NULL — it becomes its own master record. Overrides aren't auto-purged, so a cleanup pass is required.

Can franchisees write their own overrides? Yes, with role-based access. A franchise owner can edit only their branch overrides; the parent record is read-only to them.

Which thMenu plan is required? Multi-location management is in Pro+. Single-location operators stay on Starter for free.

Found this helpful? Share it.