Sales funnel

A sales funnel breaks the buying process into observable steps, from first problem recognition to purchase. It isn't a neat staircase. Buyers skip steps, disappear for six weeks, come back with a security questionnaire, and sometimes start over with a different stakeholder.

That matters because a stage without an entry rule or exit rule is just a label in the CRM.

What does a sales funnel show?

Take a 70-person fintech company selling reconciliation software to online retailers. Its best accounts have 200 to 1,000 employees, use multiple payment processors, and have a finance or operations leader responsible for fixing settlement errors.

One target account announces a processor migration. A finance director searches for ways to reduce reconciliation mistakes, reads an article from the fintech, then checks the integration page. That account has shown interest. It hasn't earned a sales call just because someone downloaded a guide.

The next evidence might be a request for a processor-specific review. Then a call with the controller. Then technical validation, security review, commercial approval, and a signed contract. Those are useful stages because each one reflects a change in the buyer's behavior or the seller's work.

The usual labels are awareness, interest, consideration, intent, evaluation, and purchase. Use them if they help. Use fewer labels if they don't. The names matter less than the question behind each stage: what has this buyer actually done that proves they're moving forward?

Why teams get the funnel wrong

Most teams put too much weight on activity and too little on evidence.

The fintech might report 1,200 guide downloads in a quarter. Sales might say none of those accounts are real opportunities. Both could be right. A download measures attention. It doesn't prove the company has the problem, has a budget, or plans to solve it.

Here’s a more useful view: 200 accounts download the guide, 45 request an integration review, 18 attend a qualified demo, and 5 enter a commercial evaluation. One becomes a customer.

The problem isn't automatically a lack of leads. Maybe the product doesn't support the processor used by most target accounts. Maybe the security review takes eight weeks. Maybe the demo never shows how exceptions are handled in the prospect's actual workflow.

My view is simple: teams often try to fix funnel problems at the top because top-of-funnel work is easier to report. If qualified evaluations aren't becoming customers, publishing more content rarely fixes the real issue.

Sales funnel vs. sales pipeline

A sales funnel is buyer-centric. It describes how much the prospect understands, how serious the problem is, and what they are willing to do next.

A sales pipeline is seller-centric. It tracks the work required to close the account, such as discovery, technical validation, security review, proposal, legal, and procurement.

The same retailer can be in consideration in the funnel and in technical validation in the pipeline. That isn't a contradiction. The buying group is still judging fit while the sales team is arranging the technical proof.

This distinction prevents bad forecasting. “Proposal sent” doesn't mean the buyer is close to signing. It means someone sent a proposal. The account may still lack an internal owner, a budget decision, or a reason to act this quarter.

How the stages work in a real account

At the awareness stage, the buyer notices a problem or a change in their business. For the fintech, that could be an audit finding, a processor migration, or a new VP of Finance discovering that reconciliation is being handled in spreadsheets. Search content, referrals, and targeted cold outreach can create the first interaction.

Interest starts when someone investigates. They read the integration documentation, look at the product page, or ask a colleague how the problem is handled today. This is where an ideal customer profile keeps the team honest. A 20-person retailer with one payment processor may be curious but still be a poor fit. A 300-person retailer adding a second processor has a credible reason to continue.

Consideration is more practical. The buyer wants to know whether the product works with their systems, what implementation involves, and what it will cost. Give them evidence, not slogans. Show the workflow for resolving settlement exceptions. Provide a processor compatibility table. Share a customer example from a similar retailer. Generic claims tend to stop working here.

Intent appears when the buyer takes a step that carries some risk or effort. They request a demo, ask for security documents, bring in an implementation owner, or ask whether the product supports the processor they are migrating to. A guide download is an interaction. A request for a processor-specific integration review is stronger evidence.

Evaluation is the buying group's attempt to expose risk. Finance, security, legal, engineering, and procurement may all enter. For this fintech, an account should not count as being in evaluation after a demo alone. A better rule might require a completed technical review, an identified business owner, and agreement on the first workflow to implement.

Purchase is the contract signature, but the work doesn't stop there. A signed account that never deploys is not a successful funnel outcome. Track time to first reconciled account, active users, exception resolution time, and whether the customer expands to another processor. Otherwise the team will celebrate contracts that are quietly heading toward churn.

How to build a sales funnel

Start with the account and the trigger. Don't start by adding twelve stages to the CRM.

For the fintech, define the target as online retailers with 200 to 1,000 employees, multiple processors, and a finance or operations owner for reconciliation. Then watch for concrete triggers: a processor change, an audit problem, a funding announcement, or a new finance leader.

Map the buyer's questions to those triggers. Early on, they may ask, “Do we actually have this problem?” Later, it's “Can this work with our stack?” During evaluation, the question becomes “What will implementation disrupt, and who has to approve it?”

Set a rule for every stage. An account might enter evaluation only after technical validation and an agreed use case. It might leave evaluation when the buyer signs, chooses a competitor, delays the project, or confirms that the product cannot support its environment.

Give every active account an owner and a next action. “Follow up next week” is not a next action. “Send the processor mapping and schedule a 30-minute review with the controller on Thursday” is.

The SDR should not be judged only on meetings booked. A meeting with a company outside the ICP inflates the top of the funnel and creates work for everyone downstream. Track qualified meetings, opportunity creation, stage conversion, sales cycle length, loss reasons, and closed revenue.

Which metrics are worth tracking?

Keep the dashboard small enough that someone will inspect it. For each stage, track the number of accounts, conversion to the next stage, time in stage, and why accounts leave. Then cut the data by source, segment, and trigger.

The fintech may find that accounts responding to processor-change outreach convert from qualified evaluation to purchase at 18%, while generic content leads convert at 4%. That should change targeting, outreach timing, and sales capacity.

Don't fix the stage with the biggest number. Fix the constraint. If 40 demos produce two evaluations, improving email open rates is probably wasted effort. Inspect qualification, discovery, and the proof shown during the demo first.