How to Build a Sales Pipeline from Scratch: Stages, Criteria, and Setup

Building a sales pipeline starts with deciding what counts as progress. Imagine two salespeople each marking a deal as Proposal: one has emailed a price sheet, while the other has reviewed scope and pricing with the buying team. Their records look equivalent, but the buyers have made different commitments. Adding a dashboard will preserve that ambiguity. Before configuring your CRM, define the evidence required to enter each stage, the buyer action needed to leave it, and who records the change. Those decisions turn a collection of opportunities into a process another person can understand.

What is a sales pipeline?

A sales pipeline is a structured view of sales opportunities and their position in the buying process. Each opportunity has an owner, a current stage, and a next action. Stages describe meaningful changes in the opportunity, such as an agreed business need or a commercial offer under review. Entry criteria define when a deal belongs in a stage; exit criteria define when it can advance.

Choose the boundaries before naming the columns. A prospecting list can contain people who have never replied, while an active opportunity pipeline should use a deliberate admission rule. For a first B2B setup, keep unqualified names in a lead list and create a deal when a suitable buyer agrees to investigate a relevant problem. Keep delivery tasks outside the open sales stages after the purchase is complete. New business, renewals, and expansion may need different pipelines when their buying steps differ. Separate sales teams following the same process can usually share stage definitions and use ownership or team filters instead.

A pipeline describes individual opportunities. Forecasting adds assumptions about whether and when those opportunities will become revenue, so it comes after the underlying records are dependable.

Step 1: Set the pipeline entry and closing rules

Start your pipeline design with a short agreement between the sales manager, a seller, and the person responsible for CRM administration. Define the customer profile you serve, the buying event that creates an opportunity, and the evidence needed to record a win. If there are no completed deals to review, use your current conversations and mark the resulting process as provisional.

For example, an entry rule might require a company within your target segment, a named contact who has acknowledged a relevant problem, and an agreed discovery conversation. A downloaded brochure alone would not meet that rule. Record the problem and the agreed next step when creating the deal, rather than asking the seller to reconstruct them later. This makes the admission decision inspectable without requiring a full qualification interview up front.

Define the end just as carefully. Depending on your business, Closed Won might require an executed agreement or an accepted purchase order, subject to your commercial policy. Closed Lost should capture why an opportunity ended, including no decision where appropriate, rather than serving only as a competitor-loss category. A buyer who asks to revisit next year needs a follow-up record outside the active opportunity view, not an indefinite place in late-stage negotiation.

Step 2: Design five open stages and two outcomes

Use five to seven stages as a starting design constraint, not a universal optimum. The example below has five open stages plus Closed Won and Closed Lost, for seven total stage values. Some CRMs represent the closing outcomes as statuses instead of board columns.

Each open stage should answer a different operational question. Qualification asks whether the opportunity deserves active work. Discovery establishes what the buyer needs to change. Evaluation tests the proposed solution against that need. Proposal brings a defined commercial offer into the buyer’s decision process. Approvals covers the remaining commercial and purchasing work before closure. If two neighboring stages would have the same evidence and next action, merge them rather than preserving an arbitrary count.

Qualification: confirm a credible buying conversation

Enter Qualification when the opportunity meets your admission rule and has an assigned owner. Exit when the buyer confirms a relevant need, basic fit is established, and someone agrees to participate in discovery. Store the contact, need, and scheduled next step as evidence; do not treat an email sent by the salesperson as buyer commitment. If the account cannot use or purchase your offering, close the opportunity with a reason instead of advancing it to obtain more activity.

Discovery: agree on the problem and decision path

Enter Discovery after the buyer agrees to examine the problem with you. Before advancing, confirm the desired outcome, the people involved in evaluating and approving a purchase, and how the buyer expects to make a decision. Capture unknowns explicitly, particularly around funding or timing, rather than filling fields with guesses. Exit when the buyer agrees on what an evaluation must demonstrate and who will assess it.

Evaluation: validate the proposed solution

Enter Evaluation when the buyer has agreed to assess a defined solution against those criteria. A demonstration, trial, workshop, or technical assessment may support this work, but completing the activity alone does not satisfy the gate. Exit when the relevant buyer confirms that the solution meets the agreed requirements and requests or agrees to review a commercial offer. Record unresolved requirements separately so that a positive demonstration does not obscure a blocking dependency.

Proposal: obtain a commercial decision path

Enter Proposal when an offer with defined scope and pricing has been shared and the buyer has agreed to review it. The exit rule should require a buyer response to the offer, identification of outstanding terms, and agreement on the approval process. Sending another version without that response leaves the deal in the same stage. Record the proposal version and the agreed review date so another salesperson can continue the conversation.

Approvals: resolve purchasing conditions

Enter Approvals when the buyer intends to proceed subject to specific commercial, legal, or procurement conditions. The seller should know which condition remains open, who owns it on the buyer’s side, and the next decision date. Exit to Closed Won only when your documented completion rule is met; a verbal assurance is insufficient if your rule requires a signed agreement. Exit to Closed Lost whenever the buyer rejects the purchase or the opportunity meets your agreed closure policy, even if earlier stages were completed.

The next stage’s entry conditions should match the previous stage’s exit conditions. Allow documented exceptions when a buyer arrives with work already completed, rather than forcing fictional meetings into the record.

Step 3: Configure CRM fields and stage controls

Build the CRM pipeline only after the stage definitions are readable outside the software. First create the pipeline and its ordered stages, then configure the closing classifications and supporting fields. Mria CRM is one option for teams that want to manage sales stages inside Jira; the same design exercise applies to a standalone CRM. Check the chosen product’s permissions and subscription requirements before promising enforced gates.

