Saltar al contenido principal

Bundles

Great question — this is exactly where a unified POS architecture shines. Bundles exist in both retail and restaurants, but the intent and behavior differ. The trick is: 👉 Same engine 👉 Different bundle types / UX This is how FlowPOS should think about it. Core Idea (Unified Model) Bundle = grouped items + pricing rule + inventory behavior This works for both industries. Your engine should NOT be “retail bundles” vs “restaurant combos”. It should be: bundle types configuration per industry Same tables. Same evaluation service. Bundles in Retail (primary goal) Retail bundles are about: Merchandising + inventory movement Examples: Outfit bundle (shirt + pants) 3 for $30 (mix & match) Buy shoes → socks discount Clearance packs Accessory attach bundles Inventory behavior Always component-level consumption. Retail bundles often: move slow inventory increase ticket size support markdown strategy Retail bundles can be: static dynamic lifecycle driven Bundles in Restaurants (primary goal) Restaurant bundles = combos / meals Examples: Burger + fries + drink combo Family pack Lunch menu combo Upgrade combo (add drink for $1) Choose 1 side from list The focus is: 👉 menu structure 👉 faster ordering 👉 upsell Not inventory lifecycle (usually). Key Difference (very important)

But structurally they are the same concept. Bundle Types That Work for BOTH You can support both industries with these types:

  1. Fixed bundle Retail: gift set Restaurant: combo meal
  2. Mix & match Retail: 3 shirts Restaurant: choose any 2 tacos
  3. Conditional bundle Retail: buy shoes → socks discount Restaurant: add fries → drink discount
  4. Kit (composition bundle) Retail: starter kit Restaurant: recipe kit / meal kit Same model. Data Model Strategy (important) Your existing bundle design already works. You just need: Bundle type flag Add concept: bundle_mode retail restaurant universal But behavior mostly comes from: component groups selection rules Restaurant-specific additions (important) Restaurants need choice groups. Example: Combo includes: 1 main (choose 1 from list) 1 side (choose 1) 1 drink (choose 1) So bundle_component needs: group_key (you already added) min_select max_select This supports combos perfectly. This is the main difference. Inventory differences Retail Inventory is critical. Bundle affects stock strategy. Restaurant Inventory still matters, but: sometimes ingredient level sometimes finished item level modifiers may not affect stock FlowPOS can support both if ledger is flexible. POS UX differences Retail bundle UX auto grouping highlight savings often invisible logic Restaurant bundle UX guided selection flow step-by-step choices faster ordering Same engine → different UI. Reporting differences Retail bundle analytics attach rate slow inventory moved margin impact bundle lifecycle Restaurant bundle analytics combo popularity upsell rate average ticket lift modifier choices Again → same bundle_application table works. MVP recommendation for FlowPOS (important) Implement bundles generically with: bundle bundle_component group_key min/max selection price_method bundle_application That alone supports: ✅ Retail bundles ✅ Restaurant combos No separate architecture needed. Very Important Insight (strategic) This is a big one: Bundles are the first step toward: promotion engine merchandising engine menu engine guided selling AI recommendations Meaning: If bundles are done well → many future features become easier. If you want — next step options I can show you: Unified bundle schema that works for both ⭐ recommended Restaurant combo builder UX design Bundle price allocation algorithm (critical for retail returns) Promotion + bundle interaction rules Modifier vs bundle difference (restaurant architecture) ⭐ very important Guided selling engine design (future FlowPOS differentiator) Just tell me 👍 Bundles are one of the most powerful retail pricing tools because they combine: pricing strategy merchandising promotions inventory movement Bundles increase average ticket and help move slow inventory. Here’s what to add for Pricing & Promotions → Bundles. What “Bundle” means (business meaning) A bundle is a set of products sold together with special pricing or rules. Common retail bundle types: Fixed bundle predefined items fixed price Example: “Outfit set $49” Mix & match choose from group Example: “Any 3 t-shirts for $30” Conditional bundle buy X → get Y discounted/free Example: “Buy shoes → socks 50% off” Kit / pack operational bundle (not promotional) Example: gift box, starter kit These are different behaviors — but share structure. Core concept (very important) Bundle = Structure + Pricing rule Meaning: which items belong how many required pricing logic how inventory is consumed Bundles must consume inventory at component level (always). Never treat bundle as a single stock item unless you support kitting (Phase 2). What you must track For each bundle: name type (fixed / mix_match / conditional / kit) bundle price rule components definition required qty per component eligibility scope schedule locations active status priority (if promo engine later) And per application: which bundle triggered which items were grouped discount generated Database additions (recommended)
  5. Bundle definition table bundle id business_id name type price_method (fixed_price | discount | conditional) price_value start_at / end_at active priority
  6. Bundle components (core) bundle_component bundle_id variant_id (recommended at variant level) min_qty max_qty group_key (for mix & match groups) optional flag (conditional bundles) This supports mix-and-match.
  7. Bundle application tracking You need audit + analytics. bundle_application id bundle_id sale_id amount_generated created_at And optionally link to sale_line grouping.
  8. Sale line grouping (important concept) To know which lines belong to bundle: Add to sale_line: bundle_application_id (nullable) This is extremely helpful for: returns exchanges analytics Inventory behavior (critical) Bundles must: reduce inventory per component respect variant selection validate availability before applying For mix & match: engine must evaluate eligible items dynamically This is where bundle logic intersects promotion engine. Backend functionality you need Bundle evaluation service When cart changes: detect bundle eligibility group lines calculate bundle price generate discount applications assign bundle_application_id Endpoints CRUD bundle preview bundle impact evaluate bundles for cart This can reuse promotion engine later. Frontend screens (PWA) Admin bundle builder (MVP) Simple: name type select components define qty rules define price rule schedule Avoid complex rule builder initially. POS UX Cashier experience: badge: “Bundle applied” bundle preview before confirming highlight grouped items show savings clearly This increases adoption. Apparel importance (very high) Bundles are common in apparel: outfit bundles seasonal kits multi-buy promos accessory attach bundles clearance packs Bundles help move slow sizes/colors. This directly supports markdown strategy. Reports (Metabase — very valuable) Bundle revenue impact Attach rate (accessory attachment) Bundle margin vs individual margin Bundle performance by collection Slow inventory moved via bundles Bundle usage frequency This informs merchandising decisions. MVP vs Phase 2 ✅ MVP bundles bundle + bundle_component tables fixed bundle + mix & match basic bundle_application tracking sale_line bundle link inventory validation schedule support 🚀 Phase 2 (strong differentiation) dynamic bundles (AI suggestions) cross-sell bundles size-aware bundles auto bundle suggestions in POS supplier bundles omnichannel bundles bundle analytics optimization Biggest edge cases (important) Partial return of bundle items (very tricky) Exchange of one item inside bundle Bundle price allocation per item (needed for COGS) Promotion + bundle stacking Bundle with markdown items Rounding issues Multi-location availability differences These must be explicitly designed. Architecture insight for FlowPOS (important) Bundles sit at the intersection of: promotions pricing merchandising inventory optimization If you model: bundle bundle_component bundle_application sale_line grouping You can evolve toward a real merchandising engine. Most POS don’t model this well → opportunity. If you want, next I can give you: Minimal Kysely schema for bundles ⭐ recommended Bundle price allocation algorithm (very important for returns/COGS) How bundles interact with promotion engine ⭐ critical Return logic for bundles (hard problem) Outfit builder design (apparel gold feature) Attach rate analytics model