Home / admin / sales-process-mapping

sales-process-mapping

Eliciting and documenting a sales process before it is built in Salesforce: stage sequencing, entry/exit criteria per stage, win/loss analysis requirements, and stage transition rules.

v1.1.1
Salesforce Spring '25+
Updated 2026-09-18
Operational Excellence
User Experience

sales-process
stage-design
entry-exit-criteria
win-loss-analysis
stage-gate
sales-methodology
opportunity-stages
discovery
admin

Open the skill folder on GitHub

Sales Process Mapping

This skill activates when a practitioner needs to design or document a sales process as a structured artefact before any Salesforce configuration work begins. It covers discovery interviews, stage sequencing, entry/exit criteria definition, win/loss requirement analysis, and transition rule documentation. The output is a mapping document that the opportunity-management skill then uses as its input specification.

Before Starting

Gather this context before working on anything in this domain:

Confirm how many distinct selling motions the business runs (new logo, renewal, upsell, channel). Each motion that diverges meaningfully at more than two stages needs its own stage sequence — and eventually its own Salesforce Sales Process.
Identify who owns the definition of each stage. In most organisations the VP of Sales or RevOps lead is the decision authority; without their involvement, agreed-on definitions will not be adopted by the sales team.
Establish whether a named sales methodology (MEDDIC, MEDDPICC, SPIN, Challenger, Value Selling) is in use or intended. Methodology constrains stage names and entry criteria. If the business has no methodology, the mapping exercise will need to establish one — that is a larger consulting engagement than a configuration task.
Determine whether win/loss analysis is currently tracked anywhere (CRM, spreadsheet, survey tool). If it is, obtain the existing reason taxonomy before proposing a new one. Replacing an established taxonomy breaks trend reporting.
Ask whether the sales stages are tied to a quoting or CPQ process. If a quote must be sent before a stage can advance, a CPQ dependency exists and must be noted in the transition rules.

Questions to Ask Before Configuring

Ask these before anyone opens Setup. Each one exists because a specific platform behaviour punishes the default answer; the right-hand column is what the answer changes in templates/sales-process-mapping-template.md.

Ask	Why it matters	What a good answer adds
"Walk me through the last deal you lost at proposal — what happened first?"	Stated criteria are aspirational; loss narratives expose the gate that actually existed	Rewrites one exit criterion into something observable, and usually one required field
"Who is allowed to move a deal into Negotiation, and who actually does?"	The platform allows backward and skipped moves silently — only a rule stops it	The owner per stage, and either a validation-rule row or a decision not to enforce
"Do renewals run these same stages, or does the CSM run something else?"	Two sequences means two Sales Processes, and `businessProcess` is required on an Opportunity record type (api_meta.txt:45007–45014)	The record type count — the largest cost line in the handoff brief
"When a deal closes, who has to know, and what do they need from the record?"	The Closed Won exit obligations (onboarding Case, Contract, booking) get built by nobody unless they are stage requirements	The Sales → Service and Sales → Finance handoff rows and their fields
"Which team must not see the other team's pipeline?"	Record types and business processes do not govern read access (api_meta.txt:42960–42962, 44974–44980)	Moves the requirement out of the stage map into `standards/decision-trees/sharing-selection.md`
"What does the board pack call each forecast bucket?"	Only the documented `ForecastCategoryName` values exist (object_reference.txt:195492–195504)	The internal-label ↔ platform-value translation table, or a separate forecast session
"How do deals actually get closed — rep in the UI, manager bulk edit, or a load?"	Close-path assumptions decide whether a validation rule is sufficient enforcement	The enforcement mechanism per rule, rather than "validation rule" by reflex

What a proper configuration adds over just doing it: the stage ladder ships with an owner, an observable exit condition and a field requirement per stage, so the forecast means something on day one and the Service and Finance handoffs exist before the first deal closes.

Core Concepts

Stage as a Gate, Not a Label

A stage in a well-designed sales process represents a verified milestone — a point at which the deal has cleared a defined bar — not simply a label that the rep drags the opportunity to when the mood is right. Each stage must have explicit entry criteria (what must be true before the deal enters this stage) and exit criteria (what must be true before the deal can leave). Without both, stage data degrades quickly: reps park deals in whichever stage looks best for the forecast and move on.

In Salesforce terms, entry criteria become the driver for required fields on the record at that stage (enforced via validation rules). Exit criteria become the condition the rep must satisfy before the stage can advance. Documenting both in plain language during discovery is what makes the subsequent validation rule design deterministic rather than guesswork.

Win/Loss Analysis as a First-Class Requirement

