For the longest time, I thought spreadsheets were a symptom of a failed CRM implementation. It made perfect sense in my head. If a company spent months implementing a CRM, invested thousands of dollars, and trained everyone on the new system, why would anyone still be tracking customers, forecasts, or opportunities in Excel? If they were, surely something had gone wrong..right?

Well, I worked on a project one summer that changed my mind. The funny part is the CRM wasn't the problem. I had started with an open source CRM, but by the time I was finished it barely resembled the product I'd originally installed. I had customized it around the company's business processes, built ticket management, drug management, reports, dashboards, workflows, and enough integrations that I was starting to forget what came with the CRM and what I had written myself.

Literally every week I'd get an email asking for a new feature or customization to be added and the answer was almost always yes. So, after some months passed I assumed I had hit every pain point at this org and surely no one was running a shadow system behind my back.

And, then one afternoon I opened the company's SharePoint looking for something completely unrelated. And there it was, a two ton spreadsheet filled to brim with tabs, migraine inducing colors, and valuable data that others needed for their job functions.

I had spent months building this thing and somehow the spreadsheet had looked at all my work, shrugged its shoulders and said, "That's cute."

All the sales guys and a couple others still used Excel. For a while I treated that spreadsheet like it was the villain in the story. Every time someone updated it instead of the CRM, I took it as a failure in my engineering design. It felt like a vote against everything I'd built.

Eventually it hit me that the spreadsheet wasn't trying to ruin my billable hours. And it wasn't plotting against me. It was just doing what spreadsheets have been doing since the 1980s. It became more important than anyone ever intended, by being the path of least resistance when it comes to data entry.

So there was really nothing to be upset about. In this particular role, I was the developer, not the CEO. Nobody hired me to change company culture. Nobody hired me to convince experienced salespeople that after twenty plus years in Excel they should suddenly become CRM enthusiasts because I thought it was a better design. My job wasn't to win ideological debates about spreadsheets, it was to solve business problems, which I did.

The CEO wasn't forcing anyone to stop using Excel and, if I'm being honest, I don't think it would've mattered if he had. You can certainly mandate software use but good luck mandating habits.

Pro tip: If you're not running for elected office, don't try to win hearts and minds. Analyze, architect, execute, document, and move on.

So I stopped trying to solve the problem I wished I had and started solving the problem that actually existed. I also started paying more attention to the people using the spreadsheets instead of the spreadsheets themselves. After enough projects you begin to notice patterns.

  • Some people have simply been burned too many times. They've survived CRM implementations, ERP implementations, and enough "digital transformation" initiatives that every new application sounds exactly like the last one. Every project promises to make their lives easier. Some do but then most don't. Their spreadsheet has quietly survived every single one of them.
  • The other group honestly just doesn't care, and I don't mean that as criticism. Their job isn't to become experts in Dynamics, Salesforce, SuperEasyCRM, or whatever platform the company bought this year. They just clock in to sell stuff or answer customer questions or keep operations moving. The CRM is simply another application standing between them and getting home to watch the latest Game of Thrones spinoff. The older I get, the more I understand that.

Not Everyone Enjoys Modern Technology

I genuinely enjoy working inside CRMs. I love designing them, customizing them, and building automations around them. I'm the guy who gets excited about workflow engines and cleaning up data models. It's the reason that while I'm building my own SaaS, I lose track of time so easily.

But if my paycheck depended on closing one more deal before the end of the month, and that commission determined whether I could buy my kids Robux, I probably wouldn't use a CRM either. I'd be trying to close the next deal.

Speed is king in sales while architecture is king in IT.

Neither side was wrong. They were just being measured by completely different scoreboards, and once that clicked for me I started asking a different question. Leadership wanted sales forecasts inside the CRM, sure, but did they actually care how the numbers got there, or did they just care that the numbers showed up? Because those are two very different requests, and nobody had ever actually asked for the first one. Operations needed those numbers for capacity planning. Leadership wanted dashboards they could trust without chasing down Bob every Friday. Not once did anyone call me and say "Matt, I don't care about the forecast, I just need Bob to personally type it into the CRM." They wanted the data. I had been so busy defending the process that I never stopped to notice nobody outside of IT actually cared about the process.

Practical Solutions for Enterprise Microsoft Users

