CRM Pipeline Setup: Define Stages and Verify Your First Deals

A useful CRM pipeline setup makes each deal’s position explainable. Someone should be able to open a record and answer four questions: why is it in this stage, who owns it, what happens next and what would justify moving it forward?

Creating columns is the easy part. The harder work is defining what those columns mean and checking that the CRM preserves that meaning in records, history and reports. A board can look orderly while its totals combine different currencies, its probabilities overstate confidence or its stage names mean different things to different people.

This Guide walks through a small-team setup using a written stage matrix and a controlled acceptance check. It draws on Exploripo’s September 2026 tests of Pipedrive, HubSpot CRM, Close and Zoho CRM, plus official documentation checked on October 18, 2026. Those were separate product tests, not a synchronized four-CRM implementation study. The example pipeline and test cases below are an original reader-run plan, not newly measured results.

The quick setup checklist

1. Choose one sales process and define when a deal enters it.
2. Write observable entry and exit conditions for each stage.
3. Separate stage, activity and final outcome.
4. Set the minimum record fields, an owner and a dated next action.
5. Review probability, currency and reporting behavior in your chosen CRM.
6. Verify the setup with synthetic deals, including a stalled and a lost case.
7. Resolve discrepancies before inviting the team to rely on the pipeline.

Keep the first version small enough to explain without a presentation. Add a stage only when it changes a decision, a handoff or the evidence needed to continue. A longer board is not automatically a more accurate sales process.

Step 1: define what belongs in the pipeline

Write down the process you are representing before changing settings. For example: a small consultancy sells scoped implementation projects, from an accepted discovery opportunity to an explicit won or lost outcome. Renewal work may follow a different process; customer support does not belong in this sales pipeline.

Decide what qualifies as a deal. An email subscriber, a company in a directory and a genuine buying opportunity are different records. If every contact becomes an open deal, your board starts overstating demand before anyone has reviewed a proposal.

Use one sentence as an entry rule: “Create a deal when a named organization has expressed a relevant need and we have agreed a next conversation.” This is an illustrative policy, not a universal qualification standard. A self-service product, agency and enterprise sales team may need different rules.

Start with one pipeline where the selling steps are the same. Separate pipelines are useful when processes genuinely differ, rather than simply because two sellers want separate views. Check your account’s entitlement first: HubSpot’s pipeline documentation distinguishes the default pipeline from custom pipelines, which require a paid subscription. Do not design around an extra pipeline your current account cannot create.

Step 2: write a stage matrix before editing the board

A stage should describe a defensible state of the opportunity. Give it an entry condition, evidence to retain and an exit decision. Avoid labels such as “Working on it” that explain effort without showing what the buyer has done.

The following is an illustrative consultancy pipeline. Adapt it to your actual buying process; it is not a tested template or a recommended number of stages for every business.

Stage or outcome	Evidence needed to enter	Decision before advancing
Qualified opportunity	Relevant need and an agreed next conversation	Confirm scope and decision participants
Discovery complete	Requirements and buying constraints recorded	Agree what a useful proposal must cover
Proposal shared	A specific proposal delivered to the intended buyer	Confirm that the buyer has reviewed it
Decision pending	Buyer feedback and remaining questions recorded	Obtain an explicit acceptance or rejection
Won	Evidence meeting your agreed acceptance rule	Complete the defined operational handoff
Lost	Explicit rejection or a documented closure decision	Record the reason and remove it from open work

Write one counterexample for each open stage. A proposal drafted internally does not satisfy “Proposal shared.” A meeting booked does not prove “Discovery complete.” These counterexamples expose ambiguous definitions faster than polishing stage names.

Specify whether a deal can move backwards or skip a stage. A buyer might reopen scope after a proposal, or arrive with requirements already documented. Your policy should say what evidence is needed in those cases. Whether the software can enforce that policy is a separate, account-specific question.

Keep won and lost as explicit outcomes even if the CRM displays them outside the open-stage board. Their representation differs between products. Do not create an ordinary open column called “Won” and assume reports will recognize it as a completed sale.

Step 3: separate stages from tasks and follow-up

