Model Multi-Phase Deals with Separate Acceptance Gates

One commercial relationship can contain several decisions

A buyer may authorize discovery without authorizing implementation. Implementation may be commercially approved but unable to start until a data owner resolves a dependency. Expansion may remain an option even after the first phase succeeds. A single opportunity total can conceal all three distinctions.

Model the phases explicitly. The purpose is not to create more CRM records by default. It is to keep each scope, authorization state and delivery gate visible enough that a colleague cannot mistake a possible later phase for approved work.

Separate purchase authorization from delivery acceptance

Each phase needs at least two questions. First, what evidence authorizes this phase's commercial scope? Second, what evidence accepts its completed deliverable? Add start prerequisites where relevant. A signed discovery order does not establish that discovery has been completed or that the implementation design has been accepted.

You can maintain this model in a structured note or an approved CRM design. If separate records are used, link them to a shared project identifier and define which record contributes to each report. For example, HubSpot's deal-property documentation describes its “Deal split added” field in terms of a split between users, not a delivery-phase model. Verify feature meanings before choosing a configuration.

Completed phase model for project J-28

This fictional service project uses invented US-dollar amounts to demonstrate scope handling. It is not accounting guidance, a real contract or a claim about a CRM's native features.

• Project envelope: J-28, reporting-process redesign. Commercial owner Dana; delivery owner Ellis. The project envelope links the phases but contributes no additional amount to the phase-level total.

• Phase A, discovery: US$6,000 for interviews and one approved workflow map. Commercial status: accepted under the example's verified order A-01. Start prerequisite: interview participants confirmed. Deliverable gate: designated buyer reviewer accepts the map or records required corrections. Current state: work authorized, prerequisites met, deliverable not yet accepted.

• Phase B, implementation: Proposed US$18,000 for one team's approved design. Commercial status: proposal only, separate buyer acceptance required. Start prerequisites: Phase A's map accepted, data owner named and implementation scope reconfirmed. Deliverable gate: agreed test cases reviewed by the designated buyer owner. Current state: not authorized; no start date committed.

• Phase C, second-team rollout: Indicative US$9,000 option, not an accepted purchase or current delivery reservation. Entry gate: buyer chooses to evaluate the second team after Phase B evidence is available. Scope and price must be reconfirmed. Current state: optional future scope, not active delivery work.

• Commercial summary: US$6,000 accepted scope; US$18,000 proposed subsequent scope; US$9,000 indicative option. US$33,000 describes the sum of these unlike-status figures, not an accepted project value.

• Next review: Ellis reports Phase A's deliverable status. Dana reviews Phase B only after the relevant design and buyer decision are available. No automatic conversion of Phase A completion into Phase B authorization.

Follow the dependency when scope changes

Suppose discovery reveals that the intended source system cannot supply a required field. The workflow map can still document that finding, but its acceptance does not make the original implementation proposal feasible. Phase B returns to scope review. The buyer may choose a narrower implementation, additional preparation or no further work.

This is a meaningful successful discovery outcome even when it reduces later revenue. Do not mark the whole project lost merely because the optional rollout disappears, and do not keep all phases active to preserve the original total. Update each phase according to its actual decision.

A phase payment is not necessarily a phase option

There is an important counterexample: one accepted scope may be billed in installments tied to milestones. Three invoices do not automatically mean three separate purchasing decisions. Inspect the actual commercial structure with the responsible owner. Model optional phases only when the evidence supports separate scope decisions, not simply because payments occur at different times.

Likewise, keep forecasts, invoicing and recognized revenue under their own approved definitions. This model describes scope and gates; it does not determine financial treatment.

The decision-reason guide helps preserve why work stops or remains unresolved. At phase level, a precise reason prevents one technical dependency from being misread as rejection of the entire relationship, while keeping unauthorized later work out of delivery planning.