Warehouse Automation BRD — Creme Collective / Sage Distribution

Status: Working Draft
Version: 0.9
Date: May 6, 2026
Authors: Diego Sanz (DataStudios), Danny Castro (Sage Distribution)
Sessions: Discovery Sessions 1–3 (May 4–6, 2026) + Danny Castro screen recordings

High-Level Process Flow

flowchart TD
    subgraph intake ["INTAKE — Two Streams"]
        DTC["DTC<br/>Shopify Storefront"]
        EDI["EDI / B2B<br/>Bamboo Rose · Spring Systems · SPS Commerce"]
    end

    B1["① ORDER ENTRY — Camelot WMS<br/>DTC: TecOMS functional but unstable — replacement on table<br/>EDI: manual — broken ✗"]

    B2["② SHIPMENT CREATION — EDI only<br/>Spring Systems · Bamboo Rose · SPS<br/>ASN · EDI 855 · 856 · 810"]

    B3["③ TRANSPORTATION & ROUTING<br/>Path A: TechShip Desktop — standard retailers<br/>Path B: TMS portal → UPS WorldShip — Nordstrom<br/>Path C: TBD — Bluemercury · Bamboo Rose TMS?"]

    B4["④ BILLING — Camelot Compute Charges<br/>DTC + EDI — same step, same root gap<br/>Root gap: no product dimensions in Camelot"]

    DTC --> B1
    EDI --> B1
    B1 --> B2
    B1 -.->|"DTC skips Bucket 2"| B3
    B2 --> B3
    B3 --> B4

1. Objective

Automate the warehouse fulfillment and billing operations at Sage Distribution (Creme Collective’s 3PL) across three order intake streams — Direct-to-Consumer (DTC via Shopify), EDI/B2B (retailer purchase orders via Bamboo Rose, Spring Systems, and SPS Commerce), and Manual PO (retailer emails PO directly to the Sage orders team, bypassing DTC and EDI integration).

The engagement is structured around the four operational buckets Danny Castro identified in Session 2. Each bucket represents a distinct phase of work with its own pain points, automation approach, and dependencies.

Holiday season deadline is the primary forcing function. At 10× holiday volume, billing alone requires 3–4 people working continuously. Removing the manual billing bottleneck before Q4 is the highest-priority outcome.

Confirmed automation approach (Session 3): Horizontal — automate by bucket across all brands, rather than automating one brand end-to-end before moving to the next. Rationale: faster measurable milestones, earlier quantifiable value (work genuinely removed from team’s plate), avoids repeating the same build steps per client, and enables validation against known-good truth data at each layer. Danny Castro agreed in Session 3.

2. Scope

In Scope

• Bucket 1: EDI order extraction and Camelot entry automation
• Bucket 2: EDI shipment creation and ASN automation (Spring Systems, Bamboo Rose, SPS Commerce)
• Bucket 3: Transportation routing automation — TechShip (standard path) and TMS exception paths (Nordstrom, Bluemercury)
• Bucket 4: Camelot billing automation (Compute Charges) — applies to both DTC and EDI orders
• DTC billing automation (subset of Bucket 4 — same Camelot step, same root gap)

Out of Scope

• Client communication alerts (shipment notifications, inventory alerts) — separate engagement
• DTC order intake (already automated via TecOMS — no work required)
• Shopify storefront changes
• Retailer-facing EDI platform changes
• Accounting reconciliation (UPS freight vs. Camelot charges) — TBD with Diego + Andrea

Adjacent Scope (deferred — not in this BRD)

• Monthly fulfillment billing report to Andrea — Danny spends 1–1.5 days/month building this report; Andrea uses it to invoice clients. Overlaps with Bucket 4 outputs but involves accounting-side logic (UPS rate matching, adjustment reconciliation, international duties). Deferred to a separate Diego + Andrea + Danny scoping conversation.
• UPS bimonthly invoice reconciliation — Line-by-line review of UPS adjustments (dimensional weight corrections, residential surcharges, international duties billed months late) and reinvoicing customers. In 2025 this was skipped entirely. Owned by Andrea/Connie. Out of scope here but noted as a downstream unlock once Bucket 4 billing data is structured.

3. Systems Inventory

