B2B Sales Funnel for Long Deals: CRM Stages and Fields

Why forecasts for long deals often end up ‘gut-feel’\n\nLong B2B deals rarely follow a straight line. Planning horizons differ: sales needs a quarter close, the buyer budgets for a year, and legal works “when they get to it.” Add several client stakeholders (IT, security, procurement, finance), and the forecast starts to drift.\n\nIn these funnels schedule shifts are normal: the tender was postponed, requirements approval dragged on, the decision maker changed, the project was put on hold. If CRM records these inconsistently across the team, the B2B sales funnel for long deals becomes a collection of personal expectations.\n\nWhen data is missing, decisions are made on feelings. That usually leads to one (or more) outcomes:\n\n- revenue is promised “to meet the plan,” then misses are explained by postponements;\n- production or implementation is overloaded “based on the forecast,” but demand doesn’t materialize;\n- it’s unclear where a deal is actually stuck, and intervention comes too late;\n- discounts are offered “just in case,” while the real risk wasn’t price.\n\nA good forecast answers simple questions: what amount, by what date, with what probability, and what will be done next. In infrastructure projects (for example, delivering servers plus integration) the key question often isn’t “will they buy” but “has the architecture approval been completed and who signs the final specification.”\n\nCollect only what helps management. Typically you need: the next step and date, the expected decision date, the amount (preferably target and confirmed), reason for delay, and the role of the current contact. Everything else quickly becomes “pretty fields” that are filled formally and obscure the picture.\n\n## Specifics of a long B2B cycle: what to consider before setup\n\nIn long B2B sales a decision is almost never made by one person. Usually there’s an initiator, technical experts, security, legal and a final budget committee. So the funnel for long deals should reflect control points where you gain (or lose) the right to treat the deal as forecastable, not a list of “conversations.”\n\nThe cycle often includes a tender, pilot or testing, several approval rounds and changing requirements. Tie stages to events and artifacts that can be checked, not to subjective labels like “client interested.”\n\n### Documents that typically move a deal\n\nDecide in advance which materials in CRM count as proof of progress. In long projects these are usually a requirements document or questionnaire, a specification or configuration, a commercial offer (with version and date), a committee protocol or decision letter, and a contract or contract draft under review.\n\nAlso separate: what is still a lead and what is a deal. Requests like “send price list” or “recommend a model” aren’t reasons to create a full deal with a forecast.\n\n### Where to draw the line between a lead and a deal\n\nIn practice a deal begins when the client has a clear procurement process and the next step is agreed. Useful criteria:\n\n- a client-side owner and responsible person are identified;\n- the budget contour is clear (at least a range);\n- there is a decision date or procurement stage (tender, request for proposal, committee);\n- requirements are agreed (at least a draft of a requirements document or specification).\n\nOne more nuance: in projects that combine hardware and services (delivery, implementation, support), don’t mix everything into one line without structure. Hardware can be approved earlier, services later. That affects timings and forecasted amounts differently.\n\n## How to choose funnel stages so they reflect reality\n\nIf CRM stages are labeled “In progress” or “Thinking,” the forecast will almost always be gut-feel. For long deals what matters is not what the manager did, but what the client decided and what objectively changed.\n\nAs a rule of thumb, 6–10 stages are usually enough. Fewer stages mean loss of control (too large “chunks”). More stages lead to inconsistent understanding and people moving deals between stages for the sake of it.\n\nA good stage is one verifiable result. If the result can’t be named in one sentence and confirmed by an artifact (email, protocol, version of requirements, invoice), the stage quickly becomes a dumping ground.\n\nSigns the stages are defined correctly:\n\n- each stage is linked to a client decision (e.g. “Requirements agreed” rather than “Meeting held”);\n- clear entry and exit conditions exist;\n- there is one measurable outcome (document, approval, procurement status);\n- stages are mutually exclusive (a deal can’t honestly be in two at once);\n- names are self-explanatory.\n\nA small example for a long infrastructure project: instead of “Negotiations” break it into “Requirements collection confirmed,” “Commercial offer received by client,” “Budget confirmed,” and “Procurement process started.” This way the funnel shows progress rather than activity.\n\nA useful check: for each stage ask “what must become true on the client side for us to move forward?” If the answer sounds like a manager’s action, rewrite the stage.\n\n## Step-by-step: how to define stages with the team\n\nGather sales, presales and a leader and map a typical deal path: from first contact to payment and closing documents. Describe how it usually happens, not how it should ideally be.\n\nThen take 10–20 closed deals from the last 6–12 months and mark the moments after which the deal noticeably changed: budget approved, decision maker engaged, requirements received, security checks passed, contract agreed. These turning points become the templates for stages.\n\nKeep names simple and consistent so a new manager understands them without explanation. A bad sign is labels like “working” or “under review” when it’s unclear what is being reviewed.\n\nNext define rules for each stage:\n\n- entry conditions;\n- what constitutes the result (exit);\n- who owns the movement and the data (owner);\n- which artifact confirms the fact (email, protocol, commercial offer, requirements).\n\nExample: in a servers-plus-implementation project the stage “Requirements confirmed” might have entry — received requirements or configuration list from the client; exit — agreed specification and list of requirements for timelines and service; owner — the sales manager with presales support.\n\nFinally agree on data hygiene: how often to update the next-step date and amounts, and who checks deals without movement weekly. Without this, even well-defined stages become formalities.\n\n## Stage entry/exit and required fields: how to record agreements\n\nTo stop the funnel for long B2B deals being gut-feel, each stage must have clear entry and exit rules. Then managers won’t move deals by “feeling” and the team will have a shared understanding of a deal’s actual status.\n\nAn entry criterion is a check: what is known and recorded before a deal receives a new status. An exit criterion is an event on the client side after which it makes sense to move forward. The exit is not a manager action (“called”), but a fact (“client confirmed participants,” “requirements received,” “commercial offer agreed”).\n\nTie minimal required fields to the decisions you want to forecast. At qualification stage company, contact person, need and approximate timeframe are usually enough. Requiring “configuration, specification and contract” at this stage is a sure way to create empty fields and fake data.\n\nA working rule is “not saved — not moved.” Apply it only where skipping a field breaks the forecast and next work: amounts, dates, decision makers, and a concrete next step.\n\nA commonly justified set of required fields for long projects (including hardware delivery and integration, as in cases at GSE.kz) includes:\n\n- planned amount and currency;\n- planned date of the client’s next decision (tender, budget defense, approval);\n- funding source (budget, grant, own funds);\n- client procurement stage (requirements collection, request for prices, tender);\n- client contact and role (initiator, user, decision maker, procurement).\n\nIf a field doesn’t affect stage transition or the forecast, keep it optional or collect it later.\n\n## Fields you actually need to manage a long deal\n\nIn long B2B sales CRM easily becomes “the manager’s notes.” For a stable sales forecast fields must answer: what happens next and what can derail the deal.\n\nFirst define the “skeleton” of the deal. Without it reports by amount and date will jump around:\n\n- amount and currency (and what’s included);\n- planned close date (and the basis for it);\n- owner and team (if presales or engineers are involved);\n- current stage;\n- date of next step (meeting, demo, approval).\n\nNext, client roles are critical. In a long cycle decisions aren’t made by one person; without a roles map deals stall in approvals. Minimally record: initiator, future user, decision maker, procurement and security/IS.\n\nThird group — contents. Fill so any colleague understands what is being bought and why: subject of the deal, configuration or composition, volume, key requirements, competitors (if known). In a server infrastructure project it’s useful to note needed rack/servers, certification constraints and expected delivery time.\n\nFinally, commercial and process fields: discount, margin, payment terms, delivery and warranty or service help spot where a deal may become unprofitable or delayed. For dates, usually “last contact date” and a simple overdue-risk flag are enough to keep momentum.\n\n## Loss reasons: how to describe and collect data without chaos\n\nIf loss reasons are recorded “however it’s convenient,” the funnel for long B2B deals quickly becomes unmanageable. The same situation turns into ten different formulations in CRM, making analysis hard.\n\nStart by separating three scenarios: “not qualified” (initially not our client), “lost to competition,” and “postponed” (project frozen or delayed but may return). These are different cases and should not be mixed.\n\n### How to write reasons so they work\n\nKeep the list short (usually 10–15) and write labels unambiguously without emotion. Instead of “client changed their mind” use “priorities changed (project cancelled).”\n\nHelpful categories to start from:\n\n- not qualified: no budget, wrong segment, not our profile;\n- lost to competition: price, delivery times, brand or origin requirements;\n- postponed: funding frozen, tender delayed, leadership change;\n- internal stop: missed deadlines, no presales resource;\n- technical stop: critical requirement not met.\n\nTo make data useful, add a few short mandatory clarifications to the reason: competitor (if any), decision factor (what mattered most for the client), the key loss cause (one item) and “what could have been done differently” (one sentence).\n\n### When and how to record it\n\nRecord the reason immediately when moving to “lost” or “postponed” and do it by the rules. For example: if the project went to a competitor because of delivery times — that points to one improvement path. If a specific certification was needed, actions differ.\n\nUse these reasons for improvement, not blame: update qualification checklists, strengthen presales, adjust commercial offers, or gather requirements earlier. Then a “loss” becomes a source of improvements rather than CRM noise.\n\n## How to set up the sales forecast: amounts, dates and probability\n\nTo make forecasts for long deals less gut-feel, agree on three things: which amount you forecast, the date, and why you trust the probability.\n\nTrack two dates in each deal. First — planned close date (when you expect to sign or receive the order). Second — expected date of the client’s next decision (tender commission, requirements approval, meeting with IT director). The second date helps detect delays quickly and shows that the deal is still alive.\n\nProbability is better not set manually “by feeling” but tied to rules. Two common approaches work: fixed probability per stage or rising probability as criteria are met (written requirements received, budget confirmed, procurement plan exists).\n\n### Forecast categories\n\nTo avoid mixing hopes with commitments, divide the forecast into three buckets:\n\n- Commit — we are willing to be accountable for closing on time.\n- Best case — chances are good but risks remain.\n- Pipeline — early stage, more data than certainty.\n\nFor partial closes and phased deliveries (e.g., servers first, then workstations and implementation) track amounts in parts with separate dates. That way only what truly closes this quarter appears in the forecast.\n\nUpdate the forecast on a schedule, not mood. Weekly, review only facts that changed: the client’s next decision date moved, the scope changed, a new competitor appeared or procurement condition changed, a stage criterion was met (or missed), or X days passed with no client activity.\n\n## Example scenario: a long infrastructure deal\n\nImagine a deal: a regional hospital plans to upgrade servers and workstations. Supply includes rack servers, PCs, licenses, plus implementation, migration and training services. The contractor must pass the client’s internal approvals and procurement procedure. In these deals “almost agreed” can last months.\n\nThe deal progresses through stages and at each stage the team records concrete facts, not feelings. For example:\n\n- Qualification: client type, source, objective, budget estimate, date of decision or committee. Probability is low until budget and decision maker are confirmed.\n- Survey and requirements gathering: survey results, list of sites, responsible architect, infrastructure risks. Probability rises with a statement of need or protocol.\n- Commercial offer and calculation: offer version, amount, margin, delivery time, payment plan. Probability depends on whether specifications and timelines are agreed.\n- Approvals: status with legal, IS and finance, who blocks, next step date, competitors. The field “next action and date” is critical here.\n\n- Procurement and tender: procedure type, publication date, local content requirements, contract conditions. Don’t raise probability without confirmation of admission.\n\nExample loss: the client chooses a competitor due to delivery time. If “target commissioning date” and “timing criticality (high/medium/low)” were mandatory on the commercial offer stage, the timing risk would have been visible earlier and the team could propose partial delivery or another scenario.\n\nFor a manager, useful reports include funnel by stages, forecast by close date, reasons for delays (where approvals hang), and a list of deals without a next step. This quickly shows where help is needed and which deals live only in the manager’s head.\n\n## Common mistakes when configuring a funnel for long deals\n\nLong B2B deals rarely fail from one event. More often the issue is a pretty funnel that isn’t maintained daily. Then the forecast develops a life of its own.\n\nTypical mistakes:\n\n- Too many stages and fields. If a manager must fill 15 items for one transition, updates get postponed and CRM falls behind.\n- Stages not tied to client decisions. Labels like “processing,” “in progress,” “under review” say nothing. Better record facts: “requirements received,” “added to budget,” “tender date set.”\n- Probability set by feeling. Without rules percentages rise after a “good call” and fall after a pause. Define criteria for probability changes.\n- No next-step date and control deadlines. A deal can hang for months: not lost, but no progress. The minimum saving measure: next step, its date and an owner.\n- Loss reasons chosen at random. If options are too many and similar, analytics becomes noise. Better 6–10 clear reasons and the rule: record the reason immediately while details are fresh.\n\nA simple test: take a typical project involving IT and procurement (e.g., server delivery and infrastructure implementation). If you can’t understand in 30 seconds from a single card what the client decided, what remains undecided and what will happen next week, simplify the funnel and tie it to client decisions.\n\n## Short checklist: is the funnel ready for a reliable forecast?\n\nIf your B2B forecast for long deals still rests on feelings, the problem is usually discipline, not the formula.\n\nCheck the basics:\n\n- Stages are named plainly and the team understands them uniformly.\n- Entry and exit conditions are described for each stage.\n- Each stage has a minimum set of required fields: amount, planned close date, next step, expected result of that step, key contact.\n- Every deal has one owner and a next-step date. If no date, the deal should not be counted as an “active” forecast item.\n\nAlso check losses and postponements:\n\n- Reason is chosen from a short list (5–8 items) and details go into a single comment field.\n- Reasons are factual: “no budget,” “lost due to delivery times,” “chose incumbent supplier.”\n\nFinal check — forecast by rules:\n\n- Probability is tied to stage (or clear conditions), not a manager’s mood.\n- Reviews happen regularly: weekly for active deals and monthly for the long tail.\n- Any change to amount or close date is recorded with a reason (short pick + comment) so later you can see what drove the forecast movement.\n\n## Next steps: how to implement rules and make them stick\n\nFor the funnel to stop being a set of “approximate percentages,” it’s not enough to describe stages and fields — you must make upkeep a team habit. Start with a short feedback cycle and lock the rhythm.\n\n### Plan for the next month\n\n1) Let the funnel run for 2–3 weeks and see which fields are most often left blank. Typically gaps appear in next-step dates, budgets and delay reasons.\n\n2) Hold a 60–90 minute session with the team to decide which CRM required fields actually influence the client’s decision and the forecast. Remove or make optional everything else.\n\n3) Add quality control to the regular rhythm: a weekly funnel review (15–30 minutes), check the next step for every active deal, and a monthly cleanup of loss-reason lists.\n\n4) If you sell to the public sector or large corporations, separate tender and approval steps. For these deals the fact of passing gates (submission, admission, protocol, contract) matters more than a percentage.\n\n5) For infrastructure projects (PCs, servers, data centers, integration) compare practices with companies that handle both manufacturing and integration. For example, GSE.kz (gse.kz) runs projects end-to-end — from specifications and supply to implementation and support — which helps design data structures and reporting around the real process.\n\n### How to cement rules without pressure\n\nCreate a short cheat-sheet “what counts as filled” with examples. For instance: “next step date — a specific meeting or client deadline, not ‘call back in a week.’”\n\nEnsure CRM helps, not hinders: required fields should only turn on at the relevant stages. Then the manager doesn’t spend time entering data for the sake of it, and the leader gets a forecast that’s not just gut-feel.