sims-hq/docs/11-ADMIN-SUPPORT-CONSOLE.md

# 11 — Admin, Settings & the HQ Support Console

Founder review question (2026-07-09): *"how are the support sections, and are there admin
pages/settings — default settings, multi-tenant settings, etc.?"* Verdict: the tenant-side
Admin module is specified in 09-UX-FLOWS-AND-MENUS.md (in the Store repo) (§2 menu
tree → Admin; §5.7 error-code support handshake; print-profile remote fixes in §5.4). What
was **missing** is the vendor side — the console *our* team and dealers use to run the
whole fleet. This doc fills that gap and consolidates the settings model.

> ## ⚡ Staging update (founder call, 2026-07-09 — see D15)
> **The commercial slice of this console is built early** as `apps/hq`, aimed at the
> *current Classic client base*: tenant/client directory, Billing & Collections,
> notes/history — spec: [14-SPEC-HQ-CONSOLE.md](14-SPEC-HQ-CONSOLE.md), which adds
> quotations/proforma, AMC, AWS cost attribution and the interaction log beyond this doc.
> Fleet/support/catalog features keep the §5 phase mapping and still wait for the cloud tier (D14).

## 1. The five surfaces (corrected count)

| Surface | Who | Where specified |
|---------|-----|-----------------|
| POS Counter | store staff | 09 §1 |
| Back Office web | tenant's managers | 09 §2 |
| Owner App | tenant's owner | 09 §4 |
| Customer Display | the queue | 09 §1 |
| **HQ Console** (internal web) + dealer portal view | **SiMS staff, dealers** | **this doc** |

## 2. The settings model (one mechanism, five scopes)

Every setting is a row: `setting(scope_type, scope_id, key, value, effective_from)`.
Resolution: nearest scope wins — `user → counter → store → tenant → system`.

| Scope | Edited from | Examples |
|-------|-------------|----------|
| **system** (= SiMS default) | HQ Console → Catalogs → Default Settings | default rounding rule, default print routing, default alert thresholds, IRN retry window, grace-period days |
| **tenant** | Back office → Admin → Settings | GST scheme (regular/composite), FY start, invoice formats, dealer-first support routing, languages enabled |
| **store** | Back office → Admin → Stores | store print language, negative-stock policy, khata limits default |
| **counter** | Back office or POS Settings (supervisor) | print profiles, approval timeout, quick-keys layout, font size |
| **user** | The user (POS/app settings) | language, notification preferences, muted alert types |

Rules: every override shows what it inherits ("Inherited from Store: ₹500 — Override?")
with one-click **reset to inherited**; changes are effective-dated and audit-logged; a
"changed from default" filter exists at every scope — support's first question answered
in one click. **New-tenant provisioning = the system scope snapshot** + edition template;
that's what "default settings" means operationally.

## 3. HQ Console — menu tree

Internal web app on the cloud tier (never store-installed). Staff roles: Support Agent,
Support Lead, Product Admin, Finance, Read-only Auditor. **Every staff action touching
tenant data is itself audit-logged — we are tenants of our own audit system.**

- **🏬 Tenants**
  - Directory: search, filters (edition, region, dealer, version, sync health, renewal due).
  - Tenant 360°: stores/counters/devices with app versions, sync lag, last backup,
    subscription state, usage stats (bills/day), open error-code counts, notes/history.
  - Lifecycle: provision (from edition template), suspend (grace rules), archive/export
    (DPDP-compliant handover), delete with legal-hold checks.
  - **Migration tracker**: Classic→Next pipeline per customer (scheduled → data pulled →
    verified → parallel-run → cut over → Classic retired), verification-report status.
- **💳 Plans & Pricing** (Product Admin only)
  - Plan editor (`plan`, `plan_feature` matrix — feature flags as rows).
  - `price_book` with effective dates (D5: prices are data; changing them is a row, not a release).
  - Offers: migration discounts, dealer pricing, renewal offers.
  - Upsell content editor: the in-app paywall screenshots/text per feature (DB-driven marketing).
