Pipedrive setup without the blank page

The blank page, and the other blank page

A fresh Pipedrive account is friendly and empty. There is a pipeline with stages in it, a handful of standard fields, and an invitation to import your contacts. Nothing is wrong with any of it. It is also a description of a generic sale rather than of yours, and the account has no way of knowing the difference.

So somebody makes a start. A stage gets renamed, a field gets added because a colleague asked, a second pipeline appears for a product that felt different enough. None of those moves is unreasonable on the day it is made. Together, over a year, they produce the second blank page: an account that filled itself in, where nobody can say why a field exists or which of the three pipelines is the real one.

Both versions have the same underlying condition. The account reflects a series of small decisions instead of one described process. That is what makes the reporting disappointing, and it is why adding a report rarely fixes it.

What you can do yourself

A useful amount, and we would rather say so. Most of the first pass does not need us.

Write the process down before you open the settings. Not a flowchart. A list of the moments where a deal genuinely changes state, in the words your team uses on a call. If two people describe those moments differently, you have found the actual work, and it is not a configuration task.

Name stages after events, not after feelings. A stage should be something that either happened or did not: a meeting held, a quote sent, a decision maker confirmed. Stages named after optimism cannot be audited, and every forecast built on them inherits the mood of whoever last dragged the card. The reasoning is on the stages and probabilities page, and the shape of the pipeline itself on pipeline design.

Add fields last, and add fewer than you want. Each field has to name the report, the filter or the routing rule that reads it. Fields with no reader are the ones that go empty first, and they go empty quietly. That test, and what to do with the fields that fail it, sits on the custom fields page.

Decide who sees what before you invite anybody. Visibility is easy to set on an empty account and awkward to tighten on a full one, because tightening it takes something away from people who had it. Permissions and visibility covers the options.

Where it stops being a settings problem

Three things reliably stall a self build, and none of them is a missing button.

The first is that the cheap decisions are the expensive ones. Renaming a stage in an empty account costs nothing. Renaming it in month eight means deciding what the deals that passed through the old stage were doing, which report they now belong in, and whether last quarter is still comparable. The decisions with the longest shadow are the ones you make on day one, with the least information you will ever have.

The second is that configuration and agreement get confused. The settings screen implies the question is technical. It almost never is. When a team cannot agree what qualified means, no amount of clicking resolves it, and the account ends up with two stages that both mean maybe. Somebody has to run that conversation to a conclusion, and it is genuinely hard to do from inside the team.

The third is the work that does not live in the settings at all. Assignment rules that follow territory or product. Follow up that is created rather than remembered. Anything that has to react to an event on one object by touching another. That is where automation starts, and where a first build usually stops, because the pipeline looks finished long before the account does anything on its own.

What we built for this

At Sales Surge we implement Pipedrive and we build our own software around it, because implementation work kept running into gaps that configuration alone could not close. Setup is the oldest of those gaps, and the one everything else rests on.

Surge Setup is our own product and our own way of doing this work. We map the sales process first, translate it into pipelines, stages and fields, then build the assignment rules, the follow up tasks, the deadlines and the permissions on top. The handover happens on your own records rather than on a demo account, because a walkthrough on sample data teaches people the tool and not their job. It is described on the Surge Setup product page, alongside the rest of what we make at the Sales Surge product overview.

Two things about how we work are worth saying plainly. We do not start again by default. Most accounts we are shown contain a core the team already trusts, and the job is to keep that and remove the layer nobody uses, which is closer to the argument on rebuild versus repair than to a new build. And we deliver in phases with something usable at the end of each, rather than one reveal at the end, which is the method described in the six step page. We are a Pipedrive Platinum Partner and have been in the global top 8 since July 2026, so read the next section knowing exactly what we sell.

When you do not need this

If you sell one thing, in one motion, to one kind of buyer, with a team small enough to fit around a table, the default account plus an afternoon of naming is very likely enough. Structure exists to carry weight. Adding it before there is weight makes the tool feel like paperwork, which is the fastest way to lose the people you need using it.

If you have never worked with a CRM at all, start smaller than this page implies and read starting without a CRM first. Your process will change more in the next six months than any build can anticipate, and a setup built on guesses has to be unpicked later.

And if what you want is one field changed or one automation adjusted, that is support rather than a setup, and buying a setup to get it is the wrong shape of purchase. The honest split between doing this in house and bringing somebody in is on the DIY page, and the rest of what we build, including the parts we tell people to skip, is on the product list.

Questions