Pipelines & Boards

Boards and Pipeline Mode

A board presents records from a datastore as cards in columns, where the column is a field on the record. Moving a card changes that field.

Where to find it

Architect Panel → Commercial:

• Boards & Pipeline — the console — build and work boards
• Pipelines — the underlying board definitions

Architect Panel → Data:

• Datastores — the datastore a board is built over

What a board is configured with

• The datastore it displays.
• The status field — which field becomes the columns.
• The title field — what each card shows.
• An ordering field, and a field controlling what else appears on the card.
• Maximum cards per column.

That is enough for a working board over anything with a status: tasks, applications, repairs, tickets.

Pipeline mode

Switching a board into pipeline mode turns it from a task board into a sales pipeline. It adds three field mappings:

• Amount field — the value of each record.
• Close date field — when it is expected to conclude.
• Owner field — who is responsible.

With those, the board can weight and total its columns rather than merely counting cards, and stages gain probability and forecast meaning.

Why it is one mechanism rather than two

A sales pipeline is a board whose columns happen to be sales stages. Building it as a mode on the general board rather than as a separate feature means any staged process can become a pipeline — and a pipeline is not restricted to a datastore called Opportunities.

Choose the status field carefully

It should be a field with a small, controlled set of values. A free-text status produces a column per distinct spelling, which is how boards become unusable.

If your status field is free text, fix that before building the board.

Set the card limit deliberately

A column with hundreds of cards is a list, not a board. The limit keeps the view readable; if a stage genuinely holds hundreds of records, that is usually a sign the stage is doing too much or nothing is being closed out.

Moving a card is a data change

Worth stating plainly: dragging a card edits the record's status field, which is audited like any other change and subject to the same permissions. Somebody who cannot edit the field cannot move the card.

Start without pipeline mode

Get the board working first — right datastore, sensible columns, readable cards. Turn on pipeline mode once that is right, because the three extra field mappings are easier to reason about on a board you can already see.

Worked example

A team builds a board over their Opportunities datastore with the stage field as columns and the opportunity name as the title. Once it reads well, they enable pipeline mode and map value, expected close date and owner. The board immediately totals each column by value rather than count.

Recommendations

• Use a controlled-value field for columns, never free text.
• Build the board first, then enable pipeline mode.
• Consider pipeline mode for any staged process, not only sales.
• Keep card limits low enough to stay readable.

Configuring Stages

In pipeline mode each stage carries more than a label. These settings are what turn a board into a forecast.

Where to find it

Architect Panel → Commercial:

• Boards & Pipeline — the console, where stages are configured
• Pipelines — the board definitions

What a stage holds

• The value it matches in the status field, and a readable label.
• A probability — the likelihood of winning from this stage.
• A forecast category.
• Won and lost flags.
• A sort order — the left-to-right sequence.

Probability

Each stage's probability weights the value of everything in it, so the pipeline can be totalled as a weighted figure rather than a raw sum.

Set these from your own history, not from instinct. Most organisations overstate early-stage probability considerably — if a third of your qualified opportunities close, the qualified stage is 33%, however optimistic the team feels.

A pipeline weighted with honest numbers is a forecast. Weighted with hopeful ones it is a wish list that senior people will plan around.

The won and lost flags

These mark the terminal stages. They matter because they tell the system which records have concluded, which is what makes conversion rates and stage history meaningful.

Mark them explicitly. A pipeline where nothing is flagged as won cannot tell you your win rate, and every stage looks permanently full.

Always have a lost stage

Teams sometimes leave lost deals in their last active stage rather than moving them, because it feels like admitting defeat. The effect is a pipeline that only grows and a forecast that is nonsense.

Make losing explicit and easy, and if you can, record why — that is the most useful sales data most organisations never collect.

Forecast category

Groups stages for reporting — the usual split being what is committed, what is upside and what is early. It lets a manager report a commit figure separately from a weighted total, which are different questions.

Keep the stages few

Five or six. Every stage is a judgement somebody must make about every deal, and a ten-stage pipeline produces cards that sit in the wrong stage because moving them accurately is more work than anybody will do.

The test is whether each stage has a clear entry criterion somebody could apply without asking.

Do not change stages casually once running

Stage history is recorded against stage values. Renaming or removing stages makes historical comparison harder, so get the set right early and change it rarely.

Worked example

A team runs five stages: Qualified (20%), Proposal (40%), Negotiation (70%), Won (100%, won flag) and Lost (0%, lost flag). The probabilities came from two years of their own outcomes, which put Qualified considerably lower than the team had assumed. The weighted forecast has since been within about 10% each quarter.

Recommendations

• Set probabilities from your own history.
• Always flag won and lost stages.
• Make losing explicit and record the reason.
• Five or six stages, each with a clear entry criterion.

Working a Pipeline

