Before you buy a new CRM, check what it's standing on

Jacek Szafader Jacek Szafader August 31, 2026

Why most CRM and ERP rollouts start with the wrong question, and what to do about it

It started with a simple request. A manufacturing company, two brands under one roof, calls with a clear expectation: we want a new CRM because the current one is outdated, and what we care about most is a better proposal editor, something like Word, because our proposals run twenty pages and it’s a pain to insert photos into them. Sounds reasonable. The client knows what they want. Just quote it and build it.

And yet the longer we talked, the clearer it became that this was a request for a hammer when the problem was never a nail. This piece is about how easily we look in the wrong place, and why sometimes the most valuable thing a good implementation partner can do is say: hold on, before you buy what you’re asking for, let’s check if you even have something to build it on.

The client almost always describes a solution, not a problem

That’s not a criticism. It’s natural. When something in our daily work is painful, we describe it through the tool we happen to be using. Since the proposal is written in an editor and the editor is clunky, the conclusion writes itself: we need a better editor. The trouble is, that’s a description of the symptom, not the disease. And underneath, exactly like an iceberg, sits what nobody names out loud at first.

Rys. 1. To, o co klient prosi na wejściu, to zwykle czubek góry lodowej. Prawdziwy ciężar leży pod wodą.

Fig. 1. What the client asks for upfront is usually the tip of the iceberg. The real weight sits below the surface.

The real pain is one floor down

A few questions were enough to change the story’s protagonist. This company’s proposals aren’t ready-made price lists, they’re engineering projects: the end client wants, say, a cooling system, an engineer selects components, calculates, assembles them. Every proposal is a little different. Each one lives for weeks, and the bigger projects drag on for six months to a year. And that’s where the real pain showed up.

It was never about the editor. It was about project memory and version chaos.

Picture the scenes that play out weekly in companies like this. A salesperson prepares a proposal, the client asks for a change, then another, and after a month there are a dozen versions of the same document, each under a different name, some sitting on a laptop’s local drive. The salesperson leaves the company, and the knowledge of which version was actually agreed with the client leaves with them, along with any idea of where the file even is. A new employee takes over the account and starts from zero, because the whole negotiation history lived in their predecessor’s head. And sometimes two different proposals with two different prices go out to the same client, because two versions of the file were living in parallel.

That’s not a text editor problem. It’s a problem of process, and of where a company’s knowledge actually lives. Here’s a scene from the other side of the business: a technician has a full set of equipment documentation on their laptop, serial numbers, repair histories. The laptop gets lost, or the drive fails, and none of it can be recovered. No editor, however beautiful, fixes that.

The client asked for a more convenient Word. What they actually needed was a place where company knowledge doesn’t disappear along with a laptop and a departing employee.

Why a modern CRM without a foundation misses the point

This is where it gets to the heart of it. A modern CRM, something like Dynamics 365 Sales, draws almost all its value from being integrated with a cloud-based work environment. Cloud email means a message from a client lands against their record automatically. A meeting transcript flows into the CRM without anyone retyping it. Files sit on a shared SharePoint drive with version history, not on someone’s desktop. Take that foundation away, and all of these advantages simply disappear.

In the conversation we started with, it turned out this company runs on local servers, and email sits on classic mail clients, outside the cloud. And this is the point where it has to be said plainly, even if it’s uncomfortable: moving to a Microsoft CRM when you’re not already in the Microsoft cloud somewhat misses the point, because you lose most of what the rest of the ecosystem gives you. It’s like upgrading to a faster car without knowing how to drive. The car is quicker, but that’s not what decides whether you actually get there.

It helps to lay this out in order. The foundation is a cloud-based work environment, the so-called Modern Workplace: email, files, shared workspace, one place where documents actually live. Only on top of that does a shared data model and a 360-degree customer view make sense. The next floor up is a modern CRM or ERP. And only at the very top sit today’s trendy AI agents and predictive tools. Whoever starts at the top is building a tower with no foundation.

Fig. 2. Order matters. No bottom, no top: AI and prediction only work when there’s a foundation underneath.

Data is an advantage, not decoration

There’s a second, more serious reason the foundation isn’t a whim. A world where the manager runs service operations from memory and the salesperson keeps a client’s history in their head is slowly coming to an end. Not because these people are bad at their jobs, but because the competition is starting to play a different game. It’s building an advantage on data.

