Kryterea · sample deliverable
Customer onboarding requirements
A worked example of the decisions and evidence that can sit behind an approved build brief.
Fictional demonstration. This is illustrative data, not a customer document, live product export, or claim of certification.
01 · Request and outcome
Original request: “We need a better onboarding flow.”
Defined outcome: A new admin can complete first-time setup for a self-serve workspace, or pause and resume without losing entered information.
In scope: setup progress, recovery after leaving, and a clear next step. Out of scope: account billing and invitations after setup.
02 · Evidence and assumptions
| Reference | Sample material | How it is used |
|---|---|---|
| SRC-01 | Fictional support-note themes | Points to lost progress as a question to investigate. |
| SRC-02 | Fictional current-journey review | Identifies where setup can be interrupted. |
| ASM-01 | Admins may return on a different device | Marked as an assumption requiring validation before implementation. |
Real work would link the underlying notes, dates, authors, and permissions. No fabricated performance metric is used in this example.
03 · Requirements and acceptance checks
| ID | Requirement | Acceptance check |
|---|---|---|
| REQ-01 | Save entered answers after each setup step. | Given a paused setup, returning with the same account restores saved answers. |
| REQ-02 | Show the next required action when setup resumes. | The admin sees the first incomplete step and can continue from it. |
| REQ-03 | Make failed setup states recoverable. | An error states what failed, what remains saved, and how to retry or seek help. |
04 · Review finding
Finding F-01: The initial draft did not name who owns the failed setup path. A team could ship a retry message without an escalation route.
Resolution in the sample: The product lead owns the user-facing route. Support owns the escalation procedure. Both roles review REQ-03 before release.
Resolved in example · The record retains the finding and its resolution.
05 · Decision and handoff
The sample product lead approves version 1.0 with SRC-01, SRC-02, ASM-01, REQ-01–03, and F-01 attached. A builder receives this version as the brief. Any later change creates a new version for review.
A real approval would include an authenticated person, timestamp, and actual evidence. This demonstration intentionally uses roles and fictional references.