Mistakes to avoid

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. 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.

Build-your-own as a wall of add-ons

A salad with twenty toppings and per-group rules is a build-your-own product, 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, 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, not something the customer re-buys by hand each month.

The wrong axis scaling the recipe

On 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 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, a scheduling mode, a recipe. 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. 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 for direct answers, or the glossary for any term.