- **📚 Catalogs** (pushed to fleet via sync)
  - `message_catalog` editor with translation workflow (missing-strings report,
    machine-draft → human-confirm per language).
  - `error_catalog` editor incl. the internal `support_note` playbook per code.
  - GST rate catalog: dated rate pushes (the GST-2.0-style event = one dated dataset push).
  - HSN reference data; default print/label template gallery.
  - Default Settings (the `system` scope — §2).
- **🚀 Fleet**
  - Version dashboard: which store runs what; rollout **rings** (internal → pilot stores →
    dealer wave → all) with halt/rollback; version pinning per tenant when needed.
  - Sync health map: red/amber stores (lag, backlog size, last error), drill to op log.
  - Telemetry explorer: error-code frequencies (E-xxxx as the currency of support),
    per-bill timing percentiles by store — the "fastest counter" SLA, watched live.
- **🛟 Support**
  - Queue/board (or ticket-system integration — decide in D13): tickets carry tenant +
    error codes automatically from the diagnostic bundle.
  - Store 360° (same as tenant view, scoped to one store) with **remote actions**:
    pull logs, push config fix (e.g., print profile), re-pair a reinstalled POS,
    refresh license token, trigger backup, queue a test print.
  - **Impersonation** ("view as tenant back office"): requires owner consent (OTP/WhatsApp
    approve), is time-boxed, watermarked on screen, fully audit-logged, and never covers POS.
  - Backup/restore console with restore-drill tracking per store (the drill is a checklist
    item, not a hope).
- **🤝 Dealers**
  - Directory, territories, their customer lists, commission statements.
  - **Dealer portal** (restricted HQ view): only their tenants; onboarding wizard launch,
    migration tracker, first-line support tools (no impersonation, no catalogs, no pricing).
  - Kit management: install packages, keyboard sticker sheets, training scripts.
- **💰 Billing & Collections** (Finance)
  - Our own GST-compliant subscription invoices to tenants; renewals-due pipeline;
    dunning sequences (WhatsApp/email, from `message_catalog`); dealer commission runs.
- **⚙️ Internal Admin**
  - Staff users/roles, staff-action audit browser, GSP/WhatsApp/UPI credential vault
    (rotation dates), environment health.

## 4. Support flow, end to end (shop → HQ)

1. **In-app**: error rail shows `E-2101` + plain-language fix; if unresolved, **"Get help"**
   sends a diagnostic bundle (app version, device profile, last 50 error events, sync
   status, anonymized — never bill contents) and shows the tenant's support route.
2. **Routing** (tenant setting): dealer-first (default — the dealer relationship is the
   channel) or direct-to-SiMS; WhatsApp support number deep-link with the error code
   pre-filled — the shop's preferred medium.
3. **HQ**: ticket lands with tenant/store/code attached; agent opens Store 360°, uses
   remote actions; escalation to impersonation only with consent; the `support_note`
   playbook per error code is the agent's first screen.
4. **Loop closed**: resolution tagged per error code → weekly top-codes review feeds the
   backlog (a code that spikes is a product bug, not a support workload).

## 5. Phase mapping

| Phase | HQ Console scope |
|-------|------------------|
| **1 (MVP)** | Tenant provisioning + lifecycle, license/plan assignment, fleet version dashboard + rollback, Store 360° with log pull + config push, migration tracker, system-scope defaults, staff roles + audit |
| **2** | Full catalogs editing (messages/errors/GST pushes), sync health map, rollout rings, billing & dunning *(moved early → HQ-1/HQ-2, see staging note and [14-SPEC-HQ-CONSOLE.md](14-SPEC-HQ-CONSOLE.md))*, support queue |
| **3** | Dealer portal, impersonation (with consent flow), telemetry explorer, upsell content editor, commission runs |
| **4** | Restore-drill automation, advanced fleet analytics, API/partner management |

## 6. New decision raised

**D13 — Support ticketing: build the queue in HQ or integrate an existing helpdesk?**
Recommendation: integrate something boring in Phase 2 (the diagnostic bundle and Store
360° are ours; the ticket list is commodity), revisit building only if the integration
fights the error-code workflow.