API availability (confirmed Session 3): - TechMS (Techdinamics): API confirmed — Danny showed the endpoint configuration during the Session 3 screen share. Integration profiles (pull inventory, push shipments, pull/push orders) are configured in Camelot under Interface Profile List. - Camelot: API confirmed — Danny uses the existing API endpoints built for the TecOMS integration (read shipment info, inventory, receive data). These are a reuse asset for any custom build. - Spring Systems / Bamboo Rose / SPS Commerce: Unknown — API discovery needed. Interim automation may use UI-based methods; longer-term goal is backend API integration.

4. Current State & Pain Points by Bucket

Bucket 1 — Order Entry

Manual PO path (confirmed Session 3 — third intake stream): A retailer sends a purchase order directly to the Sage orders team via email, bypassing both DTC integration and EDI portal routing. The orders team manually enters the PO into Camelot. The downstream process (Buckets 2–4) follows the same path as EDI orders from that point. Volume is lower than EDI but it is a real ongoing channel — Danny confirmed it in Session 3 as a distinct third intake stream that the current BRD had not captured.

DTC path (functional but unstable): Shopify → TecOMS (polls automatically) → Camelot. The order flow works, but TecOMS has accumulated “many breaking points” per Danny — enough that Leila, Jeremy, and Danny have been actively discussing building a proprietary middleware replacement. Danny described it as: “we’ve been kind of fed up with system issues… having a proprietary system — a lot of 3PLs have these because there’s not really a solution that’s been great.” Diego confirmed in Session 1 that with agentic coding this is now more feasible than it would have been before, and explicitly named it as not off the table.

Key asset if a custom middleware is built: The Camelot API endpoints created for the original TecOMS integration already exist (Danny confirmed these in Session 1 — read shipment info, inventory, receive data). A custom system would piggyback on these rather than building a Camelot integration from scratch.

Known DTC constraint (regardless of middleware): Supplies must be entered in the Camelot billing module only — not added to the Camelot order object — or TecOMS pushes an unrecognized SKU to Shopify, which marks the order unfulfilled and requires manual tracking entry to fix.

EDI path (broken): 1. EDI platform sends notification email to Rita 2. Rita logs into EDI portal (each retailer = different system, different login) 3. Rita navigates to the PO, saves as PDF 4. Rita emails PDF to orders@cremecollective.com 5. Creme orders team manually re-types all PO data into Camelot

This is pure duplicate work — the structured data already exists in the EDI portal and is being destroyed into a PDF and retyped. No 2FA on most EDI systems (confirmed in Session 2 for Urban Outfitters, Free People).

Pain level: High. Multiple people, daily, every retailer. Entirely eliminatable.

Bucket 2 — Shipment Creation (EDI only)

After the PO is in Camelot and the order is picked/packed:

1. Rita reviews the EDI order and notes retailer-specific requirements (bagging, labeling, carton marking) — varies significantly by retailer
2. Rita builds the Order Acknowledgment (EDI 855) in the EDI platform
3. Rita builds the ASN (EDI 856) — assigns items to cartons, fills shipment header fields, attaches UPS tracking number
4. Rita sends — EDI platform auto-fires the EDI 810 invoice immediately on ASN send (confirmed for Spring Systems)

Retailer-specific complexity in this bucket: - Spring Systems: 855 + 856 → auto-810. Nordstrom requires MATM# in ASN header + Mark For store code per carton - Bamboo Rose: process TBD — needs Session 3 walkthrough - SPS Commerce: process TBD — needs Session 3 walkthrough

Pain level: Medium-high. Highly manual and error-prone. Automatable once label data is machine-readable (dependency on Bucket 3).

Bucket 3 — Transportation & Routing

Path A — Standard (TechShip Desktop): Used for standard retailers (e.g., Credo Beauty via Spring Systems). Select carrier + service (UPS Ground), enter carton weights, Process & Print → UPS tracking numbers generated. Freight billed to Sage’s UPS account.

Path B — TMS Exception (Nordstrom, fully documented): 1. Submit routing request to Nordstrom CTE portal 2. Receive approval email from Routing@nordstrom.com — contains UPS vendor account A66F31 (3rd Party), MATM shipment numbers, DC assignments 3. Open UPS WorldShip (separate desktop tool). Set Bill To: Third Party. REF1=PO#-DC, REF2=MATM#, REF3=Sage shipment# 4. Repeat per DC — one PO may ship to 5+ DCs

