Pre-Book · Phase 1
Prioritized Requirements Specification
Fifty-two requirements across ten areas, prioritized against one goal: taking pre-book from a proof of concept that works to a branded tool dealers choose St. Croix for.
What Phase 2 is for
Pre-book works. It was built as a proof of concept and it has become one of the primary ways St. Croix does wholesale business. That is the problem this specification is written against: the tool carries a large share of B2B volume while presenting itself as an internal utility that happens to be pointed at customers.
Phase 2's goal is not a reskin. It is to make pre-book something a dealer would describe as a good reason to work with St. Croix — a tool that tells them where they stand in a program, what a decision costs, what they bought last season, and what they are committing to before they commit to it. Everything below is prioritized against that sentence.
Where they stand. Program total, distance to the next discount tier, orders used against the cap, and how long the window stays open are scattered, partial, or absent.
Why the tool said no. Ship dates disappear from the picker with no explanation; order caps announce themselves by being hit.
What they just did. Submit is a one-way door with no review in front of it and no confirmation behind it.
Method
Fifty-two requirements across ten areas. Each is written as a capability, not a solution, so that Phase 2 design remains free to solve it well.
| Priority | Count | Definition |
|---|---|---|
| P0 | 14 | Blocks Phase 2 design from starting, or is a live business risk in the tool as it runs today. |
| P1 | 22 | Core to the Phase 2 goal. Without these the tool is improved but not transformed. |
| P2 | 16 | Real value, safely deferrable. Several are worth carrying into Phase 3 or beyond. |
ID scheme. PB-AREA-nn. Areas: FND foundation, DSH dashboard, ORD order building, PRG program logic, REP rep tools, CSV import, SUB submission, ADM administration, SYS system, BRD brand.
Priority matrix
The fourteen P0 requirements plotted against effort, with selected P1s for context. The upper-left cluster is the argument for starting Phase 2 with behavior and legibility rather than with visual design.
Foundation
The assets and paradigm shift that everything else depends on.
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-FND-01 | A complete, high-fidelity UI design file covering every screen and state | The tool has never had a visual source of truth. Nothing can be reskinned, extended, or handed to another team without it | P0 | 2 |
| PB-FND-02 | A component and token system that can inherit the broader dealer-site styles | Phase 3 positions pre-book to sit inside the future B2B platform rather than beside it | P0 | 2 |
| PB-FND-03 | Reframe from static pages to an application shell with persistent program context | The current paradigm is why program state is scattered and why overlays carry so much logic | P0 | 2 |
| PB-FND-04 | Defined empty, loading, error, and success states for every surface | Today these are undesigned; failure is where a tool either earns trust or loses it | P1 | 2 |
| PB-FND-05 | Responsive down to tablet | Depends on OPEN-09 — whether reps work the guide centre on tablets | P1 | 2 |
| PB-FND-06 | WCAG 2.1 AA baseline: contrast, keyboard paths, focus states | A B2B tool used all day by professionals; cheap to build in, expensive to retrofit | P2 | 2 |
Dashboard
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-DSH-01 | Decompose the dashboard into regions that each do one job | IA-01: six unrelated jobs on one accreted surface | P0 | 2 |
| PB-DSH-02 | A program detail view — the program as a single object | IA-02: the thing the tool manages has no screen | P0 | 2 |
| PB-DSH-03 | A persistent program status component: total, distance to next tier, orders against cap, window remaining | The single clearest answer to "where do I stand" — the most common unanswered question in the tool | P0 | 2 |
| PB-DSH-04 | One canonical entry point; the account page links rather than duplicates | IA-05: two front doors that behave differently | P1 | 2 |
| PB-DSH-05 | Saved-order list showing label, line count, value, ship date, and status | A list of undifferentiated orders is unusable past four or five | P1 | 2 |
| PB-DSH-06 | Program history across seasons | Last season's buy is the most useful reference a dealer has and the tool cannot show it | P2 | 3 |
Order building
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-ORD-01 | A ship-date control that explains its own constraints as they change | The only rule a user can fail, and its logic is invisible while it narrows underneath them | P0 | 2 |
| PB-ORD-02 | Cart shows dealer identity and program context at all times | Mis-attribution risk for reps; orientation for everyone | P1 | 2 |
| PB-ORD-03 | A rapid quantity-entry pattern suited to wholesale buying | Dealers buy across a grid of models and lengths, not one product page at a time | P1 | 2 |
| PB-ORD-06 | Name or label a saved order | Makes DSH-05 usable and matches how dealers already think ("first shipment", "tournament stock") | P1 | 2 |
| PB-ORD-04 | Line-level view of what each item contributes to the program | Connects the buying decision to the threshold at the moment it is made | P2 | 3 |
| PB-ORD-05 | Duplicate an existing saved order as a starting point | Second and third orders in a program are usually variations of the first | P2 | 3 |
Program logic
The rules exist and are enforced. Almost none of them are explained. This area is where the tool most visibly reads as internal software.
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-PRG-01 | One canonical program state, displayed consistently wherever it appears | IA-03: dashboard and cart can disagree today | P0 | 2 |
| PB-PRG-02 | Make discount-tier progress explicit: current tier, next tier, what it takes to reach it | The commercial mechanism of the entire program is currently a status sentence | P0 | 2 |
| PB-PRG-03 | Surface program window status — open, closing, days remaining | Deadline pressure is real and the tool never mentions it | P1 | 2 |
| PB-PRG-04 | Communicate the order cap before it is reached | Currently announced by failure | P1 | 2 |
| PB-PRG-05 | Support multiple program buckets in the interface, not only configuration | Depends on OPEN-07; sizes a whole dashboard pattern | P1 | 2 |
| PB-PRG-06 | Warn when an action would drop the program below a tier already cleared | Deleting an order can quietly cost a dealer their discount | P1 | 2 |
Rep tools
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-REP-01 | Persistent, unmissable indication of which dealer the rep is acting for | After the overlay closes, nothing shows it. Highest-consequence, lowest-cost fix in the set | P0 | 2 |
| PB-REP-02 | Guarded dealer switching, with a warning before working context resets | OPEN-01: currently protective but destructive | P1 | 2 |
| PB-REP-03 | A rep home showing every dealer in the book with program status | Reps manage a territory, not a session. The tool has no view of the job they actually do | P1 | 2 |
| PB-REP-04 | Internal-only rep notes, distinct from the dealer-visible note | One free-text field is doing two jobs | P2 | 3 |
| PB-REP-05 | Rep attribution visible on the program and its orders | Supports reporting and commission; depends on CONF-06 | P2 | 3 |
Import
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-CSV-02 | An import reconciliation report: valid, draft, unavailable, missing — each with an action | The backend already computes all four outcomes; the interface discards the distinction. Silent partial imports reach fulfillment | P0 | 2 |
| PB-CSV-01 | A downloadable template and column mapping | Removes the most common cause of a failed import | P1 | 2 |
| PB-CSV-03 | Preview before items enter the cart | Import currently commits before the user can check it | P1 | 2 |
| PB-CSV-04 | Export a program back out as CSV | Dealers reconcile against their own systems; today they retype | P2 | 3 |
Submission
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-SUB-01 | A pre-submit review of the whole program before it is final | The largest commitment in the workflow currently has nothing standing in front of it | P0 | 2 |
| PB-SUB-02 | Explicit confirmation that submission cannot be undone | Users cannot be expected to infer irreversibility from a button | P1 | 2 |
| PB-SUB-03 | A post-submit confirmation surface | IA-04: the workflow currently ends on a screen not designed for the moment | P1 | 2 |
| PB-SUB-04 | A program acknowledgment document, in St. Croix's voice, covering the whole program | Today the dealer's only artifact is a generic Shopify receipt for a season's buy | P1 | 2 |
| PB-SUB-05 | A defined amend path after submission | Depends on OPEN-06 and CONF-03. Dealers will ask regardless of whether the tool supports it | P2 | 3 |
Administration
There is no administrative product. Programs, windows, thresholds, caps, and every word a dealer reads are configured through Shopify theme settings and customer metafields by whoever knows which field means what. This is the largest distance between how pre-book is used and what pre-book is, and it is the requirement most likely to change the shape of the Phase 2 and Phase 3 estimates.
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-ADM-01 | A program configuration interface for operators | IA-06. A live wholesale channel should not be configured in theme settings | P0 | 2/3 |
| PB-ADM-02 | An ops view of program status across all dealers | Ops currently has no way to see how a season is tracking without querying the data directly | P1 | 3 |
| PB-ADM-03 | Managed content for instructions, headings, and tooltips | Copy is a program asset that changes every season; it should not need a developer | P1 | 3 |
| PB-ADM-05 | Open and close a program without a deploy | Ties the program lifecycle to release cycles today | P2 | 3 |
| PB-ADM-04 | A change log for program configuration | When a threshold changes mid-season, someone needs to know who and when | P2 | 3 |
System
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-SYS-01 | Document and harden the pre-book vs. regular-rep-order discriminator | CONF-05. Every backend branch depends on it; both failure directions are silent | P0 | 1/3 |
| PB-SYS-02 | Surface backend failure during save and submit | OPEN-08. A silent failure on submit is the worst outcome the system can produce | P1 | 3 |
| PB-SYS-03 | Decide whether customer metafields remain the system of record for program data | CONF-08. Size limits, no transactions, last-write-wins. Sets the Phase 3 architecture and its cost band | P2 | 3 |
| PB-SYS-04 | Define concurrency behavior when rep and dealer touch one program | OPEN-04. Currently undefined and silently destructive | P2 | 3 |
| PB-SYS-05 | Session recovery for an expired session with a populated cart | OPEN-03. Mode lives in session state; expiry has no defined behavior | P2 | 3 |
Brand
Phase 2's stated goal is that dealers see pre-book as a good way to work with St. Croix. That is not achieved by styling — it is achieved by everything above, plus these four.
| ID | Requirement | Why | Pri | Phase |
|---|---|---|---|---|
| PB-BRD-01 | Pre-book presented as a St. Croix product, with its own considered identity inside the dealer site | A tool that looks like internal software is experienced as internal software | P1 | 2 |
| PB-BRD-02 | Program storytelling — what is new this season, what is worth a dealer's attention | The pre-book moment is the single best opportunity St. Croix has to influence a dealer's buy | P2 | 2/3 |
| PB-BRD-03 | Upsell and program-detail components at the point of decision | Named in the anticipated Phase 3 scope; needs design in Phase 2 to be buildable | P2 | 2/3 |
| PB-BRD-04 | Product imagery and merchandising context inside the ordering flow | Dealers are buying rods; the tool currently shows them SKUs | P2 | 3 |
What this sizes
The Statement of Work carries planning estimates of $30,000–$38,000 for Phase 2 design and $50,000–$67,000 for Phase 3 development, both to be confirmed following this phase. Read against these requirements, here is our honest assessment.
| Cluster | Contents | Against the planning estimate |
|---|---|---|
| Phase 2 core | FND-01 to 04, DSH-01 to 05, ORD-01 to 03 and 06, PRG-01 to 06, REP-01 to 03, CSV-01 to 03, SUB-01 to 04, BRD-01 | Sits inside the $30–38k band, toward the upper half. This is the transformation described in the SOW. |
| Phase 2 deferrable | FND-05, FND-06, DSH-06, ORD-04, ORD-05, REP-04, REP-05, CSV-04, BRD-02 to 04 | Can be cut to protect the band, or carried into Phase 3 design. Recommend keeping FND-05 and FND-06 in scope regardless. |
| Phase 3 build | Everything designed above, plus SYS-01 and SYS-02 | Sits inside the $50–67k band if the three variables below are resolved as no-change. |
| Variable — admin | ADM-01 to 05 | Outside both bands. An operator interface is its own product. Recommend scoping separately once its shape is agreed. |
| Variable — data | SYS-03, SYS-04 | Outside the band if metafields are replaced as the system of record. No change to the band if they are retained. |
| Variable — integration | CONF-04 (ERP and downstream systems) | Unknown. Cannot be estimated until St. Croix IT confirms what pre-book is expected to reach. |
Take Phase 2 as the core cluster and hold it to the planning band. Handle the admin interface as a separate, parallel conversation rather than absorbing it into a design phase that would then miss its estimate. Resolve the data and integration variables before Phase 3 is priced, not during it.
What blocks sizing
Nine items from Documents 01 and 03 must close before Phase 3 can be priced with confidence. Five of them are questions, not investigations.
| ID | Item | Owner | Blocks |
|---|---|---|---|
| CONF-01 | Where the final submission lands downstream | Backend | Phase 3 integration design |
| CONF-03 | Orders, draft orders, or program data — and when | Backend | SUB-05, Phase 3 scope |
| CONF-04 | ERP and other downstream systems | St. Croix IT | Phase 3 cost band |
| CONF-05 | The pre-book discriminator | Backend | SYS-01, all backend work |
| CONF-08 | Whether metafields remain the system of record | Joint | SYS-03, Phase 3 architecture |
| OPEN-05 | Saved orders when a program window closes | St. Croix ops | PRG-03, business rules |
| OPEN-06 | Whether an amend path should exist | St. Croix ops | SUB-05 |
| OPEN-07 | Single vs. multiple program buckets in practice | Agency / ops | PRG-05, dashboard pattern |
| OPEN-09 | Tablet use at the guide centre | St. Croix ops | FND-05, responsive scope |
One working session with St. Croix IT and ops closes seven of these nine. It is the shortest path from this documentation set to a Phase 2 statement of work with a firm number attached.