Visual product map

Start here. This page exists so a developer, product team member or new joiner can understand the whole car_sales product in a few minutes, before reading any prose. Every diagram answers one question.

Decisions are in product decisions · mechanics in operating model · pricing in commercial model.

Read in this order

#	Diagram	Answers
1	The ecosystem	What is this product, in one picture?
2	Group structure	How does a multi-outlet, multi-brand dealer group map onto the model?
3	Dealership hierarchy	Who are the people, and how does information move between them?
4	Customer journey	What actually happens, from first contact to won or lost?
5	Operational data flow	How does an interaction become data, and who sees it?
6	Feature ecosystem	What are the capabilities, grouped meaningfully?
7	Manual to digital	What does this replace inside the dealership?
8	Communication automation	How do WhatsApp messages fit the workflow?
9	Cross-brand consolidation	What can this do that no OEM system can? The moat
10	Why a dealer would pay	What is the business case?
11	Build status	What exists today, and what does not? Read this before writing code

Conventions used in every diagram

• Solid arrow = an action or a write. Dotted arrow = a read-only view or rollup.
• Dashed border = a system QR Setu does not own and does not replace.
• No diagram on this page asserts that a capability is built. Diagram 11 is the only statement of build status, and it is the one a developer needs first.

1 · The ecosystem

The one picture. Everything else on this page is a zoom into part of it.

Three things to take from this diagram

1. The card is the entry point. Every path to a lead starts at a card or at reception. There is no path that starts in the OEM system.
2. The dotted OEM arrow is a deliberate non-connection. No Indian OEM publishes a third-party API, and the card generates its own data — so v1 needs no integration. That is what removes the project's only existential risk.
3. The GROUP box is the commercial one. Everything below it exists in some form elsewhere in the market. The group view is the thing no single-brand system can produce — see diagram 9.

2 · Group structure: multi-outlet, multi-brand

The buyer is usually not one showroom. It is a group that carries several brands across several outlets, and each brand comes with its own mandated OEM system.

Four rules this structure encodes, all already decided

• Levels are expressible, never mandated. Brand and Region are optional nodes. A single-brand dealer carries no Brand level and no empty placeholder. Dealer groups genuinely differ — some run location-P&L (Thane → {Sales, Service}), others division-P&L (Sales → {Thane, Andheri}) — and the tree lets the customer choose rather than imposing one shape. 📘 ADR-0024 D5.
• Depth is capped at 6. root → brand → region → showroom → division → agent is the realistic deep case.
• The customer belongs to the SHOWROOM, one level above Sales and Service. That is what makes the sales-to-service join a property of the data model rather than a report someone has to build. 📘 ADR-0024 D2.
• Sharing flows down, oversight flows up, and they are never symmetric. A child may use an ancestor's resources (default off). An ancestor may read descendants' operational data, never write it.

A location is not a business unit

📘 The test from ADR-0023: if a place needs its own card and its own P&L it is a WORKSPACE; if it is only an address it is a LOCATION. A showroom is a workspace. A second collection point with no separate books is a location. Getting this wrong is what produces empty tree levels and meaningless rollups.

3 · Dealership hierarchy and information flow

Authority flows down. Visibility flows up. They are separate mechanisms.

Persona and scope are two different axes

Persona = role — what you may do. Scope = workspace subtree — where you may do it. A Sales Manager at Thane and a Sales Manager at Andheri are the same role at different scopes, and a regional manager is one role over several scopes. 📘 ADR-0023 D4 makes roles assignable to a subtree, which is what lets one model serve all three without a per-outlet special case.

And the privacy boundary: oversight reaches only organisation-owned workspaces. An employee's personal side business or consumer identity is never visible to their employer.

4 · Customer journey, card to outcome

Note the "no action" branch, because it is the difference between this and a CRM

A CRM starts at "a lead exists". This starts one step earlier: a customer who opened a card and left without acting is still a recorded, attributed interaction. That is the population no other dealership system can see, and it is where follow-up discipline actually pays.

5 · Operational data flow and management visibility

How one interaction becomes data, and who then sees it.

The same rows read at a different scope, never a separate report:

Level	Reads
Rep	own card views, leads, tasks due and overdue, test drives, conversions
Team Leader	the above per rep, plus team totals and who is not following up
Sales Manager	per team, per outlet, funnel by stage and by loss reason
GM	the whole outlet, all divisions
Dealer Principal	every outlet and every brand in the group, compared side by side

6 · Feature ecosystem

Grouped by the job they do, not as a flat list.

🔎 Group Intelligence is the only cluster a competitor cannot clone cheaply, because it needs the workspace tree underneath it. Everything else on this diagram is a feature; that one is an architecture.

