Inside-sales flow
Audience: Managers, reps, and anyone who needs the current inside-sales model in one place.
Purpose: Show how work moves from inbound → identity → lead qualification → deal → deployment, and which fields must be filled before each move.
Campaign is where the lead came from. Product lives on the deal. Must-have lists below match live Deal Types seed defaults (as of 28 Aug 2026). Admins change ladders on Workspace → Deal Types; the server enforces whatever is configured.
How work moves now
Section titled “How work moves now”flowchart LR
subgraph inbound [Inbound]
Meta[Meta Lead Ads]
Web[Website form]
Field[Field / CDSL]
end
subgraph campaigns [Campaign]
Dead[Dead Stock]
Fin[Inventory Financing]
Enq[Website Enquiries]
Lahore[Lahore Field Visits]
end
subgraph identity [Identity]
Company[Company + Contact]
end
subgraph leadPhase [Lead · Qualification]
New[New]
Attempting[Attempting]
ContactInfo[Contact Info]
MQL[MQL]
SQL[SQL]
DQ[Disqualified]
end
subgraph dealPhase [Deal · POS + optional addons]
Convert[Convert to deal]
NewDeal[New]
PreDemo[Pre Demo]
PostDemo[Post Demo]
DeployReady[Deployment Ready]
DealLost[Lost]
end
subgraph deployPhase [Deployment]
TrialSetup[Trial setup]
CheckIn[Trial check-in]
Negotiation[Negotiation]
Won[Won]
Health[Health-check]
DeployLost[Lost]
end
Meta --> Dead
Meta --> Fin
Meta --> Enq
Web --> Dead
Web --> Fin
Web --> Enq
Field --> Lahore
Dead --> New
Fin --> New
Enq --> New
Lahore --> New
Dead --> Company
Fin --> Company
Enq --> Company
Lahore --> Company
New -->|"first recorded interaction"| Attempting
Attempting --> ContactInfo
ContactInfo --> MQL
MQL --> SQL
New -.->|"jump + prior must-haves"| MQL
New -.->|"jump + prior must-haves"| SQL
Attempting -.->|"jump"| MQL
Attempting -.->|"jump"| SQL
ContactInfo -.->|"jump"| SQL
New --> DQ
Attempting --> DQ
ContactInfo --> DQ
MQL --> DQ
SQL --> DQ
ContactInfo --> Convert
MQL --> Convert
SQL --> Convert
Convert -->|"lead becomes Converted"| NewDeal
NewDeal -->|"must-haves"| PreDemo
PreDemo --> PostDemo
PostDemo --> DeployReady
NewDeal --> DealLost
PreDemo --> DealLost
PostDemo --> DealLost
DeployReady --> DealLost
DeployReady -->|"opens"| TrialSetup
TrialSetup --> CheckIn
CheckIn --> Negotiation
Negotiation --> Won
Won --> Health
TrialSetup --> DeployLost
CheckIn --> DeployLost
Negotiation --> DeployLost
End-to-end path: inbound → campaign → Company + Lead → Qualification → Convert to deal (POS + addons) → Deployment Ready → Deployment (Trial → Negotiation → Won → Health-check). Dotted lines are skip-ahead jumps (prior must-haves still required).
1. Inbound
Section titled “1. Inbound”Meta sheets (ad name) or the website form (ad id in utm_content) land in Dead Stock, Inventory Financing, or Website Enquiries. Field and CDSL lists stay on Lahore Field Visits 2026. Field-sales screens (Journey plan, Area lists) stay parked unless NEXT_PUBLIC_FIELD_SALES_ENABLED is on.
2. Identity
Section titled “2. Identity”Every inbound lead gets a Company + Contact, matched on licence number, otherwise phone. That pharmacy identity is durable across campaigns. Campaign is only where they came from; it is not the product.
3. Lead (Qualification)
Section titled “3. Lead (Qualification)”The lead is the rep’s work queue inside that campaign. The Qualification column on the leads table is the pipeline label (campaign visit stages are separate history).
| Qualification | How it is set |
|---|---|
| New | Default on create |
| Attempting | Auto on the first recorded interaction |
| Contact Info | Rep sets on the lead (must-have gate) |
| MQL Qualified | Rep sets on the lead, or records via Full interaction (must-have gate) |
| SQL Qualified | Rep sets on the lead, or records via Full interaction (must-have gate) |
| Disqualified | Rep sets with a lost reason + details. Unreachable after repeated attempts requires 4 CALL interactions on 4 different days. |
| Converted | System-set when Convert to deal succeeds |
Skip-ahead is allowed. From New / Attempting a rep can jump straight to MQL or SQL. The gate still asks for every earlier must-have that is empty (Contact Info when entering MQL; Contact Info + MQL when entering SQL).
Two separate actions on the lead:
| Action | What it does |
|---|---|
| Add interaction | Logs Call / WhatsApp / Meeting / Other. Outcomes: No answer, Quick note, or Full interaction (can set MQL or SQL and collect those must-haves). Never creates a deal. |
| Convert to deal | Creates the commercial deal(s). Available once Qualification is Contact Info, MQL, or SQL. |
4. Deal
Section titled “4. Deal”Convert to deal always creates a POS App deal at New (deal converted). Optional addon products (dead-stock liquidation, inventory financing, stock audit) create separate deals on the same lead in one save.
The convert form collects:
- Lead answers through SQL (cumulative Contact Info + MQL + SQL must-haves still empty)
- First-stage must-haves for each selected addon (POS New has none)
- Close date horizon — 7 / 14 / 21 / 30 days (default 30); saved as the deal’s expected close date
- Ailaaj ONE package on the POS monthly line (Starter / Professional / Enterprise / Clinic) with up to 20% discount — package, rate, frequency, and discount (no quantity)
Pre Demo must-haves (attendees, pain points from the POS module list, demo mode, scheduled demo date & time in Pakistan Standard Time) are collected when advancing New → Pre Demo. The deals table shows the demo schedule; use Add to calendar to open a Google Calendar invite with deal/POC details prefilled.
POS commercial ladder: New → Pre Demo → Post Demo → Deployment Ready / Lost. Won is recorded on Deployment, not as a POS deal stage.
5. Deployment
Section titled “5. Deployment”When the POS deal reaches Deployment Ready, delivery gets a deployment at Trial setup. The ladder continues: Trial check-in → Negotiation → Won → Health-check / Lost. Trial auto-pop metrics are collected automatically; they are not a stage.
What lives where
Section titled “What lives where”| Record | Answers | Notes |
|---|---|---|
| Company + Contact | Who is this pharmacy? | Licence, else phone |
| Campaign | Where did they come from? | Dead Stock, Inventory Financing, Website Enquiries, or Lahore Field Visits |
| Lead | Is this worth pursuing in this campaign? | Qualification axis; interactions; convert eligibility |
| Deal | How far is this product sale? | POS baseline + optional addon deals — own stages and must-haves |
| Deployment | Has POS gone live? | Created when POS reaches Deployment Ready; delivery owns the ladder |
How inbound is routed
Section titled “How inbound is routed”Each row is one routing rule. The Google Sheets Apps Script does not pick the campaign — it posts adName / adId, and the CRM routes on ingest.
| Source | Signal | Campaign |
|---|---|---|
| Meta Lead Ads | Ad name starts with Dead Stock | Dead Stock |
| Meta Lead Ads | Ad name starts with Finance / Financing | Inventory Financing |
| Website form | utm_content / ad id listed in DEAD_STOCK_AD_IDS | Dead Stock |
| Website form | utm_content / ad id listed in FINANCING_AD_IDS | Inventory Financing |
| Either | Unknown or missing attribution | Website Enquiries |
| Field / CDSL | Outside-sales list | Lahore Field Visits 2026 |
Lead qualification must-haves
Section titled “Lead qualification must-haves”Configured on Workspace → Deal Types → Lead qualification (POS App baseline tab). Gates are cumulative.
| Target | Typical must-haves (seed defaults) |
|---|---|
| Contact Info | POC name · POC contact number · POC role |
| MQL Qualified | Internet access · PC availability · Willing to use software · Current software |
| SQL Qualified | Decision maker confirmed · Pain points (2–3 modules from the POS module list) · Target timeline · Budget discussed |
Contact Info also always includes the campaign’s POC name and phone fields when those exist on the campaign type.
Day-to-day lead workflow
Section titled “Day-to-day lead workflow”- Work the lead list by Qualification.
- Log touches with Add interaction (drafts autosave; activity type is Call / WhatsApp / Meeting / Other).
- Advance Qualification from the leads table or lead details — unmet must-haves open in a gate drawer.
- When ready commercially, use Convert to deal (not the interaction wizard).
See the How work moves now diagram above for the full Qualification → Convert → Deployment path.
POS App deal ladder
Section titled “POS App deal ladder”Demo-led subscription. Convert creates POS at New; advance to Pre Demo with demo must-haves before the demo.
| From | Enter | Must-have information added at this stage |
|---|---|---|
| (new deal) | New | — (deal converted; no POS field gate yet) |
| New | Pre Demo | Attendees by name and role · Pain points (2–3 modules) · Demo mode · Scheduled demo date & time (PKT) |
| Pre Demo | Post Demo | Features demoed · Features asked · Objections · Asked price unprompted · Competitors named |
| Post Demo | Deployment Ready | Interested modules (2–3) · Why onboard now · Migration data status · Trial invoice + next step |
| Any open stage | Lost | Lost reason |
Deployment Ready opens a deployment at Trial setup. Won is recorded on the deployment.
Addon products
Section titled “Addon products”Each addon is a separate deal with its own fields and must-haves. Answers live on that deal’s data, not on the POS deal.
- Dead-stock liquidation — Stock qualified → Offer placed (after POS trial day-7 check-in) → Offer accepted → Agreement signed → Stock lifted & settled → Won. Requires Sales data migration when selected.
- Inventory financing — starts Active with facility / financials must-haves; requires GRNs / purchase data migration when selected.
- Stock audit — scaffold product with its own must-haves on Deal Types.
Deployment path
Section titled “Deployment path”Delivery moves: Trial setup → Trial check-in → Negotiation → Won → Health-check / Lost.
Negotiation is POS App only (addon products keep their own deal stages). Commercial terms are prefilled from convert-to-deal with the same Ailaaj ONE package dropdown, subscription frequency, monthly charges, and discount %. Delivery can update them in Negotiation if the client renegotiated. Also required: first invoice duration (1 / 3 / 6 / 12 months), invoicing date, and go-live date (stamped on the deployment so the same trial tenant can be reset for live).
Trial check-in due dates default to day 3 / 7 / 14 after trial start (configurable on Deal Types). Reps and delivery see overdue check-ins in the deployments queue.
Delivery users (DELIVERY role) drive this ladder. They cannot move deal stages. Sales can see deployments in their own scope but cannot drive them. When deployment reaches Won, the linked POS deal is closed as won.
Campaign visit stages are a different ladder
Section titled “Campaign visit stages are a different ladder”Campaigns can still define visit outcome stages (New, Intro, Demo, and so on) for interaction history. Those are not the lead’s commercial pipeline — that is Qualification. Closing a sale is deployment Won (or an addon deal Won), not a lead campaign stage.
Where to change must-haves
Section titled “Where to change must-haves”Workspace → Deal Types.
| Tab | Controls |
|---|---|
| Lead qualification (POS baseline) | Contact Info / MQL / SQL fields and must-haves |
| POS App | New / Pre Demo / Post Demo / Deployment Ready must-haves |
| Addon tabs | Each product’s ladder and first-stage convert gates |
| Deployment (pipeline config) | Trial check-in fields and due-day offsets |
Gate drawers and Convert to deal list unmet items before save; the server enforces the same lists. New must-have questions need a key + label, and must be checked for the stage — otherwise they will not appear on convert or qualification gates.