BiznessTag — CRM program: two new application sections (client brief)

Program nature: This is not a navigation-only refactor. We are introducing two new major product areas — Leads and Commerce — which require fundamental application changes: entitlement and session-driven visibility, new API/domain contracts, information architecture shifts (where catalogue depth lives), and new user journeys end-to-end.

Purpose: Align stakeholders on what is being introduced, who gets it, how access is decided, and how each section fits the business—not on “reshuffling tabs” alone.

Status: Planned. Phase2 items are directional until product signs off MVP.

1. Program scope (one picture)

The app grows from a single-purpose storefront shell into a dual-track product: pipeline (Leads) alongside catalog + commercial operations (Commerce), while preserving existing areas for non-CRM merchants.

flowchart LR
  todayMind[Mobile_application_today]
  program[CRM_program_fundamental_expansion]
  leads[New_section_Leads]
  commerce[New_section_Commerce]
  keeps[Existing_areas_evolve_in_parallel]

  todayMind --> program
  program --> leads
  program --> commerce
  program --> keeps

Outcomes: clearer ownership of “work the deal” vs “run price, tax, quotes, orders, and money”; new capabilities surfaced as first-class sections—not buried in Catalogue.

Surface labels may still be rebranded (e.g. Pipeline, Sell desk); scope remains new product + platform work.

2. Application shell: before vs after (concept)

Before: Bottom area reflects Home · Catalogue · Share · Shop · Insights (conceptual order—implementation as today).

flowchart LR
  subgraph beforeProgram [Shell_before_CRM_sections]
    direction LR
    t1[Home] --- t2[Catalogue] --- t3[Share] --- t4[Shop] --- t5[Insights]
  end

After (when entitled and flags allow): Same family of areas, plus dedicated entry points for Leads and Commerce — a structural change to how the app is organised, not a swap of icons only.

flowchart LR
  subgraph afterProgram [Shell_with_new_CRM_sections]
    direction LR
    x1[Home] --- xl[Leads_NEW] --- xc[Commerce_NEW] --- x3[Share] --- x4[Shop] --- x5[Insights]
  end

iA = information architecture. Deep catalogue and selling work is expected to centralise under Commerce over time; transitional dual entry is a product/design decision.

3. Who gets the new sections? (access model)

flowchart TD
  start[Merchant opens app]
  crmPurchased{Bought CRM digital product}
  login[Login_or_session_refresh]
  flags{Server_flags}
  customers["customers_tab = true"]
  billing["billing_tab = true"]
  showLeads[Surface Leads section]
  hideLeads[Omit Leads section]
  showCommerce[Surface Commerce section]
  hideCommerce[Omit Commerce section]
  account[Account_two_program_options]
  shell[Application_shell]

  start --> crmPurchased
  crmPurchased -->|"no"| noCrm[No new CRM sections]
  crmPurchased -->|"yes"| login
  login --> flags
  flags --> customers
  flags --> billing
  customers -->|"true"| showLeads
  customers -->|"false"| hideLeads
  billing -->|"true"| showCommerce
  billing -->|"false"| hideCommerce
  showLeads --> account
  hideLeads --> account
  showCommerce --> account
  hideCommerce --> account
  account --> shell

Flags belong in authenticated session/profile (login, refresh, /auth/me—contract TBD). Account exposes two program-related controls (visibility, shortcuts, defaults — exact UX product-owned).

Commercial packaging ↔ flags

flowchart LR
  suite[CRM_Suite_bundle]
  leadsOnly[Leads_addon]
  billOnly[Billing_addon]
  cf[customers_tab]
  bf[billing_tab]
  suite --> cf
  suite --> bf
  leadsOnly --> cf
  billOnly --> bf

Substitute your real SKUs. Plan changes and refunds must keep commercial SKUs and server flags in lockstep.

4. New section — Leads (customer pipeline)

Intent

Seller-side onboarding into the merchant’s funnel (the end contact need not install BiznessTag).

Create lead (multi-step product flow)

flowchart LR
  step1["1_Customer_phone_or_id"]
  step2["2_Pick_own_product_service"]
  step3["3_Confirm_defaults_label_status"]
  step1 --> step2 --> step3

