The first call with a vendor brings a simple offer: three modules, a clear price, a fast rollout. By the third call, the scope has already doubled. Three modules become eight, one integration becomes five. Instead of “start small and grow,” the offer now includes a full system meant to solve everything: sales, marketing, support, loyalty, board reporting. The client is thrilled. And completely lost.
This pattern repeats too often to be a coincidence. It's a sales process.
Here's the sentence I hear almost every time: “But they told us we needed it.”
No, they didn't know what you needed. They knew what they could sell you.
Companies don't stall on CRM projects because they lack a specification. They stall because they hand that job to the platform's salesperson. His bonus grows with deal size. Your success grows with clarity. Neither of them will align those two goals for you.
This doesn't happen to companies in trouble. It happens to companies growing fast enough that Excel and disconnected tools can no longer keep up. That's a good problem to have. But the speed itself is the trap: once a company feels pressure to act now, it adopts the first framework offered instead of building its own.
It isn't the salesperson's job to define your process. It's to sell as much of the system as possible. He sees your growth as an opportunity - a company with budget and a decision-maker on the call, not one with a formal specification. It's far easier to pitch everything the platform can do than to ask what you actually need. Confuse the two and you pay twice. Once for licences you never use. Once for the months your team spends wrestling with a system that wasn't built for it.
PMI, the US project management association, found in its research that 47% of failed projects miss their goals because of inaccurate requirements management. Not because of the technology. Not because of the budget. Because no one said, at the start, exactly what the system had to do.
Panorama Consulting surveys companies every year, right after they finish rolling out a business system. The data is for ERP, not CRM. The logic of any rollout is the same, though - whether it's manufacturing or sales and marketing. In their 2026 report, one in four projects ran over budget. Nearly one in four missed its deadline. The most common reason for the overrun? An unexpected need for extra technology, traced back to the wrong system choice or architectural gaps no one saw coming at the start.
The most tangible example, though, isn't a statistic. It's a court filing.
In 2019, Hertz sued Accenture for $32 million over a failed website and mobile app overhaul. The launch date slipped three times. The code, according to Hertz, was “specific to the Hertz brand in North America.” That meant it couldn't even be reused for sister brands Dollar and Thrifty - let alone for markets outside the US.
It sounds like a technical detail. In reality, it's a question that should be settled on day one of the project, not one that surfaces halfway through it. Which brands and which markets does the solution actually need to work for? The claim came to $32 million, and the dispute dragged on for years.
Your project probably won't end up in court. The logic still holds. Anything you didn't write down in advance becomes an expensive surprise halfway through the project.
At FrodX, before we ever propose a platform, we run a workshop. Together with the client, we map their processes - not the features they want, but the decisions they currently make by hand. Who in the company decides where a lead goes today. What happens when a customer misses a third payment in a row. Where data gets stuck in Excel today because no one passes it on.
Only then does a specification exist. And only then does the platform choice follow from it - not the other way round. It sounds slower. In practice it's faster. The company never has to go back to the start after discovering the system was built for someone else, not for them.
The fix isn't complicated, just uncomfortable, because it means work before the work. Before you even pick up the phone, set aside an afternoon. Map three to five processes where money is actually leaking today - not all of them, just those. For each one, write down who decides what, and by what rule. Even if that rule exists only in one person's head, and has never been written down anywhere. If those processes span sales, marketing, and support at once, bring someone from each function into that exercise. A specification written by only one of them almost always misses what the other two need. Only once you're holding that document should you call the salesperson. Hand him the specification. Not the question “what have you got?”
A specification written by the salesperson answers the wrong question - “everything this platform can do,” not “what your company actually needs.” The fix isn't to distrust every salesperson you meet. It's to walk into the first call already holding the answer to the second question.
The platform was never the problem. There's only one question that matters: who, right now, is writing the specification for the project already underway at your company - you, or the salesperson waiting for your call?
igor.pauletic@frodx.com
P.S. If someone can tell you, within the first hour of the first call, exactly how many modules you need, that isn't a sign they understand your business. It's a sign they haven't listened long enough to know.