Path C — Resolved in Session 3 (no longer a distinct path): Danny confirmed: Bluemercury follows Path B (TMS portal → UPS WorldShip, similar to Nordstrom). Bamboo Rose follows Path A (TechShip Desktop). So “Path C” is not a third routing architecture — it was a placeholder for retailers whose path was unknown. All retailers now map to either Path A or Path B. Full-cycle walkthroughs from Rita are still pending for Bamboo Rose and SPS Commerce (Rita cannot record until actual orders are available), but the routing path for each is now known at a high level.

Pain level: High for TMS exception paths. Manual, multi-step, error-prone. Each DC requires a separate label run. MATM# must be manually copied from email into WorldShip and Spring Systems ASN.

Bucket 4 — Billing (Camelot Compute Charges)

Applies to both DTC and EDI orders — same step, same system, same root gap.

Current state: Office opens each shipment in Camelot → “Compute Charges” → manually selects and enters all supply line items (box type, labor codes, pick method) based on handwritten notes from the warehouse floor.

Root gaps (three related but distinct problems):

1. No product dimensions in Camelot. Box size is determined by visual judgment at the packing station and written by hand on the physical pick ticket. No SKU-level dims/weights stored anywhere in the system. This is the primary blocker for algorithmic box selection and billing automation.

2. No supply inventory tracking. Packing supplies (boxes, labels, tape, etc.) are not tracked in Camelot inventory at all — no SKU assignments, no consumption deduction, no reorder triggers. The warehouse monitors stock by sight (“down to a pallet, order more”). A scan-at-packing-station approach (scanning a box barcode to auto-capture the supply) is the preferred fix, but it runs into the TecOMS/Shopify constraint below.

3. The TecOMS/Shopify order-object constraint. Supplies cannot be added to the Camelot order object — if they are, TecOMS pushes the unrecognized SKU to Shopify, which then marks the order unfulfilled (requiring manual tracking entry in Shopify to fix). Supplies must be entered in the billing module only. This means any scanning solution must write to the billing module, not the order — which currently has no scan-to-add path in Camelot. Requires a Camelot configuration or API solution.

Scale of pain: - Normal volume: 2–3 hours/day, 2–3 people - Holiday (10× volume): 3–4 people billing continuously all day

Known charge codes:

5. Proposed Automation by Bucket

Bucket 1 — EDI Order Entry Automation + DTC Middleware Decision

Strategic decision required — DTC middleware: Before or in parallel with EDI automation, the team (Leila/Jeremy/Danny) needs to make a go/no-go decision on TecOMS. Two paths:

• Path A — Fix/configure TecOMS: Investigate the order rule flexibility and resolve known breaking points within the existing vendor platform. Lower upfront cost, but constrained by TecOMS’s architecture and whatever Techdinamics supports.
• Path B — Build custom proprietary middleware: Replace TecOMS with a DataStudios-built system that handles Shopify ↔︎ Camelot sync, order rules, and supply logic in one owned platform. Higher upfront cost, but fully tailored to Sage’s needs, no vendor dependency, and the existing Camelot API endpoints mean the Camelot integration side is already built. Diego explicitly noted agentic coding makes this more viable now than it would have been before.

This decision directly affects the scope of Bucket 4 (billing automation) — if a custom middleware is built, supply scanning and box selection logic can be built into it natively, bypassing the Camelot order-object/Shopify constraint entirely.

Phase 1A — PO Extraction: - Set up email forwarding from EDI notification addresses → analytics@cremecollective.com - Parse notification email → extract PO number + retailer + EDI platform - Auto-login to EDI portal (no 2FA on most systems) → navigate to PO → download structured data - Prerequisite: Email forwarding rules set up by Danny/Rita — unblocks Phase 1A immediately, no code required from DataStudios

Phase 1B — Camelot Entry: - Write extracted PO data directly to Camelot via API - Eliminates the PDF-email-retype loop entirely - Prerequisite: Camelot API endpoint and auth details from Danny

Bucket 2 — Shipment Creation Automation

• Once label data is machine-readable (Bucket 3), all ASN header fields are available programmatically
• Auto-populate 855 (acknowledgment) and 856 (ASN) in EDI platform via API or UI automation
• MATM# from TMS approval email (Bucket 3) auto-populated into Spring Systems ASN header
• Mark For store codes populated per carton for Nordstrom sub-shipments
• EDI 810 invoice auto-fires on ASN send (Spring Systems — confirmed) — no additional work needed here for Spring retailers
• Prerequisite: Bucket 3 automation (label data must be machine-readable first); EDI platform API access

