Appearance
car_sales — the dealership operating layer
New to this? Start at the visual product map — eleven diagrams, a few minutes, no prose. Then read this page and product decisions. Everything else in this section is supporting evidence for the refusals.
Visual product map · Product decisions · Why QR Setu? · Personas, auth & RBAC · Operating model · Commercial model · Go to market · Market landscape · Operational gaps · Discovery brief
The thesis, in one paragraph
QRSETU is not building dealership software. It is building the attribution and accountability spine that dealership software does not have.
The OEM's system records transactions. A CRM records a pipeline. WhatsApp holds the conversation. Nothing records the causal chain from a named employee to a named customer outcome — which rep caused which interaction, what the customer looked at, what was promised, whether anyone followed up, and what happened in the end.
The Setu Card is the instrument that closes that chain, because it is the one artefact that is simultaneously a person's identity, a customer-facing surface, and an instrumented event source. That is the product. Everything else is either a consequence of it or a refusal.
What this is, and what it is not
| It is | It is not |
|---|---|
| An identity layer: every customer-facing employee has a card | A CRM with configurable pipelines |
| An attribution layer: every interaction traces to a person | A DMS, or any part of one |
| An accountability layer: hierarchy rollups, follow-up SLA | A reporting tool bolted onto someone else's data |
| A capture layer: walk-ins, enquiries, test drives, feedback | A lead source — see the correction below |
| A communication layer: WhatsApp, usage-priced | A marketing agency, or a website builder |
The eight decisions
| # | Decision | Consequence if you get it wrong |
|---|---|---|
| D0 | Sell to multi-brand dealer GROUPS, not to single dealerships | It is the only buyer that owns its own P&L, chooses its own tools, and has a problem the OEM systems structurally cannot solve, because each brand's system is a separate silo. Pricing the group layer is also where the margin is. See cross-brand consolidation |
| D1 | The employee Setu Card is org_owned, and customers belong to the showroom, not the rep | With 🌐 29.53% frontline attrition, a rep-owned card is a product that helps salespeople take your customers to their next employer. No Dealer Principal buys that twice |
| D2 | Positioned as lead CAPTURE and ATTRIBUTION, never lead GENERATION | Sell "more leads" and the dealer measures leads and you lose. A card is a warm mechanic; it does not create demand |
| D3 | Build nothing that touches the OEM transaction record, and integrate with no DMS in v1 | It is the most expensive, most fragile part of any dealership product, no Indian OEM publishes an API, and the card makes it unnecessary |
| D4 | Visitor management ships in the first release, not the sixth | It is the cheapest daily-habit hook in the whole product, and walk-ins are the majority of showroom traffic and currently invisible |
| D5 | QR Setu's account sends, so recharges stay sellable. Option B is REFUSED, Option C is the graduation | Meta bills whoever owns the account, and credits-versus-verified-branding is mutually exclusive. 🔎 A → C is a clean migration; B → C recreates every account and forfeits its quality history, so B is the only branch with no path onward. Utility messages need only the dealer name in the body. ⚠ Non-deferrable: a per-workspace send cap before the first campaign, because limits pool. Decision and its correction · QRS-848 |
| D6 | Sold as an ANNUAL platform commitment. No monthly price is published anywhere, on any surface | The value curve is back-loaded, so a monthly contract terminates before the product works. Floor Rs 75,000/yr, volume tier Rs 1,50,000/yr. The Rs 30,000 tier is withdrawn as below cost to serve (commercial model) |
| D7 | QR Setu NATIVE CHAT is the system of record for customer conversations. WhatsApp is reach and notification, never record | 🌐 The Cloud API can only read messages sent to a business number we control, so a rep's WhatsApp is permanently inaccessible — and routing customers to a business number is a customer-side behaviour change, the exact failure mode the roadmap avoids. Native chat gives a complete thread, free attribution and zero channel cost. ⚠⚠ But conversations.consumer_user_id is NOT NULL, so chat REQUIRES REGISTRATION — it is the destination, not the entry point. The entry point is an anonymous enquiry (orders.buyer_user_id is nullable, so the pattern already exists) answered over WhatsApp or by phone. Full analysis · QRS-860 |
⚠ Three validation pages were added 2026-08-23, and they exist to stop this section becoming a wish list
| Page | Answers |
|---|---|
| Persona feature map §0 | Does this persona need a Setu Card at all? The Team Leader card was challenged and removed from default scope — the card follows the target, not the title |
| Architecture validation | Can the existing multi-tenant schema carry each capability? 30 capabilities, five-level verdicts, checked against the live migration set |
| Deployment and isolation | Does a dealer have to share infrastructure? Four models, the version-parity strategy, and the gate that blocks selling dedicated environments today |
| ⭐ Screen blueprint | THE DESIGN INPUT. 51 screens across 9 personas, revalidated end to end, with a twelve-screen first cut. Where it disagrees with an older page, it wins |
| ⭐ Core vs industry-specific | ⭐ PLATFORM-WIDE. Google Business, reviews, messaging, campaigns, bookings and leads are CORE capabilities the dealership needs first, not dealership features. 🧮 Tested item by item: exactly ONE thing on the dealership list is genuinely industry-specific, and it is a compliance rule rather than a feature |
| ⭐ User lifecycle | ⭐ PLATFORM-WIDE, and it supersedes the dealership rules. 🌐 Researched against SCIM and DPDP. ⚠ users.status already declares a soft delete that NOTHING reads, and the design is bypassed by one click in the Supabase dashboard |
| ⭐ Data continuity | What happens to the data when an employee leaves? 🧮 The departure lifecycle and the audit log already exist; ⚠ but the employee Setu Card has no table and eight rules must be written into six tables that do not exist yet |
| ⭐ Admin control plane | Can the existing admin design carry custom per-dealer subscriptions? 🧮 The entitlement half already exists — 8 scopes, precedence as data. The RBAC half is 0%, and role SCOPE is missing from the design too |
| AI strategy | Which AI is real and what does it cost? 🧮 Inference is ₹25,500/yr for a busy outlet, and most proposed "AI agents" are SQL queries wearing a label |
| Podium teardown | Why is the proven competitor worth $3bn, and what should we take? 7 ADOPT · 4 ADAPT · 4 AVOID |
What must be true before any of this ships
Four prerequisites, all measured, in order of how badly they break the vision.
| Status | Note | |
|---|---|---|
| Card view tracking works | 🔴 BROKEN TODAY | 📘 QRS-734: the card's analytics beacon posts to track-card-event, which exists only in _archive_pre_v2/ and is not among the nine active functions on Dev. sendBeacon swallows failures, so every card view has recorded nothing, silently. The vision's first sentence is currently false at the platform level. 1-2 days. Fix this before anything else |
parties + leads exist | 🔴 not built | 🧮 Zero tables. 📘 QRS-823: parties is the party primitive and four registered features wait on it. A bespoke contacts table strands three of them |
| Role hierarchy exists | 🔴 0% built | 🧮 No roles, permissions, role_assignments, no is_admin(). The rep → TL → Manager → GM rollup is ADR-0023 D4 subtree roles plus ADR-0024 D1 oversight. Designed, accepted, unimplemented |
| Images resolve | 🔴 fails closed | 🧮 There is no public media URL in this repo; mediaUrl.ts returns null until a base is set, and nothing sets it. A vehicle card with no photographs is not worth sharing |
And the commercial arithmetic does not change, however good the product gets
The reframe makes the product far more differentiated. It does not fix the sales-capacity finding. 200 closes in twelve months is still 4 per week from two people who are also building and supporting the product; Pune still holds 45-70 franchised PV dealers. 🔎 The honest August 2027 commitment remains 20-30 logos and ₹20-35 lakh of ARR, with ₹2 Cr in H2 2028 — see commercial model.
What the reframe changed commercially is the pricing unit. ⚠ That framing was itself superseded on 2026-08-23 by annual per-outlet packages, because a per-card meter reintroduces the per-seat negotiation it was meant to avoid. Original reasoning, kept because it is still half right: per-card tiers scale with the dealership and make the unit of value countable, where flat-per-outlet did not.
How to read the rest of this section
| Page | Answers |
|---|---|
| Visual product map | What the product is, in eleven diagrams. The fastest way in, and the only statement of build status |
| Product decisions | What to build, what is table stakes, what to refuse, what we own, what compounds. The primary artifact |
| Why QR Setu? | Why a dealer would buy, and why they would not. Adversarial by design, and it revises the roadmap |
| Personas, auth & RBAC | Who the users are, how they log in, what each may and may not see, and the login-route decision |
| Operating model | How the card, the hierarchy, the visitor register and the journey actually work, and the three hard design decisions inside them |
| Commercial model | Per-card pricing, ARPU, add-ons, the WhatsApp economics, and the ₹2 Cr arithmetic |
| Go to market | Pune denominator, positioning, roadmap, risks, and the three validation experiments |
| Market landscape | Who else sells here and what they charge. This is the evidence that licenses the refusals |
| Operational gaps | Dealer P&L, where the money actually is, and pain by role |
| Discovery brief | The G-D gate artifact, deliberately at 🔴 not started |
Evidence classes
Same discipline as the Strategy section. 📘 documented in this repo · 🧮 measured by a command or probe · 🌐 external with a source · 🔎 inferred judgement · ❓ unvalidated.
The limitation that has not changed
No Indian dealer has been asked anything. Zero interviews, zero franchise agreements read, zero realised contract values. The product reasoning here is strong because it rests on QRSETU's own architecture and on audited dealer filings; every price remains 🔎, and the three experiments are still the recommendation.