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 |
| Bids Received | status: proposal_submitted | Experts submit proposals with price, timeline, and milestones |
| Bid Accepted | status: proposal_accepted | The customer selects a proposal and a 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 |
Status workflow
All entities — leads, proposals, 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 — 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):
| 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 |
| Unmatched | No expert submits a proposal before the bid deadline |
| No Fit | Customer rejects all submitted proposals |
| Closed Lost | Project fails or is terminated during active delivery |
These drop-offs are tracked separately in the funnel losses section of the vendor dashboard, giving vendors and CSMs clear visibility into where engagement breaks down.