AssureShift.in · Lead Back-end · Phase 4c / 4d

Mover (Vendor) Portal — design blueprint

Where vetted movers log in, see the leads matched to them with customer details hidden, buy a lead (atomic wallet debit, max 3 buyers), then get the contact info. This is a first look — nothing here is built yet. Question is at the bottom.

Core loop — proposed first slice

ENTRY

Log in

Mover enters phone → 6-digit OTP via SMS. Session = their company.

Phone + OTP
1 · BROWSE

Lead feed

Leads matched to me I haven't bought. Route, move type, size, date, price.

PII hidden
2 · INSPECT

Lead detail

Full requirement, what it costs, how many seats left (of 3) — name/phone still hidden.

PII hidden
3 · BUY

Purchase

One tap → wallet debit + seat claimed, atomically. Rejects if sold out / low balance.

unlocks ↓
4 · ACT

Customer revealed

Name, phone, email now shown. Lead moves to "My purchased leads".

PII revealed

Supporting — same slice

WALLET

Balance & ledger

Current balance + history of debits/top-ups (read-only view of the Transactions ledger).

ACCOUNT

My company

Read-only: cities served, move/shifting types, KYC status, accepting-leads toggle.

Notifications

The SMS "new lead" alert already exists server-side; portal just deep-links into it.

Deferred to a later slice

laterRefund requestsCollections exist; provider-facing request UI later.
laterComplaintsFile / track. Schema exists; UI later.
laterIn-app chatBigger build; out of this slice.
laterGST invoicesIts own phase after the portal.
Question 1 of a few

How does a mover first get into the portal?

This fork decides how much we build now. Everything downstream (login screen, what's editable, KYC) hangs off it.

MY REC A

Staff-provisioned, login-only

  • Ops vets & KYCs the mover, creates their Company + Provider (already how it works today)
  • Mover just logs in with their phone → OTP
  • Portal is browse / buy / wallet — no self-registration

Why I lean here: matches the "vetted network" model — only approved movers buy leads. Smallest first slice, no KYC-intake/anti-abuse UI needed yet. Self-signup can come later as its own flow.

B

Self-signup

  • Mover registers themselves: phone → OTP → creates a Company (KYC-pending)
  • Can browse leads but can't buy until ops approves KYC
  • Needs intake forms, KYC upload, pending-state UX, abuse guards

Trade-off: bigger build, and lets unvetted accounts in the door. Better suited once the vetted core is proven and you want to scale acquisition.

Served at mockup.csoul.cloud/as-leads-portal/ · noindex · throwaway design exploration, not the app.