Mautic stages: Our September 2026 operating rule for teams

The operating rule is about record identity

A stage makes sense only when the team can name the record moving through it. In Mautic, that record is a contact. The stage can summarize where that person sits in a lifecycle and can support campaign or segment decisions. In Deal Flow, the moving record is a deal. Its stage describes the progress of a particular purchase with its own commercial context.

This distinction prevents one field from answering two different questions. “Where is this person in our relationship?” is a contact question. “What has happened in this purchase?” is an opportunity question. A team can use both answers at once without forcing either one to carry the other’s meaning.

Two tests expose a mixed stage model

First, imagine one contact considering two purchases at the same time: a new implementation and a later training package. The contact has one lifecycle state, but the purchases can move independently. The implementation may be in Proposal while training is still Qualified. Two Deal Flow records preserve those simultaneous truths; each can hold its own stage and optional amount, expected close date, and owner.

Second, imagine one purchase shared by a champion, a budget holder, and a technical evaluator. Three contact records should not become three opportunities. One deal represents the purchase, while contact-to-deal associations label each person’s role. The opportunity can advance once the buying group supplies the required evidence, even though each contact keeps an individual lifecycle state.

Design contact stages around durable person-level meaning

Write each Mautic contact stage so it remains true even when the person is associated with more than one deal. The definition should answer what the organization knows about the relationship with that contact and what lifecycle treatment follows. If a label becomes contradictory as soon as the same person enters a second buying process, it is carrying opportunity state and belongs on a deal instead.

Keep automation intent visible in the definition. A contact-stage change may affect campaign participation or segment membership, so document the trigger, the expected downstream action, and the condition for reversing or advancing the state. That makes the contact lifecycle useful without turning it into a substitute deal board.

Design pipeline stages around observable opportunity progress

Deal Flow supports deal creation, reading, updates, and deletion; multiple pipelines; and configurable ordered stages categorized as open, won, or lost. On the kanban board, a move changes the stage of that deal. The stage definition should therefore describe evidence attached to the purchase: a qualification decision, a completed evaluation, a reviewed proposal, or a recorded outcome.

Give each open stage an entry condition, an exit condition, and an owner for resolving ambiguity. Avoid definitions based on private optimism. If two teammates looking at the deal’s contacts, notes, tasks, and recent activity would choose different stages, tighten the evidence rule. The objective is not a longer stage list; it is a shared decision about what must be true before one opportunity moves.

Use mapped stage sync as a bridge, not a merger

Deal Flow supports mapped bidirectional synchronization between deal stages and Mautic contact stages. That connection is useful when a specific opportunity milestone should intentionally change contact lifecycle state, or when an approved contact-stage change should place a related deal into a mapped pipeline stage.

Mapping does not erase the record boundary. Review every mapping against the two tests above. Ask what happens when one contact has two active deals and what happens when one deal has several associated contacts. If the desired result is unclear in either case, keep the stages separate and handle the transition through a reviewed workflow. Synchronize decisions the team can explain, not labels that merely sound similar.

Apply the rule to your September stage review

1. List each Mautic contact stage and finish the sentence, “This says the contact is…”
2. List each Deal Flow stage and finish the sentence, “This says this purchase has…”
3. Test one contact with simultaneous purchases and one purchase with several contacts.
4. Confirm that each deal stage has observable entry and exit evidence.
5. Review every bidirectional mapping and write down its intended person-level effect.

After that review, configure the ordered open, won, and lost stages each pipeline needs. Keep optional amount, close date, and owner values on the opportunity they describe. Associate the relevant contacts and label their roles. The result is a model that can answer lifecycle and revenue questions without asking one stage field to mean both.

Frequently asked questions

What is the difference between a Mautic contact stage and a Deal Flow pipeline stage?

A Mautic contact stage represents one contact’s lifecycle state and can guide campaign or segment decisions. A Deal Flow pipeline stage represents the progress of one specific opportunity.

Can one Mautic contact have more than one opportunity?

Yes. Create a separate deal for each simultaneous purchase so each opportunity can carry its own pipeline stage, amount, expected close date, and owner.

Can several contacts share one Deal Flow opportunity?

Yes. Associate several contacts with the same deal and label their roles so the shared purchase stays one opportunity while each person remains a distinct Mautic contact.

Should every deal stage synchronize with a Mautic contact stage?

No. Map stages when a deal milestone should intentionally change contact lifecycle state. Deal Flow supports bidirectional synchronization for mapped stages, but the two stage models should keep separate jobs.