Sales Process Documentation: Document Inputs, Not Steps

Most sales process documents die the same way. Someone in enablement or RevOps writes them during a quiet quarter. They list the stages, the activities in each stage, the fields to fill in, and a few talk tracks. Six months later the product has a new tier, the ICP has shifted, two competitors have repositioned, and the document still says "Discovery: run a discovery call and log it." Nobody updates it because nobody reads it, and nobody reads it because it tells a rep nothing they did not already know.

The fix is not a better template for the same content. It is a different unit of documentation. A step is something a rep does. An input is something a rep has to know before the step can go well. Steps barely change from year to year. Inputs change every quarter, and they are where deals are actually won or lost. This article lays out a documentation format organised around the inputs each stage gate needs, with a worked example you can copy into your own wiki.

Why step-based process docs decay

Open almost any published sales process template and you will find the same skeleton: prospect, qualify, discover, present, handle objections, close, expand. Each stage gets a paragraph of activities. That skeleton is correct, and that is exactly the problem. It is correct for every company, so it tells a rep nothing specific about yours.

Three things make step lists go stale faster than anyone expects:

• The steps were never the hard part. A rep with three years in the seat knows how to run a discovery call. What they do not know is which of your products this particular account is most likely to need, and what has happened at the account recently that makes the conversation timely.
• The knowledge that matters lives somewhere else. Product fit, competitive position, and account context sit in battlecards, Slack threads, call recordings and the heads of your best reps. The process doc points at none of it.
• Nothing forces an update. A step list has no expiry date. An input with a named owner and a source does, because the source moves and someone notices.

The cost of this shows up in how reps spend their week. In Salesforce's State of Sales survey of 5,500 sales professionals, reps reported spending 70% of their time on non-selling tasks such as administrative work and meeting preparation, and only 35% said they completely trust the accuracy of their organisation's data. Preparation that a good process doc should shortcut is instead rebuilt from scratch, deal by deal, from sources the rep is not sure they can trust.

Gartner's research on seller workload points at the same gap from another angle. In a survey of 1,026 B2B sellers, 72% said they felt overwhelmed by the number of skills required for their job, and overwhelmed sellers were 45% less likely to attain quota. A process doc that adds steps adds to that load. A process doc that hands the rep the answer to "what do I need to know here" takes load away.

Document the inputs each stage gate needs

A stage gate is the point where a deal is allowed to move forward. Most teams already define exit criteria for each stage, usually as a checklist in the CRM. The format below keeps those criteria but adds the column most docs leave out: what the rep must know before entering the stage, where that knowledge comes from, and who keeps it current.

For each stage, write down four things:

1. Required inputs. The specific facts the rep must have before the stage starts. Not "understand the customer." Something closer to "which of our three products fits this account, and the evidence for that."
2. Source. Where each input comes from: the CRM, a named research step, a public filing, a job posting, a product usage report, a call with a champion.
3. Owner. The person or team accountable for the input being available and correct. For account-level research this is often RevOps or an SDR pod. For product fit it is product marketing.
4. Exit evidence. What must be true, and recorded, for the deal to leave the stage. This is the part most teams already have.

If you are rebuilding your stage definitions at the same time, our breakdown of the stages of a sales pipeline covers the exit criteria side in more depth. This article focuses on the inputs side, because that is where the documentation usually stops.

A worked example: the input table

Here is what the format looks like for a mid-market B2B team selling more than one product. Adapt the rows to your own stages, but keep the columns.

Two things stand out once a team fills this in. First, the early stages carry most of the research load. Target and first contact both depend on knowing what the account needs and why now, and that is the work most process docs skip entirely. Second, several inputs repeat across stages. The problem hypothesis formed at Target is the same one tested at Discovery and reused at Expansion. Writing it down once, with its source, means the AE and the CSM are not each rebuilding it from memory.

What a good input looks like

A good input is specific, sourced, and dated. Compare these two versions of the same first-contact input:

