Customer Success — Discovery Prototype (wiring hub)

Iteration goal: FoodBridge's customer success team sees every store a distributor built — newest first — and opens his answers and every file he sent, as he sent them, to set the store up. Only the team gets in.

Screens

Built stores — the team panel: key gate, list, search, downloads, and (v2) a status per store with filter tabs (runs on the seed, no server; team key fb-team-demo)

▶ Start the flow →

Transition map — team access (→ SSOT-5 workflow)

From	Event	To
Panel, no key	OPEN	Key form (the server answers 401)
Key form	SUBMIT_KEY (wrong)	Key form, “That key was not accepted.”
Key form	SUBMIT_KEY (right)	Built stores list (the key is kept in this browser)
List	SEARCH (shop · owner · mobile · GST · id)	List, filtered
List	DOWNLOAD (Excel · setup.json · his files · photos · voice notes)	The file, as he sent it (pieced files rejoined)
List	REFRESH	List, newest first

Transition map — a built store, as the team sees it (→ SSOT-1 state machine)

State	Event	To
`arriving` (“Still arriving from the phone: …”)	last file lands	`received`
`received`	— (v1 has no review states)	—

Transition map — a ticket (v2, → SSOT-1 state machine)

State	Event	To
`new` (every store arrives as one)	START_REVIEW	`inReview`
`new` / `inReview`	MARK_SET_UP — only once every file has arrived	`setUp`
any	MOVE (to another status)	that status; each move is timed and kept in the ticket's history

v2 (2026-10-01, owner): every store is a ticket — the start of a ticketing and operations workspace. No reply to the owner. One common team key. Builds stay read-only; tickets are the team's own.

Data: seed-data/seed.json — three built stores exactly as GET /api/stores returns them. Builds come from the store-builder module (through its SSOT-7 StoreBuildFeed); this discovery stands on its own and does not link to that one.