Why your team goes back to the spreadsheet

Nobody abandons an internal tool in one decision. The spreadsheet stays open for one urgent order, then for the month's close, and by the fourth week the real numbers live there. What caused it is rarely a missing feature: five small frictions, each with a fix cheaper than the retraining session you were about to book.

Which three fields are harder to fill than the paper form?

The paper was filled by a person holding the object; the screen wants a different word for it.

A code where the paper had a name. The paper said "client: Boulangerie El Baraka". The tool wants an account code from a list of thousands. The clerk leaves the counter, asks the accountant, or picks the nearest wrong name. Search by the name they said and derive the code.

A fixed list where the paper had judgement. A free note becomes a mandatory dropdown of twelve options, the real case is the thirteenth, and people choose "other". Keep a short optional text field beside it; after a month, the list writes itself.

A unit nobody converted. The paper counted crates, because crates arrive on the pallet. The tool asks for units, and the conversion lives in one storekeeper's memory. Ask for the unit the person counts in, and convert in the database.

None of this is fixed by explaining the field again. A field that needs a lookup gets filled with an approximation.

What is the step that costs six clicks and happens forty times a day?

Receiving a delivery: open the tool, find the order, open the line, press receive, choose the warehouse, confirm. Six clicks, forty times a day, before anyone has thought about the goods.

The arithmetic is not the problem; the interruption is. Each click pulls attention from the queue at the door, which is what the person is actually managing. Six demands on attention lose to a sheet of paper where the task is one line and a pen.

The fix is a task screen, not a record screen: today's date already there, the warehouse there, the supplier's open order preloaded, one quantity field and Enter. Count the clicks in the task your team repeats most, not in the flow you demo.

Why does nobody start with their own data?

Because the tool opens empty, and it cannot answer the first question anyone asks: what is this customer's balance, what did we pay this supplier last time, is this item in stock.

The team's response is rational. They retype the two records they need today, keep the spreadsheet for the rest, and now two sets of numbers exist, neither complete. Within a week nobody trusts either, and the argument about which is right becomes the reason the project is paused.

An import is part of the build, not a migration task for later. It ships with the first release, it uses the real list rather than twenty sample rows, and it can run twice without duplicating anything — because it will run twice.

Why does the report no longer match what the manager used to see?

The two totals follow different rules. The old sheet counted an order that was cancelled and later reinstated; the new report excludes cancelled lines. On Monday the manager sees a figure two hundred thousand dinars lower and concludes the tool is wrong. No interface change answers that.

Reproduce the old report exactly, with its odd filters, and label it the legacy view. Then put the corrected one beside it with a line naming the difference. A better number is not an argument; a reconciliation is.

What the team had	What the tool asked	What to change
A customer name spoken aloud	An account code from a long list	Search by name, derive the code
Six clicks to receive a delivery	The same six, forty times a day	One task screen with defaults
A year of history in a file	An empty database	Import the real list first
A monthly figure they trust	A different, more correct one	Ship the old report, then the fix

Is a spreadsheet a habit?

No. A habit is something you do without deciding. The spreadsheet is the only tool in the building that never asks permission: it opens without a login, it works while the connection is down, it accepts a half-filled row without complaint, and the person owns the file.

The tool asks for all of that on day one, from people who were not consulted. Their choice is not laziness; it is the path with fewer gates. Treat adoption as a budget of gates: one login that stays signed in, a draft that survives a closed tab, no approval step during the first month, a printed fallback for the day the line dies.

A decision procedure

1. Sit with the person who does the task for one hour. Count clicks and lookups separately; lookups are what break the rhythm.
2. Run the task on paper and in the tool, side by side. Note every question the paper asked differently.
3. Load the real data before the pilot — customers, stock, this week's open orders — and prove the import is repeatable.
4. Rebuild the report the manager already trusts, with its old filters, and mark it as the old calculation.
5. Remove one gate a week and watch whether the record arrives earlier, then give the spreadsheet a read-only period with an end date.
6. Ask one question on Thursday: was the record I needed today already in the tool yesterday?

Where this goes wrong

• The team is asked which features they want. They ask for what they know. Ask what they did yesterday, in order, and where they had to leave their chair.
• Adoption is measured by logins. Logins are cheap and say nothing about whether the business runs on the number in the tool.
• The pilot runs on sample data. The friction lives in the real list: duplicate names, missing codes, one customer spelled three ways.
• The old spreadsheet stays writable with no deadline. A fallback with no end date is the system of record, whatever the contract says.
• The answer is a training day. Training closes a gap in knowledge. These are gaps in effort, trust and permission.

What this does not cover

This is about the first month of a rollout, not the tool's architecture, and it assumes the process is worth keeping. It is no help when the tool is genuinely wrong for the job, or when the people using it have decided to wait the project out. And friction alone does not explain every abandonment: a tool can be effortless and still be ignored if no review, handover or decision depends on the number inside it.

We build internal tools around the task as performed — the real units, the real lists, the report the manager already trusts — and then remove one gate at a time.