Service Journey
The Sustentus service journey describes the complete lifecycle of a client engagement — from the moment a lead is submitted through to project delivery and payment. Every stage is tracked through a deterministic status workflow that records every transition, maintains a full audit history, and handles both forward progress and exception paths.
End-to-End Flow
Journey Sections
Stages at a Glance
| Stage | Key Signal | Description |
|---|---|---|
| Lead In | status: pending / backlog | A service request arrives via webhook, embeddable form, or manual entry |
| Activated | Customer account exists | The customer account is validated; new customers receive an invitation |
| Engaged | isBrdApproved = true | The customer completes a BRD session with an AI requirements agent |
| Bid Pool | bidPool = true | The qualified lead is opened to matched experts |
| Quotes Received | status: proposal_submitted | Experts submit quotes with price, timeline, and milestones |
| Quote Accepted | status: proposal_accepted | An expert quote is accepted and a customer quote is generated |
| Work in Progress | isActiveProject = true | The expert delivers against agreed milestones, each invoiced separately |
| Delivered | All invoices paid | All milestones are complete and a CSAT survey is issued |
isActiveProject says whether the account is in delivery now: it is set when the customer accepts the quote and cleared when the lead reaches delivered, survey_sent, completed or qualified_out. Figures that count the active portfolio (the CSM portfolio, the vendor’s active projects) therefore count only work in delivery; the expert’s open work and SDM SLA adherence read the lead’s status instead, so the billing and CSAT stages after delivery stay in them.
Status workflow
All entities — leads, expert quotes, customer quotes, invoices, and milestones — progress through a single deterministic status workflow. It is defined in version-controlled JSON (packages/services/src/db/workflows/workflows.json), the single source of truth — there is no runtime status graph or configurable engine. Statuses and transitions are changed in-repo via a pull request, not edited at runtime; the /admin/status screen is a read-only viewer of this file.
The workflow is a nested tree. lead is the parent journey, and the sub-workflows run inside the lead stage they belong to:
- proposal (the expert quote) — inside the bid process started stage
- quote — inside the quote review stage
- milestone and invoice — inside the work in progress stage
A separate top-level verification workflow tracks expert evidence on the expert profile; it is intentionally not part of the lead journey.
Each status defines its allowed transitions, and each can carry optional per-persona display-name overrides so the same status reads differently for, say, a customer versus a CSM. The lead journey uses these overrides, so the shared workspace journey strip reads in each persona’s own wording — at the first stage a customer sees “Project submitted”, an SDM “New project”, and an expert “Project available”, while any status without an override falls back to its default name:
| Transition Type | Direction | Example |
|---|---|---|
positive | Forward progress | invoice_submitted → invoice_approved |
negative | Rejection or failure | invoice_submitted → invoice_rejected |
loop | Return to an earlier state | blocked → in-progress |
Every status change is written to StatusHistory (recording the status name) and the broader Activity log, providing full auditability across the entire journey.
Unhappy Paths
Not every lead reaches delivery. The platform tracks structured exit points at each stage:
| Drop-off | Trigger |
|---|---|
| Disqualified | Lead is bogus or out of scope — closed immediately on intake |
| Abandoned | Customer never registers or logs in after invitation |
| Gone cold | Customer stops engaging during the BRD session — sent a follow-up, then escalated to the CSM |
| Unmatched | No expert submits a quote before the bid pool deadline |
| No fit | Customer rejects all submitted quotes |
| Closed lost | Project fails or is terminated during active delivery |
A lead closes on one negative status, qualified_out, and the reason is recorded beside it: whoever qualifies the lead out picks one of the six above, and can add a free-text note alongside it. Unmatched and No fit are also picked automatically by the daily bid pool deadline sweep — see Expert quotes. Gone cold is the one drop-off the platform detects but never records on its own: a daily sweep nudges the silent customer and then alerts their CSM, and the CSM makes the call — see Requirements. The reason is shown on the lead’s Customer Service Journey and in its activity timeline.
These drop-offs are tracked separately in the funnel losses section of the Live Service Command Centre, giving vendors and CSMs clear visibility into where engagement breaks down. Leads closed before the reasons were recorded are shown as Unclassified — no reason is inferred from their note.