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 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 open a sheet, type some formulas, maybe add a few conditional formatting rules, and 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. The initial version replaced the spreadsheet in a weekend. 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 could see what was happening. 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. The tool gave salespeople confidence to hold on better rates, and it made the preapproved discount ranges unambiguous.

A spreadsheet could not have delivered that. At minimum, spreadsheets would not have let us measure the results.

The Old Bottleneck

Before AI, commercial teams who recognized they needed an actual 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 own tools. They may look for the easiest way to fit your tool into their application, and that may not do what you wanted.
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 costs 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, because it is the tool commercial teams can build and iterate on themselves. Excel and Google Sheets become the programming language of the business.

The Bottleneck Is Gone

That constraint is gone. Tools like Claude, Codex, and Gemini have 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 solves the immediate problem and adds:

• Proper authentication and access controls instead of “anyone with the link”
• Audit trails for every interaction, not just the name of 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

CPQ is 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 of these is a process waiting to be properly built. With AI, the barrier 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. Once you start treating these processes as software problems, the options keep opening up.

Architectural Literacy

The biggest unlock is not the AI tools themselves. It is the language and frameworks that let your teams 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.

That investment pays dividends across the organization. It is not another SaaS platform, and it is not more engineers hired for internal tooling. It is 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 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 past the sheet.

If you want help training your teams on architectural thinking, or need someone to consult on converting your spreadsheet processes into working applications, reach out at [email protected].