Turning your Excel file into a tool with AI: the step by step method

The Excel file that runs the department

In many companies, an Excel file carries part of the business. It tracks orders, schedules field work, calculates quotes or consolidates reports from several teams. It started as a simple table, then gained tabs, nested formulas, macros and colours whose meaning only one person knows. It works, but it relies on constant vigilance: the right version, the right formula copied down, the right column filled in.

Turning that file into a tool with AI does not mean plugging an assistant into the spreadsheet and hoping for the best. It is a scoping job, then a build, in which AI has a precise role: reading documents, sorting, drafting, spotting anomalies. The rest is a classic application, with a database, screens and access rights. This article describes the method we follow, step by step, to go from the file to the tool without breaking what already works.

If you are still wondering whether it is time to leave your spreadsheet, our article on the signs it is time to replace Excel helps you decide. Here, we assume the decision is made and look at how to carry it out.

Step 1: define the why, and with whom

Before looking at a single cell, you need to know why the tool should exist. The answer is almost never "because the file is old". It sounds more like: quotes go out too late, the figures for the leadership meeting differ depending on who prepares them, someone spends the end of every month copying data from one file to another, or a customer received wrong information from an outdated version. That why becomes the criterion for every later decision.

It fits in one sentence, with an observable effect. For example: every quote leaves on the day it is requested, or the monthly report is produced without any retyping. A sentence like this lets you turn down an appealing feature that does not serve the goal, and measure after launch whether the tool kept its promise.

Then comes the question of stakeholders. A business file almost always has several audiences, and each sees it differently:

• The person who fills it in every day, who knows its shortcuts, workarounds and traps.
• The person who reads it to decide: a manager, leadership, sometimes a customer.
• The person who maintains it, often whoever created it, now indispensable without having chosen to be.
• The project owner, who arbitrates when needs conflict.
• Those who depend on it without seeing it: accounting receiving an export, a partner receiving a file, another system fed by hand.

Each of these stakeholders is met, ideally in front of the open file. We ask them to show what they actually do, not to describe it from memory. That is where the steps nobody mentioned appear: the hidden tab copied every Monday, the column filled in "just in case", the email sent after every update. A single project owner with the authority to decide then keeps the tool from becoming the sum of every request.

Step 2: estimate volumes to choose the architecture

The technical choice follows from volumes, not preferences. A tool used by a small team on a few hundred rows a year does not have the same needs as a tool that ingests, every day, files of thousands of rows sent by dozens of sites. Getting it wrong one way costs a lot in unnecessary infrastructure; getting it wrong the other way forces a rebuild just when the tool becomes indispensable.

The questions are simple, and the answers are often in the file itself or its history:

• How many rows are added per day, month and year, and how many must stay searchable.
• How many users work at the same time, and from where: one office, several sites, the field on a phone.
• How many files or documents enter the process: purchase orders, supplier PDFs, service reports, photos.
• How fresh the data must be: real time, within the hour, the next morning.
• What peaks exist: a monthly close, a season, an annual event that concentrates activity.
• What AI processing volume is expected: how many documents to read, texts to draft, checks to run.

These answers shape the architecture quite directly. For a small team and modest volumes, a lightweight web application with a simple database, on shared hosting, is more than enough and stays easy to maintain. When users multiply, several sites write at the same time or history stretches over years, a server database and a layered application become necessary. When the core need is ingesting large files or feeds from other systems, a dedicated processing pipeline is added, running in the background without blocking the screens.

AI processing volume matters too. Every document read or text drafted by a model has a cost and a response time. A batch job run overnight is not designed like an answer expected on screen within seconds. Estimating this volume during scoping lets you pick the right model, decide what runs live and what runs later, and avoid surprises on the bill. Our article on the cost of an AI agent in production details what to watch.

Sobriety is part of this decision. A tool sized to the actual need consumes less, costs less and fails less. A common example: when the heavy processing can happen in the browser, the server only validates, converts and purges, and the whole thing runs on shared hosting.

Step 3: identify the repetitive tasks

A business file always hides repeated gestures. They are what consumes the team's time, and they are what the tool should absorb first. To find them, observe a typical day or week and note every action that comes back identically or nearly so.

The most common ones look alike from one company to the next:

• Retyping: copying into the file information already present in an email, a PDF or another system.
• Consolidation: gathering several files sent by different teams or sites into a single table.
• Checking: verifying that a row is complete, an amount consistent, a date not overdue.
• Chasing: writing to someone because a cell is empty or a deadline is near.
• Document production: generating a quote, a report or a work order from the rows of the file.
• Formatting: renaming, marking, merging and exporting files one at a time.

For each task, note its frequency, the time it takes and the risk of error it carries. This small inventory sets priorities: the first version of the tool handles the tasks that combine high frequency, significant time and error risk.

The inventory also shows what should not be automated. A decision that calls for judgement, an approval that commits the company, a delicate exchange with a customer stay human. The tool can prepare those moments, gather the elements, propose a draft; it does not replace them.

Step 4: map the data and the hidden rules

A spreadsheet mixes three things the application must separate: data, rules and presentation. Tabs become tables, columns become typed fields, drop-down lists become reference lists. Formulas are business rules written in a hard-to-read syntax, and each one must be extracted, understood and validated with the person who maintains it.