7 · Manual process to QR Setu workflow

Note the wording on the website row

The dealership card is a storefront, not a website replacement. A real dealer website carries SEO, brand compliance, hosting and support obligations, and is often controlled by the OEM. Claiming replacement there would be over-promising, so the diagram says partly served by.

8 · Communication and marketing automation

Every message is triggered by an operational event, never sent blind.

One architectural fork this diagram cannot show, and it must be decided before the first customer

Selling recharges requires QR Setu to be the party the messaging provider bills, which means messages go out on QR Setu's account, so the dealer does not get a verified sender name in the chat header. Giving the dealer their own verified sender means the provider bills the dealer, and there is nothing to recharge. The two are mutually exclusive, and the choice is irreversible per account.

⚠ And with a shared account, messaging limits pool across every tenant, so a per-workspace send cap is non-deferrable — one group's festival campaign could otherwise throttle every other dealer's transactional messages. Recommendation: operating model §8, decided in commercial model - Option A now, C as the graduation, B refused because B → C forfeits every account's quality history.

9 · Cross-brand consolidation: the one thing no OEM system can do

This is the moat, and it is structural rather than a feature

A group carrying Maruti, Tata and Skoda runs three mandated systems that cannot be joined, because each one exists to report upward to its own manufacturer. Consolidation today is a person with a spreadsheet at month end.

Be precise about what is being consolidated, or this becomes a false claim

🔎 QR Setu consolidates card-originated operational data — interactions, leads, follow-ups, test drives, visitor volume, per-employee performance — across brands. It does not consolidate OEM transaction data, because there is no OEM API and v1 deliberately does not integrate.

So the honest pitch is "one view of how your people and your enquiries are performing across every brand you carry", not "one view of your whole business." The second would require the DMS data this product refuses to depend on.

🔎 Why a competitor cannot copy this quickly: it needs an organisation tree with a materialized path, subtree-scoped roles, and oversight policies that prove the negatives. And the strongest local incumbent structurally cannot sell it at all — its customer is the manufacturer, and a cross-brand view is the one thing a manufacturer does not want its dealers to have.

10 · Why a dealer would pay

The dashed final box is deliberate

🔎 Improved conversion is the intended business impact, not a guarantee, and there is no Indian dealer measurement behind it yet — no interviews, no pilot, no realised numbers. What the product can honestly promise on day one is the boxes before it: attribution that did not exist, follow-up that is now visible, and a group view that previously took a person and a spreadsheet. Sell those; let conversion be the consequence the dealer measures for themselves.

The positioning, in one line

TIP

Not another CRM or DMS. A digital operational layer connecting dealership employees, Setu Cards, customer interactions, leads, follow-ups, test drives, communication, team performance and management visibility — across every outlet and every brand the group carries — sitting alongside the OEM systems the dealer already has to use, not replacing them.

11 · Build status: what exists today

Read this before writing any code

The ten diagrams above describe the product model. This one describes the repository, measured 2026-08-22. The gap between them is the roadmap, and mistaking one for the other is the most expensive error available on this page.

The group layer is the best-built and the least-reachable part of the product

🧮 The tree, the materialized path, the depth cap and the three RLS helpers are done and pgTAP-proven against a fixture named Kalyani Motors with Thane and Andheri showrooms. But nothing in the product can create an organisation — the only INSERT into organizations anywhere in the repo is that test fixture, and provision_merchant_workspace creates only member-owned workspaces with organization_id is null. There is also no org-level subscription (workspace_subscriptions is keyed on workspace_id) and no org admin surface (apps/web has no auth at all).

🔎 So diagram 9 — the moat — is the capability with the strongest foundation and the longest remaining path to a customer. That is worth knowing before it gets promised in a demo.

The first release is deliberately the subset that needs the least:

Order	Item	Why first
1	Fix the card view beacon	Without it "every scan becomes a data point" is false, and it is 1-2 days
2	parties	The customer record. Four registered features depend on this one primitive
3	Visitor register	Needs only parties plus a task. No attribution model, no hierarchy, no OEM data
4	Card attribution + auto-lead	The product thesis, once 1 and 2 exist
5	RBAC with subtree roles	The hierarchy. Its own wave, and the gate on everything above Team Leader
6	Org provisioning + Group Intelligence	The moat, and the premium SKU. Needs 5 plus an org write path and billing

Full measured table with file-level detail: operating model §9.

Related

• Product decisions — build, must-have, never build, own, moat
• Operating model — ownership, attribution, the hierarchy, the WhatsApp fork
• Commercial model — annual packages, Group Intelligence, cost to serve, ARPU
• Index — the thesis and the decisions