When Excel Is the Glue in Your Systems, You Have a Problem

Every founder has a spreadsheet they would rather not show their CRM vendor.

It is probably called something along the lines of Pipeline_v4, Renewals_Q3 or Board_numbers_FINAL. It sits on one person's desktop, gets updated by hand on a Sunday evening, and it is the version of the truth the leadership team actually trusts and leans on.

The instinct is to treat this as a discipline problem. The team is not updating the CRM properly, we need better routines, we need to enforce data entry more carefully. This is almost always wrong. Nobody keeps a spreadsheet alive just for fun. When a spreadsheet like that exists, it does something no other system in the company does, and that makes it the most honest diagnostic tool you have.

So the question is not how to get rid of it, but rather what it is telling you. There are three possible answers, they have almost nothing in common, and one of them is not really about your CRM at all.

Run this test first: "If your spreadsheet was deleted tonight, could you rebuild it tomorrow morning from the CRM alone, without asking a single colleague?"

If the answer is yes, you have the cheapest of the three problems. Everything you need is already in the system, and the spreadsheet holds no new information at all, only a different presentation of it.

The typical case: you want monthly recurring revenue split by who won the account, with churned customers stripped out. Every one of those facts sits in the CRM, but the report builder gives you deal value by owner, not recurring revenue by owner over time. So you export two lists, join them on customer name, add a month column and build a pivot table. Next month you do all of it again.

This does not take a couple of hours, it eats a whole day a month. Fortunately it is not a fault in the CRM, only a reporting change. Spend an hour with someone who works at the CRM company and ask whether the report can simply be built. Often it can, and nobody has asked yet. This is the one case where the answer is not an entirely new CRM.

If you could not rebuild the spreadsheet from the CRM alone, you need to look at the columns the CRM has no home for. This is the most common problem in companies that have outgrown a generic CRM. The system can hold a version of your process, but not the whole of it.

The symptoms are recognisable once you know what to look for:

1. A picklist used for something other than its name, because your team put it to another use.
2. A notes field doing real structural work, because there is nowhere else to put the thing that decides what happens next.
3. A step in the real process with no equivalent in the system, so it lives in a spreadsheet column and in the head of the person who owns it.
4. New hires who need a person, not documentation, to understand how the pipeline actually works.

It also shows up in the shape of the business itself.

"We have seen a number of examples over the years where the CRM only fitted one specific type of deal, or only part of what the company actually sells, so everything else had to be handled in Excel", says Andreas Lundmark, COO at DealJourney. "There are also companies where certain deals never get entered at all. Someone just adds them to the spreadsheet by hand at the end of every month."

Whatever the reason, the consequences are the same three every time. Correcting the data by hand takes time you should not be spending. Traceability disappears, because the reasoning behind a number sits in a file only one person owns. And that goes straight to measurability.

The last one is the dangerous one. A slow process is visible, and somebody will eventually complain about it. A confident decision built on three quarters of the full picture is not visible at all, and nobody complains, because everyone believes the number.

There is an even worse version of all this, which is when the system cannot be adapted even if you pay for it. Leadway, a Norwegian call centre, asked their previous CRM vendor for a change to their SMS setup and were quoted 40,000 kroner for it. "That settled it. We started looking around for something else that same week," says Tønnes Klungland, Managing Director and Partner at Leadway.

The test: are you storing information the CRM has no field for, and no way to create one? Then you will not configure your way out of it. Either the tool adapts to you, or you keep paying the tax for a system that does not fit.

The third diagnosis looks different. The spreadsheet is not holding information the CRM lacks. It is holding information from four systems at once.

The tell is where the columns come from. Deal value from the CRM. Delivery status from the project tool. Open tickets from the helpdesk. Invoiced amount from the accounting system. Someone pulls each of them, lines them up by customer name, and builds the only view that shows what is actually happening with a customer, and does it in Excel.

That person is your integration layer. A human being, joining data by hand, on a schedule, with the error rate you would expect from someone who has to pull and sort data out of four systems.