Win/loss analysis is the closed-loop mechanism that tells the business whether its sales process is working. It depends on three design decisions made during the mapping exercise:

Category taxonomy: what are the allowable win reasons and loss reasons? A good taxonomy has 5–10 mutually exclusive, collectively exhaustive categories per outcome, not a free-text field.
Capture point: at what stage transition does the rep record the reason? Almost always this is the transition to Closed Won or Closed Lost. Capturing it too early (e.g., at Proposal) means the reason changes; too late means it never gets filled in.
Who owns the data: is win/loss self-reported by the rep, validated by the manager, or collected via an external survey? Self-reported data has selection bias; external surveys have response rate issues. Document the chosen approach explicitly.

In Salesforce, win/loss reasons are typically implemented as a required dependent picklist on Opportunity (primary picklist: Stage outcome; dependent: specific reason) or as a required custom field enforced by a validation rule on close. The mapping document must specify which approach is needed so the configuration can be designed correctly.

Stage Transition Rules

A stage transition rule defines which movements are valid, which require field completion, and which require an additional approval or review. Common transition rules include:

Rule	Behavior
Linear progression only	The opportunity must move through stages in order (no skipping).
Backward movement restricted	Once past a stage, the opportunity cannot return without manager approval.
Required fields per stage	Certain fields must be populated before an opportunity can be saved at or past a given stage.
Stage-triggered notifications	Advancing to a specific stage sends an alert to legal, finance, or deal desk.

Documenting these rules in the mapping artefact is critical because Salesforce does not enforce stage order natively — Path is visual only. Enforcement requires validation rules, and those rules are only as good as the transition requirements that were documented during the mapping exercise.

Mapping to Platform Constraints

During the mapping exercise the practitioner must track which design decisions will hit Salesforce platform limits or constraints. Key constraints to flag:

ForecastCategoryName is a fixed, documented value set: Best Case, Closed, Commit, Most Likely, Omitted, Pipeline (object_reference.txt:195492–195504). They cannot be renamed, and the deployed metadata spells them differently again — see references/gotchas.md Gotcha 6. Every stage must map to one of these; if the business uses different category names in its forecast process, a translation layer must be documented.
Stage picklist values are global: every stage defined in the mapping becomes a global picklist value. Stage names that are too generic (e.g., "Stage 1") will conflict with other business units if the org is shared.
Multiple Sales Processes require multiple Record Types: if the mapping produces two distinct stage sequences, two Sales Processes and two Record Types are required in Salesforce. The mapping document should flag this dependency explicitly.

Common Patterns

Discovery-First Stage Mapping

When to use: The business has informal stages (whiteboard, verbal, legacy CRM) but no documented entry/exit criteria. The practitioner needs to produce a formal stage map before any Salesforce work can begin.

How it works:

Run a structured discovery session (60–90 minutes) with the VP of Sales and 2–3 front-line AEs. Use the Stage Map Template (see templates/). Ask for each stage: "What has to be true before a deal enters this stage?" and "What has to happen before the deal can leave?"
Document every stage with a plain-language definition, entry criteria, exit criteria, and the role responsible for advancing the stage.
For each stage, ask which Salesforce forecast category it should map to. Explain the values plainly: Pipeline (actively working), Best Case (likely to close), Commit (near-certain), Most Likely (available to orgs using the extra tier), Closed (done), Omitted (not forecast). Let the sales leader assign each stage.
Identify all transition rules: which stage jumps are blocked, which require additional fields, which require manager sign-off.
Document open questions (anything stakeholders disagree on) separately. Do not proceed to configuration until these are resolved.
Produce the Stage Map Document as the output. Hand it to the opportunity-management skill as the specification input.

Why not skip to configuration: Configuring stages without agreed-on entry/exit criteria means the rep community will not adopt the process. Re-configuring after go-live is expensive and creates data integrity problems for historical records.

Win/Loss Reason Design

When to use: The business wants to track why deals are won or lost, but has no existing reason taxonomy or has a taxonomy that is too granular to be useful (more than 15 values).

How it works:

Interview the VP of Sales and at least two deal-experienced AEs separately. Ask each to name the top five reasons they think deals are won and lost, without prompting.
Cluster the responses into themes. A healthy taxonomy has 5–8 win reasons and 5–8 loss reasons, each representing a meaningfully distinct cause.
For loss reasons, always include a "No Decision / Status Quo" category — deals where the prospect did not choose any vendor. This is the most commonly omitted category.
Decide the capture point and enforcement mechanism. Recommend: required picklist on Opportunity, enforced by validation rule only when StageName = 'Closed Won' or StageName = 'Closed Lost'.
Decide who validates the data. If managers will review and override rep-entered reasons, document this as a workflow step.
Record the final taxonomy and all design decisions in the mapping document.

