Why Your Team Keeps Going Back to the Spreadsheet

The new system has been live for six weeks. The usage numbers look fine. Then you open the shared drive and find a file called “tracker_actual_USE_THIS,” last edited yesterday, with 300 rows that don’t exist anywhere in the new tool.

Your team hasn’t rejected the new system out of spite. They’ve gone back to the spreadsheet because, for some part of their job, it still works better for them. Your task is to find out which part.

Mandates don’t work on their own

The tempting fix is a firm email: “From today, the new system is the only source of truth. Spreadsheets will not be accepted.” Sometimes leadership will back this with a deadline and some pointed remarks in a team meeting.

It might reduce the visible spreadsheets. It won’t reduce the invisible ones. People will keep a private copy on their laptop, do the real work there, and paste results into the system at the end of the week. You’ll have compliance on paper and the same old process underneath, plus a team that now resents the tool.

The better approach is to treat every return to the spreadsheet as a bug report. Something in the new system isn’t meeting a real need. Here are the usual culprits and what to do about each.

Reason one: familiarity

People have used spreadsheets for years. They know the shortcuts, they know where everything is, and they can do things without thinking. The new tool, however well designed, makes them think about every click for the first few weeks.

That discomfort is real and temporary, but people will avoid it if they can. The fix is to shorten the awkward phase:

• Show the three things each role does most, not a tour of every feature. A coordinator who logs 30 jobs a day needs to be fast at logging jobs, not at configuring dashboards.
• Make the common path as short as possible. If creating a record takes eight fields and three screens, cut it back. Required fields should be truly required.
• Have someone nearby. A colleague who knows the tool well and sits with the team for the first fortnight beats any manual. Training Users Without a 40-Page Manual covers this in more detail.

Reason two: speed of ad-hoc edits

This is the big one. In a spreadsheet, changing 40 rows takes seconds: select, paste, done. Adding a column for a one-off question takes a click. In a structured tool, the same changes might mean opening 40 records one at a time, or asking an admin to add a field.

When someone gets a call saying “can you push all of the Henderson jobs back a week,” and the tool makes that a 20-minute job, they’ll do it in the spreadsheet instead. Then the spreadsheet is the one that’s correct.

Fixes that usually help:

• Bulk editing. Most decent tools support editing many records at once from a filtered list. Make sure people know it exists, and that their role is allowed to use it.
• A grid view. Many platforms offer a spreadsheet-like table view of records. For people who think in rows, this is a comfortable bridge.
• A fast path for new fields. If adding a field needs a two-week request, people will route around it. Agree that simple field requests get handled within a day or two.
• A sanctioned scratch space. For genuinely ad-hoc analysis, exporting to a spreadsheet is fine, as long as nobody edits the export and treats it as the record.

Reason three: missing features

Sometimes the spreadsheet did something the new tool doesn’t. Often it’s something nobody listed during planning, because it wasn’t a “feature.” It was just how someone used the sheet.

Common examples: a column where someone kept personal notes, a colour code that meant “call this customer first,” a formula that calculated margin on the fly, or a tab where the team lead sketched next week’s rota.

When you find these, resist the urge to dismiss them as habits. Ask what the person was using it for, and whether it’s worth building properly. The colour code probably means you need a priority field. The personal notes might need a notes field per record. The rota might be a separate process entirely.

Keep a running list. For a fictional events company, the first month’s list looked like this:

Four fixes, each a few hours’ work. After they shipped, the shadow sheet stopped being updated within a fortnight.

Reason four: trust

If people have seen the new tool show wrong data even once, they’ll keep a backup “just in case.” A missed sync, a dropped record during migration, or a confusing status will do it.

Trust comes back through visible fixes. When someone reports a problem, fix it, tell them it’s fixed, and tell the team. A short weekly note saying “here’s what we changed based on your feedback” does more for adoption than any launch announcement.

Talk to the people using the sheet

The fastest way to find out why the spreadsheet survives is to ask the person who last edited it. Not as an accusation, but with genuine curiosity: “I noticed you’re still using this. What does it do that the system doesn’t?” You’ll usually get a precise, actionable answer in under five minutes.

Where to start this week

• Search your shared drive for recently edited copies of the old spreadsheet and note who’s using them.
• Have a short, blame-free conversation with each person about what the sheet still does for them.
• Start a “why people go back” list with three columns: what, why, fix.
• Ship the easiest fix within a week and tell the team you did.