How Much of Your Business Runs on a Spreadsheet?

Take a minute and think about it. How many processes at your company are built on top of a Google Sheet or Excel file? Pricing models, approval workflows, inventory trackers, onboarding checklists, capacity planners, commission calculators. The spreadsheet is, quietly, the most popular application platform in the enterprise.

And it makes sense. Spreadsheets are accessible. Anyone can build one. You do not need to file a ticket, wait in a backlog, or learn a programming language. You just open a sheet, type some formulas, maybe add a few conditional formatting rules, and suddenly you have a “tool” that your team relies on every day.

The problem is what happens next.

The Spreadsheet Breaks Down

The moment more than one person needs that spreadsheet, things start to unravel. Someone downloads a copy to “work offline” or “customize for their region,” and now you have two versions of the truth. Then three. Then twelve. Even in a shared Google Sheet, if someone modifies a cell while you are in the middle of a calculation, your results shift underneath you with no version control and no conflict resolution.

Over time the sheet accumulates hidden tabs, nested VLOOKUP chains, and formulas that reference cells three sheets deep. The person who built it understands it. Nobody else does. When that person leaves the company, the sheet becomes a black box that everyone is afraid to touch. And through all of this, you are sharing potentially confidential pricing data, customer information, or financial models in a document that lacks proper authentication, access controls, or audit trails.

From Google Sheet to Global Tool

I saw this firsthand at Adyen. The commercial team had a CPQ (Configure, Price, Quote) process with its pricing strategy defined as a shared Google Sheet. Sales teams around the world originally had a pricing sheet in their office managed by someone on that office’s sales team. This meant we had inconsistent, unaudited, and untracked pricing strategies. To try to unify this, our global pricing team created a Google Sheet that attempted to bring together each region’s unique pricing strategies and calculations that varied by payment method, volume, and region. They would enter their deal parameters, reference rates from other tabs, and try to arrive at a discount that fell within preapproved ranges.

I saw this first iteration and, working with the team, I explained the problems that would emerge. Over the course of 48 hours we came up with a webapp version of the sheet, converting it into a database-backed JavaScript tool that produced the same calculations. This way the tool could handle concurrency, formulas could not be modified by end users, and the results were output for the pricing team to see what users were submitting so they could spot trends by region and potentially offer proactive price guidance.

So we built the Price Guidance Calculator, a Vue.js web application that replaced the entire spreadsheet in a weekend of initial development. The app pulled pricing data from a database, ran calculations on the frontend with the same logic the sheet had (but validated and tested), looked up peer deal data through Salesforce, and posted results back to Slack so the pricing team had visibility. Every interaction was written back to the database for reporting.

After a couple of months of iteration with the pricing team, we launched it worldwide. Within a year, hundreds of users were running deals through it monthly, and we measured a 25% improvement in revenue on deals that used the tool compared to those that did not. Not because the pricing logic was different, but because the tool gave salespeople confidence to hold on better rates and made the preapproved discount ranges unambiguous.

A spreadsheet could never have delivered that. Or at least, spreadsheets would not have allowed us to see the results.

The Old Bottleneck

Before AI, commercial teams who recognized they needed a real application were stuck. The path forward looked something like this:

1. Build it yourself. Enter a request into the engineering or tooling team backlog and hope it gets prioritized. But internal engineering and product teams are focused on building the core product you sell, not internal tooling for the commercial org. And other tooling teams are focused on their tools and may try to find the easiest way to fit your tool into their application, which may not actually do what you want once it’s implemented.
2. Buy a tool. Work with procurement to evaluate and purchase a SaaS solution. But CPQ tools and workflow platforms are deeply integrated into business processes. They have unique requirements that rarely fit a one-size-fits-all product. The customization you need ends up costing as much as building from scratch.
3. Stay in the spreadsheet. Accept the limitations and keep going. This is what most teams do.

So the spreadsheet wins by default. Not because it is the best tool, but because it is the only tool that commercial teams can build and iterate on themselves. Excel and Google Sheets become the programming language of the business.

AI Changes Everything

This is no longer the case. Tools like Claude, Codex, and Gemini have fundamentally shifted what a non-engineering team can build. A few hours of learning how to prompt an AI coding assistant can produce a web application that not only solves the immediate problem but also provides:

• Proper authentication and access controls instead of “anyone with the link”
• Audit trails for every interaction, not just whoever last edited cell B7
• Real-time reporting and metrics that would take a pivot table wizard hours to assemble
• Scalability across teams, regions, and use cases without copy-pasting sheets
• Integration with the systems your team already uses: Salesforce, Slack, internal databases

The Price Guidance Calculator was a weekend conversion. With today’s AI tools, that timeline shrinks even further. A commercial operations lead who understands their process can describe it to an AI assistant and have a working prototype in an afternoon.

Beyond CPQ: The Spreadsheet Graveyard

CPQ is just one example. Look around your organization and you will find spreadsheets acting as:

• Databases. Master lists of customers, vendors, or products maintained in a sheet, with teams emailing updated copies back and forth to “synchronize.”
• Approval workflows. A row gets added, someone highlights it yellow to mark it “in review,” then green for “approved.” Status tracking via cell background color.
• Reporting pipelines. Data exported from one system, pasted into a sheet, transformed with formulas, then copy-pasted into a slide deck. Every month.
• Integration layers. Two teams that cannot agree on a shared system just exchange CSV files on a schedule. The spreadsheet becomes the API.

Each one of these is a process waiting to be properly built. And with AI, the barrier to building it has dropped from “we need an engineering team” to “we need someone who understands the process and can spend a few days with a coding assistant.”

You can replace the email-a-spreadsheet workflow with a simple API endpoint. You can swap the color-coded approval rows for an actual state machine with notifications. You can build AI-monitored inboxes that intercept, structure, and process the files people are manually shuffling around. The possibilities compound once you start thinking about these processes as software problems rather than spreadsheet problems.

The Missing Piece: Architectural Literacy

The biggest unlock is not the AI tools themselves. It is giving your teams the language and frameworks to think about their processes as systems.

When a commercial operations lead understands the difference between a database and a flat file, between an API call and an email attachment, between authentication and “I’ll just password-protect the sheet,” they can design solutions that are secure, scalable, and maintainable. They do not need to become software engineers. They need enough architectural literacy to have a productive conversation with an AI coding assistant and to make sound decisions about how data flows through their process.

This is the investment that pays off across every team in your organization. Not buying another SaaS platform. Not hiring more engineers for internal tooling. Just a few hours of training that gives your commercial, operations, and finance teams the vocabulary to turn their spreadsheet-shaped problems into application-shaped solutions.

The spreadsheet era is not over. Sheets are still great for ad hoc analysis, quick calculations, and exploratory work. But for the processes that your business depends on every day, the ones with multiple users, sensitive data, and complex logic, it is time to graduate.

Your teams already know how to build. They have been building in Excel for years. Now give them better tools and teach them to think bigger.

If you want help training your teams on architectural thinking, or need someone to consult on converting your spreadsheet processes into real applications, reach out at hello@escapecommand.com.