“Call on Tuesday” is an activity. “Discovery complete” is a state. Mixing them creates stages that stop making sense as soon as an appointment changes. Use tasks or activities for the next action and the deal stage for progress through the buying process.

For each open deal, capture an owner, a next action and a due date. “Follow up” is weak; “Ask the buyer to confirm the implementation scope by Thursday” gives the owner something verifiable to do. If there is no legitimate next action, review whether the deal is still an active opportunity.

Choose a simple stalled-deal policy. For example, a seller reviews a deal after an agreed number of working days without a meaningful update. Set that threshold from your selling cycle, not a generic internet benchmark. A scheduled next step and the last meaningful buyer interaction may tell different stories, so review both.

Do not turn on messages or stage-triggered automations while the definitions are still changing. Once the manual process is stable, use the separate CRM workflow testing Guide to validate a narrow internal action. This article’s acceptance check does not prove that an automation runs correctly.

Step 4: configure the minimum useful deal record

Record the information needed for the next decision, rather than every field the CRM offers. A useful starting set is:

• a deal name that distinguishes the opportunity from the company;
• the associated person and organization where appropriate;
• the selected pipeline and stage;
• a responsible owner;
• deal value, currency and the basis of that value;
• an expected close date, when there is a defensible estimate;
• the next action and due date;
• notes or evidence supporting the current stage.

Define what the value represents. A one-time project fee, monthly recurring amount and annual contract total are not interchangeable. If two sellers enter different bases, summing the values creates a misleading headline even when every number was typed correctly.

Decide how to represent an unknown amount. Do not silently substitute a guessed average and let colleagues read it as an agreed quote. If you use an estimate, label its basis and replace it when better information arrives. Likewise, distinguish a target close date from a date the buyer has actually committed to.

Review which fields your account can require or conditionally display. A written policy can still be used when software enforcement is unavailable, but call it a manual control. We did not test team permissions, mandatory stage rules or multi-user enforcement across all four CRMs.

If you are migrating records, stop before a bulk import and use the separate Pipedrive contact-field mapping Guide. This setup workflow does not replace mapping, duplicate review or migration verification.

Step 5: verify probability and value behavior

Treat probability as a model input, not evidence that a buyer will sign. Avoid assigning increasing percentages merely because the columns move from left to right. Without suitable historical outcomes, label initial percentages as provisional and keep them out of promises about future revenue.

The products also handle probability differently. Pipedrive documents separate stage and deal probabilities, with a deal-specific value taking precedence. Its stage probability defaults to 100% unless adjusted. Check the setting rather than assuming an untouched board already has a calibrated forecast.

Zoho’s stage-probability documentation separates stage, probability, record category and forecast category. That distinction matters when a record looks closed but is mapped incorrectly for reporting. HubSpot also requires explicit Won and Lost classifications for correct deal reporting; a friendly display name alone is insufficient.

Close uses opportunity Confidence in its expected-value calculation. Its status-to-confidence guidance describes a separate workflow-based setup requiring workflow access. Do not assume that changing a status automatically applies your desired percentage, or activate workflows merely to complete this manual check.

For an illustrative arithmetic test, a one-time deal worth 10,000 in one currency at 20% has a weighted value of 2,000. At 40%, it has a weighted value of 4,000. These are invented verification inputs, not win-rate benchmarks or expected earnings. Check which probability field the CRM actually uses before comparing the result.

What our existing tests actually showed

The historical evidence offers concrete reasons to inspect records and reporting separately. It does not establish which CRM is best or guarantee the same behavior on every plan.

Product and test date	Directly observed	Setup lesson and limit
Pipedrive, September 25, 2026	Two synthetic deal moves appeared in timestamped history; a EUR deal remained EUR while the aggregate displayed CZK	Check history and display currency separately; conversion accuracy and forecast calibration were not tested
HubSpot CRM, September 28, 2026	A Free Tools deal retained associations, a task and two stage moves in history	Check the record behind the board; paid stage enforcement and team permissions were not tested
Zoho CRM, September 29, 2026	An Enterprise-trial deal moved from Qualification to Needs Analysis; probability changed from 10% to 20% and expected revenue from Kč4,500 to Kč9,000	Stage changes can affect calculated values; this was one Kč45,000 synthetic deal, not a forecasting study
Close, September 29, 2026	An import created four leads but rejected all four opportunity components using the generic status Active	Use valid destination statuses; this import finding does not establish that manual stage changes fail