Single catalogue truth — reuse business products; avoid duplicate SKU semantics.
Phase2 roadmap: source, assignment, SLA, attachments, integrations.

Lists, detail, and customer-level coherence

flowchart TB
  list[Lead_list_labels_sort]
  open[Open_lead_detail]
  editStatus[Edit_status]
  sameCust{Same_customer_id}
  history[Surface_related_prior_leads]
  coherent[Harmonise_statuses_no_silent_conflict]

  list --> open --> editStatus
  open --> sameCust
  sameCust -->|"yes"| history --> coherent
  sameCust -->|"no"| editStatus

5. New section — Commerce (catalog depth + quotes + orders + money)

Working name: Commerce (alternatives: Business hub, Sell desk). This section is the anchor for advancing how selling is modelled in-app—broader than “add product” on Catalogue.

Capability stack (product building blocks)

flowchart TB
  subgraph struct [Catalog_structure]
    cat[Categories_subcategories]
    taxCat[Tax_defaults_per_category_phase]
  end
  subgraph prod [Products]
    cols[India_relevant_tax_fields_taxable_exempt_ETC_phase]
  end
  subgraph sell [Commercial_lifecycle]
    q[Quotes_proposals_revision]
    payIntent[Full_or_partial_payment_intent_phase]
    o[Orders]
    inv[Invoices]
    pay[Payments_via_gateway_CTX_only]
  end
  struct --> prod
  prod --> q --> payIntent --> o --> inv --> pay

Compliance posture: GST / HSN / SAC / place-of-supply are merchant-entered and CA-validated contexts; not legal advice. Payment behaviour follows gateway and regulatory constraints.

Document and money flow (narrative)

sequenceDiagram
  participant M as Merchant
  participant Cat as Catalogue
  participant Q as Quote
  participant O as Order
  participant I as Invoice
  participant P as Payment

  M->>Cat: structure_and_products
  M->>Q: draft_revise_convert
  Q->>O: optional_path
  O->>I: optional_path
  I->>P: collect_partial_or_full

Open program decision: Does billing_tab authorise entire Commerce or only invoicing/settlement? Locks navigation and downgrade behaviour.

6. Rollout — continuity beside fundamental change

flowchart LR
  noCRM[No_CRM_sale] --> baseline[Current_app_behaviour_only]
  hasCRM[Has_CRM_program] --> flags2{Flags}
  flags2 --> expanded[Shell_plus_Leads_and_or_Commerce]

Users without CRM remain on the baseline experience—no imposed CRM complexity.
Catalogue-heavy workflows migrate toward Commerce as the primary home for advanced selling (training and support messaging).
Authoritative logic and data for leads, quotes, invoices = backend; mobile is the primary UX surface for the program—not the source of truth.

7. Program decisions to lock

flowchart TD
  dec[Cross_functional_commitments]
  d1[API_surface_for_flags_login_refresh_me]
  d2[billing_tab_scope_all_Commerce_vs_invoicing_only]
  d3[MVP_cutline_vs_Phase2_tax_and_workflow_depth]
  d4[Copy_and_localisation]

  dec --> d1
  dec --> d2
  dec --> d3
  dec --> d4

MVP direction (examples): entitlement flags + shell integration + Account pairing; Leads CRUD with labels/status + catalogue attach; Commerce foundations (categories/products) to support quoting.
Phase2: heavy tax automation, approvals, richer proposals, credits/returns.

8. Success signals (examples)

Lead time-to-save ↓ • quotes per active merchant-week ↑ • quote→paid invoice ↑ • “where is tax/catalogue?” tickets ↓ • draft abandonment ↓ (after instrumentation).

9. Engineering touchpoints (current codebase)

Shell / bottom affordances → app/src/components/ui/CommonBottomNavigation.tsx
Main container switching views → app/src/screens/HomeScreen.tsx
Account → app/src/screens/AccountScreen.tsx
Session/user typing → app/src/services/authApi.ts
Payments context (no secrets in docs) → app/app.config.ts

Owner: Product / Program • Audience: Clients, partners, enablement.

HarshSonawane/doc.md

Select an option

No results found