Almost every CRM ships with a default pipeline: Lead, Qualified, Demo, Proposal, Negotiation, Closed Won. It's a reasonable generic template and it is very rarely how a software company actually sells. Teams that keep the default end up with a pipeline that looks tidy in a report and tells nobody anything useful about what's actually happening in a deal.

Good pipeline stages do two things at once: they reflect a real, observable change in the buyer's behavior, and they trigger a specific next action from the rep. If a stage doesn't meet both bars, it's decoration, not a working part of your sales process.

The test for a stage that's worth keeping

For every stage in your pipeline, ask: what did the prospect do to get here, and what do we do next because they did it? "Qualified" fails this test constantly, because different reps qualify differently, so the stage stops meaning anything consistent across a pipeline report. A stage like "Technical evaluation started" passes, because it maps to something concrete (a sandbox was provisioned, an API key was issued) and it triggers a specific next step (solutions engineer assigned, check-in scheduled for day 5 of trial).

Stages built around a technical sale

For software companies specifically, the stages that tend to hold up over time look less like a generic funnel and more like a map of technical trust being built. A pattern that works well for teams selling to engineering or technical buyers:

  • Discovery: first real conversation happened, use case and technical constraints identified. Exit trigger: a scoping call is booked.
  • Technical evaluation: sandbox or trial environment is live, prospect's engineers are actively testing. Exit trigger: usage crosses a meaningful threshold (e.g. first successful API call, first integration connected) or a security review is requested.
  • Business case: technical fit is confirmed, conversation has moved to budget, procurement, and internal buy-in beyond the technical champion. Exit trigger: a proposal or pricing document has been sent to an economic buyer.
  • Contracting: pricing is agreed in principle, legal and security review are in motion. Exit trigger: redlines are resolved or a signature request is sent.
  • Closed won / Closed lost: self-explanatory, but closed-lost should always capture a reason code, not just a stage change.

Notice that "Demo" isn't a stage on its own here. A demo is an activity, not a milestone, and treating it as a stage tends to produce pipelines where 40% of deals sit in "Demo scheduled" indefinitely because nothing forces movement forward. Fold the demo into Discovery and gate the exit on something that actually indicates progress: a scoping call, a trial start, an intro to a second stakeholder.

Common mistakes that quietly wreck a pipeline

  • Too many stages. Past six or seven stages, reps start parking deals in whatever stage is easiest to justify rather than the one that's accurate, because the incremental stages don't map to anything they'd naturally track. Five stages plus closed won/lost is usually the ceiling for clean data.
  • Stages that only sales can see progress on. If "Qualified" depends on a rep's private judgment call, two reps will use it differently and your stage-to-close conversion rate becomes noise. Anchor every stage to something a manager could verify by looking at the account, not just reading the rep's notes.
  • No exit criteria written down anywhere. If the criteria for moving a deal from stage to stage live only in a rep's head, they drift the moment that rep leaves or gets busy. Write the exit trigger into the stage name or description field directly.
  • Ignoring signals from outside the CRM. For a technical sale, some of the best stage-progression signals (a sandbox going live, a support ticket volume spike, a Slack Connect channel going quiet) live in your product or your dev tools, not in anything a rep types manually. A pipeline that only updates when a human remembers to update it will always lag reality.

Building this in Softmatica

Pipeline stages in Softmatica are fully custom per pipeline, so you can define a technical-evaluation-first pipeline like the one above without fighting a fixed default. Because GitHub, Linear, Jira, and product usage events sync onto the deal automatically, stage-exit triggers can be partly automated: a rule can flag a deal for stage advancement when trial usage crosses a threshold, rather than waiting for a rep to notice and update it manually. That keeps the pipeline closer to what's actually true, which is the entire point of having stages in the first place.

Once your stages reflect reality, forecasting gets meaningfully better almost immediately, not because the forecasting math changed, but because the inputs finally mean something consistent.