Why not use a free-text field: Free-text win/loss fields produce unusable data within 3 months. Analysis is impossible without normalization. A constrained picklist with a defined taxonomy is always the right choice.

Decision Guidance

Situation	Recommended Approach	Reason
Business has one selling motion	Single stage sequence, single Sales Process	No need to separate processes; keep it simple
New logo and renewal have divergent stages past Proposal	Two separate stage sequences, two Sales Processes	Stage names and forecast category mappings differ; a shared process creates confusion
Stage names already exist in legacy CRM	Keep names where possible, add entry/exit criteria	Changing stage names mid-cycle creates adoption friction; criteria can be added without renaming
Business wants to enforce stage order	Document as transition rule; implement as validation rule — not Path	Path does not block saves; validation rules do
Win/loss taxonomy has more than 12 values	Consolidate to 5–8 per outcome	Large taxonomies are not completed consistently; data quality degrades
Business uses MEDDIC methodology	Map MEDDIC components to stage entry criteria	MEDDIC identifies what must be confirmed at each stage — use components as entry criteria directly
Stakeholders disagree on stage definitions	Document the disagreement, escalate to VP of Sales, do not configure until resolved	Configuration built on disputed definitions requires rework; the mapping exercise forces the decision
Stage must trigger a downstream process (e.g., legal review)	Document as a stage-triggered notification or approval requirement	This becomes a Flow or Approval Process requirement passed to the implementation phase

Recommended Workflow

Count the motions, then open the template. Copy templates/sales-process-mapping-template.md and fill the Selling Motions table first. Every motion that diverges at more than two stages becomes its own stage sequence — and, because businessProcess is required on an Opportunity record type, its own record type. Get that number agreed before booking discovery time.
Run the discovery sessions off the question table. Use ## Questions to Ask Before Configuring above and §6 of references/worked-examples.md as the agenda. Interview sales leadership and front-line AEs separately; where their answers diverge, that gap is the finding, not noise.
Write the ladder as a machine-readable map, not prose. Fill the stage map in the shape of §2 of references/worked-examples.md — one entry, one exit, a ForecastCategoryName value, a probability, an owner persona and at least one required field per stage, terminal stages included.
Lint it before anyone reads it. python3 scripts/check_sales_process_mapping.py --map <your-map>.yaml (or --manifest-dir <design-dir> to lint every map plus a retrieved stage value set). Fix every ERROR: a missing exit criterion, a non-monotonic probability, two stages exiting on the same condition and a stage with no required field are all design defects, not formatting complaints.
Turn transition rules into enforcement intent. For every restriction, write the row shape in §3 of references/worked-examples.md: where it fires, the condition in words, the rep-facing message. Decide once — in the mapping — how "at or past stage X" will be represented, because StageName is a picklist and gives you no ordering for free.
Design the win/loss taxonomy and its capture path. 5–8 values per outcome, always including "No Decision / Status Quo", plus the answer to how deals actually get closed. Run the narrative document through python3 scripts/check_sales_process_mapping.py --doc <document>.md to catch an oversized taxonomy, a catch-all "Other", a free-text fallback or Path-enforcement language.
Read references/gotchas.md, then produce the handoff brief. Close the open-questions log, and hand admin/opportunity-management the exact picklist strings, the process and record type count, the per-record-type stage availability matrix, and the validation rules the ladder implies.

Review Checklist

Run through these before marking work in this area complete:

[ ] The stage map exists as a machine-readable artefact and python3 scripts/check_sales_process_mapping.py --map <map> reports no ERROR
[ ] Every stage has a plain-language definition, entry criteria, and exit criteria documented
[ ] Every stage is assigned to exactly one documented ForecastCategoryName value, spelled as the label and not as the metadata token
[ ] Win/loss reason taxonomy is finalised (5–8 values per outcome), capture point is defined, enforcement method is documented
[ ] Stage transition rules are documented: which transitions are blocked, which require fields, which require approvals
[ ] Open questions log has no unresolved items (or all unresolved items have a named owner and target date)
[ ] Number of distinct sales processes required is confirmed and matches the number of distinct stage sequences
[ ] Stage names in the handoff brief are the exact strings that should appear as Salesforce picklist values
[ ] If a named methodology (MEDDIC, SPIN, Challenger) is in use, its components are explicitly mapped to stage entry criteria in the document
[ ] The handoff brief carries a per-record-type stage availability matrix, not just a flat stage list — see references/gotchas.md Gotcha 7
[ ] Any visibility requirement voiced in the workshop has been moved out of the stage map and routed to standards/decision-trees/sharing-selection.md

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

