A B2B SaaS sales funnel connects awareness, consideration, evaluation and purchase, with a handoff to onboarding and renewal. Define stages for the actual buying route. Advance opportunities using verified buyer commitments; calls, content views and trial activity alone do not establish commercial progress.
Map the SaaS Buying Path Before Naming Funnel Stages
“If buyers keep using the trial, surely the funnel is moving.” Sometimes it is. I would count a first successful product task as progress in an activation funnel. I wouldn't call it agreement to buy. A B2B SaaS sales funnel maps how business audiences become evaluators and customers; its stages need to preserve that distinction.
Self-serve trials and sales-assisted evaluations
Start with the path your buyer can actually take. Awareness means encountering a relevant problem or solution; consideration means investigating whether it fits; evaluation means assessing the product; purchase means making a commercial commitment. Onboarding, adoption and renewal follow, and deserve a connected view even when acquisition reporting ends at purchase. For a self-service product, your proposed path might be visit, account creation, meaningful product use and completed paid purchase. A sales-assisted evaluation adds a person who agrees what to test and how to decide. Procurement introduces another question: who can approve the terms and authorize the purchase? These are alternative routes, not compulsory meetings on one universal ladder. Stripe documents free subscription trials without collecting payment details, including settings that pause or cancel when the trial ends without them. That makes room for a real evaluation before payment. It also means your trial population cannot automatically stand for committed revenue. I would map the self-service route first, then add human assistance where the buyer needs it. If a customer can legitimately purchase without a demo, your funnel should record that shorter route without creating a fictional demo stage. Capture the purchase evidence directly and leave the skipped stage outside that route's denominator.
Marketing funnel versus sales opportunity stages
Keep the record types clear while drawing the path. HubSpot's lifecycle stages describe contacts and companies; its Opportunity label means association with a deal. Salesforce opportunities represent potential sales moving through stages that can differ by company. Neither label tells you that every associated person made the same commitment. A marketing funnel can count people discovering and considering a category, while an opportunity funnel follows a particular potential purchase. Connect the records, but don't divide a count of opportunities by a count of page views and call the result a stage-to-stage buyer conversion. Specify what enters each stage: a person, an account, a trial workspace or a purchase opportunity. For your B2B SaaS sales funnel, the useful unit depends on the question you're answering.
Define the Buyer Evidence Required at Each Transition
“Then every stage needs a signed promise?” No. I mean a verifiable commitment appropriate to that stage: a stated problem, an agreed evaluation task, or accepted commercial terms. Requiring a contract before evaluation would make the funnel useless. Requiring nothing beyond your own activity would make it equally uninformative.
Problem recognition, evaluation, and commercial commitment
Here is a proposed stage design you can adapt. At problem recognition, retain the buyer's description of the task and the consequence they want to change; a seller's guess remains an unconfirmed hypothesis. At evaluation entry, record the product question, a named participant and the agreed next action. For a self-service route, the participant's deliberate use of a relevant feature may establish evaluation without a conversation. For an assisted route, agree the success criteria and decision date with the person doing the assessment. At evaluation completion, record what the buyer accepted, what remains unresolved and whether they want a proposal. GitLab's commercial handbook makes the distinction concrete: its technical evaluation work includes agreeing success criteria, timing and next steps with the customer. Further along, its proposal exit criteria include a mutual close plan, confirmed procurement process and implementation strategy. I read these as different questions, not interchangeable signs of enthusiasm. Technical fit asks whether the product can meet the need. Commercial progress asks whether the organization is proceeding under workable terms. For your own procurement route, name the remaining approval, the responsible party and the evidence expected before advancing. An emailed quote proves that you sent a quote; a buyer-confirmed review date supports a narrower and more useful conclusion about what happens next.
- Problem recognition: the buyer states a task and desired change; keep seller assumptions visibly unconfirmed.
- Evaluation: identify the participant, product question and agreed action; use meaningful product behavior for self-service and jointly defined criteria for assisted work.
- Commercial commitment: establish whether the buyer wants to proceed, which approvals remain and which event will constitute purchase.
Activation and trial activity without a purchase commitment
The self-service objection wins an important point here: product behavior can be the buyer's commitment. You don't need to ask someone to repeat in a meeting what their completed task already demonstrates. Define activation around a meaningful task for your product, then label it as activation. Keep trial status, product use and purchase status separately visible. Stripe's free-trial documentation allows access before payment details are collected; when those details remain absent, configured trial-end behavior can pause or cancel the subscription. That documented possibility rules out treating trial participation alone as proof of purchase. It doesn't tell you whether a particular user likes the product, has budget, or will convert later. I would retain those unknowns. For an assisted trial, record the evaluator's assessment beside usage; for a self-service purchase, use the agreed checkout or contract completion event. Choose the purchase definition with finance, especially if invoicing and cash collection occur later. Don't silently change between signed contract, paid invoice and active subscription as the report moves from one system to another.
Handle Deals That Look Active but Have Not Advanced
“But the team has delivered three demos. Leaving the deal in evaluation understates the work.” It would understate the work only if the stage were your sole activity record. Keep the demos in the activity history. Ask a separate question before promotion: what did the buyer agree to that was previously unresolved?
Repeated demos, stalled trials, and reopened evaluations
GitLab's published process supplies a useful counterexample to activity-based advancement. Demos and trials sit inside technical evaluation, while the exit criteria separately require mutual agreement to move to proposal and identified next steps. The point is limited but decisive: in this documented process, completing the activity isn't sufficient. You can use that distinction without adopting every GitLab stage. Consider a hypothetical trial whose participants keep requesting new demonstrations but haven't agreed whether the original task was met. I would keep its evaluation status, record the unresolved task and ask which next action will resolve it. That is an illustrative decision, not a customer result. A trial extension also deserves a reason. GitLab directs teams to prepare a project plan with the customer before granting a requested license extension. For your process, distinguish missing evaluation time from a new requirement or an unavailable decision-maker; each calls for a different follow-up. If the buyer has explicitly stopped evaluating, use your agreed closed or inactive status and preserve the reason. Silence alone shouldn't be rewritten as a confirmed loss to a competitor. If an evaluation reopens, retain the earlier dates and identify what changed rather than presenting the reopened work as an uninterrupted march forward. More activity may be worthwhile; it needn't create a later stage.
Advance the Funnel Only on the Agreed Stage Evidence
A reasonable compromise emerges: count seller work as work, buyer use as use, and commercial advancement against the evidence agreed for that transition. I wouldn't discard a busy trial. I'd stop making one label carry all three meanings.
Write a short definition for each stage before automating movement: the eligible record, entry evidence, exit evidence, who verifies it and what happens when evidence is missing. These are proposed operating definitions, not fields promised by a particular CRM. For a team considering OKKI Go, settle those B2B SaaS sales funnel requirements before discussing implementation. Include exceptions openly: self-service purchases can bypass assisted evaluation; a procurement review can reopen a technical question; an existing customer can evaluate an expansion while continuing to use the original subscription. The agreement should let you preserve those facts without pushing the record into an inaccurate stage. GitLab's later commercial stages distinguish agreed business and legal terms from fully executed documents. That is a useful reminder to keep “ready for signature” separate from whatever your organization has defined as a completed purchase. After purchase, carry the promised use case, implementation responsibility and unresolved obligations into onboarding. Track adoption and renewal readiness as subsequent work. A closed acquisition opportunity doesn't answer whether the customer achieved value, and it shouldn't be reopened merely to measure routine onboarding. If a renewal or expansion requires another buying decision, give that decision its own appropriate path.
Conversion, aging, and loss reasons under consistent definitions
Consistent definitions make the metrics interpretable. For a chosen cohort, calculate a transition rate as eligible records reaching the next agreed stage divided by eligible records entering the prior stage, using the same observation window and unit. Show still-open records separately so a recent cohort isn't mistaken for a completed one. Track time since stage entry and time since the last verified buyer commitment as different clocks; repeated calls can reset activity recency without resetting either. HubSpot documents lifecycle entry and exit dates, illustrating the availability of stage timestamps, but verify the behavior of the particular report you use. Review loss and inactive reasons with explicit unknowns, and split self-service from assisted routes before comparing them. You can then investigate a stalled transition: unclear evaluation criteria, an unresolved product issue, purchase approval or simply insufficient elapsed time. These are questions for review, not causes proved by the funnel. The final agreement is practical: preserve every useful signal, advance only when the defined transition is supported, and let the report say when you still don't know.
Frequently asked questions
Is a SaaS trial signup a qualified sales opportunity?
Not automatically. A signup shows that someone entered a trial. Qualification needs the information your sales process requires, while a self-service journey may proceed without creating an assisted sales opportunity. Keep product evaluation and commercial commitment distinct.
How should a stalled trial appear in the funnel?
Keep its last supported evaluation state, record the unresolved question and agree a useful next action where possible. Use an inactive or closed status when your definition supports it. An extension or another demo should not automatically promote the opportunity.
Should SaaS renewals use the same funnel as first purchases?
Connect acquisition to onboarding and adoption, but define renewal around the subsequent decision to continue. Reuse a stage only when its meaning and evidence are the same. Keep an expansion evaluation separate from the status of the existing subscription.
