Why it’s never OK to ignore the customer experience

“This is a tech project; so why do I need to consult the customer?”

Sigh. During my working career I have heard this very question (well, it’s more of a statement really) more times than I would have expected. Sometimes it was worded differently and may have sounded something like, “No, no, no. We don’t need to talk to end users; it’s just forms.” Or, “This is purely technical — there are no customers involved.” Or even, “This is about employees, not customers.”

Many years ago, when I was managing customer contact centres, IT was notorious for imposing changes to the systems my teams were using without seeking understanding on how it would affect both staff and customers. Before I had even heard of customer experience, I instinctively knew something wasn’t right. Of course these technical changes would affect the way staff interacted with customers, and the way we would be perceived by our customers. Whether that perception was positive or negative, the impact needed to be understood before moving forward.

Regardless of the change — whether it’s adding a field to a CRM or rolling out a new enterprise-wide solution — tech providers and organisations need to rethink and re-evaluate the role customers and employees play in the technology landscape.

Let me state up front, I am no Luddite. I love technology and what it can do for us. I love the opportunities afforded us through its constant evolution, and the options it offers us for more efficiency and to create better customer solutions. Call me a geeky pragmatic customer experience evangelist.

But I’m also of the opinion that technology works better when we give it a little help. Knowing what our customers really want and how they feel about proposed changes to the way they do things makes delivering technology solutions if not easier, then certainly more successful.

So why and what do we need to understand about the customer when we are delivering a technical project?

In simple terms, we need to be sure of who we are making changes for and what they really want, otherwise there is a good chance we will deliver the wrong solution.

Customers and users want to know what problems we are solving for them, not how cool the technology is. To fix problems, we need to first understand what they are, and this leads me to the next point.

“I’m the expert, I’ve done this a thousand times before.”

This statement, which I’ve also heard more than I’d like, is one that worries me. Although experience (and the knowledge and wisdom that one hopes comes with it) is invaluable, it can also come back to bite us – especially when we use it to make assumptions.  It’s not that I discount knowledge gained in previous undertakings, but treating each tech project like a “cookie cutter” of the last is fraught with danger. Ultimately, unless projects are executed under exactly the same conditions, with the exact same staff, customers and solutions, a gap exists in which failure can rear its ugly head. [Dramatic pause.]

We can never mitigate every risk when delivering a technology solution. Things often change beyond our control or expectations. However, it is fitting to gain a level of understanding that will provide us with the best chance for success. This means understanding the problem we are proposing to solve and testing the proposed technology solution with those who will be using it.

Just to be clear, I am not talking about user acceptance testing or change management (although both play an important part to ensure success). What I am referring to, is understanding the needs and behaviours of those who will be affected by the changes being delivered.

This understanding is achieved by conducting employee and/or customer research, benchmarking the current state and learning how the proposed changed environment will impact these groups. The organisation will gain clarity as to how the different groups and individuals will respond to change, and will be able to revise and modify the solution to reduce risk or rejection and ensure that the implementation of the tech solution will be positively received.

 “But I haven’t budgeted for that level of research, how much is it going to cost me?”

The answer: How much more expensive is failure?

Organisations need to consider how much more they will need to spend to deliver the solution users expect. If you don’t know the problem you are solving, then how are you sure that what you deliver will be successful? How can you be sure you are solving the actual problem and not a symptom?

If you do not evaluate the impact change can have on customers, it can result in catastrophic consequences far beyond just a few customers losing faith in your organisation.

I’ll tell you a quick story, modified to protect the innocent.

A utility organisation developed a tool that would help field staff undertake components of their work. The tool was designed so that the workers could open an app on tablets and choose from a dropdown menu with options and information. Workers could also take notes on the tablet about particular tasks they were performing. It was hoped this would aid efficiency.

A great deal of time was spent in development to be sure it would look and feel great and be effective. The company wanted uptake by the field force to be high. In testing in the office, the app was working perfectly. It was quick, smooth and looked great. The development team was extremely happy.

The decision was made to deliver this tool to the workforce and things quickly went downhill.

At the first work site, the field staff looked at the delivery team strangely and asked them how they were expected to use it.

The delivery team was confused and told them it had tested perfectly in the office.

“That’s because you don’t wear safety gloves in the office, mate.”

The lead hand at the depot told the team that the only time they would need to use the tool was in situations where they would also need to be wearing gloves for safety reasons, meaning there was no way to use the tablet.

“Why didn’t you ask us?”

As this true story shows, sometimes the solution we are told to execute, although technically correct, is just not right. Sometimes the decision makers aren’t close enough to the problem to know what they are solving. The only way to be sure of the right course of action is to ask the end users.

“See you later! I’ve ticked all the boxes; my job is done”

True. But what happens when the customer recognises that you ticked boxes but didn’t actually solve the real problem?  You’ll get paid because the contractual terms have been met, but overall customer satisfaction will be low, reducing the opportunity for repeat business.

As the saying goes, “If you are referring to the contract, the relationship is broken.” This is so true. Projects are truly successful when they deliver not to the letter of the law, but to their purpose. Using a customer experience research and design methodology allows you to find and deliver for that purpose, and solve that identified problem. This sort of delivery is what grows relationships and opens the path to future opportunities.

Let me make a final point. We “customer-centric advocates” are not just about fluffy clouds and back rubs. There has to be pragmatism involved in making appropriate decisions. The actual reason for undertaking any technology change is to make things better for the users and/or the organisation. Sometimes that means finding a balance between these two needs.

If we have knowledge about true needs and behaviours and the problems we are trying to solve, we will be better able to make those “balance” decisions with clarity and an understanding of the consequences, and thus have a greater chance for successful delivery.


Rob VilenskyRob Vilensky is a Senior Customer Experience Designer and member of the Customer and Employee Experience team at DXC Consulting ANZ. He has extensive knowledge of customer experience provision, service design and transformation. With a background in operational contact centre management, coaching and mentoring staff Rob is also experienced in leading development and delivery of customer-centric learning and capability uplift programs.

Comments

  1. Ha love this article. Customers are grateful for geeky pragmatic customer experience evangelists! 🙂

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: