Skip to content

Use Cases

Flows captured in Topic 3 of the requirements session (2026-04-27). Cross-cuts: V2 scope, data model, glossary.

UC-1. Stringing-day flow (Stefan-as-stringer)

Today: all desktop. V2 ideal: phone OR desktop, in-the-moment OR later — both must work.

Typical sequence:

  1. Client hands over racket.
  2. Client declares setup ("same as last time" is the usual case).
  3. Stringer records the order (Add Stringjob — see UC-2).
  4. Stringer strings the racket.
  5. Stringer texts client "ready" (V2: emailed receipt at Strung; V3: configurable notification).
  6. Handover at training, dropoff, or pickup.

Occasional deadline pressure ("tournament Saturday").

The V2 must-fix (single biggest pain in V1): kill the spreadsheet dance — find last row for that client, copy/paste, edit CHF.

State + edit rules for each step in this flow are pinned on the order lifecycle page (state machine, who-may-do-what, reversibility, audit).

UC-2. Order entry — "Add Stringjob"

The headline V2 UX pattern. Key requirement (M9):

  1. Tap Add Stringjob.
  2. Search clients → select.
  3. Either an explicit "copy last" button OR auto-prefill from previous setup populates the form.
  4. Adjust as needed. Price field must remain editable.
  5. Save.

Natural sequence for a fresh entry: Player → Racket → String. In practice usually a copy of the previous order, so the form must support both fresh entry and one-click copy.

Racket picker

  • Show the list of rackets owned by this player, ordered by last-strung-date DESC.
  • "Add new racket for this client" button always available as fallback.

String picker

  • Pick from shared catalogue; manual override always available.
  • Cross side defaults to "same as main" (89% of orders match — see V1 baseline).
  • Cross tension defaults to main tension; one-tap nudge ±1 kg.

BYO

Per-side BYO toggle (M11). In practice it is all-or-nothing (~48% of client orders, both sides), but the per-side flag handles the rare cross-only case (0.9%).

UC-3. Receipts and handover

  • Both printed AND emailed (M14).
  • Receipt is final at Strung. Re-generatable on demand.
  • One receipt per racket-order, always. No batching multiple rackets onto one receipt.
  • A4, clean modern redesign, total in top-left quarter (must be visible when folded twice and attached to racket) — M13.
  • EN + DE templates (M19).
  • Edit + re-emit semantics are pinned in Order lifecycle: which post-Strung edits trigger an automatic receipt re-emit, when prices lock (default: at paid_at), and when admin override is required.

UC-4. Notifications (V2 data model, V3 dispatch)

V2 captures the data model; V3 adds the dispatch pipeline. See V3 vision — C2.

Captured in V2:

  • Per-channel notification opt-in/out flags on the Player (email default; SMS if cheap).
  • Stringer-level notification template + behaviour, with per-client override.
  • Trigger model: auto-on-Strung AND manual "notify" button — both available.
  • Content: message includes the receipt.

V2 actual send: the Strung event already triggers the receipt email per M14. V3 generalises that into a configurable notification pipeline.

UC-5. Multi-stringer admin

Onboarding

  • Admin (Stefan) sends an email with magic link → recipient registers → self-fills stringer profile. (M3)
  • Day 1 = empty slate. No import path on signup. (Bulk import is V3 — see V3 vision — C3.)
  • The profile-field set collected at onboarding (display name, locale, business identity, notification template) and the offboarding flow (deactivate + 90-day grace + admin-finalize) are pinned in stringer lifecycle.
  • First sign-in (registration): stringer clicks the admin-issued magic link in their email; this both verifies the address and registers them.
  • After registration: the stringer can set a password on their profile. From then on, either method is available at every sign-in — magic-link to email or email + password.
  • Both methods remain available going forward for every stringer. The system is neither magic-link-only nor password-only.

Isolation and sharing

  • Strict isolation by default. Orders and ClientProfiles are private per stringer. (M2)
  • Shared resources: the catalogue of Strings + Rackets (mfr / model / version / gauge), plus stringing-job data shared via the three sharing rules (Rule 1 stringer-initiated, Rule 2 client-initiated per-job, Rule 3 client global preference). See client identity & sharing.
  • Same human, two stringers: one platform-level Person, two stringer-scoped ClientProfile rows. Identity matching is verified-email only; no name/phone/fuzzy auto-matching. ~~Duplicate Player entities, no automatic linking.~~ (Updated 2026-05-02 — see client identity & sharing.)

UC-6. Share stringing-job data

Updated 2026-05-02. The original UC-6 ("Share player" — single button, snapshot, stringer-initiated only) is superseded by the three sharing rules in client identity & sharing. UC-6 below is the use-case-shaped summary; that page is the authoritative requirement.

Three sharing flows, all read-only:

UC-6a. Stringer-initiated job share (Rule 1, M18)

  • Stringer A picks specific past jobs they performed for a given client.
  • Stringer A grants Stringer B read-only access (per-job, with a "share all existing past jobs for this client" bulk-UI shortcut).
  • Stringer B sees the jobs in their "Shared with me" inbox, with redaction applied: client PII (except first name), pricing, and the comments field are hidden; technical fields (racket, strings, tension, DT, method, color, BYO, lifecycle dates) are visible.
  • Either side can revoke at any time. All grants and accesses are audit-logged.

UC-6b. Client-initiated job share, per-job (Rule 2 — V3 portal)

  • Client browses their own merged history (across all stringers) in the V3 portal.
  • Client picks specific past jobs and a target stringer; grants read-only access.
  • Receiving stringer sees the jobs in "Shared with me" with full client identity exposed (client is consenting). Pricing exposure is an open question — see open questions.
  • Either side can revoke; all grants and accesses audit-logged.

UC-6c. Client global preference, future-inclusive (Rule 3 — V3 portal)

  • Client toggles "share ALL my jobs (past + future) with Stringer X".
  • Stringer X automatically sees every existing job and any new job recorded later — including jobs from stringers added to the client's network after the toggle was set.
  • Either side can revoke at any time. All accesses audit-logged.

This is the only future-inclusive sharing mechanism in the model.

See client identity & sharing for the full visibility/redaction matrix, identity-matching rule, edit/revoke semantics, audit requirements, hidden requirements (inbox, sharing-management screens, notifications), and out-of-scope notes.

UC-7. Catalogue moderation (request-queue)

Wording correction from Topic 4 draft: this is a request-queue, not a flag-flip.

  • New catalogue entries created by a stringer are unshared by default — visible only to the creating stringer.
  • Stringer can mark a row as "request shared" → enters admin queue.
  • Admin (Stefan) sees an inbox with unread badges + admin notifications for each new submission.
  • Admin promotes or rejects each entry. On promotion the row enters the global shared catalogue. (M17)
  • For one-off "very old random racket" entries, the stringer can explicitly choose NOT to add to catalogue — it stays attached to that order only.

UC-8. Edge cases

Case Handling
Late payment (months after pickup) Just set the Paid date whenever it actually gets paid. No special workflow.
Cancellation Not a real use case.
Warranty / partial returns Not a real use case. Occasional free re-string for early breakage; price stays at 25 CHF in the books "to not break stats."
Racket not in catalogue Stringer adds it as a one-off attached to the order, OR submits to the catalogue queue (UC-7).

Reporting

Year/month rollups (preserve V1), plus new V2 asks (M16):

  • Top clients (by job count or revenue).
  • Mean turnaround time (Ordered → Strung).