In Salesforce's seventh State of Sales report, a survey of 4,050 sales professionals across 22 countries including Norway, Sweden and Denmark, the average seller spends 40% of their time actually selling. The rest of the time goes somewhere else, and a good deal of it goes on assembling data from several systems.

This is also the diagnosis founders most often confuse with the previous one. You go out looking for a better CRM when your CRM may be perfectly fine. The problem is not inside any single system. It is in the space between them, and in the missing integrations.

There was never anyone who decided to have several systems. Sales needed a pipeline, so someone chose a CRM. Support was drowning in email, so someone chose a helpdesk. Delivery needed to keep track of the work, so someone chose a project tool. Finance needed invoicing. Each of them was a sensible choice, made by a capable person, solving a real problem at a point when the company had bigger things to worry about.

Nothing went wrong, and yet the same customer now exists five times, and the five copies contradict each other. The company name is spelled two ways. The renewal date in the CRM is from before the contract was extended. Support does not know this customer renews in three weeks. Sales does not know there are four open tickets. That is the real cost, not the licence fees, even if those pile on top of it all.

This is not a marginal problem. In the 2026 Database Strategies and Contact Acquisition Benchmark Survey, roughly half of organisations now report having a single source of truth for their sales and marketing data. That is the good news. It also means the other half do not. Two years earlier, 57% said their customer data sat in manual Excel sheets, alongside the CRM, the analytics tool and the marketing platform.

In the same Salesforce survey, 51% of sales leaders using AI said disconnected systems were slowing their AI initiatives down. If you are hoping AI will eventually take some of the admin off your team, fragmented data is what stands in the way. A model that sees a quarter of the customer will give you answers about a quarter of the customer.

Consolidating everything is too simple an answer. Some separation can be right. A better test is this one:

"Does this system need to know who the customer is and what they pay?"

If the answer is yes, it probably should not be a separate system. Support needs to know, because whether a customer pays 200 euro a month or 4,000 changes how you answer the ticket. Renewals need it. Onboarding needs it. Invoicing obviously needs it. So yes, quite a lot of this ought to talk to each other, and therefore belongs in one system.

Your codebase does not need it, and neither does your design tool. An internal board tracking your own roadmap does not. Those can live wherever the team wants them.

For subscription businesses the test cuts unusually sharply, because everything that matters revolves around one object: the subscription. What it costs, when it renews, how it has changed, who is using it, whether they are happy. Sales, onboarding, support, renewals and invoicing are not five subjects. They are five views of the same subject at different points in time.

There are cases where "best of breed" genuinely wins. If one function has requirements deep enough that a specialised tool is noticeably better, and that function does not need to be connected to the customer record continuously, you should keep the specialised tool. A support team handling tens of thousands of tickets with complex routing and response time rules will get more out of a specialised helpdesk than a general one.

So the honest version of consolidation is not one system for everything. It is one system for the customer, with specialised tools around it for work that genuinely is a different discipline.

Switching also has a real cost. Migration takes time, people have to learn things over again, and the gain does not arrive in week one. Anyone who says otherwise is selling.

The spreadsheet is not necessarily the main problem. It is the most useful evidence you have about what your systems are failing to do, and that answer has been sitting on one person's desktop the whole time.

Open it. Look at the columns. Ask where each one came from.

This is the problem we built DealJourney around. Sales, subscriptions, invoicing, support and project delivery run in one system, against one customer record. Not five copies that quietly disagree, and no person in the middle joining the data by hand every month.

We are still adding features on the same principle. Every part of the lifecycle that needs to know who the customer is and what they pay belongs in the same place as the customer.

• Salesforce, State of Sales report, seventh edition, 3 February 2026. Survey of 4,050 sales professionals, August to September 2025. https://www.salesforce.com/news/stories/state-of-sales-report-announcement-2026/
• Demand Gen Report, The Dawn of the Unified Data Strategy: Breaking Down Silos in 2026, citing the 2026 Database Strategies and Contact Acquisition Benchmark Survey. https://www.demandgenreport.com/blog/the-dawn-of-the-unified-data-strategy-breaking-down-silos-in-2026/51565/