Bucket 3 — Transportation & Routing Automation

Path A (TechShip): - Automate TechShip label generation via Techdinamics API - UPS tracking number auto-pushed to Spring Systems ASN — eliminates manual copy-paste

Path B (TMS Exception — Nordstrom): - Automate CTE portal routing request submission - Parse MATM# and DC assignments from Routing@nordstrom.com approval email - Auto-populate UPS WorldShip reference fields per DC - Batch label generation across all DCs

Path C (resolved — no distinct third path): - Bluemercury → scope against Path B automation (TMS portal + UPS WorldShip) - Bamboo Rose → scope against Path A automation (TechShip Desktop) - Pending: Rita’s full-cycle walkthroughs for both when actual orders arrive

Bucket 4 — Billing Automation

Prerequisite (must be completed first): Collect product dimensions and weights for all active SKUs and load into Camelot. This is the primary dependency that unlocks algorithmic box selection and billing automation for both DTC and EDI orders.

Path A — TecOMS order rules (near-term, leverages existing infrastructure): TecOMS has configurable order rules (SQL-like logic) that execute when an order arrives from Shopify. These rules can auto-apply a shipper and box type based on order contents — without touching the order object (which would break Shopify fulfillment). Diego and Danny identified this in Session 1 as a viable near-term path: rather than building custom logic, encode patterns (e.g., “if order contains SKU X in qty ≥ N, assign box 20×14×4”) into TecOMS rules. Limitations: doesn’t work for high-permutation SKU catalogs (hundreds of SKUs × many combinations), but covers uniform or simple catalog clients well. Requires investigation into TecOMS rule flexibility and whether it can write to the billing module specifically.

Path B — Full algorithmic billing automation (longer-term): Once product dimensions are loaded into Camelot: - Algorithmic box selection engine (SKU dims + quantities → optimal box recommendation) - Auto-populate supply line items in Camelot billing module (box type, qty, labor codes) - Auto-trigger Compute Charges on shipment completion - Apply correct charge codes by client (SWEED vs. METACINE vs. others) - Scan-at-packing-station: packer scans box barcode → auto-writes to billing module (not order object) — requires Camelot API or configuration path to billing module

Pick plan automation (Bucket 1 adjacent): Identifying batch-eligible orders (same client, same SKU, same qty) is rule-based and fully automatable — eliminates the manual step of office staff scanning orders to find batch candidates. Low complexity, high value at peak volume.

Recommended prototype client — Metacine: Danny identified Metacine in Session 1 as the best test case for billing automation. Reasons: manageable SKU count (measurable if dims aren’t available), and their new VP of Operations is actively pushing for automated supply consumption tracking — making them a motivated internal champion. If dimensions need to be collected manually for the first pass, Danny confirmed Metacine’s SKU count is small enough to do it. All new clients going forward should be required to provide dims/weights at onboarding.

6. Prerequisites & Dependencies

7. Open Questions

Updated after Session 3 (May 6, 2026). Answered items marked ✓.

Resolved in Session 3

• Camelot API — ✓ Confirmed. Danny showed endpoint configuration (Interface Profile List in Camelot). Existing endpoints from TecOMS integration are a reuse asset.
• TechMS API — ✓ Confirmed. Danny demonstrated API profile setup in Session 3.
• Bluemercury TMS path — ✓ Follows Path B (TMS portal → UPS WorldShip), similar to Nordstrom.
• Bamboo Rose routing path — ✓ Follows Path A (TechShip Desktop).
• Third intake stream — ✓ Manual PO confirmed as distinct intake channel (retailer emails PO directly to orders team).

Highest priority (still open)

• TecOMS vs. custom middleware — go/no-go decision needed from Leila/Jeremy/Danny. What are the specific breaking points? Systemic or fixable?
• Bamboo Rose full cycle walkthrough — Rita to record when actual orders arrive
• SPS Commerce full cycle walkthrough — Rita to record when actual orders arrive
• Bluemercury full cycle walkthrough — Rita may have sent partial videos; confirm with Danny
• EDI platform APIs (Spring Systems, Bamboo Rose, SPS Commerce) — unknown. Discovery needed. Determines whether automation is API-based or UI-based interim.
• TecOMS full admin access for Diego — Danny submitted support ticket; confirm resolution

