# The Cimplify Manual — full content The entire manual for operating on Cimplify, concatenated as Markdown. For a page index instead, fetch /llms.txt. # Bookable resources URL: /docs/bookable-resources > Rooms, tables, vehicles, courts, chairs, parking, spaces. How to model the physical thing a booking occupies — the three consumption modes, assignment timing, and when a capacity number is a trap. A bookable resource is the physical thing a [service](/docs/services) occupies while it happens: a hotel room, a restaurant table, a barber's chair, a tennis court, a parking spot, a rental van. This is the chapter people most need and most often get wrong, because "how many do I have?" feels like enough — right up until two bookings collide or you sell out the wrong thing. Read it carefully. ## Two levels: the type and the unit Keep these straight and most confusion disappears: - A **resource type** is a *class* of interchangeable units: "Deluxe Room", "2-seat Table", "Barber Chair", "Compact Car". It holds the rules — how it's used up, when a specific unit gets assigned. - A **unit** (a bookable resource) is one *individual* item of that type: "Room 101", "Table 5", "Chair 3", a specific van. It has a name, an optional capacity, a location/floor/zone, and a status. A service requires a **type** (or, rarely, one specific unit). The pool of units under that type is what availability draws from. ## The two-room-types trap A hotel with Deluxe and Standard rooms is **two resource types, each with its own rooms** — not one product with a single "15 rooms" count. If you model it as one number, selling a Deluxe wrongly shows a Standard as unavailable, because they share the pool. Model one resource type per class, with that class's real rooms underneath. Then selling a Deluxe only draws down Deluxe, and the Standards are untouched. This is the canonical example of the guide's core rule: **model the fact, not a convenient number.** Whenever a merchant says "I have a few different kinds of X", that's a few resource types, not one count. Different tables sizes, room classes, car categories, court types — each is its own type with its own units. ## The three ways a booking uses a resource The **consumption mode** on the resource type is the core decision. It answers: when a booking happens, how does it draw from the pool? How each feels in practice: - **Whole unit** — a table for 2 and a table for 4 are different *units*. Booking Table 5 makes only Table 5 unavailable. A party of 6 might take a 4-top *plus* a 2-top — Cimplify packs the party across whole units automatically, so you don't pre-define "joined tables". - **Shared capacity** — a 50-seat hall is one pool of 50. A booking for 30 leaves 20. You're not assigning a particular seat, just drawing down the count. - **Fixed quantity** — a kayak rental holds 2 kayaks out of the fleet for the window. *Which* two doesn't matter; the count does. > Decide by asking: does a booking **own a specific unit** (whole unit), **share a seat pool** (shared capacity), or **hold a quantity of gear** (fixed)? For agents: this is `consumption` on the resource type — `WholeUnit`, `PerCapacity`, or `Fixed`. The resource `category` (Table, Room, Vehicle, Court, Spot, ServiceSpace, Venue, Custom) sets a sensible default consumption mode (Table, Room, Vehicle, Spot, and Court default to whole-unit; ServiceSpace and Venue to shared capacity; Custom to fixed) and drives the UX pattern. Override the consumption mode if the default doesn't fit. ## How a service asks for a resource On the service, a **resource requirement** says what a booking needs: - **By type** — "any available Deluxe Room", "any free barber chair". The common case; it lets the pool absorb demand. - **By specific unit** — "this exact unit". Rare, for when only one physical thing will do. - **Quantity** — how many units/seats/items the booking needs (3 parking spots for a group; 2 projectors). A service can require **several types at once** — an appointment needing both a *room* and a piece of *equipment*. Each requirement is checked before the slot is offered, so a booking only succeeds when everything it needs is free. ## When the specific unit is chosen: now or later The **assignment timing** on the resource type decides when a booking gets pinned to a particular unit: - **Assign now** (immediate) — the unit is chosen at booking time. The customer books Table 5 specifically. Right for tables and most appointments. - **Assign later** (deferred) — the booking reserves the *type's* capacity now and the specific unit is picked later, usually at check-in. Right for hotels: you sell "a Deluxe Room" today and assign Room 204 when the guest arrives, leaving you free to manage housekeeping and upgrades. With assign-later, availability still counts the reservation against the type's capacity, so you can't oversell — you simply haven't named the unit yet. Staff assign (or reassign) the unit from the booking later. ## Taking units offline and unit status Each unit has a status. To pull a unit from the pool — a room being renovated — set it to **maintenance** or **out of service**, and it's removed from availability entirely. **Occupied** and **reserved** are handled automatically by bookings; you don't set those by hand. To retire a unit permanently, deactivate it. ## Capacity number vs. real resources — how to choose This is the decision that trips people up. Use the table. | Use a plain capacity number | Use bookable resources | | --- | --- | | Nothing physical to assign | Specific units exist and matter (Room 101 vs 102) | | A headcount is all that matters (20 class spots) | You need to assign / reassign a unit, or take one offline | | One uniform pool, one service | Different classes that must not share a pool | | Walking tour, webinar, open class | Hotel, restaurant floor, rental fleet, courts | The trap is reaching for a capacity number because it's quick, then discovering you can't tell two room types apart, can't assign a table, and can't take a unit offline. **If real units exist, model resources from the start.** ## Checkout holds (automatic) While a customer is checking out, the unit or capacity they're taking is held provisionally for a short window, then released automatically if payment never completes. So an abandoned basket can't lock a room forever, and you don't oversell during the few minutes someone is paying. There's nothing to configure — it just happens. ## Worked examples **Hotel.** Two resource types — "Deluxe" and "Standard" — each whole-unit, assign-later, with their real rooms underneath. The stay is a [multi-day service](/docs/services#multi-day-stays-in-detail) requiring the room type. Selling a Deluxe never touches the Standards. **Restaurant floor.** One resource type "Table" (or several by size), whole-unit, assign-now. Units are the actual tables with their seat counts. A party of 6 packs across a 4-top and a 2-top automatically. **Barbershop.** "Barber Chair" type, whole-unit, assign-now, with chairs 1–4 as units. A haircut requires a chair by type — and a barber too, if barbers are individually bookable. **Car rental.** "Compact" and "SUV" types, whole-unit, often assign-later (pick the actual vehicle at pickup). The rental is a multi-day service with pickup/return wording. **Event hall.** One type, shared-capacity, capacity = seats. A booking draws its headcount from the pool; no seat assignment. **Kayak hire.** "Kayak" type, fixed-quantity. A booking holds N kayaks from the fleet for the window. ## Mistakes to avoid - **One capacity number for several real classes.** The two-room-types trap. One type per class. - **Whole-unit when it should be shared capacity** (or vice versa). Re-read [the three modes](#the-three-ways-a-booking-uses-a-resource). - **A resource-backed service with an empty pool.** It reads as zero availability (fail-safe), not "one" — configure the units before going live. - **Assign-now for hotels.** Use assign-later so the front desk keeps unit flexibility. ## Common questions **A party is bigger than any one unit. Do I make a "big table"?** No. With whole-unit, Cimplify packs the party across several free units automatically. Only make a literal big unit if it physically exists. **Can one booking use a room and equipment?** Yes — two requirements on one service. Both are guaranteed before the booking is confirmed. **How is a rental different from a sale?** A rental returns. It's a multi-day [service](/docs/services) over a whole-unit (vehicle) or fixed-quantity (gear) resource, with pickup/return wording — not a [retail](/docs/retail) sale where ownership transfers. **What happens if I take a room offline mid-future-bookings?** New availability excludes it. Existing bookings on it stay; reassign them to another unit (assign-later makes this easy) before the date. **I'm an agent. What's the minimum to model a resource-backed service?** Create the resource type(s) with the right consumption mode, add their units, then add a resource requirement (by type) to the service. Choose assign-now vs assign-later per how the business hands out units. Next: [Pricing & extras](/docs/pricing), or see a [hotel and a restaurant modelled end to end](/docs/scenarios). --- # Bundles & build-your-own URL: /docs/bundles-and-composites > Selling several things as one line: fixed packages the merchant assembles (bundles) vs. let-the-customer-choose (build-your-own / composites). When to use each and how each is priced. Sometimes one cart line is really several things together. There are two ways to do that, and they answer different questions: - A **bundle** is a **fixed package you assemble** — a combo meal, a gift set, a starter kit. *You* decide the contents. - A **build-your-own** (a composite) is a **selection the customer assembles** from groups of options — a salad, a custom pizza, a build-a-box. *They* decide the contents, within your rules. > Decide by who chooses the contents. You → bundle. The customer → build-your-own. ## Bundles (fixed packages) A bundle is a **product** of type Bundle whose contents are a fixed list of other products, each with a quantity and an optional pinned variant. Its price is one of: | Pricing | What it means | | --- | --- | | **Fixed** | The bundle has its own flat price, regardless of what the parts cost. | | **Percentage off** | Sum of the parts, minus a percentage. | | **Amount off** | Sum of the parts, minus a flat amount. | A bundled component can pin a specific variant, or let the customer choose the variant at checkout. Use bundles for combo meals, gift sets, "frequently bought together", and kits. ```text Bundle: "Lunch Combo" (fixed price 12.00) ├── Burger ×1 (variant: Classic) ├── Fries ×1 (customer picks size) └── Soda ×1 (customer picks flavour) ``` ## Build-your-own (composites) A build-your-own is a **product** of type Composite made of **groups**, each with selection rules. The customer's choices *are* the product — a poke bowl, a custom pizza, a gift hamper, a cocktail. Each **group** has: - a **minimum / maximum** number of selections (min 0 makes the group optional), - optional **repeats** — pick the same option more than once, up to a per-option cap ("max 3 shots"), - a **pricing rule**: *each adds its price*, *first N free*, *one flat fee if anything is chosen*, or *all at the highest chosen price*. Each **option** in a group can come from a catalogue product, a raw inventory ingredient, an existing add-on, or be a plain modifier with no stock. It carries its own price, optional nutrition, and availability. The whole product's **pricing mode** ties it together: | Mode | Total is | | --- | --- | | **Additive** | base price + everything selected | | **Highest per group** | base + only the dearest pick in each group | | **Highest overall** | base + the single dearest option chosen | | **Tiered** | a set price based on *how many* items were chosen (1–2 = one price, 3–5 = another) | ```text Composite: "Build Your Bowl" (base 8.00, additive) ├── Base pick 1 (Rice, Quinoa…) ├── Protein pick 1–2 (Chicken +2, Tofu +1) └── Toppings pick 0–6 (each +0.50, first 3 free) ``` Because options can pull straight from raw inventory, a build-your-own food item deducts the right ingredients as the customer builds it — the [recipe bridge](/docs/food#the-recipe-bridge) working inside a composite. ## Choosing the right tool | The situation | Use | | --- | --- | | Fixed contents, one set price | Bundle (fixed) | | Fixed contents, priced as a discount on the parts | Bundle (percentage or amount off) | | Customer picks from groups with rules | Build-your-own | | Customer just tweaks one main item ("no onions, extra cheese") | Neither — [add-ons](/docs/pricing#add-ons) on a normal product | | Two unrelated products a shopper compares | Neither — separate [products](/docs/retail), maybe in a [collection](/docs/organizing-the-catalog) | ## Worked examples **Meal deal.** Burger + side + drink at one price → bundle (fixed). Let the customer pick the side size and drink flavour. **Gift hamper, customer-built.** Pick 3 from "Treats", 2 from "Drinks", optional card → build-your-own with per-group min/max. **Pizza shop.** Menu pizzas are normal [food](/docs/food) products with a Size axis. "Create your own" is a build-your-own with Base/Sauce/Cheese/Toppings groups and a "first 3 toppings free" rule. **Spa package.** Three treatments sold together at a set price → bundle of [services](/docs/services). ## Mistakes to avoid - **A combo as a variant.** It's a bundle. - **Build-your-own as a wall of add-ons.** Use a composite; it has the group min/max and pricing rules you need. - **Summing a composite's price yourself.** Set the pricing mode and group rules; the total is computed. ## Common questions **Can a bundle contain a service?** Yes — a bundle can package services (a spa package), goods, or a mix. **Does a bundle's stock deduct from each part?** Yes — selling the bundle consumes each component (and each component's recipe, if it's a food item). **Can a build-your-own enforce "exactly one base, up to five toppings"?** Yes — that's per-group min/max (Base min 1 max 1; Toppings min 0 max 5). **I'm an agent. Bundle or composite?** If the contents are fixed at author time → bundle. If the customer selects from groups at order time → composite. If they only modify a single base item → add-ons, not either. Next: [Organizing your catalogue](/docs/organizing-the-catalog) so customers can find all of this. --- # Mistakes to avoid URL: /docs/edge-cases > The traps that quietly break a setup, the warning signs you've modelled a workaround instead of the truth, and a checklist to model anything cleanly. Most bad setups come from two things: answering "what moves?" wrong, or reaching for a quick workaround instead of the right tool. Here are the traps, the warning signs, and a checklist to keep you straight. ## The traps ### A capacity number where real units belong Modelling specific physical units (rooms, tables, courts) as a single "how many" number. It can't tell two classes apart, can't assign a specific unit, and can't take one offline. If real units exist, use [bookable resources](/docs/bookable-resources). The hotel "two room types share one count" bug is the classic version. ### Variant explosion Creating every theoretical combination, or using variants for products that aren't really the same thing. Create only the variants you stock. If items are things a shopper *compares* rather than *configures*, they're separate [products](/docs/retail#when-to-use-variants-and-when-not). ### Build-your-own as a wall of add-ons A salad with twenty toppings and per-group rules is a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites), not a product with twenty add-on groups. Add-ons tweak a fixed item; build-your-own assembles one. ### A package modelled as a variant A combo meal or gift set is a [bundle](/docs/bundles-and-composites), not a variant of one of its members. ### A membership modelled as a one-off product A recurring membership or licence is a [digital product on a billing plan](/docs/pricing#subscriptions-and-instalments), not something the customer re-buys by hand each month. ### The wrong axis scaling the recipe On [food](/docs/food), only axes that change *how much stock is used* should affect the recipe. Marking Temperature as recipe-affecting (or forgetting to mark Size) makes consumption forecasts wrong. ### The wrong tax mode Entering a tax-inclusive price in exclusive mode (or vice versa) makes every displayed price wrong. Set the [tax mode](/docs/pricing#tax-inclusive-vs-exclusive) to how you advertise prices *before* entering any. ### Modelling in "notes" or free text Stuffing real facts into a notes field or metadata blob to make something work — "room type: deluxe", "is a rental", "uses 60ml dye". That's the surest sign you've modelled the instance, not the fact. There is almost always a proper place: a [resource type](/docs/bookable-resources), a [scheduling mode](/docs/services), a [recipe](/docs/food). Free text is for genuinely free-form information, never for facts the system already has a home for. ## Warning signs you're modelling a workaround - You're about to put a structural fact into a notes/metadata field. - A single number stands in for several real, distinct things. - You're creating variants for products a customer would compare, not configure. - You're recreating a calendar, a recipe, or a stock count by hand because "the built-in one doesn't quite fit" — it almost certainly does, in a mode you haven't found yet. - The setup only works if staff "remember" to do something the system could enforce. When you hit one of these, stop and re-ask [what moves](/docs/mental-model#the-three-things-that-can-move). The right model is the one where a new wrinkle is a new *value* (another variant, another resource type, another channel), not a new workaround. ## Things that are handled for you - **Empty resource pools fail safe.** A resource-backed service with no usable units reads as zero availability, never one — so you can't accidentally sell something with nothing behind it. Configure pools before launch. - **Checkout holds are automatic.** Capacity is held while a customer pays and released if they don't, so abandoned baskets don't lock a room and you don't oversell mid-payment. - **Party packing is automatic.** With whole-unit resources, a large party is seated across several free units without you defining "joined" units. - **One order, many blocks.** A basket can mix a retail good, a made-to-order meal, and a booking with no special setup. ## The modelling checklist Run this for each thing a merchant sells: 1. **What moves?** A thing (retail), a thing-you-make (food), or time (service)? Access → digital + plan. Take-and-return → rental (service over a resource). 2. **Pick the product type.** Product, Service, Digital, Bundle, or Composite. Everything keys off this. 3. **Inventory shape.** Retail → one-to-one. Made from parts → a recipe. Service/digital → no stock. 4. **Forms of the same thing?** Add variant axes and only the variants you stock. Price differences are relative; for food, mark which axes scale the recipe and set multipliers. 5. **Time-based?** Set the scheduling mode (within a day vs multi-day, coherent with the duration), duration, capacity, availability, staff, and policies. 6. **Ties up a physical unit?** Model resource types (one per class), real units, the right consumption mode, and assign-now vs assign-later. Require the resource on the service by type. 7. **Choices and money.** Add-ons for tweaks, build-your-own for assembly, custom fields for collected info and per-field fees, bundles for fixed packages, billing plans for recurring/instalment. 8. **Organize.** One category, rule-driven collections, tags, and the real channels. 9. **Sanity check.** Did you reach for notes/metadata to make it work? Did a number stand in for real units? Did variants stand in for separate products? If yes, go back to step 1. ## Common questions **I genuinely can't make my thing fit a block. What now?** Break the *order* down rather than the *business*. Each line is usually one block; model each and let them coexist. True hybrids (rentals) reuse two systems on purpose. If something still resists, model it as closely as you can with the nearest block and avoid hiding the misfit in free text. **Will the system stop me from overselling?** Yes, for resources and capacity — availability is enforced, holds cover checkout, and empty pools read as zero. Your job is to model the units truthfully; enforcement is automatic. **I'm an agent reviewing an existing setup. What do I look for first?** Capacity numbers that should be resource types; variants that should be separate products (or vice versa); recurring products with no billing plan; food axes with the wrong recipe-scaling; and any structural fact living in notes/metadata. Those five catch most real problems. Next: the [FAQ](/docs/faq) for direct answers, or the [glossary](/docs/glossary) for any term. --- # FAQ URL: /docs/faq > Direct answers to the questions merchants and agents ask most when modelling a business on Cimplify. Short, direct answers. Each links to the chapter with the full story. ## Getting oriented **Where do I start?** [The mental model](/docs/mental-model), then [getting started](/docs/getting-started), then the chapter for what you sell. **I sell several different kinds of thing. Which model do I pick?** You don't pick one for the business — you pick one *per thing you sell*. A salon's haircut is a [service](/docs/services); the shampoo on the shelf is [retail](/docs/retail). They coexist in one catalogue and one basket. **What's the single most important decision?** The [product type](/docs/glossary#product-type) of each item — product, service, digital, bundle, or composite. It's set once and decides inventory, scheduling, and fulfilment behaviour. **Can I change a product's type later?** Treat it as permanent. Switching it mid-life is disruptive because so much hangs off it. Decide it correctly with [the decision tree](/docs/mental-model#the-decision-tree). ## Products, variants, and stock **When is something a variant vs. a separate product?** A variant is the *same product in a different form* (size, colour). Separate products are *different things a shopper compares*. A shirt's sizes are variants; a shirt and a hoodie are separate products. See [retail](/docs/retail#when-to-use-variants-and-when-not). **Do I have to create every size × colour combination?** No. Create only the combinations you actually stock. **How does stock get deducted?** Retail: one sale removes one unit (matched by SKU). Food: a [recipe](/docs/food#the-recipe-bridge) deducts each ingredient by amount × (1 + waste). Set it up once and it's automatic. **Can the same item be sold on its own and used in recipes?** Yes — track it once as inventory stock, sell it as a one-to-one [retail product](/docs/retail), and reference it in [food recipes](/docs/food#the-recipe-bridge). One stock item, two uses. **Can prices and stock differ by location?** Yes. Base prices, add-on prices, and availability can all be set per location. ## Food **Do I need recipes?** Only if you want ingredient-level stock and cost tracking — which is what makes food *food*. If you sell finished items without tracking ingredients, model them as retail. **Size or add-on for milk choice?** If the milk is intrinsic to the variant or swaps an ingredient at a known cost, make it a recipe-affecting axis. If it's an optional upcharge, make it an [add-on](/docs/pricing#add-ons). **Add-ons or build-your-own?** Tweaking a set item → [add-ons](/docs/pricing#add-ons). Assembling the item from groups → [build-your-own](/docs/bundles-and-composites#build-your-own-composites). ## Services and bookings **Capacity number or bookable resources?** A headcount with nothing to assign (a class) → capacity. Specific units you assign or take offline (rooms, tables, vehicles) → [bookable resources](/docs/bookable-resources). If you'd ever say "put them in room 3" or "room 3 is closed", you need resources. **Why does selling one room type make another show as unavailable?** You modelled them as one shared count. Make each room type its own [resource type](/docs/bookable-resources#the-two-room-types-trap) with its own rooms. **Appointment or multi-day?** Minutes/hours within a day → [within-a-day](/docs/services#the-first-decision-appointments-or-multi-day). Nights/days/weeks → [multi-day](/docs/services#multi-day-stays-in-detail). The duration unit and the mode must match. **How do deposits, no-shows, and reschedules work?** They're [service policies](/docs/services#policies): a deposit at checkout, a cancellation window with a fee/partial refund, a no-show fee with a grace period, and a free-reschedule count with a fee after. **How do I model a rental?** A multi-day [service](/docs/services) over a [bookable resource](/docs/bookable-resources) (the vehicle or gear), with pickup/return wording. There's no separate rental type. **Can a service use up materials?** Yes — give it a [recipe](/docs/food#the-recipe-bridge) just like a food item (hair colour uses dye and developer). ## Pricing **Where do I put a surcharge — variant, add-on, or field?** Variant for an inherent form (Large). Add-on for an optional choice (extra shot). [Custom field](/docs/pricing#custom-input-fields) for something tied to information the customer provides (engraving, rush). See [how a price is built](/docs/pricing#how-a-line-price-is-built). **Inclusive or exclusive tax?** Match how you advertise prices. If your displayed prices already include tax → inclusive. If tax is added at checkout → exclusive. Decide before entering prices. **How do I sell something monthly or pay-over-time?** A [billing plan](/docs/pricing#subscriptions-and-instalments): subscription for recurring, instalment for splitting a one-off price. ## For AI agents **How do I classify an item fast?** Run [the decision tree](/docs/mental-model#the-decision-tree) top to bottom; first match wins. Food vs retail tiebreaker: does selling it deduct tracked *ingredients* (food) or one finished *unit* (retail)? **What order do I create things in a bulk setup?** Locations → resource types and units → products (correct type) → variants/recipes → availability rules → staff/resource requirements → prices and policies → categories/collections/channels. Dependencies before dependents. **How do I avoid the common modelling errors?** Don't use a capacity number where real units exist; don't make compared products into variants; give recurring products a billing plan; mark food recipe-scaling on the right axes; and never put structural facts in notes/metadata. See [mistakes to avoid](/docs/edge-cases). **Where's the authoritative definition of a term?** The [glossary](/docs/glossary). Didn't find your question? Work it through the [decision tree](/docs/mental-model#the-decision-tree) and the chapter for your block — the answer is almost always "model what actually moves". --- # Food URL: /docs/food > Things you make from ingredients: recipes, sizes that use more, waste, modifiers and build-your-own, allergens, and the kitchen workflow. Also covers light manufacturing. Food is the "made from ingredients" block. Raw stock becomes a finished item through a recipe, with some waste, and usually it's made fresh to order. The crucial difference from retail: **what you sell ("Large Latte") is not what you count ("coffee, milk, cups")**, so there has to be a bridge between them. You model a food item as a **product** whose inventory is **made from a recipe** (composition). The same machinery covers anything assembled from parts: a café, a kitchen, a bakery, a juice bar, and even light manufacturing (a longer recipe, no rush to serve). ## The recipe bridge A **recipe** lists, for one item, every stock ingredient it uses, how much, and the waste: ```text Product: "Latte" (made from a recipe) uses Coffee beans 18 g waste 2% uses Whole milk 200 ml waste 1% uses 12oz cup 1 waste 0% ``` When a Latte sells, inventory automatically draws `amount × (1 + waste)` of each ingredient. **Waste** is the spillage, trimming, and cooking loss you expect — set it honestly and your stock forecasts stay accurate. A few percent for liquids; more for items with heavy prep loss. For agents: set `inventory_type = Composition` and define product components (ingredient stock, base quantity, waste percentage). Retail is the same mechanism with one component, quantity 1, waste 0 — which is why a business can mix both freely. One ingredient can feed many recipes. A "house sauce" used in ten dishes is one stock item referenced by ten recipes; selling any dish draws down the shared sauce. That's the bridge working as intended. ## Sizes that use more: multipliers A food size ("Small / Medium / Large") usually changes *how much of the recipe* is used, not the recipe itself. You express that with a **multiplier** on each size: ```text Latte sizes: Small ×0.8 Medium ×1.0 Large ×1.5 Large Latte → coffee = 18 g × 1.5 × 1.02 (waste) = 27.5 g ``` The catch: a multiplier should only apply to axes that actually scale the recipe. A **Size** axis does; a **Temperature: Hot/Iced** axis usually doesn't. So you mark each axis as **affecting the recipe** or not. Mark Size yes, Temperature no, and the right dimension scales consumption while the wrong one leaves it alone. The multiplier scales **stock used**, never **price**. Price comes from the size variant's price difference. A Large both costs more *and* uses more — two separate settings doing two separate jobs. See [pricing](/docs/pricing#base-and-variant-price). ## Modifiers: tweaks vs. build-your-own Two different customer experiences, two different tools. Choosing right keeps menus clean. **Add-ons — small tweaks to a set item.** "Extra shot", "oat milk", "no onions", "make it a meal". The base item is the star; the choices adjust it. Model these as [add-on groups](/docs/pricing#add-ons) on the product, with rules like "pick exactly one milk" or "up to five toppings". Each option can cost extra and can consume its own stock. **Build-your-own — the customer assembles the item.** A salad, a custom pizza from scratch, a poke bowl, a cocktail. The selection *is* the product. Model it as a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites) with groups (Base, Protein, Toppings), each with its own min/max and pricing rules (first three toppings free, etc.). Components can pull straight from raw stock so ingredients deduct as the customer builds. > Rule of thumb: if the customer is **customising a thing**, use add-ons. If the customer is **building the thing**, use build-your-own. ## The kitchen Prepared items route to the kitchen, where each order ticket moves through **Pending → Preparing → Ready → Served / Picked up → Completed**. You can route items to specific stations (grill, bar), flag rush orders, and number courses for dine-in. There's nothing to configure per product beyond it being a prepared item — the kitchen surface runs the workflow. This is separate from a [service booking](/docs/services): a kitchen ticket is a make-it job, not a calendar reservation. ## Allergens, calories, and consent Food carries safety information, and Cimplify treats it as first-class, not an afterthought: - **Calories** and **allergens** on the product (and on each build-your-own component) show on the storefront and on the order. - A [custom input field](/docs/pricing#custom-input-fields) marked as an **allergen** or **dietary preference** turns the customer's answer into a visible signal on the order/booking (a pill the kitchen sees) rather than buried free text. A field marked as **consent** can require a signed acknowledgement (an allergy waiver) before the order is fulfilled. ## Light manufacturing Manufacturing is food's transformation shape stretched out: a longer recipe, multiple stages, and no need to serve immediately. If a merchant assembles or produces goods from tracked components, model the finished good as a composition product with a recipe of its parts. Sizes/grades that consume more use multipliers exactly as food sizes do. ## Worked examples **A drink with size and milk.** Size is an axis that *affects the recipe* (scales the pour) with multipliers. Milk is either (a) an axis that affects the recipe if it swaps one stock ingredient for another at no/known cost, or (b) an add-on group if it's an optional upcharge. Choose by whether the milk is intrinsic to the variant or an optional change. **A pizzeria.** Menu pizzas are composition products with a Size axis (affects recipe). "Build your own" is a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites) with Base/Sauce/Cheese/Toppings groups pulling from raw stock. "First three toppings free" is a group pricing rule. **A combo meal.** Burger + fries + drink at one set price is a [bundle](/docs/bundles-and-composites) (fixed contents), not build-your-own. **A bottled sauce on the shelf.** Already made and counted as a unit → that's [retail](/docs/retail), not food. Only use a recipe when you make it to order from tracked ingredients. ## Mistakes to avoid - **Marking every axis as affecting the recipe.** Only sizes (and ingredient-swapping axes) should. A wrong mark corrupts stock forecasts. - **Modelling build-your-own as twenty add-on groups.** Use a build-your-own product; it has the group rules you need. - **Tracking a packaged, pre-made item as a recipe.** If it's already a countable unit, it's retail. - **Zero waste everywhere.** Some loss is real; leaving waste at 0 slowly drifts your stock counts. ## Common questions **Do I have to set up recipes?** Only if you want ingredient-level stock tracking and accurate costs. If you just sell finished items and don't track ingredients, you can model them as retail. Recipes are what make food *food*, though — they're how stock and cost stay right. **How do add-ons that use stock work?** An add-on option can carry its own ingredient, so choosing "extra shot" deducts an extra shot's worth of coffee. Set the option's stock reference. **Can one ingredient be sold on its own and used in recipes?** Yes — track it once as stock, sell it as a [retail product](/docs/retail) (1:1) and reference it in recipes. One stock item, two uses. **I'm an agent. How do I tell food from retail?** Ask whether selling the item should deduct tracked *ingredients* (food) or just one *finished unit* (retail). Made-to-order with ingredient tracking → composition; finished goods → one-to-one. Next: [Services](/docs/services) for time-based offerings, or [Bundles & build-your-own](/docs/bundles-and-composites) for combos and customisers. --- # Getting started URL: /docs/getting-started > A practical walkthrough from an empty account to your first product, menu item, or bookable service — with the order to do things in and the decisions you'll face. This page takes you from nothing to a working catalogue. It assumes you've already created your business account. If you only sell one kind of thing, you'll be done in minutes; if you sell several, repeat the relevant section for each. ## The order to set things up Do it in this order. Each step depends on the ones before it. 1. **Locations first.** Almost everything — prices, stock, availability, resources — can be specific to a location. Create your location(s) before products so you have something to attach them to. A single-location business still needs one location. 2. **Decide what each thing is.** For everything you sell, run the [decision tree](/docs/mental-model#the-decision-tree): retail, food, service, or access. This sets the [product type](/docs/glossary#product-type), the one choice everything else depends on. 3. **Create the products / services.** Follow the chapter for each block (below). 4. **Add the moving parts.** Variants, recipes, availability, resources, add-ons — whatever that block needs. 5. **Set prices and policies.** Base price, extras, deposits, tax mode. See [Pricing & extras](/docs/pricing). 6. **Organize.** Put things in categories and collections so customers can find them. See [Organizing your catalogue](/docs/organizing-the-catalog). 7. **Choose where each thing sells.** Set the [channels](/docs/organizing-the-catalog#sales-channels) (in-store, online, and so on). **The single most important decision is step 2.** The product type (retail product, service, digital, bundle, composite) is chosen once and shapes everything after it. If you're unsure, read [the mental model](/docs/mental-model) before creating anything. ## Your first retail product For a finished physical thing you hand over. 1. Create a **product**, type **Product**. Give it a name, description, image, and a **base price**. 2. If it comes in one form only (a single mug), you're done — it has one implicit variant. 3. If it comes in **sizes or colours**, add **variant axes** ("Size", "Colour") and create only the **variants** you actually stock. Each variant gets its own SKU and an optional price difference. 4. Set stock levels per variant (and per location if you have several). Full detail and the rules for when *not* to use variants: [Retail](/docs/retail). ## Your first menu item (food) For something you make to order. 1. Create a **product**, type **Product**, and mark its inventory as **made from a recipe** (composition). 2. Add the **recipe**: each ingredient it consumes, the amount, and a waste percentage. 3. If it comes in sizes that use *more* of the recipe, add a **Size** axis, mark it as affecting the recipe, and give each size a multiplier (Large = 1.5×). 4. Add **modifiers**: small tweaks become [add-ons](/docs/pricing#add-ons); a fully build-it-yourself item becomes a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites). 5. Record **allergens and calories** if relevant. Full detail: [Food](/docs/food). ## Your first service (a booking) For time, a person, or a space. 1. Create a **product**, type **Service**. 2. Choose the **scheduling mode**: **within a day** (appointments, classes) or **multi-day** (stays, rentals). Set the **duration**. 3. Set **capacity** (how many people one slot holds) — but if real rooms/tables/courts are involved, use [bookable resources](/docs/bookable-resources) instead of a plain capacity number. 4. Set **availability**: the weekly opening hours per location, plus any holiday closures. 5. If it needs a **person**, add a staff requirement. If it needs a **room/table/vehicle**, add a resource requirement. 6. Set **policies**: deposit, cancellation window, no-show fee, reschedule rules. Full detail: [Services](/docs/services) and [Bookable resources](/docs/bookable-resources). ## Your first access product (membership, course, ticket) For something that grants access with nothing physical. 1. Create a **product**, type **Digital**. 2. Attach a **billing plan**: a **subscription** (recurring — monthly membership) or an **instalment** plan (split a one-off price). A one-time access grant (a single download or ticket) needs no plan. 3. Set any access details (download limits, licence handling). Full detail: [Pricing & extras → Subscriptions and instalments](/docs/pricing#subscriptions-and-instalments). ## A first-setup checklist - [ ] At least one **location** exists. - [ ] Every item's **product type** matches what actually moves. - [ ] Retail variants exist only for forms you really stock; SKUs match your inventory. - [ ] Food items have a **recipe**; sizes that use more are marked as affecting the recipe. - [ ] Services have a **scheduling mode**, **duration**, **availability**, and policies set. - [ ] Anything tied to a physical unit uses a **resource type** with real units, not a bare capacity number. - [ ] Prices use the right **tax mode** (inclusive vs. exclusive) for your market. - [ ] Items are in a **category**, useful **collections**, and the right **channels**. When that's all true, your data describes your business and every surface — storefront, point of sale, agents — will behave correctly. ## Common questions **Do I have to create locations even with one shop?** Yes — one location. Prices, stock, and availability all hang off a location, so there must be at least one. **Can I change a product's type later?** Treat the type as permanent. It determines inventory, scheduling, and fulfilment behaviour, so switching it mid-life is disruptive. Decide it correctly up front using the [decision tree](/docs/mental-model#the-decision-tree). **What if I sell the same physical thing both as retail and inside meals?** Track it once as inventory **stock**, then: sell it directly as a retail **product** (1:1), and reference the same stock in your food **recipes**. One stock item, two uses — see [the recipe bridge](/docs/food#the-recipe-bridge). **I'm an agent doing a bulk setup. What's the safe sequence?** Locations → resource types and units (if any) → products with the correct type → variants/recipes → availability rules → requirements (staff/resource) → prices and policies → categories/collections/channels. Create dependencies before the things that reference them. Next: open the chapter for what you sell — [Retail](/docs/retail), [Food](/docs/food), [Services](/docs/services) — or read [Pricing & extras](/docs/pricing). --- # Glossary URL: /docs/glossary > Every term used in this guide, in plain language, with a pointer to the chapter that covers it. Plain definitions of every term in the guide. Skim it once and the chapters read faster. ## Core ideas ### Building block One of the few fundamental things that can move in a transaction: [retail](#retail), [food](#food), or [service](#service), plus [access](#access) and [rental](#rental) as hybrids. Every business is a mixture of these. See [the mental model](/docs/mental-model). ### Product type The kind of thing a catalogue item is: **Product** (retail or food good), **Service** (a booking), **Digital** (access/rights), **Bundle** (a fixed package), or **Composite** (build-your-own). Chosen once per item; it decides inventory, scheduling, and fulfilment behaviour. The most consequential modelling choice. See [getting started](/docs/getting-started). ### Retail The building block where a finished physical thing changes hands and the unit you sell equals the unit you count. See [retail](/docs/retail). ### Food The building block where you make something from ingredients, so the unit you sell differs from the units you count, bridged by a [recipe](#recipe). Covers kitchens and light manufacturing. See [food](/docs/food). ### Service The building block where you sell time, a person, or a space over a period — a booking. See [services](/docs/services). ### Access A hybrid block: granting rights with nothing physical (membership, course, licence, ticket). Modelled as a [digital](#product-type) product, usually with a [billing plan](#billing-plan). ### Rental A hybrid block: the customer takes a physical thing and returns it. Modelled as a multi-day [service](/docs/services) over a [bookable resource](#bookable-resource). ## Products and stock ### Product The thing a customer recognises and buys. Has a name, price, and one or more [variants](#variant). See [retail](/docs/retail). ### Variant A specific form of a product the customer can choose — "Red / Large". Variants are the *same product* in interchangeable forms, not separate products. See [retail](/docs/retail#variants-axes-and-values). ### Axis A dimension a product varies along — "Size", "Colour". Holds [values](#value). ### Value One option on an [axis](#axis) — "Large", "Red". ### Price difference (price adjustment) The amount a [variant](#variant) adds to (or subtracts from) the base price. Relative, not the whole price restated. ### SKU A code identifying a [variant](#variant) for inventory matching and scanning. ### Stock The physical inventory you count. In [retail](#retail) it maps one-to-one to a variant; in [food](#food) it's the ingredients a [recipe](#recipe) consumes. ### Recipe The list of stock ingredients a [food](#food) item consumes, with amounts and waste. The bridge between what you sell and what you count. See [food](/docs/food#the-recipe-bridge). ### Multiplier A factor on a size [variant](#variant) that scales how much of the [recipe](#recipe) it uses (Large 1.5×). Scales stock, not price. Only applies to axes marked as affecting the recipe. ### Waste The expected loss (spillage, trimming) added on top of a recipe amount, so stock forecasts stay accurate. ### Backorder Allowing a [retail](#retail) item to be bought when stock is zero. ## Services and resources ### Scheduling mode Whether a [service](#service) is booked **within a day** (time slots) or **multi-day** (date ranges). Must match the duration unit. See [services](/docs/services#the-first-decision-appointments-or-multi-day). ### Capacity How many participants one service slot holds — a headcount. Right when there's nothing physical to assign; otherwise use [bookable resources](#bookable-resource). See [services](/docs/services#duration-and-capacity). ### Availability rule A recurring weekly window when a [service](#service) can be booked at a location. ### Availability exception A one-off override of availability — a holiday closure or special hours. ### Bookable resource A physical thing a booking occupies. A **resource type** is a class ("Deluxe Room"); a **unit** is one individual item ("Room 101"). See [bookable resources](/docs/bookable-resources). ### Consumption mode How a booking draws on a [resource type](#bookable-resource): **whole unit** (takes a whole unit), **shared capacity** (draws from a seat pool), or **fixed quantity** (holds a set amount of gear). See [bookable resources](/docs/bookable-resources#the-three-ways-a-booking-uses-a-resource). ### Assignment timing Whether the specific [unit](#bookable-resource) is chosen **now** (at booking) or **later** (at check-in). Hotels use later; tables use now. ### Deposit An up-front payment on a [service](#service): none, a fixed amount, or a percentage. See [services](/docs/services#policies). ### Staff requirement A rule that a [service](#service) needs a person — a count, optionally a role or skill, and whether any qualified staff or a specific one is needed. ## Pricing and extras ### Add-on A modifier group on a product for small tweaks — "Toppings", "Milk" — with selection rules and per-option prices. See [pricing](/docs/pricing#add-ons). ### Custom input field A field that collects information at checkout (engraving, allergy, date), with optional validation, a surcharge, and a meaning tag. See [pricing](/docs/pricing#custom-input-fields). ### Tax mode Whether entered prices are **inclusive** (tax already in the displayed price) or **exclusive** (tax added at checkout). See [pricing](/docs/pricing#tax-inclusive-vs-exclusive). ### Billing plan A recurring (**subscription**) or split (**instalment**) payment arrangement on a product. See [pricing](/docs/pricing#subscriptions-and-instalments). ### Bundle A fixed package of products sold as one line, priced flat or as a discount on the parts. *You* set the contents. See [bundles](/docs/bundles-and-composites). ### Build-your-own (composite) A product the customer assembles from groups of options, with per-group rules and a pricing mode. *The customer* sets the contents. See [build-your-own](/docs/bundles-and-composites#build-your-own-composites). ## Organizing ### Category Your shop's primary structure; a product has one home category. See [organizing](/docs/organizing-the-catalog). ### Collection A flexible grouping a product can belong to many of, static or rule-driven — used for merchandising. See [organizing](/docs/organizing-the-catalog#static-vs-rule-driven-collections). ### Tag A free-form label used for search and rule-driven [collections](#collection). ### Taxonomy A global, standard classification code for marketplace and feed export — distinct from your own [categories](#category). ### Channel Where a product is sold — in-store, online, QR, marketplace, messaging. See [organizing](/docs/organizing-the-catalog#sales-channels). ### Location A place your business operates. Prices, stock, availability, and resources all hang off a location; you need at least one. Back to [Start here](/docs/) or the [FAQ](/docs/faq). --- # Start here URL: /docs > How to set up any business on Cimplify so the data fits what you actually do. A practical, complete guide for merchants and for the AI agents that help them. This is the manual for operating a business on Cimplify. Today it covers the foundation everything rests on — **modelling the business** so its products, prices, schedules, and stock describe what actually happens — and it grows from there. It is written first for the **AI agents** that set businesses up and operate them, and for the people working alongside them. So it's precise on purpose: decision rules are explicit and stated as "if this, then that", field names and options are exact, and every page is available as plain Markdown — fetch `/llms-full.txt` for the whole manual in one request, or `/llms/docs/.mdx` for any single page. - **Agents and power users:** follow the [decision tree](/docs/mental-model#the-decision-tree), then use the grey callout boxes and reference tables for the exact fields to set. - **Business owners:** read the plain explanations and worked examples; the grey boxes are configuration detail you can skip. You do not need to read front to back. Start with [The mental model](/docs/mental-model), then jump to the chapter for what's being sold. ## The one idea Cimplify is not a "restaurant app" or a "store app" or a "booking app". It models the **physics of a transaction** — what actually changes hands when a customer pays — and every kind of business is a *mixture* of a few building blocks. A salon is mostly bookings with a little retail. A hotel is bookings, food, and shop items at once. A grocer with a deli is packaged goods plus made-to-order food. So the question is never *"what kind of business am I?"* It is **"what actually moves when someone pays me?"** - A **physical thing** the customer takes away → you sell it as a *product* (retail). - A thing you **make from ingredients or parts** → you sell it as a *recipe* (food). - Your **time, a person, a room, a vehicle** for a period → you sell it as a *service* (a booking). Get that answer right and everything else — stock, pricing, scheduling — falls into place. Get it wrong and you will be fighting the tool. Almost every setup problem traces back to this one question. ## How to use this guide ## The rules that prevent most mistakes 1. **Ask what moves.** A thing, a thing-you-make, or time. This single question decides the [product type](/docs/glossary#product-type), and the product type decides everything downstream. 2. **Model what is true, not a workaround.** "Two room types" is genuinely two room types with separate availability — not one number you decrement. If a setup feels like a hack, you have usually answered "what moves?" wrong. See [the two-room-types lesson](/docs/bookable-resources#the-two-room-types-trap). 3. **A count of seats is not a set of real units.** "20 class spots" is a number. "Ten specific tables" is ten things you assign and take offline individually. They are modelled differently and the difference matters. See [bookable resources](/docs/bookable-resources). 4. **Variants are one product in different forms** (sizes, colours), not unrelated products. A shirt and a hoodie are not variants of each other. See [retail](/docs/retail#when-to-use-variants-and-when-not). 5. **One order can mix everything.** A single basket can hold a packaged good, a made-to-order meal, and a booking. You never force the business into one mode. ## What this guide does not cover This is about **modelling** — shaping your catalogue and bookings. It does not cover building a storefront, embedding checkout, payments setup, or the developer SDK and APIs. Those live in the developer documentation. Here, the goal is simply that your data describes your business accurately, so every surface that reads it behaves the way you expect. --- # The mental model URL: /docs/mental-model > Every business is a mixture of a few simple building blocks: retail, food, and service, plus access and rental. Learn to see them and you can model anything. This is the most important page in the guide. Everything else is detail. Spend five minutes here and the rest will make sense quickly. ## Why "what kind of business am I?" is the wrong question Most tools make you pick a category up front — restaurant, shop, salon — and then everything is shaped around that label. The moment your business is a little unusual (a café that also rents its space for events; a clinic that sells supplements), you are fighting the categories. Cimplify works differently. It doesn't care what label your business wears. It cares about **what actually changes hands when a customer pays you.** There are only a few possibilities, and your whole catalogue is built from them in different proportions. ## The three things that can move Ask this of every single thing you sell: **what does the customer get for their money?** | Building block | What the customer gets | The key trait | You sell it as | | --- | --- | --- | --- | | **Retail** | A physical thing they keep | What you sell is what you count — one sold = one off the shelf | a **product** | | **Food** | Something you made from ingredients | What you sell isn't what you count — a recipe turns stock into the item, with waste | a **product made from a recipe** | | **Service** | Your time, a person, or a space, for a period | Nothing is "in stock"; you sell availability on a calendar | a **service** (a booking) | That's the core. Two more shapes show up often enough to name: - **Access / rights** — a membership, a class pass, a software licence, a digital download, an event ticket. Nothing physical moves and nothing is consumed; you are *granting permission* for something. Sold as a **digital product**, usually on a recurring or instalment [billing plan](/docs/pricing#subscriptions-and-instalments). - **Rental** — the customer takes a physical thing and brings it back. It is not a sale (ownership doesn't transfer) and it is not pure service (a real object is involved). It is a **booking over a physical unit**: the [service](/docs/services) machinery (a period of time, a deposit, a return) applied to a [bookable resource](/docs/bookable-resources) (the actual van, drill, or kayak). ## The decision tree When you (or an agent) look at something a merchant sells, walk this in order. The first match wins. 1. **Does the customer reserve time — a slot, a date range, or a person?** → It's a **service**. Go to [Services](/docs/services). If it ties up a physical thing while it happens (a room, table, court, vehicle), also read [Bookable resources](/docs/bookable-resources). 2. **Does the customer take a physical thing and return it later?** → It's a **rental**: a multi-day service over a bookable resource. [Services](/docs/services) + [Bookable resources](/docs/bookable-resources). 3. **Is it granting access with nothing physical — a membership, pass, licence, ticket, or download?** → It's **access**: a digital product, often on a [billing plan](/docs/pricing#subscriptions-and-instalments). 4. **Is it made to order from ingredients or parts, where making it consumes stock?** → It's **food** (or light manufacturing). Go to [Food](/docs/food). 5. **Does the customer build it themselves from groups of options (a salad, a custom pizza, a gift box)?** → It's still food/retail, but you'll use a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites). 6. **Otherwise — is it a finished physical thing you hand over, where one sale = one unit off the shelf?** → It's **retail**. Go to [Retail](/docs/retail). A single product is almost always one building block. A single **order** is often several — and that's fine. Cimplify happily puts a bag of coffee beans (retail), a made-to-order latte (food), and a table booking (service) in one basket. ## Real businesses are mixtures Once you see the building blocks, every business is just a recipe of them. You don't model the business; you model each thing it sells, and the business is the sum. | Business | The mixture | | --- | --- | | Coffee shop | **food** (drinks) + a little **retail** (beans, mugs) | | Clothing shop | **retail** | | Salon / barber | **service** (appointments) + **retail** (products) + sometimes a [resource](/docs/bookable-resources) (the chair) | | Restaurant | **food** + **service** (tables) | | Hotel | **service** (the stay, over **resources** = rooms) + **food** + **retail** (minibar) | | Gym | **access** (membership) + **service** (classes) + **retail** (supplements) | | Car / equipment rental | **rental** (service over vehicle/gear resources) | | Clinic | **service** (consults) + **retail** (medication) | | Grocer with a deli | **retail** (packaged) + **food** (made-to-order) | | Online course | **access** (digital product + billing plan) | | Manufacturer | **food's** transformation shape with a longer recipe and no rush | | Subscription box | **retail** on a recurring timer | If a business you're modelling isn't in this table, that's expected. Break it into "what moves" line by line and it will be some blend of the same blocks. ## Why getting this right pays off The building block you choose sets the **product type**, and the product type decides what the rest of the system does for you automatically: - Choose **service** and you get a calendar, slots, staff assignment, deposits, and cancellation rules. - Choose **food** and you get recipes, ingredient deduction, waste tracking, and the kitchen workflow. - Choose **retail** and you get simple stock counts and variants. - Choose **digital** and you get downloads, licences, and access grants — with no stock or shipping. Pick the wrong one and you lose all of that and start improvising. The classic example: modelling a hotel's rooms as a single "15 rooms available" number instead of real room types. It looks fine until you sell one deluxe room and the system marks a standard room as unavailable, because they were sharing one count. The fix isn't a workaround — it's modelling the truth: two room types, each with its own rooms. The whole guide is variations on this one discipline. ## Common questions **My business does several of these. Which do I pick?** You don't pick one for the business. You pick one *per thing you sell*. A salon's haircut is a service; the shampoo on the shelf is retail. Model each correctly and they coexist. **What if something seems like two blocks at once?** Usually it isn't — look closer at what the customer actually receives. A "spa day package" feels like one thing, but it's a [bundle](/docs/bundles-and-composites) of services. A "build-your-own hamper" is a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites). Rentals genuinely are a hybrid (service + resource), and that's the one true two-block case — which is exactly why they reuse both systems rather than getting a block of their own. **I'm an agent. How do I decide quickly?** Run the [decision tree](#the-decision-tree) top to bottom on each catalogue item; the first matching rule gives you the product type. Then open that chapter for the exact fields. When unsure between food and retail, ask: *does selling it consume tracked ingredients?* Yes → food; no → retail. **Is "three building blocks" a hard rule?** It's the pattern that holds for the vast majority of commerce, plus access and rental as named hybrids. If you find something that genuinely won't reduce, model it as closely as you can and note it — but in practice almost everything fits. Next: a hands-on [getting started](/docs/getting-started) walkthrough, or jump straight to your block — [retail](/docs/retail), [food](/docs/food), or [services](/docs/services). --- # Organizing your catalogue URL: /docs/organizing-the-catalog > Categories, collections, tags, global taxonomy, and sales channels — how products get grouped, found, and routed to the right place once they're modelled. Modelling decides *what* a product is. Organizing decides *where it shows up and how people find it*. Keep them separate: a product's type and stock are facts; its categories and collections are presentation, and you can change them freely without touching the model. ## Categories vs. collections vs. taxonomy Three grouping tools, three jobs. People most often confuse the first two. So a product sits in **one category** (its home), **any number of collections**, and optionally one **global taxonomy** code. Don't stretch categories to do merchandising — that's what collections are for. ## Static vs. rule-driven collections A collection can list products explicitly (you drag them in), or define **rules** that include matching products automatically. Rules are conditions on product attributes — tags, category, type, price, vendor, condition, allergens, even nested custom data — combined with **and / or**, using operators like *equals*, *contains*, *greater than*, *starts with*, *is one of*, and pattern matching. Use rule-driven collections for anything that should stay current without manual upkeep: - "Under 20" → price is less than 20 - "Vegan" → tag contains *vegan* - "New this month" → created within the last 30 days The collection re-evaluates as products change, so new matching products appear automatically and ones that no longer match drop out. ## Tags **Tags** are free-form labels — *featured*, *bestseller*, *gluten-free*, *summer*. They're cheap, flexible, and they power both search and rule-driven collections. Tag generously: most "shop by X" groupings are just a rule over a tag. ## Sales channels **Channels** control *where* a product (and a collection) is sold: in-store point of sale, the online storefront, QR ordering, marketplace, and messaging or delivery surfaces. A product can be online-only, in-store-only, or everywhere. Set channels to match where you actually sell each item, rather than exposing everything everywhere. ## SEO and display - **SEO title and description** — how a product page appears in search engines. - **Display mode** — whether a product shows as a compact card in a grid, or warrants its own full page. ## A clean setup 1. Put every product in exactly **one category** matching your main navigation. 2. Use **collections** (prefer rule-driven) for every "shop by" and promotional grouping. 3. **Tag** generously so collections and search have signal. 4. Set **channels** per product to its real selling surfaces. 5. Set a **taxonomy** code only if you export to marketplaces or feeds. ## Examples **Clothing shop.** Categories: Women / Men / Kids → Tops / Bottoms / Shoes. Collections: "New In" (created in last 30 days), "Sale" (discounted), "Under 50" (price < 50), "Linen" (tag). Channels: online + in-store. **Café.** Categories: Drinks / Food / Beans & Merch. Collections: "Vegan" (tag), "Seasonal". Drinks on QR + POS; beans and mugs also online. **Salon.** Categories group services (Hair / Nails / Skin) and a Products category for retail. Collection "Bridal packages" (a curated set of [bundles](/docs/bundles-and-composites)). Services on online booking + in-store; retail everywhere. **Multi-brand marketplace seller.** Use the global **taxonomy** on each product so items export cleanly to shopping feeds, while your own **categories** drive the storefront navigation. ## Mistakes to avoid - **Categories as merchandising.** "Sale" and "New" are collections, not categories. - **Manual collections that go stale.** Prefer rules so they stay current. - **Everything on every channel.** Set channels deliberately; an in-store-only item shouldn't appear online. ## Common questions **Can a product be in two categories?** A product has one home category. For additional groupings, use collections — a product can be in as many as you like. **Do collections affect price or stock?** No. They're purely presentation — grouping and surfacing. Price and stock live on the product and its variants. **What's taxonomy for if I have categories?** Categories are *your* navigation. Taxonomy is a *global standard* used when exporting to marketplaces and shopping feeds. Most single-storefront merchants can ignore it. **I'm an agent. How should I auto-organize a bulk import?** Assign each product a home category from its type/name, create rule-driven collections over tags and price for common "shop by" groupings, and set channels from where the merchant says each item sells. Use explicit collection membership only for hand-curated sets. Next: [Worked scenarios](/docs/scenarios) to see complete businesses modelled end to end. --- # Pricing & extras URL: /docs/pricing > How a price is built up, add-ons and custom fields that change it, tax-inclusive vs exclusive, deposits, discounts, and subscriptions and instalments. A price on Cimplify is **built up**, not flat. It starts from the product's base price and accumulates from the choices the customer makes. Understanding the layers keeps pricing predictable and lets you set surcharges in the right place. ## How a line price is built ```text line price = base price (the product) + the chosen variant's difference (size, colour…) + each selected add-on option (extra shot, toppings…) + each filled custom field's surcharge (gift wrap, rush…) ── then × quantity ``` [Build-your-own products](/docs/bundles-and-composites#build-your-own-composites) and [bundles](/docs/bundles-and-composites) compute their own totals; everything else follows the sum above. Knowing this order tells you exactly where to put any given charge. ## Base and variant price The **base price** is the product's starting price. Each [variant](/docs/retail#variants-axes-and-values) carries the **difference** from it — positive or negative — not the whole price restated. "Large +2.00" on a 20.00 base means 22.00. Set differences relative to the base so a base-price change flows through every variant automatically. For [food](/docs/food), note the separation: a size's **price difference** is what the customer pays more, while its **recipe multiplier** is how much more stock it uses. Two different settings; a Large both costs more and uses more. For agents: base is `default_price`; per-variant is `price_adjustment` (added to base). Recipe scaling is the variant's `component_multiplier` and is unrelated to price. ## Add-ons Add-ons are modifier groups attached to a product — "Toppings", "Milk", "Extras". Use them when the base item is the star and the choices adjust it. A **group** has rules: - **Required** — at least one option must be chosen. - **Multiple allowed** — more than one option can be selected. - **Minimum / maximum selections** — bounds on how many. - **Exclusive** — only one at a time. Each **option** has a price (with optional per-location overrides) and can carry its own inventory item, so selecting it draws stock. Common patterns: | You want | Set the group to | | --- | --- | | Pick exactly one milk | required, exclusive | | Up to five toppings, optional | min 0, max 5, multiple allowed | | Add a shot (repeatable upcharge) | an option priced +0.80 | | Choose 2–3 sides | required, min 2, max 3, multiple allowed | If the customer is *building* the item rather than tweaking it, use a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites) instead of a long list of add-ons. ## Custom input fields Custom fields collect information at checkout — an engraving message, a delivery note, a prescription upload, an event date, an allergy. There are 20 field types: short and long text, number, dropdown, radio, checkbox, multi-select, colour, date, time, date-and-time, date range, file, image, URL, email, phone, address, location, and signature. Each field can: - be **required** (blocks checkout until filled), - carry **validation** — length limits, number ranges, a pattern, accepted file types and size, allowed countries, max selections, - carry a **surcharge** added when it's filled — gift wrapping +5.00, rush handling +10.00, - be tagged with a **meaning** — *allergen*, *dietary preference*, *sensitivity*, or *consent* — which promotes the answer to a visible signal on the order rather than buried text. A *consent* field can gate fulfilment on a signed acknowledgement. A field's surcharge is charged when the customer fills the field, and the storefront shows it. Put per-field fees on the field itself — don't fake them as hidden add-ons. ## Tax: inclusive vs. exclusive You enter prices in one of two modes, matching local convention: - **Inclusive** — the number you type is the customer-facing total *with tax already in it* (common where displayed prices include tax). The system works out the pre-tax base. - **Exclusive** — the number you type is the pre-tax base, and tax is added on top at checkout. Set this to how you actually advertise prices, so the figure you type is the figure you mean. Getting it wrong makes every displayed price wrong, so decide it before entering prices. ## Deposits and service money rules [Service](/docs/services) products can require a **deposit** — none, a fixed amount, or a percentage of the total — and define **cancellation**, **no-show**, and **reschedule** fees. These live with the service because they're tied to scheduling. See [Services → Policies](/docs/services#policies) for the full set. ## Discounts Each product has a **discountable** flag (on by default) controlling whether sales and discount codes apply. Turn it off for items you never discount — gift cards, regulated goods, already-reduced stock. ## Subscriptions and instalments A product — most often a [digital](/docs/mental-model#the-three-things-that-can-move) access product, but any type — can carry a **billing plan**: - **Subscription** — a recurring charge on a frequency: weekly, biweekly, monthly, quarterly, or annually. Optionally with a **free trial** period. Memberships, SaaS-style access, a magazine. - **Instalment** — split a one-off price across a fixed number of payments. Pay-over-time goods. A plan can adjust the effective price with a markup (fixed or a percentage), for when the recurring price differs from a one-off price. A one-time access grant (a single download, one event ticket) needs no plan at all. ## Per-location pricing Base prices, add-on option prices, and build-your-own prices can be **overridden per location**, so the same product can cost differently in different shops or cities. Set a location override only where the price genuinely differs; otherwise the base applies everywhere. ## Worked examples **A coffee.** Base 3.00. Size Large +0.80 (variant). Oat milk +0.50 (add-on option). "Extra shot" +0.80 (add-on). A Large oat-milk latte with a shot = 3.00 + 0.80 + 0.50 + 0.80 = 5.10. **An engraved gift.** Base 25.00. A required text field "Engraving" with a +5.00 surcharge. Total 30.00 when filled. **A monthly membership.** Digital product, subscription plan, monthly, 7-day free trial. **A sofa paid over time.** Retail product with an instalment plan over 6 payments. ## Mistakes to avoid - **Wrong tax mode** for your market — every price ends up wrong. Decide inclusive vs exclusive first. - **Putting build-it-yourself logic in add-ons.** Use a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites). - **Hiding a field fee in an add-on.** Charge it on the field itself. - **A recurring product without a billing plan** (it then only charges once). ## Common questions **Where do I put a surcharge — variant, add-on, or field?** On the **variant** if it's an inherent form (Large). On an **add-on** if it's an optional choice the customer makes (extra shot). On a **field** if it's tied to information they provide (engraving, rush). Use the [build-up order](#how-a-line-price-is-built) to decide. **Can an add-on reduce the price?** Option prices are normally additions. To model "remove" choices (no cheese), use a zero or negative option, or a required exclusive group with priced alternatives. **Do deposits work on non-service products?** Deposits are a service concept (tied to a booking). For goods, use an [instalment plan](#subscriptions-and-instalments) if you want pay-over-time. **I'm an agent. How do I price a build-your-own correctly?** Don't sum it yourself line by line — a [build-your-own product](/docs/bundles-and-composites#build-your-own-composites) has its own pricing mode (additive, highest-per-group, tiered, and group rules like first-N-free). Configure those and the total is computed for you. Next: [Bundles & build-your-own](/docs/bundles-and-composites) for packages and customisers. --- # Retail URL: /docs/retail > Things you sell and hand over: products, variants and axes, sizes and colours, stock, conditions, and the rules for when something is a variant and when it's a separate product. Retail is the simplest block: a finished physical thing moves from you to the customer, and the thing you sell is the thing you count off the shelf. Clothes, electronics, books, packaged goods, hardware. You model it as a **product** with its inventory tracked **one-to-one** (one sale = one unit deducted). ## The shape of a retail product A **product** is the thing a shopper recognises and shops for: "Cotton T-Shirt", "Wireless Earbuds". Every product has: - A **name**, **description**, **image(s)**, and a **base price**. - One or more **variants** — the specific forms you actually sell. If your product comes one way only (a single mug), it has one implicit variant and you never think about variants again. If it comes in **sizes, colours, or other forms**, you describe those with **axes** and **variants**. For agents: set `product_type = Product` and `inventory_type = OneToOne`. The base price is `default_price`; each variant's difference is its `price_adjustment`. ## Variants, axes, and values Three words, one simple idea: - An **axis** is a *dimension* the product varies along — "Size", "Colour", "Storage". - A **value** is one option on an axis — "Large", "Red", "256GB". - A **variant** is one real combination you sell — "Red / Large". ```text Product: "Cotton T-Shirt" base price 20.00 ├── Axis "Colour": Red, Blue ├── Axis "Size": S, M, L └── Variants you actually stock: Red / S +0.00 Red / M +0.00 Blue / L +2.00 ← bigger sizes cost a little more ``` Key points: - **You don't create every combination.** Three colours × four sizes is twelve *possible* variants, but you only create the ones you really stock. Create Red/S and Blue/L; skip the rest if you don't carry them. - **Prices are relative.** A variant doesn't restate the whole price; it carries the *difference* from the base. "Large +2.00" means base 20.00 → 22.00. Change the base price and every variant follows. - **Each variant can have its own** SKU, barcode, images, and a flag for which one is **preselected** on the storefront. ### How variants load (a performance setting) There is **no limit on the number of variants** a product can have. This setting only controls *how they load*, for performance — it is not a cap. | Setting | What it does | When to use | | --- | --- | --- | | **Load all at once** (`FetchAll`) | Fetches every variant up front. | The normal case — roughly 50 variants or fewer. | | **Load on demand** (`UseAxes`) | Loads only the axes and values, then fetches the exact variant when the shopper picks one. | Large grids — a phone with storage × colour × carrier running into the hundreds or more. | Default to loading all at once. Switch to on-demand when the combination count gets large; it handles hundreds of variants comfortably. The ~50 figure is just the sensible point to switch loading strategy, not a ceiling on how many you can sell. ## Stock: what you sell is what you count In retail, one sale deducts one unit. Each variant maps to one inventory item, usually matched by **SKU** — set the variant's SKU to the inventory SKU and stock decrements automatically on each sale. Under the hood this uses the same "recipe" mechanism that [food](/docs/food#the-recipe-bridge) uses, but for retail it collapses to the trivial case: one unit, zero waste. You don't configure a recipe for retail; matching SKUs is enough. (This shared mechanism is why a business can be part retail and part food without two separate systems.) Stock is tracked per variant, and per location if you have several. A few related fields: ## Other fields worth knowing ## When to use variants, and when not This is the most common retail modelling mistake, so be deliberate. **Use variants** when the items are the *same product* in interchangeable forms. The customer wants "this jacket" and then chooses size and colour. The forms share a name, description, images, and category. Sizes and colours of one garment, storage tiers of one phone, scents of one candle. **Use separate products** when the items are genuinely different things a shopper compares side by side. A t-shirt and a hoodie are not variants of each other, even from the same brand. A 13" and 15" laptop *might* be variants (same model, two sizes) or separate products (different models) — decide by whether the customer experiences them as one product with a choice, or two products to compare. **Variant explosion.** Don't create every theoretical combination. Three axes of five values is 125 variants, most of which you never stock — create only the real ones. And if your "axes" are really unrelated (a shop's entire range crammed into one product), you're modelling many products as one; split them. ## Worked examples **A clothing line.** Each garment is its own product. "Colour" and "Size" axes. Create the in-stock combinations, each with a matching SKU. Larger sizes that cost more carry a `+price` on those variants. "New In" and "Sale" are [collections](/docs/organizing-the-catalog), not categories. **A phone.** One product, axes "Storage" and "Colour". Many combinations → switch to load-on-demand. Each variant has its own SKU; serial numbers are tracked in inventory, not as variants. **A single artwork.** One product, one variant, quantity 1, condition as appropriate. No axes. **A wholesale-only case of wine.** A product with a minimum order quantity so it can't be bought as a single bottle. ## Mistakes to avoid - **Making unrelated products into variants** to "keep them together". Use a [collection](/docs/organizing-the-catalog) for that instead. - **One variant per serial number.** Serials live in inventory batches; the variant is the model/configuration. - **A gift set as a variant.** A set of products sold together is a [bundle](/docs/bundles-and-composites). - **Forgetting SKUs**, so stock can't match and never decrements. ## Common questions **Do prices have to differ per variant?** No. Most variants cost the same as the base (difference of 0). Only set a difference where a form genuinely costs more or less. **Can different variants have different images?** Yes — each variant can carry its own images, so picking "Red" shows the red photos. **How do I handle the same item in multiple shops?** Stock and price can be set per location. The product is one; its availability and pricing vary by location. **What about a product that's sometimes made to order?** If selling it consumes tracked ingredients, it's [food](/docs/food), not retail — even if it looks like a packaged good. If it's just "we'll restock", keep it retail and enable backorder. Next: [Food](/docs/food) for things you make, or [Pricing & extras](/docs/pricing) for add-ons, custom fields, and tax. --- # Services URL: /docs/services > Time you sell over a calendar: appointments vs multi-day stays, duration, capacity, availability, staff, deposits, cancellation and reschedule policy, and multi-day check-in/out. A service sells time and capability: the customer reserves a slot or a date range, a person or a space is committed, and you deliver value over that time. Haircuts, consultations, classes, hotel stays, rentals, venue hire. You model it as a **product** of type **Service**. If the service ties up a physical thing while it happens — a room, table, chair, court, or vehicle — read [Bookable resources](/docs/bookable-resources) alongside this page. That's where most of the subtlety lives. ## The first decision: appointments or multi-day? The single biggest service choice is the **scheduling mode**: - **Within a day** (intraday) — booked as time slots inside a day: a 30-minute haircut, an hour consultation, a fitness class at 6pm. Cimplify generates bookable slots from your opening hours and the service duration. - **Multi-day** — booked as a span of days: a hotel stay, a three-day van rental, a week of co-working, a weekend venue hire. Cimplify reasons in nights or days with check-in and check-out, not minute slots. This choice must match the duration unit, and Cimplify enforces it: | If the duration is in… | the mode is… | | --- | --- | | minutes or hours | within a day | | days, nights, weeks, months, years | multi-day | For agents: set `scheduling_mode` to `Intraday` or `MultiDay`, and `duration_value` + `duration_unit` (e.g. `2` + `Nights`). They must be coherent — `Nights` cannot run intraday. Prefer `duration_value`/`duration_unit` over the legacy `duration_minutes`. ## Duration and capacity - **Duration** — how long one booking lasts. A specific variant can override it (a "full set" manicure taking 60 minutes where the base is 30). - **Capacity** — how many participants one slot holds. A 1:1 consultation is 1; a yoga class might be 20. **Capacity is a headcount, not a set of real units.** A plain capacity number is right when there's nothing physical to assign — a class with 20 spots, a walking tour. The moment specific rooms, tables, or vehicles are involved, a number can't tell you *which* one, can't keep two room types from sharing a pool, and can't be assigned at check-in. Then you need [bookable resources](/docs/bookable-resources), not a capacity number. Buffers and prep round this out: **preparation time** before a booking starts, and **buffer before/after** for turnaround. These block the calendar around the booking without being billable time — clean-down between salon clients, room turnover between stays. ## Availability: when can people book? Availability is defined per location in two layers: - **Weekly rules** — your recurring opening windows: "Mon–Fri 09:00–17:00", each with an optional capacity override. For multi-day services, a rule also controls whether a *new* stay may **start** on that weekday — useful for a hotel that's open every night but takes no Sunday check-ins. - **Exceptions** — one-off overrides: a public holiday (closed), a special event with different hours, or a date range with reduced capacity. An exception can cover a single day or an inclusive range. A slot is bookable only when a weekly rule opens it, no exception closes it, and (where required) staff and resources are free. ## Staff If the service needs a person, mark it as requiring staff and add a **staff requirement**: how many staff, optionally limited to a **role** or a **skill**, and whether *any* qualified person is fine or a *specific* person must be chosen. Each staff member has: - their own **availability** (weekly working hours plus time-off exceptions), - a **booking profile**: skills, a personal duration override, a personal buffer between bookings, a daily booking cap, and whether customers can pick them directly. Use this anywhere the booking is really booking a person's time — salons, clinics, tutoring, consulting. ## Policies Services carry the money-and-trust rules. Set the ones you actually enforce; leave the rest off. ## Multi-day stays in detail Multi-day services add a vocabulary layer so the booking reads correctly: - **Check-in / check-out time** — the time of day a stay begins and ends (in from 15:00, out by 11:00). These are times of day, not full dates. - **Minimum / maximum stay** — length limits in the duration unit (at least 2 nights, at most 30). - **Handover wording** — choose the language: *check-in / check-out* (hospitality), *pickup / return* (rental), *delivery / collection*, *access / vacate* (space), *move-in / move-out* (furnished), or your own custom labels. This only changes wording, not behaviour, but it makes the booking read right to staff and guests. A multi-day service almost always sits over a [bookable resource](/docs/bookable-resources) — the actual room or vehicle. Model the resource pool first, then the service that books it. ## Services that use materials A service can consume stock as it's delivered — hair colour uses dye and developer; a treatment uses supplies. Add a **recipe** of ingredients to the service exactly as you would for [food](/docs/food#the-recipe-bridge). Service and food share the same consumption bridge, so a haircut-with-colour deducts dye while it books a stylist's time. ## Worked examples **A haircut.** Service, within a day, 45 minutes. Requires a stylist (any qualified, or a specific one the customer picks). Deposit optional; cancellation window a few hours; a no-show fee. **A yoga class.** Service, within a day, capacity 20, no resource needed. Weekly rules for the class times. No staff requirement unless you assign instructors. **A hotel room night.** Service, multi-day, nights, min-stay 1, check-in 15:00 / check-out 11:00, handover wording "check-in/check-out", over a [room resource type](/docs/bookable-resources). Deposit and a cancellation-notice policy. **A consultation that needs a room and equipment.** Service with *both* a staff requirement and a [resource](/docs/bookable-resources) requirement; both are checked before the slot is offered. ## Mistakes to avoid - **Using a capacity number where real units exist.** See the warning above and [bookable resources](/docs/bookable-resources). - **A duration unit that contradicts the mode** (nights with intraday). Cimplify will reject it; set them coherently. - **Forgetting availability rules**, so no slots ever generate. - **Putting materials a service uses into "notes"** instead of a recipe, so stock never deducts. ## Common questions **Can a service have no staff and no resource?** Yes — a self-service or capacity-only offering (a class, a tour) just needs a duration, capacity, and availability. **How do deposits get collected?** The deposit policy on the service decides what's taken at checkout; the rest is the balance. Deposits are independent of the scheduling model. **Can prices or availability differ by location?** Yes. Availability rules are per location, and prices can be set per location. **What's the difference between capacity and a resource, really?** Capacity is "how many people fit". A resource is "a specific thing that gets used up and assigned". 20 class spots = capacity. 5 specific massage rooms = resources. If you'd ever say "put them in room 3" or "room 3 is closed today", you need resources. **I'm an agent. What's the minimum to make a service bookable?** A service product with a scheduling mode, a duration, and at least one weekly availability rule at a location. Add capacity, staff, resources, and policies as the business needs. Next: [Bookable resources](/docs/bookable-resources) — essential for any service tied to a physical room, table, court, or vehicle. --- # Salons, clinics & appointments URL: /docs/scenarios/appointments > Modelling businesses that sell a person's time: salons, spas, tattoo studios, clinics, photography, tutoring, consulting, pet grooming, driving schools. What moves, the setup, and the trap. These are [service](/docs/services) businesses: you sell time and capability, usually a specific person's, sometimes in a [room or station](/docs/bookable-resources). The core moves are a service with a duration, a staff requirement, and policies. ## Hair salon **Moves:** service (a stylist's time) + retail + material use. 1. Each service is a [service](/docs/services), within a day, with a duration; it **requires a stylist** (any qualified or a specific one). 2. Colour consumes dye/developer → add a [recipe](/docs/food#the-recipe-bridge) to the service. 3. Long-hair surcharge and longer time → a variant with a price difference and a duration override. 4. Deposit + no-show fee protect the calendar. Retail products sit alongside. ## Nail / beauty studio **Moves:** service + retail. 1. Treatments are [services](/docs/services) with durations and staff requirements. 2. Add-on treatments (gel, art) are [add-ons](/docs/pricing#add-ons) or variants with duration overrides. ## Spa **Moves:** service over rooms + retail. 1. Treatments are [services](/docs/services); each **requires a treatment room** ([resource type](/docs/bookable-resources), whole-unit) and a therapist. 2. A "spa day" combining treatments is a [bundle](/docs/bundles-and-composites) of services. ## Tattoo studio **Moves:** service (artist time + a station). 1. Sessions are [services](/docs/services) requiring a specific **artist** and a **station** resource. 2. Design notes and reference images are [input fields](/docs/pricing#custom-input-fields); a deposit is standard. ## Dental / medical clinic **Moves:** service (practitioner + room) + retail + consent. 1. Appointments are [services](/docs/services) requiring a **practitioner** (by role/skill) and a **room** resource. 2. Intake forms and consent are [input fields](/docs/pricing#custom-input-fields) — consent-tagged where fulfilment must be gated. 3. Dispensed products are **retail**. ## Physiotherapy / chiropractic **Moves:** service (a person + a room), often as packages. 1. Sessions are [services](/docs/services) requiring the practitioner and a room. 2. A block of 10 sessions is a [bundle](/docs/bundles-and-composites) or a [subscription](/docs/pricing#subscriptions-and-instalments). ## Photography studio **Moves:** service (shoot + studio) + access (digital delivery) + retail (prints). 1. The shoot is a [service](/docs/services) requiring a photographer and the **studio** resource. 2. Digital galleries are [digital](/docs/mental-model#the-three-things-that-can-move) products; prints are **retail**. 3. Shoot details (location, brief) are [input fields](/docs/pricing#custom-input-fields). ## Tutoring / music lessons **Moves:** service (a tutor's time), often recurring. 1. A lesson is a [service](/docs/services) requiring a specific tutor (or a skill); online lessons need no room, in-person need a room resource. 2. A weekly slot is a recurring booking; a term of lessons is a [bundle](/docs/bundles-and-composites) or [subscription](/docs/pricing#subscriptions-and-instalments). ## Consulting / legal / accounting **Moves:** service (a professional's time). 1. Consultations are [services](/docs/services) requiring the professional; durations per service type. 2. Retainers are [subscriptions](/docs/pricing#subscriptions-and-instalments); fixed-scope work is a one-off service or product. ## Pet grooming **Moves:** service (groomer + station) + retail. 1. Grooms are [services](/docs/services) requiring a groomer and a **grooming station** resource; size/breed variants change duration and price. 2. Pet details are [input fields](/docs/pricing#custom-input-fields). Products sit alongside. ## Driving school **Moves:** service (instructor + vehicle). 1. A lesson is a [service](/docs/services) requiring an **instructor** and a **vehicle** [resource](/docs/bookable-resources). 2. Course packages are [bundles](/docs/bundles-and-composites) of lessons. **Trap across all of these:** if the booking needs both a *person* and a *room/station/vehicle*, add both a staff requirement and a resource requirement — both are checked before a slot is offered. Next: [Hotels, venues & spaces](/docs/scenarios/spaces), or back to the [overview](/docs/scenarios). --- # Cafés, restaurants & food URL: /docs/scenarios/food > Modelling businesses that make things to order: coffee shops, pizzerias, bakeries, food trucks, restaurants, breweries, catering. What moves, the setup, and the trap. These are mostly [food](/docs/food) — made from ingredients, with a [recipe](/docs/food#the-recipe-bridge) bridging what you sell and what you count — often mixed with [retail](/docs/retail) (packaged goods) and [service](/docs/services) (tables). ## Coffee shop **Moves:** food (drinks) + retail (beans, mugs). 1. Drinks are **food** with a **recipe** (beans, milk, cup). 2. A **Size** axis *affects the recipe* (multipliers 0.8 / 1.0 / 1.5); milk and shots are [add-ons](/docs/pricing#add-ons). 3. Bagged beans and mugs are **retail**. **Trap:** mark only Size as affecting the recipe — a Hot/Iced axis usually shouldn't scale it. ## Pizzeria with build-your-own **Moves:** food. 1. Menu pizzas are **food** products with a Size axis (affects recipe). 2. "Create your own" is a [build-your-own](/docs/bundles-and-composites#build-your-own-composites) product: groups Base (pick 1), Sauce, Cheese, Toppings (pick 0–N), pulling from raw stock. 3. "First 3 toppings free" is the Toppings group's pricing rule. 4. A meal deal (pizza + sides + drink at one price) is a [bundle](/docs/bundles-and-composites). **Trap:** customising a menu pizza is add-ons; building one from scratch is build-your-own. ## Bakery **Moves:** food (made to order or in batches) + retail (packaged). 1. Cakes and pastries are **food** with recipes; custom cakes add [input fields](/docs/pricing#custom-input-fields) (message, flavour, pickup date). 2. Pre-packed goods on the shelf are **retail**. 3. A custom-cake deposit is a [service deposit](/docs/services#policies) if booked for a date, or an [instalment](/docs/pricing#subscriptions-and-instalments) otherwise. ## Food truck **Moves:** food. 1. Menu items are **food** products with recipes; sizes and combos as needed. 2. Set the **channel** to the surfaces you actually use (QR ordering, in-person POS); skip online shipping. 3. Sell-outs are stock running to zero — keep recipes accurate so it deducts correctly. ## Full-service restaurant **Moves:** food + service (tables). 1. Dishes are **food** products with recipes; courses and modifiers via [add-ons](/docs/pricing#add-ons). 2. The floor is a **table** [resource type](/docs/bookable-resources) (whole-unit, assign-now) with the real tables as units. 3. A reservation is a short [service](/docs/services) booking that requires a table; a party larger than a table packs across several automatically. **Trap:** model tables as resources, not a "seats" number, so you can assign and free specific tables. ## Brewery taproom **Moves:** food/retail (drinks, cans to go) + service (tables, tastings). 1. Pours are **food**/retail; cans-to-go are **retail**. 2. A guided tasting is a [service](/docs/services) with capacity, or over tables if seated. ## Catering **Moves:** food + service (scheduled delivery/event). 1. Packages are [bundles](/docs/bundles-and-composites) of food items, or build-your-own menus. 2. The event date, time, and headcount are captured on a [service](/docs/services) booking or [input fields](/docs/pricing#custom-input-fields); a deposit secures it. Next: [Salons, clinics & appointments](/docs/scenarios/appointments), or back to the [overview](/docs/scenarios). --- # Overview URL: /docs/scenarios > Dozens of real businesses modelled end to end, grouped by family. Pick the group closest to the business — each page shows what moves, the exact setup, and the trap to avoid. These are complete, worked models for real businesses. For each one the first question is always *what moves?* — then the setup follows. They're grouped into families in the sidebar; open the one closest to the business you're modelling. Most businesses mix several blocks, so model each line for what it is and let them coexist. ## The families ## How to read each example Every industry below follows the same shape, so you can scan it fast: 1. **Moves** — the building block(s) the business is made of. 2. **Setup** — numbered steps to model it. 3. **Trap** — the mistake people make, and what to do instead. If the exact business isn't listed, find the closest one — the modelling is the same for its neighbours. When unsure which block something is, run [the decision tree](/docs/mental-model#the-decision-tree). ## Quick reference by industry Fast lookup. "Dominant blocks" lists the main building blocks; nearly all businesses also carry some [retail](/docs/retail). | Industry | Dominant blocks | Key tools | Page | | --- | --- | --- | --- | | Clothing / fashion | Retail | Variants (size, colour) | [Shops](/docs/scenarios/shops) | | Electronics | Retail | Variants, serials in inventory | [Shops](/docs/scenarios/shops) | | Bookshop | Retail | One-to-one, collections | [Shops](/docs/scenarios/shops) | | Pharmacy | Retail + service | Consent field, appointments | [Shops](/docs/scenarios/shops) | | Grocer + deli | Retail + food | Recipes for made-to-order | [Shops](/docs/scenarios/shops) | | Coffee shop | Food + retail | Recipes, size multipliers, add-ons | [Food](/docs/scenarios/food) | | Pizzeria | Food | Recipes, build-your-own | [Food](/docs/scenarios/food) | | Bakery | Food + retail | Recipes, custom-order fields | [Food](/docs/scenarios/food) | | Restaurant | Food + service | Recipes + table resources | [Food](/docs/scenarios/food) | | Catering | Food + service | Bundles, event date fields | [Food](/docs/scenarios/food) | | Hair / nails / beauty | Service | Staff requirement, durations | [Appointments](/docs/scenarios/appointments) | | Spa | Service + resources | Treatment-room resources | [Appointments](/docs/scenarios/appointments) | | Tattoo studio | Service + resources | Artist + station, deposit | [Appointments](/docs/scenarios/appointments) | | Dental / medical | Service + resources + retail | Practitioner + room, consent | [Appointments](/docs/scenarios/appointments) | | Physiotherapy | Service | Session packages / subscriptions | [Appointments](/docs/scenarios/appointments) | | Photography | Service + access + retail | Studio resource, digital delivery | [Appointments](/docs/scenarios/appointments) | | Tutoring / lessons | Service | Tutor requirement, recurring | [Appointments](/docs/scenarios/appointments) | | Consulting / legal | Service | Professional's time, retainers | [Appointments](/docs/scenarios/appointments) | | Pet grooming | Service + retail | Groomer + station, pet fields | [Appointments](/docs/scenarios/appointments) | | Driving school | Service + resources | Instructor + vehicle | [Appointments](/docs/scenarios/appointments) | | Hotel / hostel | Service + resources + food | Room types, assign-later, multi-day | [Spaces](/docs/scenarios/spaces) | | Coworking | Access + resources | Memberships + desks/rooms | [Spaces](/docs/scenarios/spaces) | | Sports courts | Service + resources | Court resources, member subs | [Spaces](/docs/scenarios/spaces) | | Bowling | Service + resources + food | Lane resources | [Spaces](/docs/scenarios/spaces) | | Event venue | Service (shared capacity) | Capacity pool | [Spaces](/docs/scenarios/spaces) | | Parking | Service + resources | Spots or fixed quantity | [Spaces](/docs/scenarios/spaces) | | Self-storage | Rental | Unit resources + subscription | [Spaces](/docs/scenarios/spaces) | | Car / equipment rental | Rental | Vehicle/gear resources, multi-day | [Rentals](/docs/scenarios/rentals) | | Bike / boat rental | Rental | Resources, by hour/day | [Rentals](/docs/scenarios/rentals) | | Gym | Access + service + retail | Membership + class capacity | [Memberships](/docs/scenarios/memberships) | | Online course / SaaS | Access | Digital + subscription | [Memberships](/docs/scenarios/memberships) | | Events / tickets | Access | Digital tickets, capacity/seats | [Memberships](/docs/scenarios/memberships) | | Cinema | Service (seats) | Seat resources or capacity | [Memberships](/docs/scenarios/memberships) | | Escape room | Service + resources | Room resource + group capacity | [Memberships](/docs/scenarios/memberships) | The recurring lesson across all of them: you never chose a "business mode". You named what moves on each line and combined the [building blocks](/docs/mental-model). A business no one has described yet models the same way. --- # Memberships, courses & tickets URL: /docs/scenarios/memberships > Modelling access-led businesses: gyms, online courses, SaaS, events and ticketing, cinemas, escape rooms. What moves, the setup, and the trap. These businesses mostly grant **access** — a membership, a course, a licence, a ticket — which is a [digital](/docs/mental-model#the-three-things-that-can-move) product, often on a [billing plan](/docs/pricing#subscriptions-and-instalments). Some also book a slot or a seat, which adds a [service](/docs/services). ## Gym **Moves:** access (membership) + service (classes) + retail (supplements). 1. Membership is a **digital** product on a monthly [subscription](/docs/pricing#subscriptions-and-instalments), optional free trial. 2. Classes are [services](/docs/services), capacity = class size — no resource unless bikes or mats are individually assigned. 3. Supplements are **retail**. **Trap:** a class with 20 open spots needs only capacity, not resources. ## Online course / membership site **Moves:** access. 1. The course is a **digital** product; ongoing access is a [subscription](/docs/pricing#subscriptions-and-instalments), a one-off purchase needs no plan. 2. Tiers (Basic / Pro) are variants or separate products, depending on whether they're forms of one thing. ## Software licence / SaaS **Moves:** access. 1. The plan is a **digital** product on a [subscription](/docs/pricing#subscriptions-and-instalments) (monthly or annual). 2. Seats and tiers are variants or separate plans; a free trial is a plan setting. ## Events & ticketed admission **Moves:** access (tickets) over limited capacity. 1. A ticket is a **digital** product; ticket types (GA / VIP) are variants or separate products. 2. Limited capacity per event is handled with capacity, or seats as a [shared-capacity resource](/docs/bookable-resources) if you cap precisely. 3. A workshop with a fixed number of seats is a [service](/docs/services) with capacity. ## Cinema / assigned seating **Moves:** access over specific seats. 1. A screening is a [service](/docs/services); seats are a **whole-unit** [resource type](/docs/bookable-resources) if you assign specific seats, or **shared-capacity** for unassigned admission. ## Escape room **Moves:** service over a room. 1. Each room is a **whole-unit** [resource type](/docs/bookable-resources); a session is a [service](/docs/services) requiring the room, with capacity for the group size. **Trap:** if nothing physical is assigned (a streaming subscription, an open online course), it's pure access — a digital product with a plan, no service or resource needed. Back to the [overview](/docs/scenarios), or read [Mistakes to avoid](/docs/edge-cases). --- # Rentals URL: /docs/scenarios/rentals > Modelling take-it-and-return-it businesses: car, equipment, bike, and boat rental. What moves, the setup, and the trap. A rental is the hybrid block: the customer takes a physical thing and brings it back. It is not a [retail](/docs/retail) sale (ownership doesn't transfer) and not a pure service. Model it as a [multi-day service](/docs/services) over a [bookable resource](/docs/bookable-resources) (the actual vehicle or gear), with pickup/return wording and a deposit. ## Car / van rental **Moves:** rental (multi-day service over vehicle resources). 1. "Compact" and "SUV" are **whole-unit** resource types, often [assign-later](/docs/bookable-resources#when-the-specific-unit-is-chosen-now-or-later) (pick the actual vehicle at pickup). 2. The rental is a [multi-day service](/docs/services), days, pickup/return wording, requiring the type. 3. Insurance and extras are [add-ons](/docs/pricing#add-ons) or [fields](/docs/pricing#custom-input-fields); a deposit and early-return policy apply. ## Equipment / tool rental **Moves:** rental of gear. 1. Gear is a **fixed-quantity** [resource type](/docs/bookable-resources#the-three-ways-a-booking-uses-a-resource) (rent 2 drills out of the fleet). 2. The rental is a multi-day service with pickup/return; a deposit covers damage. ## Bike / scooter rental **Moves:** rental, often short. 1. Bikes are **whole-unit** (a specific bike) or **fixed-quantity** (a count from the fleet). 2. Hourly or daily hire is a [service](/docs/services) over the resource. ## Boat / yacht charter **Moves:** rental, often with crew. 1. Each vessel is a **whole-unit** [resource type](/docs/bookable-resources) (often one unit). 2. A charter is a multi-day or by-the-day [service](/docs/services); a skipper is a staff requirement. **Trap:** a rental is never a retail sale — if you model it as a product that "sells", you lose the return, the deposit, and the availability of the physical unit. It's a service over a resource. Next: [Memberships, courses & tickets](/docs/scenarios/memberships), or back to the [overview](/docs/scenarios). --- # Shops & retail URL: /docs/scenarios/shops > Modelling shops that sell finished goods: clothing, electronics, bookshops, pharmacies, grocers and delis. What moves, the setup, and the trap. These businesses are mostly [retail](/docs/retail) — finished things handed over — with the occasional service or food line mixed in. Model each as a product, with variants for the forms you stock. ## Clothing boutique **Moves:** retail. 1. Each garment is its own **product**, one-to-one stock. 2. Axes **Colour** and **Size**; create only the combinations you stock, each with a matching SKU. 3. Larger sizes that cost more carry a price difference on those variants. 4. "Summer Sale" and "New In" are rule-driven [collections](/docs/organizing-the-catalog), not categories. **Trap:** a t-shirt and a hoodie are separate products, not variants of each other. ## Electronics store **Moves:** retail (+ a little service if you offer repairs or setup). 1. Each model is a **product**; axes like **Storage** and **Colour**; switch to [load-on-demand](/docs/retail#how-variants-load-a-performance-setting) for large grids. 2. Serial numbers live in inventory batches, **not** as variants. 3. Accessories are separate products; "works with" groupings are [collections](/docs/organizing-the-catalog). 4. A paid setup or repair is a [service](/docs/services) appointment. **Trap:** don't model each serial as a variant — the variant is the configuration (256GB Blue), the serials sit under it. ## Bookshop **Moves:** retail. 1. Each title is a **product** (one-to-one). The ISBN is the SKU/barcode. 2. Formats (paperback / hardback / audio) are either variants of one title or separate products — decide by whether the shopper picks a format of "this book" or compares editions. 3. "Staff picks" and "Award winners" are [collections](/docs/organizing-the-catalog) over tags. ## Pharmacy **Moves:** retail (medication, OTC) + service (consultations) + consent. 1. OTC products are **retail**. 2. Prescription items use a [custom field](/docs/pricing#custom-input-fields) of type *file* (upload) marked **consent**, so fulfilment is gated on a valid prescription. 3. A pharmacist consultation is a [service](/docs/services) appointment. **Trap:** the prescription requirement is a consent-tagged field the system enforces, not a note staff must remember to check. ## Grocer with a deli **Moves:** retail (packaged) + food (made-to-order). 1. Packaged goods are **retail**, one-to-one stock. 2. Deli items are [food](/docs/food) — fixed recipes, or a [build-your-own](/docs/bundles-and-composites#build-your-own-composites) sub. 3. Items sold by weight use the unit and price the customer understands (per kg). **Trap:** a made-to-order sandwich isn't retail — give it a recipe so ingredients deduct. ## Butcher **Moves:** retail + food (cut/prepared to order). 1. Packaged cuts are **retail**, sold by unit or weight. 2. Made-to-order platters and marinated cuts are [food](/docs/food) recipes drawing from raw stock. Next: [Cafés, restaurants & food](/docs/scenarios/food), or back to the [overview](/docs/scenarios). --- # Hotels, venues & spaces URL: /docs/scenarios/spaces > Modelling businesses built on physical units: hotels, hostels, coworking, courts, bowling, venues, parking, self-storage. What moves, the setup, and the trap. These businesses live or die on [bookable resources](/docs/bookable-resources) — real rooms, tables, courts, or units you assign and take offline. The recurring rule: model the actual units (one [resource type](/docs/bookable-resources) per class), never a single capacity number. ## Hotel — the two-room-types case **Moves:** service (the stay) over resources (rooms) + food + retail. 1. Two **resource types** "Deluxe" and "Standard", each whole-unit, [assign-later](/docs/bookable-resources#when-the-specific-unit-is-chosen-now-or-later), with their real rooms as units. 2. The stay is a [multi-day service](/docs/services#multi-day-stays-in-detail), nights, min/max stay, check-in 15:00 / check-out 11:00, requiring the room type. 3. Room service is [food](/docs/food); the minibar is **retail**. **Trap:** selling a Deluxe must not mark a Standard unavailable. Two types with separate pools makes that correct; one capacity number gets it wrong. See [the two-room-types trap](/docs/bookable-resources#the-two-room-types-trap). ## Hostel **Moves:** service over resources, including shared dorms. 1. Private rooms are **whole-unit** resource types; a dorm is a **shared-capacity** type (the pool is the beds). 2. Stays are multi-day services requiring the relevant type. ## Coworking space **Moves:** access (memberships) + service over resources (desks, meeting rooms). 1. Hot desks are **shared-capacity**; dedicated desks and meeting rooms are **whole-unit** resource types. 2. Memberships are [subscriptions](/docs/pricing#subscriptions-and-instalments); day passes and room bookings are [services](/docs/services). ## Sports courts / tennis club **Moves:** service over courts (+ access for members). 1. Each court type is a **whole-unit** [resource type](/docs/bookable-resources); courts are the units. 2. An hour of court time is an intraday [service](/docs/services) requiring a court; members on a [subscription](/docs/pricing#subscriptions-and-instalments). ## Bowling alley **Moves:** service over lanes + food/retail. 1. Lanes are a **whole-unit** resource type; a game or hour is a [service](/docs/services) requiring a lane. 2. Shoe hire is a [fixed-quantity](/docs/bookable-resources#the-three-ways-a-booking-uses-a-resource) resource or a simple add-on; food and drink sit alongside. ## Event venue **Moves:** service over a shared space. 1. The hall is a **shared-capacity** resource type, capacity = seats. 2. Hire is a [service](/docs/services), by day or by hour, drawing the headcount from the pool. ## Parking garage **Moves:** service over spots (or fixed-quantity). 1. Spots are a **whole-unit** type (assigned bays) or **fixed-quantity** (general admission counts). 2. An hour or day of parking is a [service](/docs/services); monthly permits are a [subscription](/docs/pricing#subscriptions-and-instalments). ## Self-storage **Moves:** rental of a unit, ongoing. 1. Each unit size is a **whole-unit** [resource type](/docs/bookable-resources); the units are individual lockers or rooms. 2. A rental is a [multi-day service](/docs/services#multi-day-stays-in-detail) on a recurring [subscription](/docs/pricing#subscriptions-and-instalments). Next: [Rentals](/docs/scenarios/rentals), or back to the [overview](/docs/scenarios). ---