Mautic Sales: A One-Screen Setup for a Two-Person Team

Why I would start this small now

For this September 6 recommendation, I rechecked the shipped Deal Flow documentation. It documents named pipelines with ordered stages, owned deals, a kanban board, and deal-linked tasks. Those surfaces support a compact model; they do not mean a small team should configure everything on day one.

The two-person example is hypothetical, not a product minimum. It represents a founder and one sales teammate who need shared answers: which sales are active, where each stands, who owns the next action, and when it is due.

Begin with one pipeline for one real process

Create one named pipeline with ordered stages that describes the sales process the team actually runs. “New Business” says more than “Main,” but the name is an operating choice, not a product requirement.

Keep the stage sequence short and describe observable progress. Discovery, Evaluation, Decision, and clear outcome stages are one possible starting set. The useful constraint is that both people apply the same definitions.

Do not create a pipeline for each person. Deal ownership answers who is accountable; the pipeline describes the process. A second pipeline earns its place when the team truly runs a second process with a different stage sequence, not when work is divided between two colleagues.

Give each deal a recognizable title, current stage, and owner. Add amount and expected-close date when the pair can maintain them. Stage answers where the sale stands; owner answers who moves it forward.

Treat the board as the shared starting screen

Deal Flow’s documented kanban view organizes deal cards by stage and supports moving a deal between stages with drag and drop. The cards provide compact context including amount, owner, health, and buying-committee count.

When I call this a one-screen setup, I mean one shared starting view, not a promise that every card fits inside every browser window without scrolling. The pair begins on the board, opens an individual deal when it needs more context, and returns to the board to understand the pipeline.

During a shared review, confirm each active deal’s stage, owner, and next action. Move a card when the sale has progressed, not because an even-looking board feels healthier.

Reporting comes later; first make ownership, stages, and follow-up dependable.

Put one accountable follow-up on every active deal

The documented task record belongs to a deal and can carry a title, status, priority, due date and time, reminder value, owner, and description. My operating rule is narrower: every active deal gets one concrete next action with an owner and a realistic due date.

“Follow up” is too vague. “Send revised scope to Dana” states the action and its finish line. The Mautic sales tasks and follow-ups guide draws a useful distinction: a task records what happens next, while a note preserves context.

Do not assume that a due date or reminder value sends an alert. The published documentation defines those fields, not automatic delivery, recipients, timing, or channels. Add notification behavior only from a documented and tested contract for the installed version.

Use the same short operating loop

At the team’s chosen review cadence, use this sequence:

1. Open the pipeline board and scan the active stages.
2. Confirm the stage and owner for each active deal.
3. Open the deal and check its next task.
4. Update that task so its action, owner, and due date are clear.
5. Add a note when a decision needs durable context.
6. Return to the board and move the card only when the sale has progressed.

The exact cadence depends on the sales cycle. The important part is that both people update the same deal-linked source of follow-up work. If either person keeps a private version elsewhere, the board can no longer serve as the shared starting point.

What I would deliberately not configure yet

I would not add a second pipeline, an oversized stage taxonomy, speculative custom fields, or separate workflows for each person. I would not build automation around a manual process the pair has not yet followed consistently. I would not make a reporting dashboard the primary work surface before owners, stages, and tasks are dependable.

Do not fill every task field because it exists. Use priority, descriptions, and reminder values when the team agrees what each means and will keep it current.

Let repeated work justify growth. Add a field or rule when the same missing detail keeps blocking decisions, and consider another pipeline when a genuinely different process appears. Until then, one process, one board, clear ownership, and one next action per active deal are enough.

Frequently asked questions

What is the smallest working Mautic sales setup for a two-person team?

Use one named pipeline with a short ordered stage list, assign an owner to each deal, attach one concrete follow-up task with an owner and due date, and review the work from the pipeline board.

Does Deal Flow require a two-person sales team?

The shipped documentation does not define a two-user minimum. This post uses a hypothetical two-person team to show how deal ownership and task ownership can make coordination explicit.

Does one-screen mean every deal always fits in one browser window?

No. It means the kanban board is the team’s shared starting view. The documented board organizes deal cards by stage; the number of cards and the browser size determine how much scrolling is needed.

Should every task use every available field?

No. For the smallest operating setup, record a concrete title, owner, and due date. Add priority, a description, or a reminder value when the team’s working agreement gives those fields a clear purpose.