Medium priority

• TecOMS order rules — can rules write to the billing module (not the order object)? What’s the SQL-like syntax? Can Danny share current rule configuration?
• Supply SKUs — create packing supply SKUs in Camelot inventory now or defer?
• Fineline — which retailers require it, what the workflow looks like
• Moda Operandi — which retailer(s) use this portal? What’s the process?
• Nordstrom: does Spring Systems also auto-fire the 810 on ASN send (same as Credo)?

Lower priority / later phases

• EDI provider fees — which brands pay the ~$50–75/month automation fee? Affects Phase 1 build-vs-buy
• Product dimensions — available anywhere (ERP, 3PL) or need to be measured from scratch?
• UPS reconciliation scope — fulfillment vs. accounting boundary (Diego + Andrea)

8. Success Criteria

TODO: Align with Danny / Leila on specific targets

• Holiday 2026 readiness: billing team reduced from 3–4 people to ≤ 1 at peak volume
• EDI PO extraction: zero manual portal logins by Rita for covered retailers
• EDI Camelot entry: zero manual re-typing of PO data
• Bucket 3: TMS routing requests completed without manual WorldShip data entry
• Billing: supply line items auto-populated for ≥ X% of orders (TBD — depends on dimension coverage)

9. Business Case — Quantified Cost Savings

Two independent sources corroborate the UPS-related opportunity. Figures are estimates; see source notes below.

A. UPS Address Correction Fees — ~$20,000/year

Source: Andrea DeLucia (Controller), April 2, 2026 call (00:28:46–00:36:22)

When an address on an outbound order is incorrect — residential vs. commercial misclassification, missing apartment number, etc. — UPS reroutes the package and re-bills Sage for the correction. These fees are not currently passed through to the client.

Andrea’s estimate: ~$20,000/year in avoidable carrier adjustment fees. Corroborated by Danny Castro in Session 3 (May 6, 2026), who cited a similar figure when discussing uncollected UPS charges.

Automation approach: pre-shipment address validation. Run a UPS API check before orders go out to flag bad addresses before the shipment is created — stopping the fee from being incurred in the first place. This is an independent unlock that does not depend on Bucket 4; it can be built early. Captured in the AI Agents Architecture (CC-344, Accounting Agent) as an agreed quick-win from the April 2 meeting.

B. TechMS Licensing Elimination — ~$5,000/month

Source: Danny Castro, Session 3 (May 6, 2026, 00:09:30)

Sage currently pays ~$5,000/month to Techdinamics for the TechMS (TecOMS) platform. If leadership (Leila/Jeremy/Danny) decides to replace TecOMS with a custom middleware (see Bucket 1 strategic decision), this recurring fee is eliminated. The decision is actively under discussion.

C. Camelot Seat Licensing Reduction — $200–$400/seat/month

Source: Danny Castro, Session 3 (May 6, 2026, 00:10:25–00:11:09)

Adding billing staff during peak season requires adding Camelot user licenses at $200–$400/month per seat. Licenses must be maintained even when not actively used (shutting them down and reconnecting incurs a reconnection fee). Automating billing via a single service login can eliminate the need for 2–3 additional seats.

Estimated savings: $400–$1,200/month in licensing, recurring.

D. Labor Redeployment (Holiday Peak)

Source: Danny Castro, Sessions 2 & 3

At 10× holiday volume, billing alone requires 3–4 people working continuously. Bucket 4 automation reduces this to ≤ 1 person (exception handling + sign-off). Those team members can be redeployed to other warehouse operations.

Summary

10. Phasing

Note: Phases 3A and 1A/1B can run in parallel once prerequisites are met. Phase 4 is the highest-value unlock but has the most upstream dependencies.

11. Critical Dependencies

These are items not owned by DataStudios that must be completed by a hard date for the November 1 go-live to hold. Each one has an external owner. If it slips, the sprint plan slips — there is no code workaround.

The single highest-risk item is product dimensions for all brands. This is a data collection task, not a code task — DataStudios cannot build its way around it. If brands have not provided dimensions by August 22, those brands will not have automated billing on November 1, regardless of how much development time is available. Danny needs to own this from May 1.

12. Sprint Plan

Team: See Section 13

Approach: Horizontal — automate by bucket across all brands. Metacine is the billing pilot to validate the engine; all brands go live November 1.

