St. Croix Rod
Pre-Book · Phase 1

User Flows

Every path a dealer, rep, or admin can take through the pre-book tool as it behaves today — including the mode switching that makes one storefront act like three different products.

Document01 of 04

DeliverableComplete user flows

DescribesCurrent behavior

StatusDraft for review

Open items9

Section 01

How to read these flows

These diagrams describe the pre-book tool as it behaves today. They are not proposals. Where the current behavior is known but the reason for it is not documented anywhere outside the code, it is still drawn as fact. Where behavior genuinely is not established, it is marked as an open item rather than guessed at — those items are collected in Section 09 and carried into the requirements set.

One convention matters more than the rest: a screen is not a mode. The same dashboard and the same cart behave differently depending on which of three modes the session is in. Most of the tool's complexity lives in that fact, so the modes are documented before the flows.

Notation

Screen the user sees
System action
Decision or gate
Irreversible action
Leaves the pre-book flow

Section 02

Actors

Three parties touch pre-book, but only two of them have an interface.

Actor	What they do	Where they work
Dealer	A wholesale customer ordering for their own shop. Builds and submits their own program.	Storefront: dashboard, catalog, cart.
Sales rep	Orders on behalf of a dealer. Cannot proceed until they have chosen which dealer they are acting for. Carries a separate confirmation email of their own.	Same storefront, plus a customer-selection layer that gates everything else.
Admin / ops	Opens and closes programs, sets windows, thresholds, order limits, and all instructional copy. Reviews what comes out the other end.	No interface. Shopify theme settings, customer metafields, and the backend service.

Structural finding

The admin has no product. Everything an operator does — opening a program, setting a discount tier, changing the instructions a dealer reads — happens in Shopify configuration screens that were never designed for the job, in fields whose meaning is only legible to whoever set them up. This is the single largest gap between what pre-book is used for and what pre-book actually is.

Section 03

The three modes

One storefront, one cart, three behaviors. The mode is held in browser session state, and it determines what the cart's primary action does — check out, submit an order, or save into a program.

Fig. 1.1 Mode state machine. The two dashed transitions are where work can be lost: turning pre-book off clears session state, and changing the selected dealer resets the working context. Neither is currently confirmed with the user before it happens.

Risk

Mode lives in browser session state. A session that expires, a second tab, or a device change puts the user in an ambiguous state with a cart that may still hold items. The tool has no defined recovery behavior for this — see OPEN-03.

Section 04

Master flow

The full pre-book path from arrival to a finalized program. Rep-specific and CSV-specific steps are shown here in position and expanded in Sections 05 and 06.

Fig. 1.2 Master flow. Three things are worth noticing: the loop back to the dashboard is the actual shape of the product — a program is built across sessions, not in one pass; the ship-date gate is the only rule the user can fail, and its constraints change underneath them; and the submit step is a one-way door with nothing standing in front of it.

Section 05

Rep branch

A rep is not a different application. It is the same flow with one blocking step in front of it and a different identity attached to everything downstream.

Step	Behavior	Consequence
Land on dashboard	A customer-selection overlay appears before anything else is usable.	A rep cannot accidentally start an order with no dealer attached.
Select a dealer	The rep's working context is bound to that dealer. Saved program data, discount progress, and ship-date rules all resolve against the dealer, not the rep.	The tool now has to track two identities at once for the rest of the session.
Build & save	Identical to the dealer flow.	—
Change dealer	Working context resets so an order cannot attach to the wrong dealer.	Protective, but destructive — and it happens without warning. See OPEN-01.
Submit	Dealer receives the standard Shopify confirmation. The rep receives a separate custom confirmation from the backend.	Two independent email paths that can diverge. See Document 03.
Rep without pre-book	Cart still acts as an order-entry tool, but submits as a normal order with no program state.	A third mode most users never learn exists.

Observation

Nothing in the flow persistently reminds a rep which dealer they are currently ordering for after the overlay closes. For a rep working several dealers in one sitting — the normal case at a guide center — that is a mis-attribution waiting to happen.

Section 06

