You’ve signed off the budget. The CRM is chosen. Someone on the team has admin access and a fresh, empty account, and the first screen asks you to name your pipeline stages.
So you name them. Something like: New, Contacted, Qualified, Proposal, Won, Lost.
Then it asks what qualifies a lead. And what a contact record should store. And which of your forms should create one. And what a “customer” is, exactly — the person who booked the call, or the one who paid. And whether that revenue number should come from the CRM or the payment processor, because they’re about to disagree with each other for the rest of time.
None of those are software questions. Every one of them is a strategy question, arriving disguised as a setup wizard, usually landing on whoever happens to be holding the mouse.
That’s the gap the Foundation Sprint exists to close.
A CRM build is a decision list wearing a technical costume
Here’s what usually happens when a company skips straight to implementation.
The build goes fine. Technically, everything works — the forms submit, the automations run, the dashboard populates. Six months later nobody trusts the numbers.
The reason is almost never technical. It’s that a hundred small definitional decisions got made at speed, by different people, without a shared reference. One person set up a “Qualified” stage meaning they replied to us. Someone else has been using it to mean they can afford us. The lead source field was left as free text, so it now contains “LinkedIn”, “linkedin”, “Linked In”, “LI campaign” and “Sarah”. The purchase event fires when someone clicks the booking button rather than when they pay, which means the ad platform has spent four months getting very good at finding people who click and don’t buy.
Every one of those is reversible. All of them are expensive to reverse, because by then real data is sitting on top of the wrong structure.
The CRM didn’t cause any of it. The CRM did what it was told. It just had nothing to be told.
What the Foundation Sprint actually is
Three to four weeks. Five phases — tracking, positioning, customer journey, channels, and metrics. One operational reference at the end that you hand to your team, share with a future hire, or build directly against.
It’s not a brand exercise, and it isn’t a deck. The output is closer to a specification: this is who we sell to, this is what qualifies one of them, this is the path they take from first visit to paid, these are the channels that reach them in what order, and this is what we measure to know whether any of it worked.
Some of that reads like marketing strategy. It is. But look at what it produces, and the point becomes clearer.
The four things your CRM cannot decide for you
- What your pipeline stages mean.
Not what they’re called — what they mean. A stage needs an entry criterion and an exit criterion, or it isn’t a stage, it’s a folder. Foundation maps the customer journey end to end and defines what puts a deal into each stage and what takes it out. Without that, your pipeline is a set of labels people move deals between when it feels right, and your forecast is a feeling with a number attached.
- What each field is allowed to contain.
A CRM property is only useful if every value maps to a controlled vocabulary. Free-text fields defeat categorisation — you can type anything into them, so eventually everyone does, and no report can group across them.
But you can’t write a controlled vocabulary out of thin air. The list of valid values for “customer type” is your ICP work. The list for “primary trigger” is your triggers playbook. The list for “loss reason” is your objections, mapped. Every dropdown in a well-built CRM is a strategic decision that was made earlier and then encoded. Skip the earlier part and you get free text by default, because there’s nothing else to put in the list.
- What counts as revenue.
This one is quietly the most expensive. You need to decide which specific event represents money actually changing hands, as distinct from intent to spend money — a booking click, a form start, a proposal sent. Then you need one agreed source of truth for that number across your website, your CRM and your payment records.
It sounds obvious until three dashboards give you three figures and nobody can say which is right. Getting it wrong doesn’t just distort reporting. It misdirects every pound of paid spend, because ad platforms optimise toward whatever you tell them success looks like.
- Which CRM you actually need.
Choosing between HubSpot, Salesforce and Pipedrive is a question about your team, your budget, your complexity, and how partner data and consumer data need to move through the system. All of which are Foundation outputs. Choose first and you’re sizing a tool for a business you haven’t finished describing — usually overbuilding for a stage you haven’t reached.
We ran this on ourselves, and it found something
BLND’s own Foundation Sprint ran as a pilot before we sold one. Same five phases, same audit, applied to us.
The tracking audit found the usual mix — internal team traffic sitting in the analytics data and inflating everything, key events built but never published live, UTMs applied inconsistently across channels.
Then it found the quiz.
Our diagnostic quiz had nineteen submissions. Eighteen were us, testing it. The nineteenth was a real person, from outside the company, who had answered every question and asked for their results.
They never got them. The submission created no contact record, triggered no task, alerted nobody. It landed in a spreadsheet that had no owner, and it sat there.
Nothing was broken. Every individual piece worked exactly as built. There was simply no system connecting the piece that captured the lead to the piece that would have done something about it — because nobody had ever specified what should happen in between.
That’s what a missing foundation looks like from the inside. Not an error message. A quiet, correctly-functioning gap.
What Foundation deliberately doesn’t do
Worth being straight about the boundary, because it’s the part that makes the sequence honest.
Foundation does not build your infrastructure. At the end of ours, the CRM still wasn’t built. The revenue events still weren’t live. The server-side tracking still wasn’t configured. Our three customer profiles were still hypotheses — well-researched, drawn from real market evidence, and not yet proven by a single conversion.
That isn’t a shortfall in the sprint. It’s the correct shape of the output. Foundation locks the strategy and the target state — what the system needs to do, and what every part of it means. Building the thing that runs it is the System Sprint. Proving the hypotheses is what happens once traffic starts moving through it.
The alternative is worse and much more common: build the infrastructure first, then discover which assumptions were wrong once there are eighteen months of data structured around them.
Where this leaves you
If you’re about to implement a CRM, you’re about to make forty decisions whether you plan to or not. The only real choice is whether you make them deliberately, in one place, before the build — or one at a time, under pressure, encoded permanently into a live system by whoever is closest to the keyboard.
Foundation is three to four weeks of making them on purpose.
Then the CRM build stops being a strategy exercise conducted through a settings menu, and becomes what it should have been from the start: configuration. You already know what the stages mean. You already know what the fields contain. You already know what counts as a sale.
That’s the whole argument for the sequence.
Already clear on your strategy and ready to build the system underneath it? [Here’s how CRM implementation works across our three Sprints →]
Not sure which one you need? [Take the quiz] or [book a Deep Dive].