Timeline: - May 2026 — Discovery & planning (no code) - June–August 2026 — Development (6 × two-week sprints, 2 parallel tracks) - September 2026 — Buffer, hardening, per-brand billing configuration, pre-production validation - October 2026 — Full end-to-end testing, all clients, all buckets - November 1, 2026 — Go-live target: all clients, all systems, before holiday billing crunch

Pre-Sprint: May 2026 — Discovery & Planning

No code. All outputs are access, decisions, and data. Everything here must be complete before June 1.

• Obtain all system credentials: TecOMS, Camelot API, Spring Systems, Bamboo Rose, EDI portals, Nordstrom CTE portal
• Rita records Bamboo Rose + Bluemercury full-cycle walkthroughs (when actual orders arrive — highest priority)
• TecOMS vs. custom middleware go/no-go from Leila / Jeremy / Danny — must be decided in May
• Email forwarding configured: EDI notification addresses → analytics@cremecollective.com
• Product dimension collection for ALL active brands — Danny drives; this is the Bucket 4 critical path for every brand, not just Metacine. Clock starts May 1.
• EDI platform API discovery: Spring Systems, Bamboo Rose, SPS Commerce — determines UI vs. API approach for each
• Architecture design + cloud environment setup

Two-Track Structure

Development runs as two parallel tracks from Sprint 1. Tracks converge in September for billing rollout and in October for E2E testing.

Sprint 1 — June 2–13 | Infrastructure (Both Tracks)

Track A: Shared automation infrastructure — cloud environment, scheduler, error handling, alerting, logging. Email parsing engine: monitors inbound EDI notification emails, extracts PO metadata (PO number, retailer, platform), logs to structured store.

Track B: Same shared infrastructure foundation. TechShip API exploration and integration setup — authenticate, test label creation against a sandbox order, confirm tracking number response format.

Acceptance criteria: Email monitor live and parsing real notification emails. TechShip API authenticated and label creation confirmed end-to-end in test mode.

Sprint 2 — June 16–27

Track A — Spring Systems Extraction (Bucket 1A): Auto-login to Spring Systems portal → navigate to PO → download structured PO data (line items, quantities, UPCs, ship dates, retailer packing/labeling requirements) → staged for Camelot entry. Covers Credo Beauty and Nordstrom.

Track B — TechShip Label Automation (Bucket 3A): TechShip label generation fully automated via Techdinamics API. Input: Camelot order + carrier/service selection. Output: UPS tracking number written back to order record. Covers all Path A retailers. Tracking numbers now exist programmatically — this unblocks ASN automation on Track B.

Acceptance criteria: Spring Systems PO notification → full PO data extracted and staged, zero manual portal interaction. Path A order → label generated, tracking number returned and stored, no manual TechShip Desktop interaction.

Sprint 3 — June 30–July 11

Track A — Camelot Order Entry, Spring Systems (Bucket 1B): Extracted Spring Systems PO data written to Camelot via API. Credo Beauty and Nordstrom orders entered automatically, zero manual re-typing. Validation: auto-entered order compared against parallel manual entry for Danny / Rita sign-off.

Track B — Nordstrom TMS Automation, Part 1 (Bucket 3B): CTE portal routing request submitted automatically from Camelot order data. Approval email from Routing@nordstrom.com parsed — MATM# and DC-to-carton assignments extracted and stored.

Acceptance criteria: Spring Systems PO → in Camelot with correct field mapping, no manual entry. Danny validates against 3 live orders. CTE portal routing request submitted without human interaction; MATM# parsed correctly from approval email.

Sprint 4 — July 14–25

Track A — Bamboo Rose Extraction + Camelot Entry (Buckets 1A+1B): Extends Sprint 2–3 pattern to Bamboo Rose (Free People, Urban Outfitters). UI automation used if no API available — extraction layer is the only new work; Camelot entry framework already built.

Track B — Nordstrom TMS Automation, Part 2 + ASN Start (Buckets 3B + 2): UPS WorldShip reference fields (Bill To Third Party, REF1/REF2/REF3) populated per DC automatically. Batch label generation across all DCs. Begin ASN automation for Spring Systems (Bucket 2) — 855 + 856 auto-populated using tracking numbers from Sprint 2.

