By Siddharth Gangal A sales workflow template should tell a rep what to do, what evidence allows a deal to advance, who owns the next move, and what happens when the happy path breaks. A list of pipeline labels does not do that. The template below does.
Direct answer. Copy the nine-field grid in this guide, then define each stage by an observable buyer outcome: trigger, entry evidence, rep action, buyer action, exit evidence, owner, CRM proof, next step, and exception path. Start with the completed B2B example, test it against three real deals, and only then configure it in your CRM.
This page is the artifact. If you first need to discover how work currently moves across your team, use the sales workflow mapping guide. If you need a policy manual, use the sales process documentation guide. Come back here when you are ready to define the operating rules reps will actually follow.
What is a sales workflow template?
A sales workflow template is a reusable specification for moving an account or opportunity from one meaningful state to the next. It defines both the seller's work and the evidence that the buyer has progressed. It is broader than a pipeline template, because it includes actions, handoffs, exceptions, and data requirements—not just stage names.
Salesforce Trailhead describes the sales process as steps that move a rep from research through close and beyond, while noting that the steps should change with the business, product, and prospect. That is why this is a starting framework rather than a supposedly universal “top team” formula. Your buyers decide which gates belong.
| Artifact | Primary question | What it contains |
|---|---|---|
| Sales pipeline | Where is each deal? | Stages, value, close date, probability |
| Sales process | What should happen? | Principles, stages, methods, policies |
| Sales workflow | What happens next? | Triggers, actions, evidence, owners, handoffs, exceptions |
| Sales playbook | How should a rep execute? | Talk tracks, discovery prompts, examples, enablement assets |
Copy the complete sales workflow template
The most useful version of the template has nine fields. Copy the header row into a spreadsheet, database, or whiteboard. Add one row per meaningful stage. Do not configure CRM automation until every cell has an answer.
| Field | Prompt to complete | Quality test |
|---|---|---|
| Trigger | What event starts this stage? | A person or system can detect it |
| Entry evidence | What must already be true? | Two managers would classify the same deal alike |
| Rep action | What should the owner do? | Starts with a verb and produces an output |
| Buyer action | What progress do we need from the buyer? | Describes buyer behavior, not seller effort |
| Exit evidence | What earns the next stage? | Observable and auditable |
| Owner | Who is accountable now? | One role, even when several people contribute |
| CRM proof | Where is the evidence recorded? | A named field, note, contact, or activity |
| Default next step | What immediately follows a successful exit? | Has an owner and a due condition |
| Exception path | What happens if the exit never occurs? | Move back, recycle, disqualify, or escalate |
Copy/paste row. Stage: [name] | Trigger: [event] | Entry evidence: [fact] | Rep action: [verb + output] | Buyer action: [observable commitment] | Exit evidence: [proof] | Owner: [role] | CRM proof: [field or record] | Next step: [action + due condition] | Exception: [route].
The extra fields matter. An owner without a trigger waits. An action without exit evidence becomes activity theater. A happy path without an exception turns stalled deals into permanent pipeline residents.
Worked example: a B2B SaaS workflow
This completed example fits a considered B2B SaaS sale. It uses six active stages plus won and lost terminal states. Treat every row as a hypothesis to test against your own deals.
| Stage | Entry evidence | Rep action | Exit evidence | Owner | CRM proof |
|---|---|---|---|---|---|
| 1. Target | Account matches documented ICP | Confirm contact and relevant trigger | A reachable buyer and reason to contact are recorded | SDR or founder | ICP fit, contact, trigger source |
| 2. Engaged | Buyer replied or accepted a live conversation | Establish why the conversation matters now | Buyer agrees to a qualification or discovery conversation | SDR | Reply, meeting, source |
| 3. Qualified | Initial conversation occurred | Test fit, problem, urgency, and access | Buyer confirms a material problem and agrees to explore change | AE | Problem, impact, timing, next meeting |
| 4. Evaluating | Problem and change intent are confirmed | Run discovery and a relevant solution review | Buyer confirms requirements, stakeholders, and evaluation path | AE | Requirements, stakeholders, decision steps |
| 5. Commercial | Solution fit and decision path are known | Build business case and agree scope | Economic buyer accepts the commercial basis for formal review | AE | Scope, value case, approver, target date |
| 6. Commit | Commercial basis is accepted | Resolve legal, security, procurement, and final terms | Signature path, remaining blockers, and mutual dates are explicit | AE | Mutual plan, blocker, signer, next action |
| Closed won | Agreement is executed | Complete handoff with promised context | Customer owner accepts the handoff | AE to CS | Contract, handoff note, kickoff |
| Closed lost | Buyer declines, chooses another path, or no longer qualifies | Record the known reason and appropriate follow-up | Loss reason and disposition are complete | Current owner | Loss reason, competitor or no-decision, recycle date |
The labels are deliberately plain. A stage name should help a new rep classify a deal, not advertise a methodology. For a deeper treatment of stage boundaries, see sales workflow stages.
Default next steps for the worked example
- Target exits: send the first relevant message using the recorded reason for contact.
- Engaged exits: schedule discovery and assign the opportunity owner.
- Qualified exits: send a recap and schedule the solution review with the right stakeholders.
- Evaluating exits: confirm the evaluation plan and prepare the commercial case.
- Commercial exits: open the mutual action plan and route required reviews.
- Commit exits: obtain signature or record the exact blocking event and owner.
Write stage gates that reflect buyer progress
A stage gate should say what changed for the buyer. “Demo completed” proves the rep held a meeting. “Buyer confirmed the solution addresses the documented requirement and named the remaining evaluation steps” proves movement in the decision.
| Weak gate | Stronger gate | Why it is stronger |
|---|---|---|
| Email sent | Buyer replied and agreed to a conversation | Requires engagement |
| Discovery completed | Buyer confirmed the problem, impact, and next evaluation step | Records learning and intent |
| Demo delivered | Buyer mapped the demonstrated capability to an agreed requirement | Tests relevance rather than attendance |
| Proposal sent | Economic buyer agreed the scope is worth formal review | Tests commercial participation |
| Verbal commit | Signature path, blockers, owners, and dates are documented | Turns optimism into a checkable plan |
This buyer-evidence rule is Gangly's recommended design principle, not a proven universal law. Compliance steps, internal approvals, and some product-led motions need seller- or system-controlled gates. Use the strongest observable evidence available and state who controls it.
Add exception paths before the happy path breaks
The first live deal will ignore your diagram. Design the common detours now so the rep does not invent policy under pressure.
| Exception | Decision rule | Route | Record |
|---|---|---|---|
| Not now | Fit remains, but the buyer names a future timing condition | Recycle with a dated trigger | Reason, trigger, review date |
| No qualification | Required fit or problem evidence is absent | Disqualify; do not leave in an active stage | Disqualification reason |
| Stage regression | Previously recorded evidence is withdrawn or disproved | Move to the earliest stage whose gate still holds | Changed assumption and new next step |
| Fast track | Buyer arrives with later-stage evidence already established | Skip only gates whose proof is recorded | Evidence for every skipped gate |
| No decision | Buyer stops the change project without selecting an alternative | Close lost or recycle according to a named future trigger | No-decision cause and follow-up condition |
Do not use time alone as proof of progress. A deal that has sat in evaluation for three weeks has not earned commercial status. Time can trigger review, regression, or closure; it cannot satisfy a buyer gate.
Adapt the template in 45 minutes
Use this workshop to turn the example into your workflow. One sales manager or founder owns the final call. Invite one rep and, if available, one RevOps partner. Bring three recent deals: a clean win, a slow or messy win, and a loss or no-decision.
- Minutes 0–5: set scope. Name the segment, motion, starting event, and terminal outcome. Do not combine inbound, outbound, partner, renewal, and enterprise motions by default.
- Minutes 5–15: narrate the three deals. Write down the moments when the buyer changed state. Ignore your current CRM labels.
- Minutes 15–25: draft stages. Group those moments into the smallest set that changes owner, action, evidence, or forecast meaning.
- Minutes 25–35: write gates. Complete entry and exit evidence for every active stage. Replace seller activities with buyer evidence where appropriate.
- Minutes 35–40: assign operation. Add owner, CRM proof, and default next step.
- Minutes 40–45: break it. Run the fast win and the loss through the draft. Add the exceptions they expose.
The real-deal stress test
For each of the three deals, hide its current CRM stage and classify it using only the new entry evidence. If two participants choose different stages, rewrite the gate. If a field was never known or used, remove it. If a stage does not change action, ownership, evidence, or forecast meaning, merge it with a neighbor.
That stress test is the difference between importing a generic template and producing one grounded in your actual sale. It also creates an auditable reason for every stage you keep.
Install the workflow in your CRM
Configure the CRM only after the stress test passes. The CRM should enforce the workflow lightly enough that reps can act, but firmly enough that a stage retains meaning.
- Create the stage values. Keep terminal outcomes separate from active work.
- Add the minimum proof fields. Each required field should establish a gate or change a decision. Remove decorative fields.
- Show fields when they become relevant. A procurement blocker field is useful near commercial review, not during targeting.
- Attach the next action. A stage change without a next step creates a labeled stall.
- Configure exception outcomes. Include disqualified, recycled, no-decision, and closed lost reasons.
- Test permissions and reporting. Confirm reps can correct a stage and managers can see missing evidence without editing every record.
Good data also needs maintenance. The CRM hygiene guide covers field ownership, deduplication, and stale records. This article deliberately does not prescribe a universal staleness period or stage probability; derive those from your own observed cycle and conversion history.
Run the workflow after launch
A template becomes an operating system only when someone owns its interpretation. Assign one process owner and make three reviews explicit.
- Deal review: inspect exceptions and evidence gaps while the deal is active. Do not turn the meeting into a recital of every opportunity.
- Workflow review: inspect repeated misclassification, missing fields, and off-template paths. Change the template when reality has changed; coach when the agreed rule is being ignored.
- Outcome review: compare stage entries, exits, regressions, losses, and cycle time by segment. Treat the data as diagnostic, not causal proof that the template created the result.
Track adherence before outcome claims. Useful checks include the share of active deals with exit evidence, the share with a named next step, exception volume by stage, and stage regression count. These describe whether the workflow is being used. They do not prove it increased revenue.
After the first operating cycle, run a sales workflow audit. Keep a change log in the source document: what changed, why, who approved it, and when it should be revisited.
When this template is the wrong fit
This worked example is a poor fit when the buying motion does not resemble a considered B2B opportunity. Adapt the structure—not the stage labels—in these cases:
- Transactional sales: collapse discovery, evaluation, and commercial steps if the buyer completes them in one interaction.
- Product-led sales: use product events and account expansion evidence as triggers while keeping human qualification only where it changes action.
- Enterprise procurement: split security, legal, procurement, and executive approval only when each has a distinct owner or gate.
- Channel sales: distinguish partner progress from end-buyer progress and name who owns each handoff.
- Renewals and expansion: begin with adoption, risk, or growth evidence rather than treating the account as a new prospect.
The durable part of the framework is the nine-field specification. The correct number and names of stages depend on the motion. Copy the grid, test it on real deals, and let buyer evidence—not the example—decide what survives.