Appearance
Receptionist: front-desk screen specification
Design REQUEST, not a pull. 🧮 Search space established 2026-08-24 across both ledgers (
screen-conformance.jsonfor mobile, the transcribed desktop inventory) plus the variants reception · visitor · walk-in · front-desk · enquiry: no Receptionist screen exists in either Claude Design project. So this follows CLAUDE.md's "a screen that does not exist yet goes through Claude Design first" process — specify in prose, record here, register, then send.
⚠ ONE constraint dominates every decision on this screen, and it is not a UI constraint
The register it replaces is a paper book, and the paper book takes about ten seconds.
🔎 If the digital path takes forty-five, the receptionist keeps the book — and then the visitor register has no input, the lead pipeline has no source, and every downstream screen in the dealership product is fed by nothing. This is the only screen in the vertical that can fail by being merely slow. Every trade-off below resolves in favour of speed.
⚠ It is also the only screen where offline tolerance is not a nicety: showroom wifi at the entrance is unreliable, and a visit that cannot be logged during an outage is a visit that is never logged at all.
1 · Who this serves, and who it does not
| Category | Served? |
|---|---|
| 1 · Solo / SMB owner | ❌ No. A one-person business has no front desk |
| 2 · Enterprise / dealership employee | ✅ Yes — this is the whole audience. org_owned workspace, Receptionist role |
| 3 · Consumer | ❌ No merchant surface. The consumer's half of this moment is the touchpoint QR at the desk |
📘 Owner decisions taken 2026-08-24, both confirming positions already documented in persona-feature-map:
- The Receptionist CAPTURES and SUGGESTS; the Sales Manager ASSIGNS. The screen shows a suggested consultant and must not let the receptionist pick one. 🔎 Routing quality dies when the decision is made under queue pressure by someone who does not own the outcome.
- No personal Setu Card. The DESK gets a reassignable touchpoint QR. A receptionist is the person at the desk, not someone a customer scans and follows up with. This frees plan card allocation for the consultants who actually convert.
2 · The four screens
2.1 · Today's desk (landing)
Purpose. Answer who is in the showroom right now without a tap.
| Section | Content |
|---|---|
| Action items (top) | ⚠ The proactive surface. Duration-derived, never invented — see §5 |
| In showroom | Visitors marked arrived and not departed, longest-waiting first |
| Awaiting assignment | Captured enquiries the manager has not yet routed |
| Logged today | A count and a collapsed list. Not the focus |
Primary action: Log a visit. It is the only prominent control on the screen.
2.2 · Log a visit — the twenty-second path
Three fields, and nothing else above the fold: name · mobile · purpose.
| Field | Behaviour |
|---|---|
| Mobile | ⚠ The identity key, and the returning-customer trigger. On a match, the screen says "Returning — 2 previous visits" and pre-fills the name. It must not block, and it must not show the previous consultant's notes (§6) |
| Name | Free text. Pre-filled on a mobile match, always editable |
| Purpose | A short closed set: new vehicle · service · spares · insurance · other. One tap |
Everything else — model interest, budget, timeframe, source — is deferred to §2.3 and is never required to save. 🔎 A required field is the mechanism by which a digital register becomes slower than a pen.
⚠ Save must succeed offline. The visit is queued locally with an explicit pending sync state on the row, and the receptionist is never asked to retry.
2.3 · Visit detail — enquiry capture
Opened from a queue row, used in the gap after the visitor is seated. Adds: model interest, budget band, purchase timeframe, how they heard of the dealership, free-text note.
⚠ Every field optional. A visit with only a mobile number is a valid, useful record — it is still an attributable walk-in.
2.4 · Ready for handover
Marks the enquiry ready for the manager to assign. Shows the suggested consultant and their current load, read-only. There is no consultant picker on this screen, by decision.
3 · States — every screen, enumerated
📘 Per CLAUDE.md's fourth rule (no silent design omissions), every row here must be designed and must carry a verdict in the screen's parity contract. An unassessed state fails the gate.
| # | State | Where | Notes |
|---|---|---|---|
| 1 | Loading | all | Skeleton, not a spinner over an empty page |
| 2 | Empty — start of day | desk | ⚠ Not a sad empty state. "No visitors yet. Log the first one." with the primary action |
| 3 | Empty — nothing to assign | desk | The good case. Say so plainly |
| 4 | Populated — normal | desk | 3-8 rows |
| 5 | Busy | desk | ⚠ 15+ rows. The Saturday case, and the one that breaks layouts. Must stay scannable and must not lose the action items |
| 6 | Offline — queued | log, desk | Per-row pending sync. The screen stays fully usable |
| 7 | Sync conflict | desk | Two devices logged the same mobile within minutes. Surface, never auto-merge |
| 8 | Returning customer | log | Inline, non-blocking, name pre-filled |
| 9 | Duplicate today | log | Same mobile already logged today. Offer open the existing visit — never a hard block |
| 10 | Suggestion unavailable | handover | No consultant free, or the suggester has no data. ⚠ Say so; do not show a fabricated name |
| 11 | Error — save failed for a real reason | log | Distinguish from offline. Offline is not an error |
| 12 | Permission denied | handover | A receptionist reaching an assign action they do not hold. Should be unreachable; design it anyway |
| 13 | Entitlement locked | desk | 📘 Per CLAUDE.md's fifth rule: if the visitor register is not on the plan, it is shown locked with its value stated, never hidden. ⚠ On native, "plans open on the web" — no in-app purchase CTA (ADR-0002) |
4 · Data contract
⚠⚠ None of these tables exists. 🧮 Measured: visits, parties and leads are all absent from the 69 live migrations, and screen-conformance.json already retired a prior screen for exactly this reason ("There is no enquiry or lead ENTITY in QR setu"). So this section is the design input AND the schema proposal — and it must go through the architecture change protocol before any migration.
| Entity | Shape the screen needs |
|---|---|
visits | workspace_id (not null) · party_id (nullable — an anonymous walk-in is valid) · purpose · arrived_at · departed_at · created_by (immutable, the receptionist) · status · synced_at |
parties | The customer registry, keyed by mobile within a workspace. ⚠ Whether a party is one record across tenants is unresolved (QRS-855) and this screen does not need it resolved — it only ever reads its own outlet |
leads | visit_id · created_by_user_id immutable · assigned_user_id nullable and mutable · interest fields · status |
✅ The lifecycle rules from user lifecycle apply directly, and this screen is where they first become visible: the receptionist who logged a visit stays its created_by forever, while assigned_user_id moves as consultants change. ⚠ A report that folds over the assignee will credit the wrong person (rule L10).
5 · Proactive-value answer
📘 Required by CLAUDE.md before implementation, not after.
| Question | Answer |
|---|---|
| What action does it prompt? | "3 visitors waiting over 10 minutes" → go greet them. "2 enquiries unassigned for 15 minutes" → escalate to the manager |
| What makes it timely? | A duration threshold over the live queue. The value decays in minutes, which is exactly when a nudge is worth its interruption |
| Where does the intelligence come from? | 🔎 Arithmetic over the read model — now() - arrived_at against an archetype-configured threshold. Nothing is inferred, predicted or scored |
| Why is it not noise? | It is in-app only, never a push. It disappears when the queue drains, so it cannot become wallpaper |
⚠ What it must never do: invent a name. If the suggester has no load data, say "no suggestion available". A fabricated recommendation is unfalsifiable to the user and destroys trust in the ones that are real.
6 · Permissions
| Action | Receptionist |
|---|---|
| Create a visit · read this outlet's queue | ✅ |
| Create and edit an enquiry | ✅ |
| Assign a consultant | ❌ By decision |
| See price, discount, margin | ❌ |
| See a returning customer's previous notes or consultant | ❌ ⚠ "Returning — 2 previous visits" is the whole disclosure. The history belongs to the consultant who owns the relationship |
| Any other outlet's queue | ❌ |
⚠ RBAC is 0% built — no roles, permissions or role_assignments. So these are design intent and the screen must be built to them, with the enforcement landing when RBAC does (QRS-868).
7 · Desktop and mobile parity
📘 Mandatory and simultaneous. Functional parity, not pixel parity.
| Desktop (primary) | Mobile | |
|---|---|---|
| Who | The PC at the reception desk | A roaming greeter with a tablet or phone |
| Queue | Dense table, all columns | Cards, one visitor per row, longest-waiting first |
| Log a visit | Inline panel beside the queue — never a modal that hides the queue | Full-screen, single column, one thumb |
| Action items | A strip above the table | Same content, stacked, never collapsed behind a tap |
| Handover | Side panel | Sheet |
⚠ NO KEYBOARD SHORTCUTS. 📘 Explicit owner instruction: they add implementation complexity these personas will not use. Desktop density comes from layout, not from a command palette.
8 · The prompt for Claude Design
Send after this page is registered, following the dealership journey process.
Copy-paste prompt
Design the Receptionist front-desk screens for the QR Setu car-dealership vertical, desktop and mobile together, in the existing prototype project alongside the other console sections.
The governing constraint, and it outranks everything else: the paper register this replaces takes about ten seconds. If logging a walk-in takes much longer, the receptionist keeps the book and the whole lead pipeline has no input. Design for speed first.
Four screens: (1) Today's desk — the live queue, with action items derived from waiting duration; (2) Log a visit — three fields only above the fold: name, mobile, purpose; (3) Visit detail — optional enquiry fields; (4) Ready for handover — shows a suggested consultant and their load, read-only, with no picker.
Hard rules. The receptionist captures and suggests; they never assign. A returning customer is detected by mobile and shown as a count only, never with the previous consultant's notes. Every enquiry field is optional. Save must work offline with a per-row pending sync state, and offline is not an error state. No fabricated consultant suggestion: say "no suggestion available". The receptionist has no personal Setu Card; the desk has a QR.
Design all thirteen states listed in the specification, including the busy 15-plus-row case, sync conflict, duplicate mobile logged today, suggestion unavailable, and the entitlement-locked case (shown locked with its value stated, and on native saying plans open on the web — never an in-app purchase CTA).
Desktop and mobile must be functionally equivalent. Desktop: dense table with an inline log panel that does not hide the queue. Mobile: single-column cards, one-thumb logging. No keyboard shortcuts of any kind.
Copy: no em dashes or en dashes anywhere. Use a comma, a colon, parentheses, or two short sentences.
Not verified
❓ The twenty-second target and the ten-second paper baseline are estimates, not measured at a real dealership. They should be timed before this screen is called done. ❓ visits, parties and leads do not exist, so the data contract is design intent. ❓ The suggested-consultant logic assumes load data that has no source yet.