Mautic for SaaS: A Founder’s Trial-to-Paid Sales Stack

Why document this boundary in September 2026

The Deal Flow 0.9.4 changelog, dated June 10, 2026, lists that version as current and records a fix to task-queue filtering when a pipeline is selected with “All owners.” That gives the weekly pipeline review below a specific current-release behavior to verify.

The release does not decide record ownership. As of September 7, this is the boundary I would use for a founder-led SaaS sales process: the SaaS application reports product events, Mautic holds people and engagement context, Deal Flow holds qualified sales work, and the billing tool holds the financial and entitlement record.

Write that boundary down before connecting systems. It prevents a trial, an opportunity, and a subscription from becoming three conflicting versions of the same thing. It also gives a small team a clear answer when a field differs: check the system that owns it, then pass only the useful summary to the other layers.

1. Keep trial signups as Mautic contacts

Create or update a Mautic contact when someone starts a trial. Send the identity, consent, lifecycle, and product-context fields your segmentation and follow-up actually need. Keep the contact even when the person stays self-serve, converts without sales help, or lets the trial end.

This contact step belongs to the integration between the SaaS application and Mautic. Deal Flow does not detect a trial signup by itself. Its documented inbound webhook can look up or create a contact while creating or updating a deal, but that is appropriate only after your own event definition says deal work should begin.

Do not open a deal merely because a contact exists. That would mix product adoption with active revenue work and make the pipeline harder to read.

2. Define the signal that opens sales work

Choose a small, observable set of gates. A founder might open a sales conversation when a buyer asks for annual terms, brings in several stakeholders, starts security or procurement review, or requests an enterprise evaluation. These are operating choices, not a preset supplied by Deal Flow.

Record the gate in the handoff instructions. The person or automation making the handoff should know which contact is involved, what happened, why human follow-up is useful, and who owns the next action. A clear gate stops low-intent trials from crowding the same view as active buying work.

3. Configure one conversion pipeline

Create one named pipeline for qualified annual and enterprise conversations. Keep its ordered stages tied to buyer progress, with a compact sequence such as Qualified conversation, Evaluation, Commercial review, Won, and Lost. Those names are a recommendation; your team configures the pipeline and stages.

One pipeline gives a founder a single place to inspect current conversion work without turning the billing ledger into a sales board. If the business later develops a materially different sales process, revisit the design. Do not multiply pipelines merely to mirror plans or trial states that another system already owns.

4. Create the deal and make the next action visible

When a conversation crosses the gate, create a Deal Flow deal in the conversion pipeline. Set its owner and stage, and add an amount and expected close date when the conversation supports them. The deal now represents that specific sale; the Mautic contact still represents the person.

Associate the contacts involved and assign relationship-specific labels such as Champion, Decision Maker, or Technical Evaluator. Deal Flow supports multiple contacts on one deal, but your team selects the people and their roles. It does not infer the buying committee.

Add a task for the next action and use notes for context that must travel with the opportunity. Move the stage when buyer progress changes, not when someone sends another message. For the broader contact-to-opportunity handoff, use the Mautic sales workflow guide.

5. Keep subscription records in the billing tool

The billing system should remain authoritative for subscription status, invoices, payments, plan state, and entitlements. Those records answer what is active, what was charged, what was paid, and what access should exist. A deal stage answers a different question: where a commercial conversation stands.

When the buyer converts, close the sales work according to your process and let the billing event remain the financial record. Send a concise billing summary back to Mautic only when it supports segmentation or customer communication. Avoid copying a full ledger into contact fields or treating a Won deal as proof that payment succeeded.

Run one short founder review each week

Review the conversion pipeline by stage and owner. For every open deal, confirm the next task, the stakeholders involved, the commercial amount when known, and the evidence for the current stage. Close stale work or record what must happen next.

Then sample the boundaries: trials without sales signals should exist as contacts without deals; qualified annual or enterprise conversations should have deals; and active subscription facts should agree with the billing tool. That review catches routing errors without asking one system to perform every job.

Frequently asked questions

Should every SaaS trial signup become a Deal Flow deal?

No. In this workflow, every trial signup remains a Mautic contact. Create a Deal Flow deal only when a human sales conversation has defined commercial scope, such as annual terms, multiple stakeholders, procurement, or an enterprise evaluation.

What does one SaaS conversion pipeline track?

Use it to track qualified annual and enterprise conversations through founder-defined stages. It is a configured workflow, not an automatic SaaS preset.

What should stay in the billing tool?

Keep subscription status, invoices, payments, plan state, and entitlements in the billing tool. Send only the summary fields needed for segmentation or follow-up into Mautic.

Can one Deal Flow deal include multiple contacts?

Yes. Deal Flow lets a team associate multiple Mautic contacts with one deal and assign relationship-specific role labels. The team chooses the contacts and roles; Deal Flow does not discover them automatically.