From Excel to clear processes: a pragmatic automation plan

Excel is rarely the real problem. The problem is that a spreadsheet that started as a quick stopgap carries the central steering logic for inventory, prices or reporting three years later, maintained by one person, without versioning, without validation and without cover during vacations.

Jumping straight to a complex software solution, on the other hand, often fails because the underlying process itself was never properly defined. A pragmatic automation plan therefore starts not with choosing a tool but with the process behind it.

How to tell that a spreadsheet has become a risk

• Only one person fully understands how the spreadsheet works.
• Formulas are copied by hand instead of updating automatically.
• There is no history of who changed what and when.
• Numbers are gathered manually from several sources and pasted in.
• Errors are only noticed when a result is obviously wrong.

If several of these apply, the spreadsheet is no longer an efficiency solution but a silent risk to decisions and business continuity.

A four-stage plan from spreadsheet to process

Stage 1: Document the current process honestly

Before anything is automated, the actual flow must be visible, not the ideal one but the real one: which sources are used? Who makes which decision? What happens with exceptions? This documentation often takes only a few hours but frequently already uncovers unnecessary detours and duplicate work.

Stage 2: Standardize data and rules

Automation rarely fails because of the technology, but because of inconsistent data: different item numbers, deviating formats, missing required fields. In this stage, data sources are consolidated and clear, deterministic rules are defined, such as thresholds, required fields or approval steps.

Stage 3: Automate one limited sub-process

Instead of replacing the whole flow at once, a clearly delimited part is automated, for example merging inventory data from two systems or automatically creating a weekly report. The rest stays manual for now. That way you can measure the benefit before investing further.

Deterministic steps such as calculations, data matching and fixed rules can be automated reliably. Steps that involve judgment, such as a strategic pricing decision, should deliberately stay with a person at this stage.

Stage 4: Expand, monitor, document

Only when the first automated sub-process runs stably does the extension to further steps follow. Every extension needs visible monitoring, such as a simple notification on deviations, and up-to-date documentation, so the process does not become a black box for a single person again.

When which tool makes sense

• Fixed rules, high repetition: classic automation/scripts. Fast, cheap, predictable.
• Unstructured text or documents: AI-assisted processing followed by a rule check.
• Cross-department data flows: one central system (e.g., CRM or ERP) instead of more individual spreadsheets.
• Exceptions and judgment calls: deliberately left to people, with good preparation from the previous steps.

A worked example: what a manual weekly report really costs

Automation is often discussed as a gut decision. It can be calculated, though, and the result regularly surprises people. Take a typical case: every Monday, an employee pulls numbers from the shop, Amazon Seller Central and the ad account, reconciles them in a spreadsheet and sends out a report.

• Effort: 2.5 hours per week, including follow-up questions and corrections.
• Frequency: 46 working weeks per year.
• Internal hourly rate: €45 fully loaded.

That comes to 115 hours or about €5,175 per year for an activity that produces no new insight and only moves data around. On top of that come the costs that don't show up in time tracking: delayed decisions because the report only arrives at midday on Monday, and wrong decisions when a row shifts during copying.

Against that stands a one-off effort to connect the data sources and automate the report, in many cases between 15 and 25 hours. Break-even is typically reached after three to six months. After that, the automation keeps working at no cost.

How to pick the right process to start with

Most companies don't have one automatable process, they have fifteen. The question is not whether something can be automated, but where to begin. Four criteria are enough for a solid selection:

1. Frequency: How often does the process run? Daily beats weekly, weekly beats monthly. A process that runs four times a year rarely justifies the investment.
2. Rule clarity: Can the workflow be expressed as clear if-then rules? The more room for judgment, the harder and riskier the automation.
3. Cost of errors: What happens if the step goes wrong? A wrong stock level costs more than a badly formatted newsletter subject line.
4. Data quality: Is the required data structured and reliable? If not, cleaning up the data is the real first step.

Rate each candidate on a scale of 1 to 5 and multiply frequency by rule clarity. The three highest scores are your realistic starting candidates. Processes with high error costs and low rule clarity belong at the end of the list, not the beginning, even if they feel like the most annoying ones.

In practice, the same three processes almost always end up at the top for e-commerce companies: consolidating reporting data, reconciling stock levels between systems, and preparing recurring product data uploads.

Typical mistakes when switching over

1. Too big a first step: trying to replace the entire process at once instead of starting with one sub-process.
2. No accountability: an automated process without a named owner decays just like an unclear spreadsheet.
3. No fallback: if the system goes down, it must be clear how the process continues manually in the short term.
4. No success measurement: without a before-and-after comparison, the benefit of the automation can't be proven.

When a central system is worth it, and when it isn't

At some point, every growing e-commerce company asks whether the many small automations should be replaced by a central system: an ERP, a PIM, an inventory management system. The answer depends less on company size than on the number of breaks between systems.

A central system makes sense when the same information has to be maintained in more than three places, when it is regularly unclear which system holds the correct value, or when new employees need weeks to understand where which data lives. These are symptoms of missing data ownership, and no additional interface solves that.

It doesn't make sense when only a single process hurts. An ERP project ties up resources for months and changes workflows across the whole company. Anyone who tries to solve a reporting problem with it has used a sledgehammer to crack a nut, and ends up with a system nobody fully uses.

A pragmatic middle path: deliberately define the source of truth for each type of data, even without a new system. Stock levels come from system A, prices from system B, customer data from system C, and everything else pulls its data from there instead of maintaining its own copies. This decision costs nothing but discipline and removes most of the contradictions that otherwise lead people to consider an ERP.

Why automation fails because of the team, not the technology

Technically, most automations work right away. What brings them down is almost always organizational: the process was designed without the person who has been doing it so far. That person knows the exceptions: the one supplier who sends different item numbers, the month-end close where the rule doesn't apply, the customer with the special agreement.

If these exceptions only become visible after go-live, you get the worst of all outcomes: an automated process nobody trusts, and next to it a shadow spreadsheet that is still maintained for the cases where it "doesn't fit". The effort has then doubled instead of halved.

The consequence is simple but often skipped: whoever does the process today belongs in the automation from the first hour, not as someone affected, but as a source of expertise. As a rule, a single joint conversation about exceptions brings more clarity than two days of process documentation at a desk.

What still needs to be done after automation

A common misconception: automation is a project with an end date. In fact, it only shifts the effort, from recurring execution to monitoring. Three things must therefore be settled permanently:

A named owner. Every automated process needs a person who is responsible when something doesn't work. Without named responsibility, an automated process decays just like a grown spreadsheet, only less visibly, because nobody looks at it every day.

Visible failure. The most dangerous state is not an automation that breaks, but one that quietly delivers wrong results. Every process therefore needs at least one plausibility check: if a value deviates from the previous day by more than a defined percentage, a notification goes out instead of the report being sent without comment.

A fallback. Systems fail, interfaces change, vendors switch APIs. For every critical process, it must be documented how to bridge it manually for one to two weeks. This documentation is best created right during the automation. Later, nobody writes it anymore.

A fixed review date is also useful, for example every six months: Is the process still running as intended? Have the underlying rules changed? Are there steps that have become unnecessary? Automated processes reflect the state of the business at the time they were set up, and the business changes.

Conclusion: process before tool

The most sustainable way out of spreadsheet sprawl does not lead through the next tool, but through a well-understood and simplified process. If this order is followed, automation can be introduced, measured and expanded step by step, without losing control over critical decisions.