Acceptance criteria: Bamboo Rose POs extracted and in Camelot, zero manual logins. Nordstrom PO routed → labels for all DCs generated without manual WorldShip data entry; validated on at least one multi-DC order. Spring Systems ASN draft populated automatically.

Risk note — WorldShip desktop automation: If full WorldShip automation is not achievable by end of Sprint 4, fallback is: pre-fill all reference fields, human clicks Send. Full automation moves to Sprint 5 Track B.

Sprint 5 — July 28–August 8

Track A — SPS Commerce + Billing Engine Start (Buckets 1A/1B + 4): If SPS walkthrough and API access available: SPS Commerce extraction + Camelot entry following the established pattern. If SPS still unscoped: begin Bucket 4 billing engine on Metacine — algorithmic box selection, supply line item auto-population in Camelot billing module.

Track B — ASN Complete + Bluemercury TMS (Buckets 2 + 3C): Spring Systems ASN automation complete (855 + 856, with Nordstrom MATM# + Mark For codes). Begin Bluemercury TMS automation (follows Path B — similar to Nordstrom; applies same CTE/WorldShip pattern). Begin ASN for Bamboo Rose.

Acceptance criteria: Spring Systems ASN filing fully automated, EDI 810 auto-fires on send. Bluemercury routing request submitted automatically. Bamboo Rose ASN in progress.

Sprint 6 — August 11–22

Track A — Billing Engine Complete, Metacine (Bucket 4): Billing engine fully operational for Metacine: algorithmic box selection from SKU dimensions, supply line items auto-populated, Compute Charges triggered on shipment completion, correct charge codes applied (CSTM PK, ORD EC, PICK EA, ORD WH). Danny validates against 5 live Metacine orders — this is the pilot that proves the pattern for all remaining brands.

Track B — ASN Bamboo Rose Complete + Billing Rollout Prep: Bamboo Rose 855/856 ASN automation complete. Begin per-brand billing configuration: load charge code mappings and confirm dimension data availability for each remaining brand. Work through brand list with Danny.

Acceptance criteria: Metacine billing fully automated end-to-end, validated by Danny. ASN automation complete for all Spring Systems and Bamboo Rose retailers. Per-brand billing config underway for at least half of remaining brands.

September 2026 — Buffer, Hardening & Pre-Production Validation

Development is complete. September is not a sprint — it is a dedicated preparation month before October testing.

Weeks 1–2 (Sep 1–12) — Hardening: - Exception handling across all automated buckets (partial shipments, order cancellations, portal timeouts, API failures) - Edge case coverage for Nordstrom multi-DC splits - Per-brand billing configuration for all remaining brands — dimensions loaded, charge codes mapped, spot-checked - UPS address validation automation (Andrea’s item — independent, no data dependency; can be built here if not already done) - Documentation for Danny / Rita: what is automated, what requires human review, how to handle exceptions

Weeks 3–4 (Sep 15–26) — Pre-Production Validation: - End-to-end dry run across all clients and all buckets with Danny / Rita present - Confirm automated output matches manual output for a representative sample of orders per brand - Identify and fix any brand-specific edge cases or field mapping issues surfaced in dry run - Confirm all product dimensions loaded; resolve any remaining gaps with Danny - Danny / Rita sign-off per bucket before October testing begins

October 2026 — End-to-End Testing, All Clients

Full month. No new development. Goal: validate the complete system under real conditions and get go/no-go sign-off from Danny, Leila, and Jeremy.

Week 1 (Oct 1–10): Full cycle testing across all brands and all buckets. Spring Systems, Bamboo Rose, Bluemercury, and SPS Commerce (if in scope). Every automated step run against live or near-live orders.

Week 2 (Oct 13–17): Nordstrom multi-DC edge cases, high-volume scenarios, holiday-scale stress testing. Billing accuracy validation across all brands against known-good manual output.

Week 3 (Oct 20–24): Exception handling validation — intentionally trigger failure scenarios (bad addresses, portal timeouts, missing dimensions) and confirm fallback/alert behavior. Confirm human-in-the-loop steps work as designed.

Week 4 (Oct 27–31): Final fixes from testing. Danny / Rita / Leila / Jeremy sign-off. Go / no-go decision for November 1 launch.

November 1, 2026 — Go-Live

All clients. All automated buckets. Before holiday billing crunch hits.

Sprint Risk Register

13. Team

Last updated: May 6, 2026 — v0.9, post-Session 3