Minimum deal record: Keep identity, accountability, and buyer evidence together without duplicating the contact database. Reuse standard fields where they already describe the information, and add custom fields only for missing concepts. A practical starting record includes:

• Associated company and buyer contacts, with one accountable deal owner.
• Current stage and a short description of the business need.
• Next action, action owner, and agreed due date.
• Expected amount and currency, plus expected close date when supportable.
• Decision participants, stage evidence, and any unresolved buying condition.
• Closing outcome and loss reason when the opportunity ends.

Use date fields for dates, currency fields for values, and controlled choices for recurring loss reasons. Leave narrative space for the buyer’s problem and links to supporting notes. Make information mandatory when it becomes knowable: requiring final contract value during initial qualification encourages placeholder data. If your team must enter an early estimate, label its basis and review it before the commercial stages.

Field types and ownership deserve a separate design pass; the resource on CRM custom fields for reporting explains those decisions.

In HubSpot, for example, administrators configure deal stages in the object’s pipeline settings and can add conditional stage properties for manual record creation or movement. Create the supporting properties before configuring those conditions, and distinguish open stages from the Won and Lost classifications used in reporting. Start by requiring the smallest set of evidence fields needed for a decision. A completed text field proves that someone entered a value, so managers still need to inspect whether the value supports the stage.

For the implementation details, use HubSpot’s pipeline and conditional-property documentation .

Challenges when launching a new sales pipeline

A new pipeline is most vulnerable where the buying process differs from the process its designer assumed.

Buyers complete steps in a different order

A buyer may request pricing before a technical assessment or bring procurement into the first meeting. That does not require a new pipeline stage for every sequence. Keep the stage tied to the most advanced milestone supported by the required evidence, and record parallel work as tasks or fields. If a supposedly completed requirement becomes invalid, document the change and move the opportunity back when your process permits it. For example, a replacement decision-maker may require renewed discovery before accepting an existing proposal. A one-way-only board can conceal that regression unless you provide a clear correction route.

Required fields do not cover every update path

Test how your CRM handles imports, integrations, automation, and bulk editing before relying on a mandatory-field prompt. Pipedrive’s required-fields documentation, for example, explicitly lists update routes that can bypass those requirements. HubSpot documents conditions for applying its pipeline rules through APIs and integrations. Treat each entry path as a separate acceptance test, and add a missing-evidence review where the software cannot enforce the rule.

Too many stages create administrative distinctions

An extra stage is useful when it changes the buyer evidence, accountable person, or next action. A column for each follow-up email usually duplicates the activity history. If sellers cannot explain the difference between two stages using an actual opportunity, combine them and retain the useful detail in a task or field.

Best practices for testing the first pipeline

Pilot the sales pipeline with a small set of representative opportunities before importing the whole lead list. Include an early conversation, an active evaluation, a commercial negotiation, and a deal that should close without a sale. The purpose is to expose ambiguous rules while changes are inexpensive.

Ask two sellers to classify the same opportunities

Give each seller the same notes and ask them to select a stage independently. Then compare the evidence each used, especially when their answers differ. Rewrite the criterion that caused the disagreement and repeat the exercise with another opportunity. Consistent interpretation is a better launch signal than agreement that the board looks tidy.

Test rejected moves as well as successful ones

Try advancing a test deal with missing evidence, closing one without a reason, and importing a record into a late stage. Check what a regular seller can do rather than testing only with an administrator account. Verify that a valid deal can move forward without unnecessary work and that exceptions appear in a reviewable place. Finally, check the closing handoff so a won opportunity gives delivery staff the agreed scope and a responsible contact.

Write down the results and unresolved exceptions. Keep automation limited to reminders and administrative assistance until the stage gates survive these tests; an automatic move triggered by an outgoing email would reintroduce the activity-based progression you removed.

Pipeline setup in two business scenarios

Use concrete selling situations to decide whether your starter pipeline needs adaptation. These illustrative scenarios test different buying requirements rather than prescribing extra stages for every team. Keep the shared model unless the evidence or ownership changes materially.

Selling software with a customer security review

Suppose a software buyer likes the demonstration but cannot proceed without security approval. The salesperson keeps that dependency visible during Evaluation and records the security reviewer, requested evidence, and agreed review date. If security clearance is a prerequisite for commercial approval, the stage gate must include it. When security review routinely has a distinct owner and substantial work, a dedicated stage may help; an occasional review can remain a tracked requirement within Evaluation.

Agreeing a consulting engagement before delivery planning

Consider a consultancy selling a scoped implementation project. Discovery establishes the customer’s desired result, while Evaluation may involve a scoping workshop rather than a software trial. The proposal specifies deliverables, exclusions, and commercial terms; approval confirms those terms under the firm’s closing policy. After the deal is won, delivery planning belongs in the project workflow, linked to the agreement, rather than extending the open sales pipeline through execution.

Choose the smallest pipeline your team can apply consistently

Your first sales pipeline is ready when a seller can explain why a deal belongs in its stage and what buyer action would move it forward. Review whether every open stage has distinct entry and exit evidence, an owner, and a usable next step. Remove stages that merely restate activities already recorded elsewhere. Split pipelines only when the underlying buying process requires different milestones. Keep uncertain stage probabilities labeled as assumptions until your own completed opportunities support a better estimate. A precise-looking percentage cannot compensate for inconsistent classification.

Launch the version your team can maintain, then revise it when actual deals expose missing criteria. Record stage-definition changes so later comparisons do not silently mix different processes. Once the setup is stable, shift attention from building the board to keeping opportunities current.

The next operational layer is covered in sales pipeline management, metrics, and hygiene .