Design stages around buyer commitments
This page starts after a trial or account earns active sales attention. For the earlier handoff, use our trial-to-paid systems guide. The Deal Flow page for SaaS founders shows how the resulting work fits inside the Mautic workspace.
For the pipeline itself, name stages for commitments the buyer has made. A compact multi-seat upgrade sequence might be Qualified upgrade, Evaluation, Technical review, Commercial review, and Won or Lost. These are recommendations, not a preset. Deal Flow lets your team configure ordered stages around its actual process.
- Qualified upgrade: a person has described a team-level need and agreed to a next sales conversation.
- Evaluation: the use case, initial scope, and people involved are becoming clear.
- Technical review: a named evaluator is working through agreed implementation or security questions.
- Commercial review: the buying group is reviewing a defined package, scope, and decision path.
- Won or Lost: the decision and its outcome are recorded, so the deal no longer looks active.
Activation and other product events may inform a decision; they are not buyer commitments or pipeline stages.
Give every open stage entry and exit evidence
A stage label is useful when two founders would move the same deal for the same reason. Write entry and exit rules that name the evidence, who can provide it, and what must be true before the deal advances.
For example, Evaluation could require a stated team use case and an identified champion. It could end when the buyer confirms scope and introduces the person responsible for technical review. Technical review could end when the named evaluator closes the agreed questions or records the remaining conditions. A calendar event alone would not satisfy either rule.
Keep the evidence in a deal note, then use a task for the next action. That separates what the buyer has already done from what your team plans to do. The same principle appears in our Mautic pipeline design guide: stage movement should follow evidence rather than internal activity.
Keep value tied to the current upgrade scope
Deal value should represent the commercial path the buyer is evaluating now. Add an amount and currency when you know enough about the proposed package, seat count, term, or rollout to make the number useful. Until then, leave the uncertainty visible instead of filling the field with a broad account estimate.
Deal Flow stores the amount with confidence, qualification, and expected close details. Revisit those fields when scope changes. A full-team rollout may become a smaller first phase; a monthly discussion may move to an annual term; another department may join. Each change can alter the value or timing even when the stage stays the same.
Value rule: update the deal when the option under consideration changes. The amount supports a decision about attention and timing; it is not a substitute for a quote, invoice, or product-usage record.
During review, ask whether the amount still matches the latest written scope and whether the expected close date matches the buyer’s stated process. A stale number is a work item, not a fact to carry into the next forecast.
Use role coverage to expose stalled decisions
A multi-seat upgrade is one commercial decision with several participants. Deal Flow associates multiple Mautic contacts with the same deal and gives each association a role label. That makes the buying group reviewable without turning each person into a separate opportunity.
The useful labels depend on the purchase. A typical review might look for a Champion who carries the use case internally, a Technical Evaluator who can accept implementation requirements, a Budget Stakeholder who can confirm the spending path, and a Decision Maker who can approve the choice. These are decision roles, not permanent job titles.
Treat a missing role as operational information. A known champion with no technical evaluator suggests an introduction request. A completed technical review with no budget stakeholder suggests a commercial discovery task. Our buying committee guide provides a fuller role map and questions for identifying each participant.
Hypothetical example: follow one multi-seat upgrade
Consider a hypothetical software company where one active user asks about rolling the product out to 25 colleagues. The founder opens a deal in Evaluation, associates that user as Champion, records the proposed 25-seat path, and leaves Decision Maker unfilled. The open role makes the introduction request part of the next action.
The champion then introduces an engineering manager who agrees to review deployment and security questions. The founder adds that contact as Technical Evaluator and moves the deal to Technical review because the named evaluator and review scope now satisfy the exit evidence from Evaluation.
During that review, the buyer narrows the first rollout to 15 seats and brings in a finance lead. The founder revises the deal value to match the smaller current scope, labels the finance contact as Budget Stakeholder, and keeps the stage unchanged until the technical conditions close. When those conditions close and the buyer identifies the final approver, the deal can enter Commercial review with current value and role coverage.
No product event moved this deal. Buyer evidence changed the stage, commercial scope changed the value, and new participants changed the role map. The pipeline records those three changes on one upgrade path.
Turn the three gaps into the next action
Run the weekly founder review as an exception queue. For each active upgrade, look for a stage without current evidence, a value that disagrees with current scope, or a role the next decision requires but the deal does not yet identify.
- If stage evidence is missing, ask for the buyer commitment that would resolve it.
- If value is stale, confirm the package, seat count, term, or rollout now under review.
- If role coverage is incomplete, ask the champion who owns that part of the decision.
- If all three are current, confirm one next task, owner, and date.
Deal Flow keeps tasks, reminders, notes, and activity context with the deal. The purpose is not more record keeping. It is to make the next move visible, complete it, and return to building the product.
Frequently asked questions
Should activation milestones become SaaS deal stages?
Not by default. Activation milestones describe product use. A deal stage should describe observable progress in the buyer's decision, although product activity can supply evidence for that decision.
What evidence moves an upgrade into technical review?
Move the deal when a named technical evaluator accepts a defined review scope and the required questions, documents, and owners are clear. A scheduled meeting by itself is not enough.
When should upgrade deal value change?
Change the value when the commercial path changes, such as a revised seat count, package, term, or rollout scope. Keep the current amount tied to the option the buyer is evaluating.
Which buyer roles matter before commercial review?
The useful roles depend on the purchase, but a multi-seat upgrade often needs a champion, technical evaluator, budget stakeholder, and decision maker. Record the real participants and treat an empty role as a next-action clue.
Ready to review upgrades, value, and buyer roles in one focused pipeline?
See Deal Flow for Your SaaS Pipeline