From WhatsApp and Excel to one system

Many companies run their daily operations on WhatsApp groups and Excel files. It made sense at the start: both tools are already on the team's phones and computers, and nobody needs training. But as the company grows, that simple setup turns into a daily burden that never shows up in any report.

Here I describe a typical day in a company that works this way, then explain how I move the work into one system without asking the team to give up the tools they're used to.

A typical day on group chats and spreadsheets

The day starts with a message in the operations group: a customer needs an urgent delivery. The supervisor replies "done" and messages the warehouse lead in another group. The warehouse lead replies with a photo of a handwritten note, or doesn't reply at all because he's busy.

In the afternoon, the manager asks in the main group where that order stands. Several people start scrolling through their messages. One says it has gone out; another says it's waiting on a missing item. At the end of the day, someone updates the shared Excel file based on what they remember from the chats. Meanwhile, a colleague is working on an older copy of the same file.

This describes a typical situation, not any particular company. Anyone who has lived through a day like it knows the problems:

• Orders get lost in the chat. An important message disappears under dozens of others.
• Ownership is unclear. A "done" in the group doesn't mean a specific person has committed to doing the work.
• Status is known only by asking. To find out where an order stands, someone has to ask and wait for a reply.
• Deadlines live in someone's memory. There's no place that says when the order should be finished.
• The spreadsheet lags behind reality. Excel is updated by hand, so it shows what happened yesterday, not what's happening now.
• History is missing. A new employee can't find a record of what happened with a given customer.

I'm not dismissing these tools. WhatsApp is fast and familiar, and Excel is flexible. The problem is asking a chat tool and a spreadsheet to do the job of an operations system.

What moves into the system first

I start with requests. By a request I mean any piece of work that comes into the company and needs follow-up: a customer order, a maintenance request, a supply request, depending on your business. In the system, each request becomes a single record with at least four elements:

• A clear status. For example: new, in progress, waiting on a reply, closed. The stages follow the way you actually work.
• One owner. A specific named person, not a group.
• An expected deadline. When it should be done, so delays show up without anyone having to ask.
• A history of what happened. Who changed the status, when, and what notes were added.

With those four elements, the question "where is this order?" changes. Instead of asking the group, the manager opens a screen. Late requests surface on their own in a dashboard, without anyone hunting for them.

I don't move all of it in the first release. Requests and their flow are the core. The rest comes in later releases, once the foundation is stable.

What stays

A new system doesn't mean the team has to abandon the tools they know. Some of them stay, with a clearer role:

• WhatsApp for notifications and conversation. The system can send an alert when a request is assigned or running late, through messaging services that allow integration. Quick back-and-forth between colleagues stays in the chat.
• Excel for exports and analysis. Management or the accountant can export data from the system to Excel and analyze it the way they're used to.

The rule I suggest is simple:

Discussion stays in the chat. Decisions are recorded in the system.

If two people agree in the group to move a deadline, the change is recorded on the request itself, so the system stays the reference.

Migrating existing data

The data in your Excel files is valuable, even if it's messy. The practical question is what gets moved and what stays as an archive.

• Start with what's open. Current requests, customer lists, products or services. The team needs these from the first day.
• Old, closed records can stay put. If the old files are well organized, they can be imported. If they're scattered, it may be better to keep them as an archive to look up when needed.
• Clean before you move. Duplicate names, columns that differ from file to file, empty cells. Reviewing these before the import is far easier than fixing them after.
• A clear switch-over day. Pick a day from which new requests are recorded in the system only. Running both ways side by side for a long time brings back the original problem: two versions of the truth.

Start with one department

Moving the whole company at once is an unnecessary risk. It's better to start with one department, ideally the one where the problem shows up most: where requests get lost, run late, or keep being asked about.

This approach has clear benefits:

• Smaller risk. If something needs adjusting, only one department feels it.
• Faster learning. Feedback from the first department improves the system before it reaches the others.
• Buy-in from inside. When colleagues see that the first department has stopped digging through chats, moving over becomes something they ask for, not a decision imposed on them.

This fits how I deliver. The system arrives in releases on a staging environment that the department tests itself, and I don't move to the next release until you've approved the previous one. If the company uses other platforms, I check their APIs in the first week and give you a written report on what can be connected, what can't, and the alternative.

What to measure after launch

To know whether the system is doing what you need, pick a few simple measures now:

• The number of open requests past their deadline.
• The time from a request arriving to it being assigned to an owner.
• The time from a request arriving to it being closed.
• The number of requests still handled outside the system.
• The time it takes to prepare the regular report for management.
• How often someone asks in the group about the status of a request.

Record these numbers before launch as best you can, even as estimates. Without them, the assessment turns into impressions. After launch, the support period set in the offer covers any bug that appears, and maintenance after that is optional.

A checklist

Answer yes or no:

• Do requests reach you through more than one chat group?
• Is it hard to know a request's status without asking someone?
• Is an Excel file updated by hand based on chat messages?
• Is there more than one copy of the same file in use?
• Has a request run late because nobody knew they owned it?
• Does finding out how many requests are open today require manual counting?
• Is there one department where these problems show up more than elsewhere?

If most of your answers are "yes", moving requests into one system, starting with one department, would likely save your team daily effort. If most are "no", your current way of working may be enough for now.

If it helps, describe how requests reach you today, who follows them up, and where they're recorded, and I'll share my view on a sensible first step.

Related to this articleInternal operations systems