How to replace spreadsheets and WhatsApp approvals

When an attempt to replace a spreadsheet fails, it tends to fail in one way. The new system is correct, complete and slower than the sheet. Before long the sheet is back, kept quietly alongside, and now there are two records.

The sheet and the group chat are not a mess to be cleared away. They are the current design of the process, made by the people who run it, and they are good at things formal software is often bad at. This guide sets out an order of work. It applies whatever you replace them with.

What you already own

It helps to see the sheet for what it is. It is software your business built for itself. Nobody sold it to you. Your own people designed its columns around how the work is really done, they change it the same afternoon the process changes, and they ask nobody’s permission. The group chat is the same thing for decisions: an approval process that fits the operation exactly, because the operation made it.

In other words, this is the one part of your systems that you fully control. That is why it has survived every attempt to replace it with something bought.

What the sheet lacks is everything that makes a record dependable. There is no history, so a changed cell looks as if it was always so. There are no permissions. Nothing reconciles one file with another. And the knowledge of how it works belongs to whoever keeps it.

So the task has two halves, and most projects attend to only one. You are adding a record, permissions and history. You must also keep what you had: a process that is yours, that your own people understand, and that changes when you decide. A replacement that gives you the first and takes away the second has swapped an informal capability you owned for a formal one you rent.

1. Find the registers and chats that hold decisions

Not every spreadsheet matters. Most are scratch work. You are looking for the few where a decision is made or stored: the one that says what was ordered, what was received, what was promised and who agreed.

Three questions find them quickly.

• What do you open first in the morning?
• Where do you look when a customer or a supplier rings to ask about their order?
• If this file were deleted tonight, what could you not do tomorrow?

Do the same for chat. Ask where a yes is given. Read back through a week of a busy group and mark every message that is an instruction, an approval or a figure someone later acted on. Those messages are your approval process as it really runs.

For each register and each group, write one line: what decision it holds, who writes to it, who reads it, and what happens next because of it.

2. Follow one order from start to finish

Pick a real, recent order and trace it through every file and thread it touched. This shows the joins, which is where things get lost.

The spares and consumables unit of an engineering group shows what such a trace finds. A client’s request arrived as an email, a chat message, a spreadsheet, a PDF or a handwritten slip. The quotation was worked out in a spreadsheet file of its own. The proforma invoice was made from a template and given its number by hand. Who should buy which line was agreed by voice or by message. Receipts went into one shared register, kept by one person. Dispatch was recorded in extra columns of that same register.

Each step worked. But the order existed nowhere as one thing. Its state was spread across several places, and knowing it meant asking someone.

3. Write down the exceptions before the rules

This is the step most often done in the wrong order. Teams specify the normal flow first because it is easy to describe, discover the exceptions in testing, and bolt them on.

Reverse it. The normal case is the one the spreadsheet never struggled with. The exceptions are the reason the sheet has a remarks column, and they are where the sheet’s flexibility was doing real work. List them first, in the words the team uses.

From the same operation:

• A delivery arrives short. In the sheet, the partial quantity was typed into a remarks cell as a dated note.
• One purchase order covers lines from two different proforma invoices. In the sheet, two numbers were written in one cell.
• Goods go straight from the vendor to the client and never pass through the warehouse, so the receipt register has nothing to show.
• The client describes a part in their own words, which are not the words on the item list.

In the system the unit runs today, each is an ordinary path. The unit of work is the single line of a proforma invoice, and it moves through four states: open, purchase order raised, procured, delivered. A short delivery needs no remark, because the lines that did not arrive have simply not moved. A purchase worker can select jobs from several proforma invoices at once, and the system raises one purchase order per vendor. Each line of a goods receipt is routed either into the warehouse or direct to the customer. Each item carries the descriptions clients have used for it.

The exceptions decided the design. Left until the end, they would have become a remarks column again.

4. Keep what was fast

Before you retire a sheet, write down what was good about it. Usually it is some of these.

• Entry is quick. Type, press Enter, next row. If the new screen needs six clicks for the same row, the sheet will win.
• Everything is on one screen. People read a familiar layout at a glance.
• Anyone can pull the data out. A question nobody planned for gets answered without waiting for a report.
• Conversation is easy. A chat is the right tool for talking.

Carry each of these over on purpose. A report can keep the old sheet’s layout, column for column. Data should export to a spreadsheet freely: analysis in a sheet is healthy, and it is only the record that needs to move. The phone call or the chat with the client can carry on too. What changes is that the person who took the call records the outcome on the order. The conversation stays informal. The decision does not.

5. Decide what needs a permission

In a sheet, anyone with the file can change anything. In practice this is rarely abused. It still matters, because nobody can show that it was not.

Go through the decisions from step 1 and mark the few where the person who does a thing should not be the person who approves it. Raising a purchase order and releasing it to the vendor is the usual one. Setting a price is another. Keep the list short. Every approval adds a wait, and waiting is what sent people to the group chat in the first place.

6. Move one flow at a time, and retire the sheet on a date

Choose one flow, end to end, and move it whole. Half a flow in the system and half in the sheet is worse than either.

Give the sheet a last day. After it, the file is read-only. A sheet left open “just in case” will be updated by someone careful, and from that day there are two versions again.

The first weeks will surface exceptions that step 3 missed. What matters is where they go: into the system as a new path, not back into a remarks field.

7. Keep the right to change it

The sheet could be changed the day the process changed. Before you commit to any replacement, find out what a change will involve afterwards.

• Ask how a new column, a new status or a new approval step gets added, who does it, and how long it takes.
• Ask where the rules will be written down in plain language: the states an order passes through, the exceptions and their paths, who may approve what. If the only description is the software itself, your team has lost something the sheet gave them, which was the ability to see how the process works.
• Ask what happens to the history when the process changes. Old orders should stay on record as they happened.
• Name one or two people on your side who will understand the new system as well as the sheet’s keeper understood the sheet.

This step costs an hour of questions and is the one most often skipped.

What you should end up with

One record of each order, which shows its own state. Approvals attached to the thing approved, with a name and a time. Corrections that add to the history and do not replace it. A team that is no slower at the moment of entry than it was with the sheet. And a process that is still yours to change.

Those last two tests are the ones to hold any supplier to, Jetbro included. Phlo, Jetbro’s framework, records every action as an event, which gives the history and the approvals without anyone assembling them. Speed at the point of entry comes from somewhere else: time spent on the floor before the build, watching how the sheet is really used. And the first build leaves the operation written down, its entities, events and exceptions, so that the capability you owned informally becomes a system you own properly.