Lifecycle Stage Architecture for Long-Cycle B2B Pipelines

Most lifecycle models we are asked to fix carry eleven or twelve stages, and three of them describe the same moment from a different department's point of view. For a quote-to-purchase-order cycle running six to nine months, six stages is the working ceiling. Past that, nobody can say out loud what moves a record forward, sales stops updating it honestly, and the forecast becomes a number the CFO has already learned to discount. What gets decided: This is a set of written definitions, not a diagram. Each stage gets an entry criterion that is an observable event: NDA countersigned, technical drawing received, sample shipped, PO number present in the ERP. Each gets exactly one role permitted to make the move. If a criterion reads that they seem interested, it is not a stage, it is a note field. Each stage also gets an exit rule and a maximum age, because a stage without a clock is where deals go to become quietly immortal. Dormancy is modelled separately: In industrial sales and in staffing, a large share of open opportunities are asleep rather than lost. Capex was deferred, the requisition was frozen, the tooling budget moved to next year. The common move is to park these in a Nurture stage, which corrupts stage conversion rates and inflates pipeline value at the same time. We put dormancy on its own property with a wake date and a reason code, keep those records out of the pipeline arithmetic, and route them back in when the date arrives. Objects before stages: Roughly half of what arrives described as a lifecycle problem is an object problem. A recruitment firm running candidates and client vacancies through one deal pipeline will never get either report right; that needs two pipelines and a placement object joining them. A furniture manufacturer selling both to retail chains and to specifiers needs one pipeline with a channel property, not two pipelines someone reconciles by hand each quarter. We settle the object model first, and we will say so if that turns out to be the whole engagement. What you receive: A stage definition document your sales director can enforce without us in the room. The field and property changes written as a migration plan against your HubSpot or Salesforce instance, naming which historical records get re-stamped and which are left alone, with the reason. The reporting layer that follows from the model: stage conversion, age in stage, dormancy re-entry. And a list of existing automations that should be deleted, because the model now carries what they were compensating for. Not included: We do not build the automations here. Routing, SLA escalation and enrichment are separate engagements and belong after the model is settled, not alongside it. We do not migrate between CRM platforms, we do not write sales methodology, and we do not run enablement sessions beyond the handover walkthrough. Who this is not for: Teams whose sales cycle closes in under three weeks. The value here comes from long cycles where stage discipline compounds; a fast transactional pipeline does not need this much structure and we will tell you so on the call. Companies with no named owner for the CRM after we leave, because a lifecycle model without a custodian degrades within two quarters. And anyone hoping to hear that their current eleven stages are fine. We take this work on expecting to remove several, and that argument is easier to have before the invoice than after. Working languages are English and Czech. Documentation is written in English unless the operating team works in Czech.