CSV path

CSV upload is a shortcut into the cart, not an ordering path of its own. This distinction is the source of most of its problems: users reasonably expect an upload to place an order, and it does not.

Stage	What happens	What the user is told
Upload	File is taken from the dashboard or the account page.	A loading modal.
Resolution	The backend decides which SKUs are valid, which are draft, which are unavailable, and which do not exist.	Thin. The four outcomes are computed but not clearly reported back as four distinct outcomes.
Landing	Resolved items are added to the cart.	The cart, populated.
Completion	Nothing. The order is not saved.	Nothing — the user must still set a ship date and save.

Failure mode

A dealer uploads 180 SKUs, 12 fail to resolve, the rest land in the cart, and the dealer saves the order believing it is complete. The 12 missing items surface at fulfillment, not at entry. Reconciliation of a partial import is the highest-value CSV requirement in Document 04 (PB-CSV-02).

Section 07

Save & edit loop

A saved order is a draft inside a program, not an order. It stays attached to the dealer and the program, counts toward the program total, and can be edited or removed until the moment of submit. This loop is the real center of the product and it currently has no screen of its own.

Fig. 1.3 Save and edit loop. Editing re-hydrates the cart from the saved order, which is why large orders need a loading screen. Deleting an order silently changes the program total, which can move the dealer below a discount threshold they had already cleared — a consequence the current interface does not surface.

Section 08

Gates & decision points

Eight points in the flow where the tool decides whether the user may proceed. Only three of them are visible to the user as gates; the rest either fail silently or reshape the interface without explanation.

Gate	Condition	Current behavior on failure	Visible?
Authentication	User is logged in	Redirect away; pre-book never rendered	Yes
Feature flag	Pre-book enabled in theme settings	Redirect away; indistinguishable from no access	No
Dealer selection	Rep has chosen a dealer	Blocking overlay until resolved	Yes
Program window	Program is open for orders	Not surfaced in the flow — see OPEN-05	No
Ship window	One of two available windows chosen	Cannot save	Yes
Ship date	Date inside the allowed range, which narrows by program total and window already used	Options disappear from the picker with no explanation of why	Partly
Order minimum	Program total clears the discount threshold	Informational only — does not block saving or submitting	Yes
Max orders	Program is under the configured order cap	Not communicated until the user hits it	No

Design implication for Phase 2

Five of eight gates are invisible or partly invisible. A tool that dealers experience as premium has to tell them the rules before they run into them — which program window they are in, how many orders they have left, why a ship date vanished, and what the next discount tier costs to reach. This is the largest single cluster of Phase 2 design work.

Section 09

Open items

Behavior that is not established by the current documentation and cannot be responsibly drawn as fact. Each carries forward into Document 04.

ID	Question	Why it matters	Answered by
OPEN-01	When a rep changes dealer mid-order, is unsaved cart content warned about or silently discarded?	Determines whether a save-guard is a bug fix or a new feature	Agency / code
OPEN-02	Is deleting a saved order confirmed?	Irreversible action affecting program total	Agency / code
OPEN-03	What happens when a session expires with items in the cart in pre-book mode?	Recovery behavior is undefined; likely silent data loss	Agency / code
OPEN-04	Can two sessions (rep and dealer) edit the same program at once?	Metafield writes are last-write-wins; concurrent edits may overwrite	Agency / backend
OPEN-05	What happens to a saved order if the program window closes before submit?	Business rule, not a technical one	St. Croix ops
OPEN-06	Is there any amend path after submit, in the tool or by phone?	Determines whether Phase 2 designs one or treats submit as final	St. Croix ops
OPEN-07	Does the multi-program-bucket configuration have proven UI, or only single-program?	Sizes a whole dashboard pattern in Phase 2	Agency / code
OPEN-08	What does the user see if the backend errors during save or submit?	Currently unspecified; a silent failure on submit is the worst case in the system	Agency / backend
OPEN-09	Are dealers or reps using the tool on tablets at the guide center?	Decides whether Phase 2 is responsive design or desktop-only	St. Croix ops