Appearance
The dealership design process: extending the Vendor Journey, not replacing it
🌐 Inspected from the Claude Design prototype project on 2026-08-23:
VENDOR-PARITY.md,prototype/vendor-journeys/salon.dc.htmland theJOURNEYcontract inprototype/mobile-console/vendor-core.js. Read before writing any dealership design prompt.
📘 Owner instruction, and the reason this page exists
"Before making changes to the workflow, please first inspect and understand how the existing Vendor Journey is currently structured and maintained, because I want to preserve that established pattern rather than inventing a new screen-review mechanism for Car Dealership."
🔎 The inspection changed the plan twice. The existing process is better than a new one would be, and it is missing exactly two dimensions the dealership needs. Both findings are below.
1 · How the Vendor Journey actually works
| Layer | What it holds |
|---|---|
vendor-core.js | The only place the journey lives: JOURNEY, REUSE, READINESS, journeyFor(industryId), plus capabilities, widgets, status keys, money and every derivation. Both consoles import it |
vendor-journeys/<industry>.dc.html | A thin renderer holding no journey knowledge. Its only industry-specific line is INDUSTRY = 'salon'. It calls V.journeyFor(...) and lays out whatever comes back |
| The step contract | n · name · achieves · badge{label,tone} · varies · note · gap · href · undesigned |
| Deep links | href + '?industry=' + ind.id, so the shared screen opens already resolved |
VENDOR-PARITY.md | A hand-written mobile ⇄ desktop audit with a five-point parity test and a per-step table |
⚠ The doctrine is printed on the journey page itself, and it governs everything below
"This is a reading order, not another copy of the product. Every step below opens the real shared screen. There is no folder of industry screens, because a per industry copy of a shared screen either silently diverges or points nowhere."
🔎 So adding an industry adds one file and some rows — never a screen set. That is the pattern to preserve.
🔎 The self-auditing part, which is the best idea in the whole process
Every step carries a reuse badge — SHARED · CONFIGURED · SPECIFIC · no-screen — the page counts them, and then it computes a verdict from the numbers rather than asserting one:
| Specific steps | Verdict the page prints |
|---|---|
| 0 | "That is the shape we want… If a genuinely specific step ever appears here, it is a signal that the widget model is carrying too little" |
| 1-2 | "within tolerance" |
| 3+ | ⚠ "a warning: the widget and capability model is carrying too little, and each of those steps should be examined for a shared shape it could have taken instead" |
📘 That is CLAUDE.md's third rule implemented in a design artifact — a readiness claim produced by a count, not by prose. The dealership must inherit it, and it is also the metric that will tell us if the dealership is being built wrong.
2 · ⚠ The two dimensions the existing journey does NOT have
Both are real, and neither is a flaw in the existing process. Every industry it was built for is a ONE-PERSON business
| Missing dimension | Why it was never needed | Why the dealership needs it |
|---|---|---|
| PERSONA | A Ganapati stall, a salon and a direct seller are each run by one operator. JOURNEY is a single ordered list for one person | A dealership has six personas with different jobs. "Log a visitor" is reception's whole day and invisible to a GM |
| DEVICE | The journey links only to mobile-console/*. Desktop parity is a separate hand-written document | 📘 The owner's mandate: every screen designed for both, simultaneously, and reviewable as an app on each |
⚠⚠ And the device gap has a consequence worth more than the fix
🧮 VENDOR-PARITY.md §2 is a hand-maintained table of 20 rows: phone screen, desktop screen, verdict. It is the only place that mapping exists.
Move that mapping into the
JOURNEYarray ashref+desktopHref, and parity stops being a document somebody has to re-read and becomes a COUNT the journey page prints on every load.
📘 That is "automate the check, never promise the check" applied to design parity. It also means a step added to the array with only a phone href shows up as a parity gap immediately, rather than in the next audit round. 🔎 This is the single highest-value change in this whole process, and it makes the owner's parity mandate self-enforcing rather than a discipline.
3 · ✂ What this changes about the 51-screen blueprint
⚠ The blueprint counted PRODUCT screens. The reuse doctrine means far fewer DESIGN artifacts
📘 Screen blueprint lists 51 persona × screen entries. Under "there is no folder of industry screens", most are one screen resolving per persona, not 51 files.
| Count | Examples | |
|---|---|---|
| Genuinely new — no merchant-console analogue exists | ~12 | Log a visitor · Visitor queue · Enquiry inbox · Test drives · Team dashboard · Overdue monitor · Lead funnel · Outlet overview · Group overview · Standee manager · Setup & activation · Service due list |
| Existing, needs a PERSONA parameter | ~9 | Home/dashboard (already widget-registry driven and capability-gated, so persona is a third resolution key) · Messages · Catalogue · Profile · Settings · Notifications · Analytics · QR tools · Card editor |
| Reused unchanged | the rest | The public Setu Card, onboarding, auth, plan and billing |
🔎 So the dealership is roughly 12 new screens plus 9 parameterised ones, not 51 from scratch — and the desktop counterparts of the 9 largely exist already. ⚠ If the new-screen count starts climbing past ~15, the reuse verdict will say so, which is the metric doing its job.
4 · How to add the dealership without breaking the journey
🔎 Four changes, each the smallest one consistent with the established pattern.
| # | Change | Where |
|---|---|---|
| 1 | Each JOURNEY step gains personas: [...] | vendor-core.js |
| 2 | Each step gains desktopHref beside href, seeded from VENDOR-PARITY.md §2 | vendor-core.js |
| 3 | journeyFor(industryId, { persona, device }) filters and picks the href. Unfiltered calls keep today's behaviour, so the three existing journeys do not change | vendor-core.js |
| 4 | ONE vendor-journeys/dealership.dc.html with a persona switcher and a device switcher, reading the same array | new file |
Why one file with two switchers rather than twelve files
🔎 The pattern is "adding an industry adds one file that reads the same array". Twelve files would be twelve copies of a renderer that holds no knowledge — the exact per-industry-copy failure the doctrine names. And a switcher is what makes the owner's "walk through it like an application" possible: change persona, stay on the same step, see what that persona sees.
⚠ The parity count must be per persona, not global: "Sales Rep: 11 steps, 11 on both surfaces. Team Leader: 5 steps, 3 on both, 2 phone only." A global number would hide a persona whose desktop experience is half-built.
5 · The persistent context file
📘 The owner's request: give Claude Design a durable product context so each prompt is not read in isolation. 🌐 The project's own convention is a .prompt.md per domain, in that domain's folder — consumer/consumer.prompt.md, marketplace/marketplace.prompt.md, platform/reputation.prompt.md, admin-panel/communications.prompt.md.
So: prototype/vendor-journeys/dealership.prompt.md.
⚠ The rule that keeps a context file useful rather than dangerous
📘 "The purpose is to give Claude Design product context, not to hardcode assumptions that haven't been finalized."
Every open decision must be marked TBD in the file itself. A context document that states an undecided thing as settled is worse than no document, because every later prompt inherits it silently. 🔎 The architecture validation and admin control plane pages already carry the open list, so the TBDs are known rather than guessed:
| TBD to mark explicitly | Why it is open |
|---|---|
| Role and permission model | 🧮 RBAC is 0% built; role scope missing from schema and design (QRS-863) |
| Persona login access as a plan control | Depends on the above (QRS-867) |
| Party identity across tenants | Per-organisation scoping recommended, not decided (QRS-855) |
| Marketplace featured placement | Not sellable; needs measured traffic (QRS-849) |
| AI beyond drafting | Costed and sequenced, not committed (AI strategy) |
| Public media URL | ⚠ Card images do not resolve at all today (QRS-852) |
| Subscription record · usage ledger · role templates | Designed in entitlements.js, absent from the schema |
6 · The standing process, as it will run
text
1 PRODUCT CONTEXT dealership.prompt.md, TBDs marked once, then amended
2 PERSONA + FEATURE from the screen blueprint per round
3 DESIGN, BOTH SURFACES mobile and desktop in the same prompt per round
4 JOURNEY INTEGRATION rows in JOURNEY, persona + both hrefs per round
5 WORKFLOW VALIDATION walk the journey per persona per device per round
6 PARITY REVIEW the COUNT the page prints, per persona automatic
7 FEATURE GAP REVIEW reuse verdict + READINESS block automatic
8 ITERATE🔎 Steps 6 and 7 become automatic once §4 lands, and that is the point
📘 The owner asked to "assess both versions together and identify features that exist on desktop but are missing on mobile." With desktopHref in the array, that assessment is a filter over the array rather than a reading exercise — and the same is true of the reuse verdict and the readiness block, which the journey page already computes.
⚠ What stays human: whether the mobile interaction pattern is right rather than merely present, and whether the information hierarchy reads well. 📘 No count sees those, and claiming otherwise would repeat QRS-246.
7 · Round 1 prompt: context and journey infrastructure, no screens yet
⚠ This round deliberately designs NO dealership screen, and that is the point
🔎 The journey file lands first, with all 25 steps showing the existing undesigned treatment. That gives three things nothing else can:
- A burn-down. Round 1 reads "0 of 25 steps have a screen". Every later round moves that number, so progress is a count rather than a feeling.
- A parity denominator from day one. The per-persona both-surfaces count exists before the first screen, so a desktop gap can never accumulate unseen.
- A checklist Claude Design reads back, so no round has to be told the whole journey again.
⚠ Asking for context, infrastructure and screens in one round would produce screens built against a context written in the same breath, with nothing having reviewed it.
Click to expand the full prompt
text
Three files this round. NO dealership screens yet, and that is deliberate: the
journey lands first showing every step as undesigned, so it becomes the burn-down
for the rounds that follow and the parity count exists before the first screen.
FILE 1 of 3: prototype/vendor-journeys/dealership.prompt.md
A persistent product context you will read at the start of every later dealership
round, so no prompt has to restate the product. Write it as documentation, not as
a brief. Mark every open decision TBD explicitly: a context file that states an
undecided thing as settled is worse than no file, because every later round
inherits it silently.
Contents:
VISION. QR setu is not building dealership software. It is the attribution and
accountability spine that dealership software does not have. It sits BESIDE the
OEM dealer management system the dealer is contractually obliged to use, and it
never tries to replace it. The one organising question for any dealership feature:
does it make the causal chain from a named employee to a named customer outcome
more complete or more visible.
MARKET. India. FADA counts over 15,000 dealerships across over 30,000 outlets.
Pune first, where two independent methods converge on roughly 45 to 70 franchised
passenger-vehicle dealers. The buyer is commercially stressed: a listed dealer
group reported 3.18 percent EBITDA and a profit before tax of minus 13.30 crore.
Frontline sales attrition is 29.53 percent a year. After-sales is where the money
is: roughly 20 vehicles serviced per 1 sold, at 41.2 percent gross margin.
Advertising and sales promotion runs about 14 lakh per sales outlet per year.
48 percent of new car buyers contact dealerships on WhatsApp.
THE SIX PROBLEMS. Walk-ins are invisible, written in a notebook nobody reads
again. Nobody can prove who followed up and who did not. Per-rep performance is
anecdotal. Cross-brand comparison takes a person and a spreadsheet at month end.
Service and renewal revenue leaks quietly. And the OEM system was built for
manufacturer reporting rather than dealership operations, which the dealers own
association says in its own words.
VOCABULARY. An OUTLET is one place of business with its own customers and its own
numbers: a showroom, or a service centre running its own P&L. A LOCATION is only
an address, and is free. Never use the word rooftop: it is US vendor jargon, no
Indian dealer uses it, and FADA and the audited filings both say outlet.
PERSONAS. Nine dealership logins, plus two that are not:
Receptionist no card, logs every walk-in
Sales Representative card mandatory, customer facing
Service Advisor card mandatory, after-sales
Team Leader card OPTIONAL, runs a team
Sales Manager card OPTIONAL, runs a division
General Manager card optional, runs one outlet
Dealer Principal card optional, owns several outlets and brands
Marketing no card, campaigns and reputation
Org Admin no card, the customer's own administrator
Customer / prospect NO LOGIN. Anonymous first, always
QR setu platform admin a different product on a different route. Out of scope
THE RULE: the card follows the TARGET, not the title. A Setu Card is a customer
facing acquisition channel and is justified when the person is measured on
customer outcomes they personally create. A login is an internal operational role.
SETU CARD. The product thesis. Every card is org_owned, never rep_owned: at
29.53 percent attrition, a rep-owned card is a product that helps salespeople take
your customers to their next employer. The ORGANISATION SETU CARD is the outlet's
own public card and is what a QR standee opens: dealership information, vehicle
catalogue with images and video, offers, the team, test drive booking, enquiry,
contact, feedback and a review prompt.
QR STANDEES. Physical stands through the showroom: reception, waiting area,
tables, individual vehicles, sales desks, the test drive bay. 225 rupees each plus
GST, sold separately. Each standee carries its OWN tracking code and a first class
PLACEMENT field, so the dealer learns which position produced enquiries. A QR that
merely opens the card is printing, and printing is not worth 225 rupees. A standee
scan has NO employee, so an interaction record must allow a null employee and
attribute the outlet instead. Standees are the best adoption mechanic in the
product because they require no behaviour change from any staff member.
THE JOURNEY. Customer arrives, by walking in or by scanning a standee or a card.
Reception logs the visitor, or an anonymous enquiry is created. It is assigned to a
named rep. The rep answers. A lead exists with an SLA clock. A test drive. Feedback.
Won or lost with a reason. Months later, a service due date. Everything above folds
upward: Team Leader sees overdue, Sales Manager sees the funnel and the sources, GM
sees the outlet with sales and service together, Dealer Principal sees every outlet
and every brand.
CHAT AND WHATSAPP, and this distinction is load bearing.
QR setu NATIVE CHAT is the system of record for customer conversations. WhatsApp is
reach and notification, never the record. Two tracks, and they are structurally
different objects:
TRACK A, anonymous enquiry. No account. Name, phone, free text, creating a lead
with the rep attributed. The majority of volume, and it must never have a
signup wall. The reply reaches the customer over WhatsApp or by phone, because
there is no in-app thread to notify into.
TRACK B, registered chat. Requires an account: the conversation record requires a
consumer user, so an anonymous conversation is not gated, it is
unrepresentable. Complete threaded history, zero channel cost, push through the
consumer app. Entered when the customer has a REASON to register: order
tracking, test drive management, service history.
WhatsApp carries the "you have a reply" tap at 0.115 rupees, not the conversation.
Never design a six channel unified inbox: 48 percent of Indian buyers use WhatsApp,
so five of the six channels would be dead code.
GOOGLE BUSINESS AND REVIEWS. The differentiator is not review management, which is
copyable. It is the TRIGGER: every review tool has to guess when to ask, and we
know, because the card recorded which customer met which rep and finished a test
drive twelve minutes ago. CRITICAL COMPLIANCE RULE: the review link goes to
EVERYONE. Asking only customers who rated well is review gating, which Google
prohibits, and the asset at risk is the dealer's own profile. Use the internal
rating to route a SERVICE RECOVERY task to a manager instead, which is worth more
to the dealer anyway.
AI. AI is an AFFORDANCE, never a screen. A draft reply button in the conversation,
a summary panel on the lead, a suggested slot in the booking sheet. An AI tab is a
tab nobody opens, and it hides the capability from the moment of work. Most things
that sound like AI are deterministic and must stay that way: follow-up due and
overdue, reminders at a fixed offset, service due by date or odometer, going cold
flags, review eligibility, round robin assignment. If a rule can produce the
answer, a model is a more expensive way to be less certain. Where AI genuinely
earns its cost: reading a mixed script Hindi, Marathi and English conversation into
structured lead fields, drafting a reply in the customer's own language,
summarising a long history, grounded catalogue questions, and review sentiment. A
management question NEVER has the model compute the number: it selects a
pre-built metric, SQL computes it, and the model only phrases and cites.
SUBSCRIPTION AND ENTITLEMENT. Read prototype/platform/entitlements.js. Eight
scopes with precedence as data, three independent axes, plan families. Dealership
plans are priced PER OUTLET PER YEAR, exclusive of GST:
Dealer Foundation 79,999 10 cards, cap 24 5 logins, cap 10
Dealer Growth 149,999 30 cards, cap 60 12 logins, cap 20
Dealer Complete 299,999 75 cards, cap 100 25 logins, cap 45
Extra Setu Card 4,999 a year. Extra management login 2,499 a year. QR standee 225.
Annual commitment only: never render a monthly equivalent anywhere, because this
product's value curve is back loaded and a monthly contract terminates before the
product works. Every price is shown plus 18 percent GST, never folded in.
The outlet's own organisational card COUNTS inside the card limit, so the quoting
rule is staff plus one.
DEFAULT VERSUS ADD-ON. Label every capability in a design with exactly one of:
Included Foundation and above
Plan dependent Growth or Complete
Group needs three or more outlets
Add-on separately priced
Usage based prepaid drawdown
Integration needs an external approval
Future not committed to any wave
Gating controls ACCESS, never DISCOVERY: a capability above the customer's tier
stays visible and locked with its value stated. But an UNBUILT capability is not a
locked one: it reads as not ready yet, with no upgrade call to action, because no
plan unlocks something that does not exist.
ARCHITECTURE CONSTRAINTS THAT AFFECT DESIGN.
Shared multi-tenant SaaS for the whole development phase. One dealer group is an
ORGANISATION holding a TREE of outlets. Sharing flows DOWN and is off by default;
oversight flows UP and is READ ONLY, and it never applies to an employee's own
personal business. A customer is scoped per organisation: two dealer groups may
hold the same phone number and never know.
DESKTOP AND MOBILE PARITY IS MANDATORY. Every dealership screen is designed for
both surfaces in the same round. Not pixel parity: interaction patterns should
differ, density should differ, navigation should differ. FUNCTIONAL parity: a
capability a persona has must not disappear because they picked up a phone. The
phone is the source of truth for behaviour and desktop re-expresses the same
behaviour with density, keyboard flow and multi-select, which is the rule the
existing vendor journey already follows.
WHAT WE REFUSE TO BUILD, each with its reason, so no is cheap when it is proposed
again: a DMS replacement, because it is OEM mandated. Any OEM facing view of
dealer discount or margin data, because the competition regulator has already
penalised a manufacturer for policing dealer discounting. Insurance or finance
COMMISSION, which is licence gated: sell the attach workflow, never the
commission. Vahan market intelligence dashboards, discontinued August 2026.
Advertising or profiled placement. Owning telephony. Accounting, GST filing or
parts inventory. An email channel. An AI product that claims to replace a business
development centre, a role Indian dealerships do not have as a distinct function.
TBD, UNDER EVALUATION. Do not design against these as though they were settled,
and do not invent an answer:
ROLE AND PERMISSION MODEL. TBD. There is no role model yet. Do not draw persona
toggles, role matrices or permission grids anywhere. Where a screen needs one,
render the absent-store treatment you already use in Subscriptions.
PERSONA LOGIN ACCESS AS A PLAN CONTROL. TBD, depends on the above.
SCREEN LEVEL ACCESS. Decided against as an independent control: screen
visibility is DERIVED as module entitled AND role permits. Never design a
third matrix.
CUSTOMER IDENTITY ACROSS TENANTS. Per organisation scoping is recommended and
not decided.
MARKETPLACE FEATURED PLACEMENT. Not sellable. Do not design a paid placement
control.
AI BEYOND REPLY DRAFTING. Costed and sequenced, not committed.
PUBLIC MEDIA URL. Card images do not resolve at all today. Any design that shows
vehicle photography must use the reserved image treatment, never a broken or
invented image.
SUBSCRIPTION RECORD, USAGE LEDGER, ROLE TEMPLATES. Specified in
entitlements.js, absent from the platform.
FILE 2 of 3: extend prototype/mobile-console/vendor-core.js
Three additions, each the smallest change that keeps the existing journeys working.
1. Every JOURNEY step gains personas: an array of persona ids. A step with no
personas array means everyone, so the three existing single-operator journeys
need no edit.
2. Every JOURNEY step gains desktopHref beside href. Seed it from the table in
VENDOR-PARITY.md section 2, which is currently the only place that mapping
exists. Moving it here turns a hand-maintained document into a count.
3. journeyFor(industryId, opts) accepts an optional { persona, device }. It
filters steps by persona when one is given and picks href or desktopHref by
device. Called with no opts it must behave exactly as today.
Add a PERSONAS registry for the dealership: id, label, a one line job description,
whether a Setu Card is mandatory, optional or never, and whether the login is
included with a card or counts against the management allowance.
Add the dealership industry record and the 25 journey steps below. Every step
starts with NO href and NO desktopHref and carries an undesigned line saying what
is missing, because no dealership screen exists yet. That is the burn-down.
# step personas
1 Onboarding the dealer group org_admin
2 Sign in all
3 Outlet setup and activation org_admin
4 People and cards issued org_admin
5 Organisation Setu Card org_admin, gm, marketing
6 Vehicle catalogue and offers all read, marketing and gm edit
7 QR standees: order, place, track marketing, gm
8 Log a visitor receptionist
9 Visitor queue and assignment receptionist
10 Enquiry inbox, anonymous receptionist, rep, team_leader
11 My Setu Card and card health rep, service_advisor
12 Conversations, native chat rep, service_advisor
13 Leads and the follow-up SLA rep, team_leader, sales_manager
14 Test drives rep, team_leader
15 Customers rep, service_advisor, team_leader, sales_manager
16 Service due and reminders service_advisor
17 My performance and targets rep, service_advisor, team_leader, sales_manager, gm
18 Team dashboard and overdue team_leader
19 Lead funnel and sources sales_manager
20 Outlet overview gm
21 Reputation: reviews and recovery gm, marketing
22 WhatsApp campaigns and consent marketing
23 Group overview and comparison dealer_principal
24 Subscription, invoices, limits org_admin, dealer_principal
25 Audit log org_admin
FILE 3 of 3: prototype/vendor-journeys/dealership.dc.html
ONE file, following salon.dc.html exactly: it holds no journey knowledge, imports
vendor-core, and lays out whatever journeyFor returns. Two additions to that
pattern:
A PERSONA switcher. Changing persona keeps you on the journey and re-filters the
steps, so an operator can see what one role actually does end to end.
A DEVICE switcher, mobile and desktop, which picks which href each step opens.
Keep the reuse badge counts and the computed verdict exactly as salon.dc.html
produces them, including the wording that a specific count above two is a warning
that the widget and capability model is carrying too little.
Add ONE new count beside them: PARITY, computed PER PERSONA, reading "11 of 11
steps on both surfaces" or "3 of 5, 2 phone only". A global number would hide a
persona whose desktop experience is half built, so it must be per persona.
Keep the READINESS block. Seed dealership readiness with the three real blockers:
card images do not resolve anywhere in the product, the card view beacon does not
record, and there is no role model, so every management view is unscoped.
Register all three files in SCREENS.md following the existing entries.
DESKTOP KEYBOARD SHORTCUTS ARE EXPLICITLY OUT OF SCOPE.
Do not design a shortcut layer for any dealership screen: no command palette, no
single key accelerators, no shortcut legend, no arrow key grid navigation. These
personas are a receptionist, a sales consultant, a service advisor and a manager,
not all day power operators, so a shortcut layer adds implementation complexity
and a discoverability burden for value they will not get. Desktop earns its keep
here through DENSITY, wider layouts, side by side panes and multi select, never
through accelerators.
Keep ordinary keyboard ACCESSIBILITY, which is a different thing and is not
negotiable: a sensible tab order, a visible focus ring on every control, Escape
closing a dialog and returning focus, and Enter submitting a form. Dropping those
would be a defect rather than a simplification.
Note the boundary: this applies to the DEALERSHIP screens. The QR setu admin panel
is used all day by internal staff and keeps its keyboard support.
RULES
Tokens only, no hardcoded colour, radius, spacing or font size. No native select
elements. Light and dark both work. A capability with no store behind it renders
as ABSENT, never disabled and never "coming soon". DO NOT use em dashes or en
dashes in any copy, label or example: use a comma, a colon, parentheses or two
short sentences. Do not volunteer a privacy reassurance next to a control. Do not
design any dealership screen in this round.Related
- Screen blueprint — the persona and feature source for step 2
- Persona feature map — plan labels per capability
- Admin control plane — the entitlement model the screens gate on
- Screen reviews — the retrospective half of the loop