Quartz 4

extended-catalog-and-preorders

4 min read

Extended catalog + pre-orders

Sell books we don’t have on the shelf, captured as pre-orders, batched into Omnibus.

Problem

Today dungeonbooks.com (Weebly/Square Online) is a mirror of in-store inventory. When a title pops off on BookTok or someone walks in asking for something we don’t carry, our only response is “we don’t have it” and the customer goes to Amazon. We lose the sale and probably the visit.

Edelweiss Omnibus made it easy for us to see what we can order, when, and from whom. It didn’t give customers a way to actually buy those books from us before we put the order in.

Approach

The new dungeonbooks.com (on Medusa, replacing Weebly) lists two kinds of books in one storefront:

  1. In stock — same titles you’d see on the shelf today. Customer pays, we pick from the shelf, ship or hold for pickup.
  2. Available to order — books we don’t have but can get. Customer pays now, the order goes into a fulfillment queue, staff include those titles in their next Omnibus batch order, shipment arrives, we fulfill.

Customers don’t need to know which bucket a book is in. They see “ships in 2 days” or “available to order, ships in 7-10 days.” Same checkout either way.

What lives where

Square POSMedusa (new admin)Omnibus
Walk-in sales✅
In-shelf inventory truth✅mirrors Square
Online orders + payment✅
Catalog enrichment (photos, copy, categories)✅
Customer pre-orders captured✅
Distributor selection + batching✅
Wholesale pricing + discount tiers✅
Receiving incoming shipments✅

The seam is narrow: Square is the inventory database, Medusa is the catalog + online sales engine, Omnibus is the procurement system. Each owns what it already owns.

Customer flow

  1. Customer browses any book on the storefront
  2. Storefront priority: in-stock at the shop > available-to-order via distributor
  3. In stock: “Ships from store in 2 days” — fulfilled from shelf
  4. Not in stock: “Available to order, X-Y days” (lead time pulled from Omnibus catalog data)
  5. Customer pays. Order created.
  6. From here:
    • In-stock SKU: pick + ship + decrement Square stock
    • Pre-order SKU: order lands in a “awaiting distributor” worklist. Staff include those titles in the next Omnibus batch order. Shipment arrives → received into Square → matching Medusa orders flip to “ready to ship” → fulfilled

Catalog ingestion

Adding a hot title to the catalog should take minutes, not days. Two stages:

  • Now: CSV export from Omnibus → import script in Medusa CLI → produces available-to-order Medusa products. Staff refresh weekly or on-demand.
  • Later: Automate when Bookshop.org API ships, or when we get reliable Omnibus data access. Whichever comes first.

What Medusa explicitly does NOT do

Anything Omnibus already does well:

  • Distributor catalog browsing
  • Distributor selection / batching suggestions
  • Multi-publisher order grouping
  • Wholesale pricing / discount tier negotiation
  • Publisher relationship management

Medusa is the customer capture + fulfillment-tracking layer. Omnibus is the procurement brain.

Square ⇄ Medusa sync (in-stock SKUs only)

  1. Square → Medusa: inventory webhook (real-time-ish) + 5-min polling fallback. Mirrors stock counts and new SKUs.
  2. Medusa → Square: single API call on online order placement to decrement Square stock.
  3. Nightly reconciliation: drift check between the two.

Available-to-order SKUs never touch Square — they only exist in Medusa with manage_inventory: false.

Open questions

  • Pre-order payment timing: capture at order time vs hold-and-capture-on-ship. Industry standard is capture at order, refund if cancellation. Confirm with Carrie before implementation.
  • Refund policy when ETA slips badly: at what point do we proactively offer cancellation? 30 days late? Backorder reclassified as out-of-print?
  • Square inventory webhook reliability: depends on Square subscription tier. Verify before launch, fall back to polling if webhook coverage is patchy.
  • In-stock oversell race condition: if a book sells in-store and online within the sync gap. Mitigation: soft reservation when checkout starts, apologize-and-refund flow as fallback. Acceptable rate?
  • Which CSV columns Omnibus exports: depends on what Omnibus actually gives us. ISBN, title, author, price, lead-days, publisher are the minimum. Confirm before writing the import.
  • Bookshop.org drop-ship as fallback: when their API ships, do we use it as another fulfillment path for orders we don’t want to handle ourselves?

Status

Approved by Carrie 2026-04-29. Replaces the original Phase 3 briefs in task-briefs which assumed a generic bidirectional Square sync.

Graph View

Backlinks