What We're Seeing
You Upgraded the System. Did Anyone Check What the Customer Feels?
Growing businesses love a good systems fix. New CRM, new job-management software, a proper project pipeline instead of a whiteboard and good intentions — it's satisfying work, it's measurable, and it genuinely helps. We're fans of it. We do a lot of it.
But here's the thing nobody quite budgets for: a systems project that only looks at the business's internal experience can accidentally make the customer's experience worse, even while everything internally gets better.
How this actually happens
A new system usually gets built around what the business needs — clearer reporting, better handoffs between teams, less manual work for staff. All genuinely good things. But somewhere in that process, the customer's side of the interaction quietly becomes an afterthought, because nobody in the project was specifically responsible for asking what it's like to be on the other end of it.
The result is a very specific, very avoidable kind of failure: internally, everything's smoother. Externally, the customer is now getting an automated email that doesn't sound like the business they liked working with, or filling in a form that asks for information the business used to just remember, or waiting on a "streamlined" process that's actually slower for them, even though it's faster for staff.
A systems project that only looks inward can make the customer’s experience worse, even while everything internally gets better.
The tell-tale signs
You've probably got this problem if any of these sound familiar: customers started asking "is everything okay?" after a system change, even though nothing's actually wrong. Staff have started apologising for the new process before customers even complain about it. Or the loudest praise for the new system is entirely internal — "so much easier for us now" — with nobody able to say confidently whether it's easier for the customer too.
None of this means the systems work was wrong. It means the customer experience needs to be treated as its own deliverable in the project, not an assumed side effect of making things better internally.
What actually fixes it
Map the customer's actual journey through the new system, end to end, from their side of the desk, not the business's. Read the automated messages the system now sends as if you were the customer receiving them, not the business sending them. And ask, specifically, plainly: did this change make it better or worse to be a customer here? If nobody on the project has clearly answered that question, it probably hasn't been asked yet.