Why most "digital transformation" projects solve the wrong problem

A business owner calls us with a clear request: "We need a new website." Or: "We need a CRM." Or: "Can you build us a dashboard?"

Nine times out of ten, that request is correct and insufficient at the same time. The website, the CRM, the dashboard — these are usually real needs. But they are rarely the actual problem. They are the first visible symptom of something that happens earlier, somewhere between the customer's first enquiry and the work getting done.

The pattern we keep seeing

Most failed projects solve the wrong problem well. A beautifully built CRM that nobody updates because the sales team still prefers WhatsApp. A dashboard with accurate numbers that the owner stopped checking three weeks after launch because it didn't answer the question they actually had. A new website that looks sharper than the old one but still can't tell a buyer whether a product is in stock.

None of these are failures of execution. They are failures of diagnosis. The team built what was asked for, not what was needed — and the two are not always the same thing.

Why this happens

It happens because the request usually comes from the point in the business where the pain is most visible, not from the point where it actually starts.

A founder sees that the sales team keeps asking for updates on orders. The visible fix looks like "a dashboard." But the dashboard doesn't help if the order status is still being typed into three different spreadsheets by three different people, none of whom know the others exist. The dashboard would just be showing you, faster, that your data is wrong.

A distributor sees that scheme claims from retailers are getting lost. The visible fix looks like "a claims portal." But if claims arrive by phone call, email and a handwritten register with no single owner, a portal is one more place information can get stuck — not fewer.

This is the trap: building the tool before understanding the process the tool is meant to serve.

What a real diagnosis looks like

Before recommending or building anything, the useful question isn't "what do you want built?" It's "how does this actually work today, step by step, for a real order or a real enquiry?"

That means tracing one transaction from start to finish:

• Who first sees the enquiry, and on which channel?
• Who decides what happens next, and how do they know it's their turn?
• Where does the information currently live — a phone, a notebook, an inbox, a spreadsheet?
• What happens when the person responsible is unavailable?
• Where does the founder personally have to step in to keep things moving?

That last question usually tells you the most. If the founder is still the connective tissue holding the process together — chasing updates, re-confirming details, being the only person who knows the full picture — no new software fixes that on its own. The software has to be built around a process that doesn't depend on one person's memory.

A short, real example

A distribution business came to us wanting "a website redesign." Fair enough — their site was eight years old. But when we traced how a retailer actually placed an order, the picture was different: the order arrived on WhatsApp, got copied into a spreadsheet by hand, stock was checked by calling the godown, and the invoice was raised a day later once someone remembered to. The website wasn't the business's weakest link. The order-to-invoice chain was.

We still rebuilt the website — it needed it. But the project that actually mattered was connecting enquiry, stock and invoicing into one record, so the retailer's order didn't depend on three separate people being available and paying attention at the same time.

What this means for how you brief any project

Before you ask anyone to build you a website, a CRM or a dashboard, it's worth spending a week tracing how one real customer journey actually moves through your business today — not how you assume it moves, but how it actually happens, including the workarounds.

Three questions are usually enough to start:

1. Where does information get re-typed or re-entered that shouldn't need to be?
2. Where does a decision wait on one specific person being available?
3. What would happen to this process if you took a two-week holiday?

The answers to those three questions are a far more reliable brief than "we need a new website." They tell you what to actually fix — and, just as often, what order to fix it in.