The company was heavily invested in Microsoft, so Power Automate was the obvious tool for the job, though I was itching to ramp up an n8n process and start budgeting for tokens. I set up a couple of folders in their beloved SharePoint and asked everyone for one small favor: keep doing exactly what you're already doing, just save the spreadsheet here when you're done.

That's it. Not:

  • "Please change your workflow."
  • "Mandatory CRM training next Tuesday."
  • "Excel is no longer supported effective Monday."

Just save it here.

Behind the scenes I built flows that watched those folders. The second a spreadsheet landed, the automation validated it, transformed whatever needed transforming, and loaded it straight into the CRM. Leadership got their dashboards and the operations people got real planning data. The CRM became the actual system of record and sales kept using Excel the entire time, mostly without realizing anything had changed. As far as they were concerned they were just saving another spreadsheet to SharePoint like they'd done for years. They'd accidentally become API clients and nobody sent them the memo.

There was one wrinkle though, people don't work in finished drafts. Salespeople scribble notes mid call, throw in rough numbers, revise them after the next call, then revise them again after the call after that. If every single save triggered downstream automation immediately, there would be a bunch of garbage flowing into the CRM in real time, which defeats the purpose of the build entirely.

So I built something I ended up calling the Playground, which is to say I solved a spreadsheet problem by introducing a second spreadsheet. Somewhere out there an enterprise architect just closed this tab. The Playground wasn't wired into anything. It was just a place to think. Meeting notes lived there, half-baked deal numbers lived there and along with shaky back of napkin math. Once someone was actually confident in what they had, they copied it into the monitored spreadsheet and let the automation take it from there. Looking back, I think it worked because it accepted something most software refuses to accept: people generally think in rough drafts, and systems expect final answers, and pretending those are the same thing is where most of these projects go sideways.

Spreadsheets Can Be an Asset Not a Liability In Some Cases

Now, before anyone reads this as an endorsement of spreadsheet anarchy, I want to be clear about something. The moment automation depends on a spreadsheet, it's not just a spreadsheet anymore, it's an interface, and you have to treat it like one. In fact, this is one of the main tenants of headless CRM. Being decoupled from the UI allows for maximum flexibility and adoption where it would otherwise fail.

But that doesn't mean the solution isn't brittle. Rename a required column and you'll have effectively bricked the whole automation. If you move a field because it "makes more sense over here" and you've broken the integration on a Tuesday afternoon. So I locked down headers and locked formulas where it mattered, and only let people touch the parts they actually owned. They still felt like they had full control of their own sheet. My automations just weren't one enthusiastic cleanup pass away from falling apart.

I've carried this same approach into other tools since then, Airtable being the best example. I don't usually pitch Airtable as a CRM replacement. I use it as a staging area, somewhere clients can review, clean up, reject, or approve data before it ever touches the real system of record. To them it feels like a nicer spreadsheet. To me it's a controlled intake point with APIs, permissions, and guardrails sitting quietly underneath.

Once I made peace with that, I stopped trying to build the perfect system and started building the one people would actually use:

  • Sales was thrilled because nobody had to spend their evenings updating a second application.
  • Operations finally had numbers they could plan around.
  • Leadership got dashboards they trusted enough to stop asking me to double check them.
  • The CRM stayed current without anyone forcing it to.
  • The company even ended up saving money because the sales team never needed CRM licenses in the first place, which I'd love to tell you I planned from day one, but I found that one during a budget call, not before it.

Sometimes You Don't Need New Tech, But a New Mindset

The biggest thing that changed on that project wasn't the tech stack. It was me. I think developers, myself very much included, spend a lot of energy trying to make people fit our software instead of the other way around. Every business has one front door eventually, one CRM, one database, one system of record everyone can point to. That doesn't mean every employee has to start their day standing at that door. Sometimes the journey starts in Excel. Sometimes it starts in Airtable. Sometimes it starts in whatever custom thing IT built two reorgs ago that nobody bothered to rename. The destination matters a lot more than the path people take to get there.

Looking back, the most valuable thing I built on that project wasn't the CRM customizations or the Power Automate flows. It was the bridge between how people already worked and how the business needed information to move. Ironically, the moment I stopped fighting spreadsheet users was the exact moment the CRM finally started doing what leadership wanted it to do all along.

That's the part I still carry into every project. Good automation was never about forcing people to work differently. It's about understanding how they already work, accepting it instead of fighting it, and quietly building the bridge nobody asked for but everybody ends up using.