For the broader test context and product limitations, read the Pipedrive review, HubSpot CRM review, Close review and Zoho CRM review. The four tests used synthetic data and did not connect customer mailboxes, calendars or calling integrations.

Step 6: run a small acceptance check

Use an isolated test space or clearly labeled synthetic records, with integrations and outbound actions inactive. Do not move a real opportunity merely to see what happens: an existing workflow might send a message, change ownership or notify a customer.

Before creating records, write the expected result for each case. Use fictional names and reserved example-domain addresses if an address is necessary. Keep the test small enough to inspect every record directly.

1. Normal progress: Create a qualified synthetic deal, associate the relevant records, add an owner and a dated task, then advance it only after recording the required evidence.
2. Insufficient evidence: Create a deal without discovery notes. Confirm that your written rule would keep it out of Discovery complete. Record whether the CRM blocks the move or whether manual review is required.
3. Reopened scope: Move a proposal-stage test deal back to the appropriate earlier stage. Check that the next action and history still explain why.
4. Stalled work: Create a clearly labeled test case with an overdue next action. Verify that the chosen list or report exposes the issue rather than hiding it behind a future close date.
5. Explicit outcomes: Use separate synthetic records to check won and lost handling. Confirm they are classified correctly and excluded from the intended open-deal view.
6. Value change: Change a test amount or probability and compare the expected arithmetic with the displayed calculation, using a consistent currency and value basis.

For each case, inspect the board, the underlying record and the relevant history or report. Record a pass, discrepancy or unavailable check. A successful drag-and-drop only proves that the interface accepted a move; it does not prove that entry criteria were met or reporting is correct.

If a check fails, save the observed result before changing anything. Narrow the cause: wrong stage definition, invalid status, missing association, mixed currency, stale report, unavailable entitlement or a misunderstanding of probability precedence. Repeat only the affected case after correction, retaining the original finding.

Step 7: approve the first version and review it deliberately

Your setup is ready for a small pilot when the stage matrix is agreed, synthetic cases have recorded outcomes, reporting discrepancies are understood and everyone knows who owns the process. Document any remaining manual controls and name the person responsible for them.

Keep a short setup record containing the stage definitions, field meanings, probability assumptions, test results, account limitations and review owner. A screenshot of a tidy board is helpful, but it cannot replace these definitions.

During the pilot, review a few real opportunities together and ask whether two people would place each in the same stage. Investigate recurring disagreements before adding more fields or automation. Revisit provisional probabilities when you have suitable outcome data; do not mistake a tiny sample for a reliable conversion model.

Change definitions deliberately. Renaming a stage can affect reports, imports, integrations and automation conditions. Review those dependencies before a change, retain the old-to-new mapping and repeat the affected acceptance cases. Avoid deleting established stages simply to make the board look cleaner.

Frequently asked questions

How many stages should a CRM pipeline have?

Use the fewest that preserve meaningful buying decisions and handoffs. The example above has four open stages plus won and lost outcomes, but it is an illustration. Merge stages that require the same evidence; split one only when the distinction changes how your team acts.

Should every contact become a deal?

No. Define an opportunity entry rule for your process. Keep people and organizations as records without inflating the open pipeline when there is no identifiable buying opportunity or agreed next step.

Should stage probabilities rise automatically?

Do not assume that they do. Check the product’s stage, deal or confidence settings and any override behavior. Increasing percentages are not validated win rates unless appropriate historical data supports them.

Can I set up the pipeline on a free CRM plan?

You may be able to use the default pipeline and core records, but custom pipelines, enforcement, automation and reporting can have separate limits. Verify the exact features in your account. Our HubSpot Free Tools test does not prove access to paid configuration features.

What proves that the pipeline setup is ready?

Agreed stage definitions, a consistent value basis, accountable ownership, visible next actions and recorded acceptance results. Start a limited pilot only after discrepancies are resolved or documented with an owner; a populated board by itself is insufficient.