The simplest example of what a lack of data actually costs is painfully concrete. A technician drives out to service equipment for a client who hasn’t paid their lease in months. They drive out because service can’t see the financial status, which sits in a completely different system, and checking it would mean emailing accounting. The result: the cost of the trip, the labor, and the debt collection that follows, all because customer data lived in silos instead of one shared view.

Fig. 3. The difference isn’t cosmetic. Reactive service puts out fires. Predictive, data-driven service puts them out before they start.

Let’s go further, because this is where it gets genuinely interesting. Service can be managed reactively: the phone rings, there’s a ticket, someone drives out, fixes it after the fact. Or it can be managed predictively. If equipment has communication modules and sends status data, telemetry shows something drifting into a warning state, and the technician shows up before the failure happens. The client has no downtime, their factory keeps running. Companies are building their edge exactly on this, on gathering and using this kind of data. This isn’t science fiction, it’s the current stakes of the market.

Today, putting out fires well isn’t enough. The winner is whoever has the data to avoid them in the first place.

Silos cost real money

It’s worth seeing this as a picture, because it’s the most common starting point. On one side, a separate finance and warehouse system, next to it a separate service system, plus local email, spreadsheets on laptops, files on a drive, somewhere a database tying part of this world together. Systems sit next to each other, and information moves between them by hand and by email. There’s no single source of truth about the client.

Fig. 4. From a tangle of systems and manual handoffs to a shared data model and one customer view.

And here’s an important caveat that disarms the resistance to change: the goal isn’t one giant application that replaces everything. It can still be a set of tools. The difference is that underneath, there’s one data model, consistent business rules, and one view of the client that ties together sales, service, contracts, finance, and telemetry. The client stops being scattered across systems and becomes one continuous story.

System names vary, and that genuinely doesn’t matter for the principle itself. Some companies run on large SAP-class platforms, some on Comarch Optima, others on Subiekt, others still on Exact or industry-specific ERPs. Sometimes the heart of the company is a custom-built system written a decade ago, genuinely innovative in its day, now a dead weight because nobody remembers how it works inside and it’s hard to integrate with anything. The rule stays the same no matter the label: as long as data sits in separate boxes, the company pays for it every day, it’s just rarely sees that bill directly.

Two paths, and an honest conversation about money

Back to the original request for an editor: it can be fulfilled literally. You can build an elaborate proposal configurator that lets someone click together any document with full editing freedom. But a system like that is a project running into hundreds of thousands, and at full complexity, over a million złoty. For many companies, that’s using a cannon to kill a fly, because their real problem, project memory and version control, can be solved for far less.

The second path is simpler, and usually smarter. A sensible CRM with a service module for a dozen or so users is a relatively low cost, and most of the need gets handled by good process design and a cloud-based work environment. The proposal is created on a shared drive, with version history, attached to the client’s record, tagged with a few key fields in the system. And most importantly, a good advisor should say this outright, even if for a moment it works against a bigger quote. Sometimes the best recommendation is: don’t buy what you’re asking for, let’s solve the problem cheaper and smarter.

Before you implement a CRM or ERP, check the foundation

If you recognize your own company in this story, start not by choosing a system, but with a few honest questions about the foundation. Five questions that, in a few minutes, say more than a long RFP ever could.

Foundation question
Why it matters
Do we work in the cloud, or do email and files live locally?
Without a cloud environment, a modern CRM loses most of its value.
Do we have one view of the client, or is data siloed?
Silos mean manual work, wrong decisions, and real losses, like a trip out to a debtor.
Will project knowledge survive an employee leaving?
If the history lives in people’s heads and on their laptops, the company loses it with every staff change.
Does our equipment generate data, and are we using it?
Machine data is the difference between putting out fires and predicting them.
Are we looking for a feature, or solving a process?
A feature patches a symptom. A well-designed process removes the cause, often for less money.

One last thing: the partner’s role is sometimes a Copernican turn

The conversation we started with ended differently than it began. The client came in looking for a more convenient editor and walked out with an entirely different way of thinking about the whole project. No friction, no hard sell, just a different question in their head: not which system to buy, but whether there’s a foundation worth building on at all.

Because you can buy the most expensive CRM on the market and land right back in the same problems, if people are still working off their laptop desktops. Implementing a modern CRM or ERP without the cloud, without one data model, without changing habits, is like getting into a faster car with the same poor driving skills. And that’s why a good partner’s job is sometimes less about writing a proposal and more about pulling off a small Copernican turn: showing that the center of gravity was never where it seemed to be at first.

Start with a foundation check, not a system choice

Start with a foundation check, not a system choice. It’s the cheapest step, and it saves you the most.