952d274bea
Initial planning docs for the delivery date/time scheduling app. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
14 KiB
14 KiB
Delivery Date & Time — Product Strategy & Differentiation Plan
Project: Shopify delivery / pickup date-&-time scheduling app Owner: Clicks to Cart (C2C Group), Kitchener, Ontario Benchmark: DS Pickup Delivery Date & Time by Devesha Solution (5.0★, 64+ reviews, Built for Shopify, launched Jan 2025) Goal for v1: Full feature parity with DS plus a set of differentiators that make us the obvious upgrade, targeting all Shopify plans (not Plus-only). Document version: 1.0 · August 2026
1. Strategic thesis
DS is a well-executed, well-supported, cheap app that wins on ease of setup and hands-on human support. Its ceiling is that it is a static rules engine: every lead time, capacity limit, and blackout date is typed in by hand, it has no awareness of real fulfillment load, and — by its own admission — full checkout-level enforcement only exists on Shopify Plus.
We win by being the operationally intelligent scheduler:
- Enforce on every plan, not just Plus. We use Shopify Cart & Checkout Validation Functions (server-side, available on all plans) so an order physically cannot complete without a valid, still-available slot — closing the gap DS leaves open for the ~95% of merchants who aren't on Plus.
- Schedule against real capacity, not a number in a box. Capacity is modeled as resources (ovens, drivers, pickers, delivery routes), with soft slot-holds during checkout to kill double-booking races, waitlists when full, and predictive prep-times learned from the store's own fulfillment history.
- Own the whole fulfillment lifecycle, not just slot selection: customer self-service reschedule, automated reminders that cut no-shows, deposits for future-dated made-to-order items, recurring delivery subscriptions, and a real dispatch/ops dashboard with printable run sheets.
- Match DS on the things reviewers love — dead-simple setup (vertical templates that pre-configure a bakery/florist/grocer in minutes), fast Built-for-Shopify-grade performance, and responsive support — so we never lose on their home turf.
Positioning line: "The only delivery scheduler that enforces on every plan and schedules against your real capacity."
2. Feature parity baseline (must-have to match DS)
Everything DS does, we do. This is table stakes, not differentiation.
| Area | Parity requirement |
|---|---|
| Fulfillment methods | Shipping, Local Delivery, Store Pickup as independent paths, each with own rules/rates/calendar |
| Date & time picker | Calendar date → available time slots; unavailable dates/slots hidden, not just rejected |
| Cut-off times | Per day/method threshold after which that day's slots close |
| Preparation time | Configurable lead-time buffer, settable per product |
| Date ranges | Range selection where the fulfillment model calls for it |
| Blackout dates | Block specific dates per location/method; disappear from the picker |
| Weekday/date enable-disable | Independent per location and per method |
| Order/slot limits | Max orders per slot/day per location to prevent overbooking |
| Multi-location | Each location: own address, hours, calendar, blackout dates |
| Map display | Pickup locations on Google Maps |
| Radius / driving-distance eligibility | Determine if an address qualifies for local delivery |
| Auto location assignment | Route order to nearest eligible location |
| Inventory-based location | Exclude a location that doesn't stock the ordered product |
| Product-scoped rules | Availability & lead time by product / collection / vendor / type |
| Cart-content rules | Block a slot based on what's actually in the cart |
| Product-condition-by-location | Restrict a product to certain locations |
| Zone/distance rates | Rates vary by location, postal/ZIP, distance, method |
| Placements | Cart page, cart drawer, product page, checkout (Plus), thank-you, order-status, POS |
| Accounts & i18n | Recognize returning customers; customizable, multi-language widget text |
| Write-back to order | Chosen date/time/location visible on the order record |
3. Differentiators (how we beat DS)
Grouped by theme. Each names the DS gap it closes and a rough build tier (v1 = launch, v1.x = fast-follow, v2 = later).
3.1 Enforcement & correctness (the technical moat)
- All-plan checkout enforcement (v1). Cart/Checkout Validation Function blocks completion server-side if the slot is missing or has since been taken — works on Basic/Shopify/Advanced, not just Plus. DS gap: enforcement is Plus-only.
- Soft slot-holds with TTL (v1). When a shopper reaches checkout, we reserve their slot's capacity for N minutes so two shoppers can't grab the last slot. Expired holds auto-release. DS gap: "hidden unavailable" doesn't handle the race; last-slot double-booking is possible.
- Timezone- & DST-safe slots (v1). All slots computed in the store/location local timezone, DST-correct, with explicit customer-facing timezone labels. DS gap: a class of bugs DS reviewers hint at with "mixed date messaging."
- Unambiguous pickup-vs-delivery copy (v1). Method-specific labels and confirmation strings, never a stray "estimated delivery date" on a pickup order. DS gap: a named review complaint.
3.2 Capacity intelligence
- Resource-based capacity (v1). Capacity modeled as named resources — oven batches, delivery drivers, pickers, prep stations — not just an order count. One slot can consume different resource amounts depending on cart contents. DS gap: single flat "max orders per slot."
- Waitlist & backorder for full slots (v1.x). Customer can join a waitlist; auto-promoted (and notified) if capacity frees up.
- Delivery-density / minimum-order routes (v1.x). Only offer a delivery day to a postal code once a route threshold is met, or steer sparse areas to specific days. Cuts delivery cost. DS gap: none — radius eligibility only.
- Predictive prep-time & demand (v2, AI). Learn actual prep/fulfillment durations from the store's order history and suggest lead-times and capacity limits, instead of pure manual config. DS gap: explicitly cannot derive lead times from data.
3.3 Fulfillment lifecycle (beyond the slot pick)
- Customer self-service reschedule (v1.x). Magic-link / order-status portal to change slot post-purchase, with live capacity re-check and hold. DS gap: not offered.
- Automated reminders & ETA notifications (v1.x). Email/SMS "your pickup is tomorrow," "out for delivery, ETA 2–4 PM." Cuts no-shows for the exact verticals DS serves. DS gap: none.
- Deposits / partial payment for future-dated orders (v2). Take a deposit now, balance on fulfillment — critical for cakes, furniture, made-to-order. DS gap: none.
- Recurring / subscription slots (v2). Weekly grocery or repeat delivery on a standing slot. DS gap: one-off only.
- Group / multi-drop catering orders (v2). One order, multiple delivery points or large batch capacity consumption.
3.4 Merchant operations
- Dispatch & ops dashboard (v1). Bookings by slot/day/location, capacity-utilization heatmap, revenue by method, no-show/reschedule tracking. DS gap: basic calendar view only.
- Printable run sheets & picking lists (v1.x). Per-driver route manifests and per-slot picking lists, exportable/printable. DS gap: none.
- Vertical setup templates (v1). One-click "Bakery / Florist / Grocer / Furniture / Caterer" presets that pre-configure methods, slots, prep-times, and copy. Productizes the hand-holding DS does manually — beats them on their own strength (ease of setup).
- Auto-imported public holidays (v1.x). Pull region/country holiday calendars so merchants don't hand-enter blackout dates. DS gap: all blackout dates are manual.
3.5 Platform & integration
- Headless / Storefront API support (v1.x). Works on Hydrogen / custom storefronts, not just theme widgets.
- Merchant-facing REST/GraphQL API + webhooks (v2). Push booking data to a WMS/ERP (e.g. Odoo — relevant to C2C's stack) so slots flow into back-office systems.
- POS UI extension (v1). Staff run the identical scheduling flow against the same capacity pool for phone/in-person orders. (Parity item, but we make the POS UX first-class.)
4. Additional pain points we solve (that neither app markets)
- The last-slot race condition — solved by slot-holds (§3.1). A genuinely hard technical problem most apps ignore.
- No-shows and missed pickups — solved by reminders + reschedule (§3.3). This is the #1 operational loss for bakeries/florists.
- Delivery cost bleed on sparse routes — solved by delivery-density thresholds (§3.2).
- Setup fatigue — solved by vertical templates + holiday auto-import (§3.4). Time-to-value in minutes.
- Made-to-order cash flow — solved by deposits (§3.3). Merchants front material cost weeks before fulfillment.
- Back-office double entry — solved by the merchant API/webhooks (§3.5). Bookings land in the ERP automatically.
- Festival/cultural demand spikes (C2C's own use case) — solved by capacity intelligence + waitlists + pre-set surge blackout templates, so a Diwali/wedding-season spike doesn't overpromise.
5. Data model (generic + Shopify mapping)
Restated platform-agnostically, then mapped to how it lives on Shopify. App-owned relational data lives in our Postgres via Prisma; a thin, read-optimized slice is mirrored to Shopify metafields/metaobjects so it's visible on the order and reusable by Functions and POS.
| Entity | Purpose | Shopify home |
|---|---|---|
| Shop | Installed store, plan, settings, billing tier | App DB |
| FulfillmentMethod | Shipping / Local Delivery / Pickup; top-level configurable type | App DB |
| Location | Dispatch/pickup point: address, coords, hours, blackout calendar | App DB (+ maps to Shopify Location where relevant) |
| Zone | Where a location's delivery reaches — ZIP list / radius / driving distance | App DB |
| SlotTemplate | Recurring weekly slot: weekday, start/end, capacity, per location per method | App DB |
| SlotOverride | Date-specific exception: extra hours, reduced capacity, closed | App DB |
| BlackoutDate | Blocked date scoped to one/several/all locations/methods | App DB |
| CapacityResource (new) | Named resource (oven, driver, picker) with per-slot limits a booking consumes | App DB |
| ProductRule | Product/collection/vendor/tag override of lead time, methods, locations | App DB (product refs via metafield) |
| Rate | Price table for a method keyed by zone/distance/weight/value | App DB → Delivery Customization Function |
| SlotHold (new) | Temporary capacity reservation during checkout, with TTL | App DB (Redis-backed) |
| Booking | Confirmed reservation: order ref, slot, location, method, date/time, resources consumed | App DB + written back to order via metafield/attributes |
| Waitlist (new) | Customer waiting on a full slot; promotion state | App DB |
| Reschedule (new) | Change history of a booking's slot | App DB |
| Notification (new) | Reminder/ETA message queue and delivery log | App DB |
| Deposit (new, v2) | Partial-payment record linked to a future-dated booking | App DB + Shopify draft/order |
| RecurringBooking (new, v2) | Standing slot subscription generating child Bookings | App DB |
Why app-DB-primary, not metaobject-primary (unlike DS): capacity math, holds, waitlists, and analytics need transactional integrity and fast aggregate queries that metaobjects can't give. We treat Shopify as the system of record for the order and our DB as the system of record for scheduling, syncing the confirmed slot back onto the order so staff and POS see it natively.
6. Pricing strategy
DS prices oddly — the same features cost more on a higher Shopify plan ($6.99 → $12.99), which punishes growth and leaves value on the table. We price on value delivered, not the merchant's Shopify tier.
| Tier | Price (target) | Who | Includes |
|---|---|---|---|
| Free | $0 | Solo / single-location | 1 location, 3 methods, date/time picker, blackout dates, product rules, widget customization, i18n, all-plan checkout enforcement, 1 vertical template |
| Starter | ~$9.99/mo | Growing single/dual location | Everything Free + cut-off/prep-time, order limits, resource capacity (basic), dispatch dashboard, holiday auto-import, up to 3 locations |
| Growth | ~$19.99/mo | Multi-location operators | Unlimited locations, zones/rates, distance auto-assignment, waitlists, reschedule portal, reminders (email), run sheets, delivery-density routes |
| Pro | ~$39.99/mo | High-volume / ops-heavy | SMS reminders, predictive prep-time (AI), deposits, recurring slots, merchant API/webhooks, headless support, priority support |
Notes: undercut DS at the entry point (a genuinely capable Free tier wins installs and reviews), then monetize the operational intelligence they can't match. Keep a 7–14 day trial on paid tiers. Consider usage-based SMS as a metered add-on.
7. Go-to-market & "Built for Shopify" posture
- Win DS's strengths first. Reviewers pick DS for setup ease and support. Vertical templates + in-app guided onboarding + fast, human support are non-negotiable for parity.
- Built for Shopify certification is the credibility bar in this category (DS has it). Design to the BfS checklist from day one: App Bridge, Polaris, performance budgets, no layout shift on the storefront widget, accessibility, embedded-app best practices, mandatory GDPR webhooks.
- Lead the listing with the two moats DS can't copy quickly: "enforced on every plan" and "schedules against real capacity." Everything else is parity.
- Target verticals in order: bakeries → florists → grocers/fresh food → caterers → made-to-order furniture. These are DS's own review base; we out-feature them where each vertical hurts most (capacity for bakers, routes for grocers, deposits for furniture, multi-drop for caterers).
8. Phased roadmap (summary)
| Phase | Theme | Ships |
|---|---|---|
| v1 (launch) | Parity + core moats | All §2 parity, all-plan enforcement, slot-holds, resource capacity, timezone-safe picker, dispatch dashboard, vertical templates, POS |
| v1.x (fast-follow) | Lifecycle | Waitlists, reschedule portal, reminders (email→SMS), run sheets, holiday auto-import, delivery-density routes, headless |
| v2 (expansion) | Intelligence & monetization | Predictive prep-time (AI), deposits, recurring slots, merchant API/webhooks, group/catering orders |
The engineering breakdown of v1 into concrete, buildable tasks for Claude Code is in IMPLEMENTATION_PLAN.md.