Five Mautic Sales Numbers a Founder Reads Each Week

Use one completed week and one review snapshot

For my September 5, 2026 review, the event period begins at 2026-08-29 00:00 and ends just before 2026-09-05 00:00 in the team’s chosen reporting timezone. The snapshot is taken on September 5 in that same timezone. Movement needs a time boundary; pipeline amount and stalled deals describe the snapshot.

This read follows our Mautic sales guide; the sales reporting guide explains snapshots and movement in more detail. I checked every product surface below against shipped Deal Flow documentation on September 5.

1. Pipeline amount by stage shows current exposure

Start with the full recorded deal amount in each stage. The Pipeline Summary widget shows deal count and total value per stage, while the Stage Coverage report groups current deal count and amount by stage. I read the stage amounts, note where value is concentrated, and compare the underlying deals with the previous review note.

This is a snapshot, not movement. A higher Proposal amount could reflect an arrival, exit, or value edit. Use it to choose a stage to inspect; use the records to explain the change.

2. Deals moved comes from dated stage-change events

For this weekly number, count distinct deal IDs with at least one stage-change audit event inside the half-open event window above. Deal Flow’s stage-move documentation says a move triggers a stage-change audit event. The documented audit record carries an event type, prior and new values, a timestamp, and a user reference, as summarized in the deal timeline and audit guide.

The shipped documentation does not define a built-in weekly moved-deals aggregate. Build this derived tally from the dated events outside the report dashboard if needed. Count distinct deals when the question is “how many deals moved?” Count events separately if the question is “how many moves occurred?” A deal that changed stage twice belongs once in the first reading and twice in the second.

3. Stalled deals are a native days-in-stage reading

The native At-Risk Deals report lists deals beyond configured days-in-stage thresholds and sorts the more severe state first. The dashboard also offers an At-Risk Deals widget for the same attention queue. Both surfaces are documented under reports and metrics and dashboard widgets.

Record the count at the September 5 snapshot, then open the named deals. Days in stage identifies an aged stage, not the cause. Check stage accuracy, owner, next task, and recent context before acting.

4. Compare expected close dates with the prior review

Each deal has an Expected Close field. Compare its current value with the value captured in the prior weekly review record, then count a slip when the current date is later. Audit history may corroborate the change when an entry clearly identifies Expected Close and supplies comparable prior and new dates; the shipped documentation does not define a field-specific audit filter.

The shipped release notes document an audit log that tracks every deal change with user and timestamp. The documentation does not define a built-in slippage counter, so the saved weekly value is the comparison baseline. Keep the deal IDs beside the count, and inspect any record without comparable dates instead of forcing it into the total.

5. Win rate needs the period printed beside it

The documented report formula is won deals divided by won plus lost deals over the period. Use the period the report displays or defines and copy that label beside the result. The public documentation does not state that a saved seven-day report filter is available.

If a separate weekly rate is useful, document the outcome records and timestamp rule used, label the result as derived, and apply the half-open interval above. The shipped documentation does not define which timestamp assigns an outcome to a period.

If no deals reached either outcome, record that the period had no closed outcomes instead of displaying a percentage. That keeps an empty denominator distinct from a measured result.

Keep the five-line reading beside its definitions

I record the snapshot time, event-period dates, five results, and the deal IDs that explain movement or exceptions. The repeatable order is current amount by stage, distinct deals moved, stalled deals, later expected-close edits, then period win rate. It gives the founder a compact operating read without pretending every number comes from one report.

Then ask which deals changed the stage balance, which stalled records need a decision, why a close date moved, and what the outcomes teach. Visible boundaries keep next week’s comparison consistent.

Frequently asked questions

Which five Mautic sales numbers should a founder read each week?

Read pipeline amount by stage, distinct deals moved during the period, stalled deals at the review snapshot, expected-close dates moved later since the prior review, and win rate with the period shown beside it.

Where do pipeline and stalled readings live?

Pipeline Summary and Stage Coverage show current count and amount by stage. The At-Risk Deals report and widget surface deals beyond configured days-in-stage thresholds.

Does Deal Flow calculate weekly deals moved and close-date slippage?

The shipped documentation does not define a weekly moved-deals aggregate or an expected-close slippage counter. Count distinct deal IDs with at least one dated stage-change audit event for movement. For slippage, compare each current Expected Close value with the prior weekly review record; use audit history only when it clearly identifies the field and comparable dates.

How do I calculate weekly win rate?

Use won divided by won plus lost for the period the report displays or defines, excluding open deals. If you calculate a separate weekly rate, label its timezone and half-open event window.