Sales pipeline deal progression sequence
Prospect discovery through close, with stakeholder touchpoints.
Every sales team has a pipeline, and every sales team loses deals because the prospect, the AE, the manager, and the engineer never agree on what "close" actually means. This sequence diagram maps the entire deal lifecycle: inbound inquiry, discovery, technical review, proposal, negotiation, close, and the handoff to customer success. The alt block shows both happy paths (deal won, handoff to onboarding) and sad paths (proposal rejected, deal stalled).
The key insight is that a successful close requires more than an AE and a prospect: pre-sales engineering handles technical validation, the manager forecasts pipeline health, and customer success needs context before onboarding. Drawing all these participants makes it clear when to loop them in — too early and you waste their time, too late and you lose deals that fell through because nobody answered a technical objection.
When to use this template
- Sales process documentation — new AEs need to know the exact progression from lead to close. This diagram is the runbook: here's where discovery happens, here's when you escalate to engineering, here's when the manager needs to be in the room.
- Deal reviews and forecasting — when you're forecasting quarterly revenue, shade deals by their position in the sequence. Deals stuck at "proposal feedback" are different from deals stuck at "negotiations" — different interventions apply.
- Onboarding handoff — customer success uses this diagram to understand where each deal came from, what was promised, and what the customer's timeline expectations are. The handoff message becomes a template for documentation.
How to adapt it
Extend the sequence to your exact sales cycle:
- Add a proof-of-concept phase — after proposal approval, before contract, show a PoC loop where engineering builds and the prospect validates.
- Insert approval gates — if security or legal review is required, add them as participants with explicit review and sign-off messages.
- Add competitor or budget objections — after proposal feedback, show common objections and AE responses; make it clear whether the AE can handle them alone or needs escalation.
Visual edits regenerate clean Mermaid code, so you can map your real deal flow and drop it into your CRM as a stage definition or into sales training.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
participant P as Prospect
participant AE as Account Exec
participant SM as Sales Manager
participant ENG as Pre-sales Eng
participant CS as Customer Success
P->>AE: Inbound inquiry
AE->>AE: Qualify lead
AE->>P: Discovery call scheduled
AE->>P: Discovery call
P->>AE: Needs documented
AE->>SM: Deal created in pipeline
AE->>ENG: Technical requirements review
ENG->>P: Technical deep-dive
P->>ENG: Questions answered
AE->>P: Proposal sent
P->>AE: Proposal feedback
alt Proposal approved
AE->>SM: Deal in negotiation
AE->>P: Contract review
P->>AE: Contract signed
AE->>SM: Deal won
SM->>CS: Onboarding handoff
else Proposal rejected
AE->>P: Objection handling
P->>AE: Decision deferred
AE->>SM: Deal stalled
end
Frequently asked questions
- What is a sales pipeline sequence diagram?
- It shows the exact conversation between a prospect, the account executive, the sales manager, technical team, and customer success during a deal: the discovery, proposal, objections, and either a win that handoffs to onboarding or a loss that goes stale. The alt block lets you show both happy and sad paths on one screen, so everyone agrees on what 'winning' actually entails.
- Why include the sales manager and pre-sales engineering in the sequence?
- Because they are stakeholders in the deal progression, and omitting them leaves gaps. The AE can't see when the manager needs to re-forecast or escalate. Engineering doesn't know whether a technical question will be a deal-breaker or a tiebreaker. This diagram forces those conversations to happen before a deal stalls.
- When should a deal move from discovery to proposal?
- When the prospect has said what they need and the AE has confirmed it can be solved. Sending a proposal too early wastes the prospect's time; sending it too late wastes yours. This diagram shows the checkpoint: the discovery call, needs documented, possibly a technical review, then the proposal. If you're proposing before that, you're moving too fast.
- How do I adapt this for our sales cycle?
- If your cycle includes a proof-of-concept or trial, add a Prospect PoC box showing a test deployment and feedback loop. If you have multiple approval steps (legal, finance, security), add them as participants. If trials run in parallel with negotiation, use note blocks to show the timeline. Visual edits regenerate clean Mermaid code, so you can sketch your exact deal flow without writing sequence syntax.