ForecastCategoryName values cannot be renamed — The documented value set (Best Case, Closed, Commit, Most Likely, Omitted, Pipeline) is fixed. If the business uses different labels in their forecasting process (e.g., "Called" instead of "Commit"), those translations must be documented during mapping. Many mapping exercises skip this and produce stage-to-forecast assignments that confuse reps when they see different labels in the UI than in the mapping document.
Stage picklist values are global across all Opportunity record types — Every stage name defined in the mapping becomes a global picklist entry visible across the entire org. Generic names like "Stage 3" or "Prospecting" create ambiguity when multiple business units share the org. The mapping exercise must produce stage names that are unambiguous across all business units, not just the one being mapped.
Path adds no enforcement — the mapping document must flag enforcement requirements explicitly — A common handoff failure is delivering a stage map that lists "required fields" per stage without flagging that Path alone will not enforce them. If the document does not explicitly state that a validation rule is needed, the configuration team may use Path guidance only and leave the enforcement gap open.
Backward movement is silently allowed unless a validation rule blocks it — Salesforce allows reps to move an opportunity from Closed Won back to Negotiation without any warning. If the mapping exercise documents a rule like "no backward movement past Proposal without manager approval", that rule must be translated into an explicit validation rule or approval process requirement in the handoff brief — the platform will not honour it otherwise.
Win/loss capture point timing affects data completeness — If the win/loss reason field is required only on close (StageName = Closed Won or Closed Lost), reps often close deals by skipping the requirement via mass update or bulk edit, bypassing the validation rule. The mapping document should note whether the win/loss field needs additional enforcement (e.g., manager-only close permission) to prevent this gap.

Output Artifacts

Artifact	Description
Stage map document	Ordered stage list with definition, entry criteria, exit criteria, ForecastCategory assignment, owner, and default probability per stage
Win/loss taxonomy table	Final reason categories (win and loss), capture point, enforcement method, and data owner
Transition rules table	All stage boundaries with allowed direction, required fields, and notification/approval triggers
Open questions log	Unresolved items from discovery with named owner and target resolution date
Handoff brief	One-page summary of stage names (exact picklist-ready strings), process count, and transition rule summary formatted as input to the opportunity-management skill

Reference Files

File	Read it when
`references/worked-examples.md`	Building the artefacts — a B2B SaaS swim lane, the stage ladder in YAML and CSV, validation-rule intent, the record-type decision, the deployable stage value set, and the workshop question set
`references/gotchas.md`	Before finalising a stage map — nine platform behaviours that turn a plausible mapping document into a broken configuration
`references/examples.md`	Two worked engagements: new-logo vs renewal separation, and MEDDIC components used as stage entry criteria
`references/well-architected.md`	Pillar mapping, the tradeoffs behind one process vs many, and the sources every platform claim in this package rests on
`references/llm-anti-patterns.md`	Self-checking generated output — the six ways an assistant gets sales process mapping wrong
`templates/sales-process-mapping-template.md`	Running the engagement: motions, stage map, transition rules, win/loss taxonomy, open questions, handoff brief
`scripts/check_sales_process_mapping.py`	Linting the stage map (`--map`), the narrative document (`--doc`), or a whole design directory (`--manifest-dir`)

admin/opportunity-management — use after this skill completes; it consumes the handoff brief and owns the BusinessProcess, RecordType and PathAssistant XML
admin/picklist-and-value-sets — owns the OpportunityStage standard value set once the stage names are agreed
admin/validation-rules — turns the §3 enforcement intent into formulas, including the PRIORVALUE backward-movement pattern
admin/record-types-and-page-layouts — the record type and layout work that a second sales process forces
admin/record-type-strategy-at-scale — use when the mapping produces multiple processes and the org's record type budget is already tight
admin/path-and-guidance — use after opportunity-management to layer visual guidance on the configured stages
admin/process-flow-as-is-to-be — use for the step-anchored As-Is/To-Be swim lane with exception paths; this skill only maps the stage-anchored lane
admin/pipeline-review-design — use once the ladder is live, to inspect the distribution across the stages it created
admin/collaborative-forecasts — use when the forecast category assignments need wiring into forecast types and rollups
admin/quote-to-cash-process — owns the Quote → Contract handoff that the Closed Won exit criterion points at
admin/case-management-setup — owns the onboarding Case that the Sales → Service handoff creates
admin/requirements-gathering-for-sf — use when this mapping is one component of a larger requirements discovery effort