Leads that die in an Excel sheet

The first sales record on any project is a spreadsheet. Somebody opens a file, types Name, Number, Project, Status, and the sales operation exists.

That is the correct first move. The sheet costs nothing, needs no training, and is running before the hoarding goes up. Nobody should apologise for it.

It stops working for reasons that have nothing to do with discipline. The failures are mechanical. Naming them exactly is the useful exercise, because "we should move off Excel" is not an argument anybody acts on, while "the status on this row changed last week and nobody knows who changed it" is.

The failures, named#

One file, several people. There are only two arrangements and both are bad. Either the file lives on one laptop, in which case the sales team queues at one desk and the person who owns the laptop owns the truth. Or it is shared, and within a fortnight there are four copies with suffixes, each holding some updates the others do not, and no way to combine them except by reading both side by side.

No history. A lead moves from Hot to Cold. The cell now says Cold. It does not say who decided that, on what date, or after which conversation. The previous value is gone. Six weeks later the manager asks why a good enquiry was dropped, and the honest answer is that the sheet cannot tell anyone.

A sort that took the range and not the row. Somebody selects the status column, sorts it, and the statuses reorder while the names and numbers stay put. Every row in the file is now wrong, quietly and permanently. There is no error message and no undo an hour later.

A filter left on. The last person filtered to one project and closed the file. The next person opens it and sees a subset which looks like the whole. Leads that exist, that were paid for, are invisible to the person whose job is to call them.

The lead entered at the bottom, or not at all. A sheet is unusable on a phone. So the caller at a hoarding or a mall kiosk writes the number on paper, or sends it to their own WhatsApp, and enters it in the evening. Some evenings that does not happen. The enquiry the marketing budget bought never reaches the file.

The same buyer entered twice. Two callers, two rows, two owners, and one irritated buyer receiving the same pitch twice. A sheet has no way to warn anybody, and the duplicate is usually found at booking, which is the worst possible moment. The mechanics of that case are their own subject — one buyer, three enquiries.

A date in a cell does not ring. This is the one that costs the most money. The sheet can hold follow up on the fourteenth perfectly well. It simply never mentions it again. The date is a fact, not an instruction, and a fact sitting in a cell has never called anybody.

The month-end rewrite. Before the review, the sheet is tidied. Stale rows are deleted, statuses are moved to match what was reported, the count is made to agree with the count that was announced. The file that survives is a report, not a record, and the following month starts from it.

Why the sheet survives anyway#

Because it is genuinely good at three things, and anyone proposing a replacement is competing with all three at once.

• It is instantly editable. A new column costs three seconds and no permission. When a new tower launches and somebody wants to track floor preference, it is tracked that afternoon.
• Everybody can read it. No training, no login, no explanation. A manager who has never seen the file can understand it in a minute.
• It costs nothing and asks nobody. No approval, no procurement, no vendor.

Any replacement is measured against these three whether or not the person comparing says so out loud. A system where adding a field means raising a request and waiting a week will lose to the sheet, no matter what else it does, because the sheet will reappear on somebody's desktop the first time the system says no. This is one of the places where the shipped defaults are decisions — what the software makes easy on day one is what the office will actually do.

What a sheet structurally cannot do#

Three things. Not does badly — cannot, because of what a spreadsheet is.

Hold history. A cell holds one value: the current one. Every change is a destruction of the previous state. A sales record needs the opposite property, where new information is added and nothing is overwritten, which is the whole argument for append-only records.

Be read and written by two people at once. Not "shared" — genuinely concurrent, with both people's work surviving. Two callers working the same list at the same hour is the ordinary case in a sales office, not an edge case.

Act on a date by itself. A record that knows a follow-up was due yesterday and says so, unprompted, to the person who owes it. Everything a sales team does is a sequence of dated promises, and a system that cannot act on a date is just a filing cabinet with better arithmetic. What that looks like when built properly is follow-up as a schedule.

Those three are the entire brief. A lead system that holds history, takes two people at once, and acts on dates by itself has earned its place. One that does those three and is also slower to edit than a sheet has still won, because the three are not conveniences.

Before you replace it#

Take last quarter's sheet and try to answer three questions from it alone. Who changed this lead's status, and when? Which follow-ups were due last week and not made? Which of these rows are the same person?

If the file cannot answer them, that is not a failure of the person who kept it. It is a description of what the tool is. The next tool should be chosen by whether it answers those three, and by whether the caller standing at a kiosk can enter a name into it in ten seconds. Both, or neither will be used. The field-by-field version of that requirement is what a lead record should hold.

The short version#

The sales sheet is not a bad decision, it is a tool with three structural limits: no history, no concurrency, and no ability to act on a date.

It survives because it is instant, readable and free, and any replacement must match all three or it will be quietly abandoned.

Judge the replacement by whether it can say who changed a status and when, which follow-ups are overdue, and which rows are the same buyer.