Sales Process
The sales process is the skeleton of the Sales Cloud data model, so design it explicitly and defensibly. An opportunity's stage drives probability, forecast category, pipeline reporting and automation; stages should be mutually exclusive, defined by exit criteria reps can verify, and few enough that reps actually update them.
In Salesforce, a Sales Process is the set of stage picklist values available to an opportunity record type. Multiple record types let new business, renewals and channel deals follow different stage sets on one object. Standard tools that operationalize the process include Path (guidance for success, key fields and stage-specific coaching), Kanban list views for pipeline hygiene, validation rules that block moving forward without required data, and required closed-lost/closed-won reasons for root-cause analysis.
Related process mechanics: forecast categories group stages for forecasting and do not have to map one-to-one to stages; opportunity teams and splits model overlay sellers and credit sharing; stale-deal alerts (Big Deal Alerts) flag inactivity; stage history and opportunity field history feed cycle-time analysis.
Traps: renaming or deleting stage values after go-live (historic reporting and forecast mappings break); changing default probabilities casually (forecast math shifts retroactively in reporting); expecting Path to enforce entry into a stage - Path guidance is advisory, validation rules enforce; assuming forecast categories equal stages.
Worked example: design stages as Prospecting → Discovery → Validation → Proposal → Negotiation → Closed, each with one exit criterion (e.g., Validation requires a confirmed economic buyer field and an identified decision date), validation rules on those fields, and Path guidance listing the two key fields per stage. Map Prospecting/Discovery to Pipeline, Validation/Proposal to Best Case, Negotiation to Commit.
Rule of thumb: if a stage cannot be defined in one sentence of observable evidence, it is not a stage.