• Weak: "Research the account and personalise your outreach."
• Strong: "Lead with the reporting product. The account posted four analytics roles in the last 30 days and its CFO said on the last earnings call that board reporting takes too long. Links attached."

The weak version is a step. The strong version is an input: it tells the rep what to pitch, why now, and where the evidence lives. Our pre-call research checklist goes deeper on the individual facts worth collecting, and the piece on buying signals in sales covers which kinds of events actually predict a buying conversation.

Who keeps the documentation current

An input-based doc only works if the inputs stay fresh. Assign ownership at two levels.

Owners of the format

Enablement or RevOps owns the table itself: the stages, the columns, and the definition of what counts as a good input. They review it once a quarter, and whenever the product line or ICP changes. A new product tier should trigger a review the same week, because every "which product to lead with" input just changed.

Owners of the content

The inputs themselves are account-level and change weekly. They cannot live in the process doc. The doc defines what the input is and where it is stored; the actual content lives on the account record or in a research note attached to it. This split is what keeps the doc short enough to read. The process doc says "before first contact, the account record must show a product to lead with and one sourced reason to call now." The account record holds the answer for that account.

This is also where most teams hit a capacity wall. Producing a sourced problem hypothesis for every account on a list of several hundred is real work. Gartner's 2025 survey of 227 CSOs found that organisations providing sellers with AI-enabled next best actions were 2.6x more likely to achieve commercial growth, and Gartner named account research and signal monitoring among the activities AI is well suited to. That matches what the input table shows: the research-heavy inputs at Target and First contact are the ones worth automating, while the judgement-heavy inputs at Discovery and Proposal stay with the rep.

PitchSmart was built for the research-heavy rows. It researches every lead on your list against what you sell and returns a plan for each: which product fits, why now, and what to say, with a source attached to every claim. In input-table terms, it fills the "Required inputs" column for Target and First contact, so the process doc can require those inputs without requiring a rep to spend a morning producing them.

Rolling it out without a rewrite

You do not need to throw away the existing process doc. Convert it in four passes:

1. Keep the stages and exit criteria you already have. They are probably fine. Paste them into the Stage and Exit evidence columns.
2. Interview two top reps and one struggling rep per stage. Ask each: "What did you need to know before this stage that you had to go and find yourself?" The gap between the top reps' answers and the struggling rep's answers is your Required inputs column.
3. Name a source and an owner for every input. If an input has no source, it is a skill gap, and it belongs in coaching, not in the doc. If it has no owner, it will be stale within a quarter.
4. Wire the inputs into the CRM as required fields at the stage gate. A deal cannot move to First contact without a product-to-lead-with field and a linked source. That is what turns the doc from a reference nobody opens into a gate reps pass through daily.

Then test it on new hires. Hand the input table to someone in their first month and see whether they can prepare for a first call without asking a colleague. If they cannot, an input is missing. Our guide to onboarding new sales reps covers how to fold the doc into ramp, and win-loss analysis is the right place to check, after a quarter, whether deals that entered a stage with complete inputs actually closed at a higher rate than those that did not.

Common mistakes to avoid

• Writing inputs as instructions. "Research the account" is a step wearing an input's clothes. Name the fact the rep must have.
• Storing account content in the doc. The doc defines the input. The account record holds it. Mixing the two produces a doc that is out of date the day it is published.
• Documenting one product's process for a multi-product team. If you sell more than one thing, "which product to lead with" is the first input at almost every stage. Leaving it out forces reps to default to whatever they know best.
• No expiry on research. A reason to call from nine months ago is not a reason to call. Date every input and set a freshness rule, for example 90 days for account events.
• Skipping the struggling-rep interview. Top reps forget what they had to learn. The rep who is behind will tell you exactly which input is missing.

A sales process doc earns its place when a rep opens it before a call and finds out something they did not know. Documenting steps cannot do that, because reps already know the steps. Documenting inputs can, because the inputs are the part that changes with every account, every product launch, and every quarter.