Slow growth usually gets blamed on the team. More often it is the system — data spread across files, decisions delayed, and commitments made on numbers nobody trusts.
A very large share of businesses in India still run on Excel sheets. In the video we put that figure at over 60% — the exact number is arguable, but anyone who has worked with small and mid-sized companies knows the pattern is real.
What comes with it is a familiar complaint. Growth is not happening. The team is not giving a hundred percent. Usually neither of those is the actual reason.
First, in defence of Excel
It is worth being fair about this, because the "spreadsheets are bad" argument is usually made by people selling software.
Excel is genuinely excellent. It is flexible, everyone knows it, it costs almost nothing, and it does not impose a process on you before you have worked out what your process is. For a new business, or a business doing something unusual, that flexibility is exactly right. Forcing a rigid system onto an operation that is still figuring itself out is a well-known way to waste money.
The problem is not the spreadsheet. The problem is what happens when several spreadsheets have to agree with each other.
The real problem: your data is scattered
When a business runs on spreadsheets, information ends up spread across the company. Sales in one file. Stock in another. Accounting somewhere else, probably on a different machine. Each is accurate on its own. Together they never quite agree.
That is not carelessness. It is arithmetic. Every transaction has to be recorded in every file it affects, by a person, correctly, at roughly the same time. Miss one and the files diverge. Nothing alerts you. The divergence just sits there until someone stumbles into it.
Four symptoms, and what each one is really telling you
Decisions wait for files. Before anyone can decide anything, someone opens two or three sheets and reconciles them. The decision is not hard — finding trustworthy numbers is. So decisions get postponed, and postponed decisions are what slow growth actually looks like from the inside. Not a dramatic failure. A business that takes four days to answer a question a competitor answers in four minutes.
Calls happen just to check small numbers. How much of this do we have? What did we quote them last time? Has that payment come in? Each is two minutes. There are a dozen a day. The cost is not the twenty-four minutes — it is that every one of them interrupts two people, and interrupted work is materially slower work.
Stock mismatches surface in client meetings. The worst possible moment. You commit to a delivery based on the stock figure you have, then discover the real position is different. You are now managing a relationship instead of fulfilling an order. Do that twice with the same customer and you have taught them to verify everything you say.
Everyone blames data mismatch. This is the diagnostic one. When "the data did not match" becomes a routine explanation rather than an incident, it has stopped being an error and become the system working as designed. A business that has normalised its own unreliability has stopped noticing the cost.
Putting a number on it
Most owners feel this cost without ever measuring it, which is why the decision gets deferred indefinitely. A rough calculation is usually enough to settle the argument. For one month, count:
- Hours spent reconciling files, by everyone, including you
- Hours spent entering the same transaction into a second and third place
- Decisions that waited more than a day for numbers
- Orders, deliveries or quotations that went wrong because of a figure
- Value of stock you hold "just in case", because you do not trust the count
That last one surprises people. Distrust in your own inventory data is usually financed by carrying more stock than you need, and the interest on that working capital is a real, recurring cost that never appears on any invoice.
What changes with one connected system
Before software, everything sits separately and the company runs in a mess it has learned to tolerate. After, everything sits in one place.
The mechanism is simple: one event, recorded once, updates everything it affects. A sale reduces stock, posts to accounts, and changes the position you quote from — automatically, at the moment it happens. Nobody re-types anything, so nothing can diverge.
The practical difference is that your team sees the exact number when they need it, without asking anyone. And there is a change harder to put in a business case but obvious to anyone who has been through it: you feel calm and in control. Not because the work got easier, but because you stopped making commitments on numbers you privately doubted.
When Excel is still the right answer
Do not move for the sake of moving. Spreadsheets remain correct when:
- One person maintains all of it, and that is sustainable
- Transaction volume is low enough that reconciliation takes minutes, not hours
- Your process is still changing month to month
- You are modelling or analysing rather than recording operations
Even after moving, Excel does not disappear. It remains the best tool in the building for one-off analysis — exporting data from a system and cutting it a new way is perfectly sensible. What changes is that it stops being the system of record.
How the move actually goes wrong
Three failure modes account for most bad implementations, and all three are avoidable.
Dirty data carried across. If your item master has three spellings of the same raw material, the new system will faithfully hold all three and your reports will be wrong from day one. Cleaning master data before migration is the least interesting task in the project and the best predictor of whether it succeeds.
Everything at once. Implementing every module simultaneously changes every job in the company in the same week. The usual result is that all of it gets used badly and people quietly revert to spreadsheets alongside the software — which is strictly worse than before, because now there are two versions of the truth.
No parallel run. The period where the old and new systems run side by side is what builds trust in the new numbers. It is also the first thing cut when a project runs late, and cutting it is how you end up with software nobody believes.
A sensible first step
Start with the sales–stock–accounting triangle. That is where disconnection turns into customer-facing problems, so it is where the return is fastest and most visible. Get those three connected and trusted before touching anything else.
The short version
It is not your team. It is your system.
Bring everything into one place and the things quietly consuming the week — reconciliations, checking calls, corrections after the fact — stop existing rather than getting faster. That is what custom software is for, and the first conversation should be about your process, not a product demo.
Share this article
