QR/request triage with need categories, context-specific follow-up, comments, contact preference, and a routing preview.
CASE STUDY 02 / FAMILY SERVICES
Smart Family Flow
A two-sided family-needs workflow that lets a person ask for help in plain language while staff receive a structured, ownable Need with routing, follow-up, outcome, and audit behavior.
PRODUCTHUMAN SERVICESFUNCTIONING SYNTHETIC PROTOTYPEPRESENTATION BUILD
01 / HUMAN PROBLEM
People should not need an org chart to ask for help.
Family-service systems often expose organizational structure before they understand the request. The person is expected to know whether they need a coordinator, advocate, clinician, program office, referral partner, or some other lane.
The product flips that sequence: capture the Need first, ask only context-specific follow-up questions, then route it to the appropriate team while preserving a visible owner and next action.
02 / WORKFLOW
Many doors. One Need system.
PLAIN-LANGUAGE REQUEST→CONTEXT FOLLOW-UP→ROUTE→CLAIM / ASSIGN→WORK→FOLLOW-UP / REFER→OUTCOME→RESOLVE / CLOSE→AUDIT
The client-facing side is deliberately simpler than the staff side. It asks what help is needed and a contact preference. The staff side can then express ownership, priority, waiting state, referral, escalation, resolution, reopening, cancellation, and history.
03 / SOFTWARE
One workflow, two perspectives.
Universal Intake, Family Needs Grid, current-owner concept, role-aware command availability, audit events, queue projections, referrals, and restricted lanes.
An authenticated command route, server-side Supabase adapter, SQL schema, RLS/RBAC model, and atomic command RPC exist as staged infrastructure rather than claimed live persistence.
Command model
Create, Claim, Assign, Start Work, Reassign, Wait/Block, Resume, Follow-up, Refer, Update Context, Change Priority, Route, Clinical Review, Record Outcome, Escalate, Resolve, Close, Reopen, Cancel/Void, and Link Duplicate are represented as distinct actions rather than one generic “update” button.
04 / EVIDENCE
The repository distinguishes live, simulated, and staged.
The dated project state documents working staff-side Universal Intake / Family Needs and client-side QR/request triage surfaces.
The dedicated development branch contains a richer TypeScript command model beyond the smaller public presentation command set.
Authenticated route, Supabase server adapter, PostgreSQL schema, and atomic command RPC are present but intentionally not represented as activated shared persistence.
Client-to-staff delivery and shared persistence remain simulated until a separately authorized persistence/authentication adapter is activated and tested.
05 / LIMITS
Prototype honesty is part of the design.
- No real family or client information belongs in the presentation build.
- No claim that a former employer commissioned, approved, or adopted the prototype.
- No claim of persistent cross-device delivery while the shared persistence adapter remains inactive.
- Clinical content remains a restricted lane rather than a default staff-visible field.
- Presentation completeness and production readiness are separate gates.
WHAT I LEARNED
Good service software hides the organization’s complexity from the person asking for help while making ownership and follow-through more explicit for the people doing the work.
Contact: founder@thehumancode.tech