How to set up monday.com as a CRM (the structure I use on every build)

Almost every monday.com CRM I have been asked to fix has the same problem. It is not missing features. It has too many.

Someone enthusiastic built it, added a column for every piece of information that might one day be useful, and now the sales team fills in four of them. The pipeline report is wrong because half the deals sit in the wrong stage, and nobody trusts the forecast.

This is the structure I use instead. It is deliberately smaller than what monday.com lets you build.

Start with the decisions, not the data

Before touching a board, answer one question: what decisions does a salesperson make in a normal week?

For most teams the answer is a short list:

• Which deals do I chase today
• What did I promise this person, and when
• Is this deal actually going to close, or am I lying to myself
• What do I hand over when it closes

Every column on your board should serve one of those. If a column exists because “the data might be useful later”, it is a column that will be empty, and empty columns make the whole board look untrustworthy.

One board, groups as stages

The first real decision is whether your pipeline is one board or several. Use one board.

I have tried the alternative on client builds where each stage was its own board, and it fails predictably: moving an item between boards loses its update history, automations get duplicated five times, and reporting requires mirror columns that break the moment someone renames something.

Inside that one board, your groups are your stages:

Group	What it means
Inbox	Came in, nobody has looked properly yet
Qualifying	Talking, not yet convinced there is a real fit
Proposal out	They have a number and are deciding
Closing	Verbal yes, waiting on signature or procurement
Won	Signed, ready to hand over to delivery
Lost	Closed with a reason recorded

Six groups. If you find yourself wanting eight, ask whether two of them are really the same stage with different feelings attached.

Why groups and not a status column

This trips people up, so it is worth being explicit. You can model stages as a status column instead, and keep everything in one flat list. Both work. The difference:

• Groups give you collapsible sections, per-stage counts and totals in the group header, and a drag-between-stages gesture that feels natural. The cost: group changes are slightly harder to automate against and do not appear in the item’s activity log as cleanly.
• A status column is easier to automate, easier to report on, and keeps board views simpler. The cost: your board is one long list, and stage totals need a dashboard widget rather than being right there.

I use groups for pipelines under a few hundred open deals, because the visual grouping is what makes people actually use it. Above that, a status column scales better.

The columns that earn their place

Here is the full column set I start with. Nine columns.

Deal name (the item name itself). Format it as Company: what they are buying. Not just the company name. When you have three deals with the same logo, you will thank yourself.

Owner (People). One person. Not a team. If two people own a deal, nobody does.

Value (Numbers, formatted as currency). One number, the annual or total contract value. Resist the urge to add three value columns for different scenarios.

Close date (Date). The date they said they would decide, not your hopeful guess. This one column is the difference between a forecast and a wish list.

Confidence (Status, three options). Not a percentage. Percentages invite fake precision. Three options:

• Committed means I would bet my commission on it
• Likely means it should land but something could move
• Long shot means it is in the pipeline for completeness

Next step (Text). One short sentence: what happens next and when. This is the single most valuable column on the board and the one most builds are missing. A deal with no next step is not a deal, it is a hope.

Next step date (Date). Drives every reminder automation you will build.

Source (Dropdown). Where it came from. Keep the list short and never let it become free text, or your source reporting is useless within a month.

Contact (Connect boards, linked to a Contacts board). Which brings us to the second board.

That is it. Everything else, notes, files, call recordings, lives in the item’s updates section, not in a column.

The Contacts board

Keep people on a separate board and connect them. A deal is a thing that happens; a person is a thing that persists. When a champion changes company, you want their history to follow them.

The Contacts board stays even smaller: name, email, phone, company, role, and a Connect column back to Deals. Add a Last touched date column and let an automation update it, so you can find people you have gone quiet on.

Automations worth having on day one

Build these five and stop. More automations than this on a fresh board and you will not be able to tell which one caused a surprise.

1. When Next step date arrives, notify Owner. The whole point of the Next step column.
2. When a deal moves to Won, create an item on the onboarding or delivery board. The handover that otherwise happens in a chat message and gets lost.
3. When a deal moves to Lost, require a reason. Use a status column for loss reason and make it part of the move. Loss data is the most under-used asset in most pipelines.
4. When Close date passes and the deal is still open, notify Owner. Stale close dates are how forecasts rot.
5. When a new item is created in Inbox, assign a default owner. Unowned items get ignored.

Notice what is not here: no automation that emails the customer, no multi-step sequences. Those belong in a real sales engagement tool or an integration platform, not in board automations. See what monday.com automations can and cannot do for where that line sits.

The three mistakes I keep undoing

Too many stages. Eight or nine groups means two of them are duplicates and deals will sit in the wrong one. Six is plenty. If sales genuinely has more distinct motions, that is a second pipeline, not more stages.

Probability percentages on stages. A weighted forecast built on made-up percentages is worse than an unweighted one, because it looks rigorous. Use the three-option confidence column and let a human explain the number.

Building reporting before the board is used. Dashboards built on week-one assumptions get thrown away. Run the pipeline for three weeks, watch which columns stay empty, then build reporting on what people actually filled in.

What to do next

Set this up on a fresh board before you migrate anything. Put three real deals in it and run your next pipeline review from it. You will find two things you want to change, and it costs nothing to change them now.

If you would rather start from something already built, the CRM starter board is this exact structure, ready to copy.