This is the step with the most surprises. A formula that only applies to some rows, an exception handled through a cell colour, a calculation fixed by hand every month because it never came out right. Each of these quirks is either built properly into the tool or dropped by agreement because it no longer serves a purpose. Nothing should disappear by oversight.

The quality of existing data is assessed at the same time. Duplicates, several spellings of the same customer, dates typed as text, merged cells: some clean-up is almost always needed before migration. AI can help here by suggesting matches between similar labels or flagging inconsistent values, but every proposed correction is approved by someone who knows the business.

Step 5: put AI where it really helps

Once tasks and data are laid out, you can decide where AI belongs. Much of the gain comes from the application itself: a clean database, forms that prevent input errors, automatic calculations, deadline alerts. These rely on simple rules and do not need a language model.

AI becomes useful when data is unstructured or when the task requires understanding text:

• Reading incoming documents: extracting information from a purchase order, a supplier invoice or a PDF report, and proposing to fill in the matching fields.
• Sorting and routing: filing a request under the right category and sending it to the right person.
• Drafting: preparing a reminder, minutes or a summary from the tool's data.
• Spotting anomalies: flagging a row that departs from the usual pattern, an unusual amount, an inconsistency between two documents.
• Answering questions: letting a user query their data in plain language, from within the tool, with the source of each answer.

In every case the rule is the same: AI proposes, a human approves when the stakes justify it, and every proposal is traceable. That is what we stand for in our responsible AI memo. A field filled automatically from a PDF shows where it came from; a reminder drafted by the model is reviewed before sending until trust is established. Our AI agent method applies these principles when the assistant acts more autonomously.

Step 6: plan access rights and security from the start

A shared file often gives everyone the same rights: whoever opens it can read and change everything. The tool is the chance to fix that. You define who can view, who can enter data, who can approve and who can administer, and every change is logged with its author and date.

Personal and sensitive data need particular care. Keep only what is useful, set a retention period, and check where data is hosted and which AI processes see it. For data that must not leave Europe, the choice of hosting and model takes this into account; our article on hosting AI in France presents the options.

Step 7: prototype on one batch, not the whole file

It is tempting to rebuild the entire file before showing anything. That is the longest and riskiest path. We prefer delivering in batches: a first screen that handles the most painful task found in step 3, tested by real users on their real data, then corrected before moving to the next batch.

This first batch is the proof. It shows the tool delivers, surfaces forgotten needs and builds the team's confidence. It also tests the volume assumptions of step 2 in real conditions, before the architecture is set. The automation method page describes this sequence, and the full application method extends it when the tool becomes the core of a process.

Step 8: organise the switchover and coexistence

The day the tool replaces the file must be prepared. Data is migrated, checked and compared with the source file. For a defined period both can coexist: the file becomes read-only, the tool becomes the reference, and any gaps are fixed quickly.

Some spreadsheet uses can remain. A one-off analysis, a pivot table for a meeting, an export for a partner: the tool provides clean exports, and everyone keeps the freedom to explore. What must leave the spreadsheet is the reference data several people use every day.

Training goes with the switchover. It happens on the real tool, with the team's own data, and names an internal referent who can answer everyday questions. Our article on building your teams' AI maturity covers this point.

Step 9: measure, then evolve

The goal set in step 1 becomes the success indicator. Time spent on repetitive tasks, lead time to produce a document, number of errors found after the fact: measure before the switchover, then after, with the same method. That comparison is what lets you say honestly what the tool changed.

The tool then keeps evolving. Unanswered questions, user requests and new documents to process feed the next batches. That is the advantage of a custom application: it follows the business instead of forcing it to bend to off-the-shelf software. Our article custom or off-the-shelf software helps check that this choice is right for your case.

The checklist to get started

• The why fits in one sentence, with an observable effect.
• Every stakeholder has been met in front of the open file.
• Current and expected volumes are estimated: rows, users, documents, peaks, AI processing.
• Repetitive tasks are listed with their frequency, duration and risk.
• Formulas and exceptions are extracted and validated.
• The role of AI is defined task by task, with human approval where the stakes call for it.
• Access rights and data retention are decided.
• The first batch is chosen, with real users to test it.

To find out where your organisation stands and which file to tackle first, our AI diagnostic asks the right questions in a few minutes, before committing to anything.

Frequently asked questions

Can we simply add AI inside Excel instead of building a tool?

For individual, occasional use, an assistant in the spreadsheet can help. As soon as several people depend on the file, data must be reliable and traceable, or documents enter the process, you need a database, access rights and a history, which a spreadsheet does not provide.

Why estimate volumes before choosing the technology?

Because the number of rows, concurrent users, documents and AI processing runs determines the right architecture. An estimate made during scoping avoids paying for unnecessary infrastructure, or having to rebuild everything once the tool becomes indispensable.

Which tasks should be automated first?

Those combining high frequency, significant time and error risk: retyping, file consolidation, checks, reminders, document production. Decisions that call for judgement stay human; the tool prepares them.

What happens to the file's formulas and macros?

Each formula is a business rule. It is extracted, understood and validated with the person who maintains the file, then built into the tool or dropped by agreement if it no longer serves a purpose.

Should we abandon Excel entirely?

No. The reference data used every day by several people moves into the tool, but one-off analyses and exports can continue in a spreadsheet, from clean exports provided by the tool.