A pipeline is only as good as the discipline behind it. The configuration takes an hour; the habits are what make the numbers mean anything.

Where to find it

Architect Panel → Commercial:

• Boards & Pipeline — the board itself

Architect Panel → Activity:

• Activity Log — who changed a value or a close date

Move cards when reality changes

Not at the end of the month, and not in preparation for a review. A pipeline updated before a meeting reflects what people want the meeting to show; one updated continuously reflects the business.

Close dates are the first thing to rot

The commonest pipeline failure is a mass of opportunities whose close dates have quietly passed. They inflate the pipeline, they distort every weighted total, and everybody learns to ignore the figure.

Make reviewing past-dated opportunities a weekly habit: each one moves forward with a real new date, or moves to lost. There is no third option, and allowing one is how the pipeline stops being trusted.

Every opportunity has an owner

An unowned card is nobody's job. The owner field exists to make that visible, and a pipeline review should start by looking for blanks.

Do not skip stages

A card jumping from the first stage to the last tells you the stages do not reflect how work actually happens, or that somebody is tidying up after the fact. Both are worth knowing — and both are visible in stage history.

Value should be the real number

Optimistic values are as damaging as optimistic probabilities, and harder to spot because they look like data rather than judgement. Where a value is genuinely uncertain, use the realistic figure rather than the best case.

Review the board, not a report

A weekly look at the board itself — where cards are bunched, what has not moved, what has no owner — surfaces things a summary hides. A stage with twenty cards and no movement in a month is the most important thing on the screen, and it does not appear in a total.

Watch for the qualification stage filling up

Early stages that grow without draining usually mean qualification is not happening. Cards enter and nobody wants to be the person who marks them lost. That is a management conversation rather than a configuration change.

Permissions let you narrow the view

Where salespeople should see only their own accounts, use row-level access rather than a board per person. One pipeline with restricted visibility keeps reporting whole while giving each person the view they need.

Worked example

A sales manager starts each Monday on the board: three opportunities with past close dates are either re-dated or lost, one card with no owner is assigned, and a bunching of eleven cards in Proposal prompts a question that turns out to be one person's workload. The weekly forecast is produced afterwards, from a pipeline that is already true.

Recommendations

• Clear past close dates weekly — forward or lost, nothing else.
• Never allow an unowned opportunity.
• Review the board itself, not just a total.
• Use row-level access rather than a board per person.

Stage History and Velocity

Every time a record changes stage, the move is recorded: which stage it left, which it entered, when, how long it spent there, and who moved it.

Where to find it

Architect Panel → Commercial:

• Boards & Pipeline — the pipeline that generates the history

Architect Panel → ERP - Trading & Analytics:

• Analytics — reporting over the accumulated history

What is recorded

• The board and the record.
• The stage moved from and to.
• When it entered and exited.
• Days in stage.
• Who changed it.

It accumulates automatically. There is nothing to switch on and nothing for anybody to fill in.

Why duration is the useful number

Conversion rates tell you where deals are lost. Durations tell you where they stick — which is usually a different stage and a more fixable problem.

A stage with a high conversion rate and a 40-day average is not working well: those deals close eventually, and the delay is capital, capacity and forecast accuracy.

What to look at

• Average days per stage — where does time actually go?
• The distribution, not just the average — a stage averaging 12 days made of mostly-3 and a few-60 is two different processes.
• Backwards moves — a card returning to an earlier stage means something was misjudged, and a pattern of it means the entry criteria are unclear.
• Time to won versus time to lost — if losing takes longer than winning, you are spending your most time on deals you do not get.

The most valuable question

How long does a deal you eventually lose spend in the pipeline before you admit it? In most organisations the answer is uncomfortable, and it is the single best argument for qualifying harder.

You can only ask it because losing is an explicit stage with recorded history.

Use it to set expectations

Once you know a typical deal spends three weeks in Proposal, a deal sitting there for eight is visibly stuck rather than a matter of opinion. That turns pipeline reviews from judgement into observation.

It also validates your probabilities

Stage history plus won and lost flags gives you the actual conversion rate from each stage. Compare that against the probabilities you configured, and correct them. Most pipelines are set up once with estimated figures and never revisited.

Report on it properly

The history is a datastore like any other, so Analytics can report over it — average days by stage, by owner, by period. Build that once and it answers the same questions every quarter.

Worked example

Six months of history shows deals averaging 9 days in Qualified, 31 in Proposal and 6 in Negotiation. Proposal is the constraint, and the cause turns out to be waiting for a technical sign-off nobody owned. Assigning that step cuts the average to 12 days. Separately, the data shows only 22% of Qualified deals are won against a configured probability of 40% — so the forecast had been overstated by nearly half.

Recommendations

• Look at durations, not just conversion.
• Check the distribution, not the average alone.
• Compare actual conversion against configured probability and correct it.
• Measure how long losing takes.