Appearance
Product decisions: build, must-have, never build, own, moat
Part of
car_sales— the dealership operating layer. This is the primary artifact of this section. The other pages exist to justify the refusals.
0 · The organising rule
One test decides every row below
Does it make the causal chain from a named employee to a named customer outcome more complete or more visible?
If yes, it is in scope. If it duplicates the transaction record, the pipeline, or the conversation, it is out — because the OEM system, a CRM and WhatsApp already hold those, and QRSETU would be the fourth place the same fact lives.
1 · BUILD — the differentiated core
Priority order is deliberate: each row is buildable on what the row above it establishes, and the first three are the product.
| # | Capability | Why it differentiates | Primitive |
|---|---|---|---|
| B1 | Employee Setu Card, one per customer-facing role — rep, team leader, manager, receptionist. Carries profile, designation, dealership, live catalogue, offers, and the four actions (enquiry, test drive, callback, feedback) | Nobody has this. The OEM system has no concept of an employee-owned customer surface. A visiting card is not measurable and a phone number is not attributable | existing card + party |
| B2 | Interaction attribution — every open, scan, view, tap and submission carries which card, which employee, which item | This is the whole product. It converts an unmeasurable act (handing over a number) into a countable one | analytics_events |
| B3 | Auto-lead on submission, attributed and assigned — an enquiry from Ravi's card creates a lead owned by Ravi, visible to his TL and GM, with no duplication | 📘 ADR-0024 D1: one row read at three levels. No sync, no "also flows into" | leads + party |
| B4 | Hierarchy rollups — rep → team leader → sales manager → GM, read-only upward | 📘 ADR-0023 D4 subtree roles + ADR-0024 D1 oversight. Designed and accepted; nothing implements it | RBAC |
| B5 | Follow-up tasks with SLA and overdue visibility — who has not followed up, and where leads are being lost | The single most-cited operational pain, and 🌐 currently handled by 262 tele-callers against 11 IT staff at one listed group | schedule |
| B6 | Visitor register — the receptionist's notebook, digitised: name, number, purpose, vehicle of interest, rep assigned, and an auto-created follow-up | 🔎 The sleeper hit. Cheapest daily-habit hook in the product, needs no OEM data, and walk-ins are the majority of showroom traffic and currently invisible to every system | party + schedule |
| B7 | Dealership organisational card — catalogue, offers, team directory, test-drive and enquiry actions, location, reviews | Gives the dealer a customer-facing surface they control. ⚠ Positioned as a storefront, not as a website replacement — see §3 | existing card |
| B8 | Test-drive booking against a vehicle and a slot | 🌐 Two reps promising the same demo car is a named pain (ADR-0024 P6) | schedule + resource |
| B9 | Feedback capture at the interaction, not by survey | Post-test-drive and post-visit. Feeds the rep's own record, which is what makes it get used | party |
| B10 | Targets per person and per team | 📘 ADR-0024 §0 already scoped targets as a feature over the analytics layer, not a primitive | targets |
| B11 | Group Intelligence - cross-outlet and cross-brand rollup, group targets, oversight across the subtree | The one capability no OEM system can produce, because each brand's system reports upward to its own manufacturer. Consolidation today is a person with a spreadsheet at month end | tree + RBAC |
🔎 B11 is last to build and first in defensibility. It needs B4's hierarchy and the RBAC wave beneath it, so it cannot come earlier. But it is the row a competitor cannot clone in a quarter, and it is the premium SKU. Sequence it last; price it highest.
2 · MUST HAVE — table stakes, no strategy spent here
Ship them competently and never let a demo become a feature comparison.
| Capability | Note |
|---|---|
| Mobile-first for the rep | Non-negotiable. 🌐 The named gap in every OEM DMS critique, including from the vendors who built them |
| Lead list with source, owner, age, status | Flat and fast. No configurable pipeline builder — see §3 |
| Customer record keyed on phone | 📘 This is parties, with phone_e164 and user_id both nullable, at least one present (QRS-823) |
| Search and filter that survives 40,000 rows | 📘 Keyset pagination on ledgers, predicate-based bulk actions, never a list of ids |
| Role-based access | The hierarchy is the product; the permission model is how it is enforced |
| Light and dark, English + one Indian language | 📘 Existing platform standard, not a feature |
| Masked phone display with audited reveal | 📘 A CSV export of a dealer's customer list is the highest-risk action in the module |
3 · DO NOT BUILD — and the reason, so "no" stays cheap
This is the most valuable list on the page. Each refusal has a reason that survives being re-proposed in six months.
Because the OEM owns it and the dealer cannot switch it off
| Do not build | Reason |
|---|---|
| Any part of the enquiry-to-delivery transaction record | 🌐 Mandated: Maruti, Hyundai GDMS, Kia GDMS 2.0, Tata Siebel, Mahindra DMS 2.0, Hero Connect, TVS, Bajaj iDMS, HMSI, Mercedes SKYLine, Ather |
| Invoicing, allotment, PDI, gate pass, warranty claims, parts ordering | Same. And 🌐 Excellon (₹74.21 Cr, 466 people, Pune office) competes here and will win |
| Financing origination | 🌐 Maruti Smart Finance alone: 2.5 m loans, ₹1,70,000 Cr, "over 40% of our customers" |
| CSI / SSI surveys and OEM reporting | The OEM's instrument, filed to the OEM |
Because it is the wrong product shape
| Do not build | Reason |
|---|---|
| DMS integration, in v1 or v2 | 🌐 No Indian OEM publishes a third-party API. The only working India integration found is a dealer-mediated batch extract. ⚠ And the card makes it unnecessary — the product generates its own data, which is what removes QRS-835 from the critical path. Building sync would be the most expensive and most fragile part of the product, in exchange for data the vision does not need |
| A configurable pipeline / stage / workflow builder | The moment you ship one you are competing with LeadSquared and Kapture on their terms, on their feature list, at their price. 📘 And a configurable workflow engine has been refused on three independent grounds already |
| "Lead generation" as a claim or a feature | 🔎 A Setu Card is a warm mechanic: it travels because a rep hands it over. It captures and attributes demand; it does not create it. Selling generation sets a measurement the product will fail |
| A website builder | The organisational card is a storefront. A dealer website is SEO, forms, brand compliance and hosting support — a different product with a different cost base. ⚠ 🌐 And it is OEM-dependent: Hyundai hosts dealer microsites on its own domain |
| Accounting, GST, inventory valuation | Tally and Marg territory |
| Call-centre telephony, IVR, dialler | 🌐 Integrate Exotel / MyOperator / Acefone at ₹1,300-1,999 per user per month. Never own a dialler |
| HR, attendance, payroll | Adjacent, tempting, and an entirely different buyer and compliance surface |
Because it is legally or commercially closed
| Do not build | Reason |
|---|---|
| Insurance or finance commission earning | 🌐 Licence-gated. An MISP is appointed by an insurer and may not solicit motor insurance from anyone who did not buy the vehicle from them; RBI's Digital Lending Directions 2025 govern the finance side. Sell the attach workflow; never touch the commission |
| Vahan / registration market-intelligence dashboards | 🌐 Dead. The 2019 bulk-data policy was scrapped in 2020; the Aug 2025 replacement names insurers and law enforcement, not analytics firms; and Vahan4Dashboard was discontinued 15 August 2026 |
| Marketplace lead resale | 🌐 CarDekho, CarWale, Cars24, Droom and Spinny publish nothing and own that business |
| Agency retainers, creative, 360° imaging, recruitment, training delivery | Labour businesses. They do not scale past two people. Refer out and take a fee |
| Targeted or profiled advertising on cards | 📘 Reverses ADR-0010 D7's counts-only decision and brings DPDP profiling duties |
| Any in-app purchase CTA on native | 📘 ADR-0002 / Apple 3.1.3(d). A store-review risk, not a preference |
Because it would break the platform model
| Do not build | Reason |
|---|---|
| A second card-product abstraction | 📘 The standing naming rule forbids a shared contract across card products that do not exist |
Hardcoded per-vertical nudges or if (industry === 'car_sales') branches | 📘 ADR-0021 D4 lints against exactly this. Ask for a feature, never an industry |
A bespoke contacts table | 📘 It is parties, the party primitive, and four registered features depend on it (QRS-823) |
| A per-dealer send cap deferred to "later" | ⚠ 📘 ADR-0030: Meta's messaging limits pool per business portfolio, so on a shared account one dealer's festival campaign can silence every other dealer's transactional messages. Non-deferrable |
4 · WHAT QRSETU CAN OWN
The causal chain from a named employee to a named customer outcome
No incumbent holds it, and the reason is structural rather than accidental:
- The OEM DMS records the transaction. It has no concept of which rep caused this, because it was built to report upward to the manufacturer.
- A CRM records the pipeline. It starts at "lead exists" and cannot see the interaction that created one, because there was no instrument on it.
- WhatsApp holds the conversation and has no structure, no ownership, no rollup.
- A visiting card is unmeasurable by definition.
🔎 QRSETU can own the layer between the person and the outcome. That is a genuinely vacant position, and 🌐 the local incumbent cannot take it without a conflict: Excellon's customer is the manufacturer.
5 · THE MOAT — what compounds with use
🔎 Ranked by how expensive it is to leave. A moat is not a feature; it is an asset the dealership builds inside the product and cannot carry out.
| # | Asset | Why leaving costs | Strength |
|---|---|---|---|
| M1 | The card network — every rep's card, shared with every customer, over years, sitting in customers' phones and WhatsApp histories | Switching means re-issuing every identity and abandoning every link already in circulation. This is the strongest moat available and it is unique to the card model | Very high |
| M2 | Attribution history per employee | After a year it is the dealership's own performance and incentive record. Not exportable in any useful form, and it is what the GM runs reviews off | Very high |
| M3 | Follow-up and SLA history | The record of who did and did not act. It has evidentiary value in an appraisal, which makes it politically load-bearing | High |
| M4 | Customer interaction history keyed to parties | Who visited, what they viewed, what was promised. 📘 ADR-0024 D2 puts the customer at the showroom, so it survives a rep leaving | High |
| M5 | WhatsApp consent ledger and template library | 📘 Migration is a re-consent exercise, not an export | High |
| M6 | Vehicle / asset service history | 📘 ADR-0024 D3. Later, and it is the bridge into the 🌐 41.2%-gross-margin after-sales line | Medium now, high later |
| M7 | Cross-brand, cross-outlet operational history | Ranks with M1 and M2 despite being built last. Once a Dealer Principal runs a Monday review off one screen covering six brands, no single-brand system replaces it - and rebuilding the comparison elsewhere means re-instrumenting every outlet | Very high |
⚠ M1 and M2 only hold under decision D1. If the card and its leads belong to the employee rather than the organisation, then every asset above walks out of the building at 🌐 29.53% a year, and the moat inverts into a liability. See operating model.
6 · Where the vision needs correcting
🔎 My job is to argue with this, not to dress it up. Five items, in descending order of how much money they cost if left as written.
| # | The vision says | The correction |
|---|---|---|
| 1 | "Lead Generation" is in the ecosystem list | It is capture and attribution. A card does not create demand. Keep the word out of the pitch and the roadmap, or the dealer will measure lead volume and conclude the product failed |
| 2 | The salesperson's card is "their digital identity and customer acquisition channel" | Correct as an experience, dangerous as ownership. The card must be org_owned and the customer must belong to the showroom, or the product becomes a customer-export tool for departing reps |
| 3 | "Every Setu Card scan should become a business data point" | It does not today. 📘 QRS-734: the beacon posts to an archived function and fails silently. This is prerequisite zero |
| 4 | WhatsApp as a "recharge / usage-based" add-on | Wanting recharges means QRSETU must be the party Meta bills, which means QRSETU's own account sends — so the dealer does not get verified branding in the chat header. Dealer-branded sending requires the dealer to own the account, and then Meta bills them and there is nothing to recharge. Pick one, and know that credit-line attachment is irreversible per account. ✅ Decided 2026-08-23: Option A now, C as the graduation, B refused - commercial model |
| 5 | Visitor management appears sixth, as a "simple but very real" problem | 🔎 It should be in the first release. It is the only capability here that creates a daily habit for a non-sales employee, needs no OEM data, no attribution model and no hierarchy, and it captures the traffic every other system misses |
And one thing the reframe does not fix
The product case is much stronger than the generic one. The commercial case is unchanged: 200 logos in twelve months is still 4 closes a week for two people. 🔎 A better product does not create sales capacity. See commercial model.
Related
- Operating model — how B1-B6 actually work, and the three hard design decisions
- Commercial model — the annual package book, cost to serve, and the WhatsApp decision
- Market landscape — the evidence behind §3's refusals