Escaping spreadsheet dependency: should you build a system or adopt AI first?

“We want to move off spreadsheets, but should we build a proper system or bring in AI first?” This is one of the most common questions we hear from digital-transformation leads at small and medium enterprises (SMEs). The short answer: these aren’t competing options. Whether to prioritize a business system or AI adoption is determined almost mechanically by how structured the underlying spreadsheet data already is. Point AI at a spreadsheet with low structure — free-form notes, layouts that differ by owner — and it has nothing to read; the results will disappoint. Conversely, replacing an already well-structured spreadsheet with a heavyweight system is often overkill relative to the investment. This article lays out a three-axis framework for making that call, plus a staged path you can run without retiring the spreadsheet.

Why spreadsheet dependency blocks AI: the data lives in “work,” not in a table

The real problem with a spreadsheet-dependent process isn’t the spreadsheet software itself. It’s that the data exists as “steps only one person can follow,” not as a structured table.

Telltale signs:

Meaning is encoded in cell color or position (yellow means “needs review,” bold means “priority”) — and the legend lives only in one person’s head
The same field sits in a different row or column depending on the file or the month
A single cell mixes several pieces of information (“Client A, delivery due 3/15, needs confirmation”)
Part of the process lives outside the file entirely — a macro, or manual re-keying between systems

AI here means generative AI and workflow automation tools broadly. They read and act on text and data, but they can only read data that has structure. If column headers are consistent and each cell holds exactly one fact, AI can reliably answer “when is Client A’s delivery due?” But when meaning is embedded in color coding or free text, AI can’t reconstruct it, and a human ends up re-explaining the context every time. This is the classic failure mode behind “we adopted AI and still need a person for everything.”

The implication: the first move in escaping spreadsheet dependency is neither “buy a system” nor “turn on AI” — it’s making the data’s structure independent of the person who built it. The framework below decides whether you enforce that structure by building a system, or by cleaning up the spreadsheet itself.

Two competing claims — and the conditions under which each is right

Two arguments show up repeatedly in the field, and each is correct under different conditions.

“Build the system first.” A business system (order management, production scheduling, etc.) enforces an input format, so structured data becomes the default rather than an aspiration — and it removes the spreadsheet that enabled the dependency in the first place. This argument holds when the process itself — its steps, its fields — keeps changing fast enough that a spreadsheet genuinely can’t keep up.

“Adopt AI first.” Implementing a business system typically takes months to over a year across requirements, migration, and training, with meaningful upfront cost. The counter-argument: use AI to make the current spreadsheet workflow more efficient first, confirm the payoff, and only then commit to a bigger investment. This holds when the shape of the work is already stable, and cleaning up the spreadsheet’s contents is sufficient to handle it.

Apply either argument to the wrong kind of process and it fails. Push “AI first” onto a process whose structure changes monthly, and you’ll keep paying the cost of rebuilding the AI-readable structure every cycle. Push “system first” onto a stable, well-defined process, and you can spend six months on requirements definition only to discover the spreadsheet was already good enough.

The decision axes: data structure, volatility, and ownership depth

Score the target process on three axes. As a rule of thumb, if two or more point toward “build a system,” prioritize that; otherwise, start with AI adoption (data cleanup plus generative AI) and hold off on the spreadsheet’s retirement.

Axis	Favors building a system	Favors AI first (keep the spreadsheet)
Data structure	The fields themselves change by deal or by department; the schema needs to be fixed in code	Columns are largely stable; the main issue is inconsistent formatting and free text
Process volatility	Counterparties, product mix, or approval flow change several times a year	The process is stable on a six-month to one-year horizon
Ownership depth	Multiple people or departments update the same data concurrently, requiring access control and conflict handling	Effectively one or two owners maintain it; other users mostly read

A common tripping point is whether concurrent write access matters. If multiple departments update the same inventory figures simultaneously and you’re seeing duplicate entries or overwritten updates, AI cannot fix that. That’s a job for a database’s transaction handling — the mechanism that makes one writer wait while another completes, discussed in Database basics for business — and it’s a clear signal to build a system. If, on the other hand, there’s effectively one owner and everyone else just reads the data, keeping the spreadsheet and layering data cleanup plus AI on top is enough.

Figure 1: Deciding between a business system and AI adoption

The staged path: cleaning up the data without retiring the spreadsheet

When the three-axis check points to “AI first,” run these three steps without retiring the spreadsheet. The goal is to confirm value at small scale before committing to a system investment.

Fix the input rules (1–2 weeks). For the target spreadsheet, write down the column headers and input formats (date format, allowed values, and so on) as a one-page rule set, and turn every meaning currently carried by color or free text into its own column. No tooling is introduced at this stage.
Standardize existing entries (2–4 weeks). Find and normalize inconsistent formatting in historical data (for example, “Inc.” versus “Incorporated” for the same company). It’s unglamorous work, but skipping it materially degrades how well AI can read the data later.
Start with low-risk drafting and summarization tasks (3 months). With the spreadsheet’s structure now in place, begin with tasks where a mistake is cheap to catch — drafting a quote, summarizing a daily report. The detailed five-step version of this approach is covered in Where should SME AI adoption start (Japanese).

If, after three months, the process starts changing more often or multiple departments start asking to update the same data concurrently, that’s the signal to revisit building a system. There’s a useful side effect here too: migrating from data that’s already clean is far faster and cheaper than migrating from data that isn’t, since the requirements-definition and migration work shrink substantially.

Common pitfalls

Trying to clean up every spreadsheet at once. The wider the scope, the longer it takes to get buy-in, and the later you actually start. Scope the target to one process and one family of files.
Skipping standardization and buying an AI tool anyway. AI applied to unstructured data reads poorly, and that first bad impression sticks — teams conclude “it doesn’t work” and stop trying. This is exactly why standardization has to come before tool adoption, not after.
Carrying the spreadsheet’s bad habits into a system’s requirements. If you build a system around the same ad hoc, person-dependent input rules the spreadsheet had, you’ve just reproduced the dependency inside new software. Cleaning up the data structure before requirements definition avoids this.
Scoring the three axes alone. Ownership depth is a blind spot for the person closest to the process. Check with the other departments touching the same data before scoring.

FAQ

Is continuing to use a spreadsheet itself a problem? No. For any process that scores toward “AI first” on the three axes, keeping the spreadsheet in place is often sufficient to get real results. Retiring the spreadsheet isn’t a goal in itself.

Do we eventually have to pick one — a system or AI — permanently? No. Since the nature of a process changes over time, the common pattern is to start with AI adoption and move to a system once volatility or the number of concurrent owners increases. Treat the three axes as something to revisit every six to twelve months, not a one-time decision.

If we outsource the data-cleanup work, what should we actually ask for? Ask for help selecting the target process and running the three-axis assessment and input-rule design — not just “tool installation.”

Summary

Escaping spreadsheet dependency isn’t a binary choice between building a system and adopting AI — it’s a question decided by data structure, process volatility, and ownership depth. When two or more of those axes favor a system, build it. Otherwise, keep the spreadsheet and work through three steps: fix the input rules, standardize existing entries, and apply AI to low-risk tasks. Resisting the urge to jump straight to a heavyweight system investment, and cleaning up the data first, is usually the cheaper path to either outcome.