In this series to date, we’ve looked at the issues faced by the outsourced services industry. From the drive to be the lowest cost bidder and the gap that creates to customer expectation and value creation, to clients who are desperate for some innovation.
Now we’re getting down to cases and it’s time to bust some myths.
Myth #1: It’s all about technology
Honestly, it isn’t. Is tech important? You bet! But is it what people buy? What people care most about? I’m afraid not.
When technology fails, accidentally or through a poor set up, people get frustrated. A chatbot that doesn’t understand or has no empathy is of no use. And people are often a decent judge of what they need – they don’t want to call you any more than you want them to call you (remember the 65% with their head in the loo). They don’t want to wait in a long queue, but if they’ve got a complex problem or can’t find what they need, then they need to talk.
“A chatbot that has no empathy is of no use”
How you deliver through technology comes down to the insight you have drawn, from website interactions to frustrating calls. The bad stuff is gold if ever you want to make it good.
Technology must, therefore, be agile and responsive, not big and lumbering. But technology is nothing without the people. Technology instead of people at the wrong time is a brand disaster.People matter, technology must be intuitive
Myth #2: Channel choice is critical
How many meetings or design sessions have you had on how to navigate customers to the right one? How many messages do you play in your IVR telling customers they could do stuff for themselves online (as if they don’t already know…)? How many on hold messages do you play saying your call is important to us…?
I know that people saychannel choice is critical, but the reality is that they will use whichever ones they think will give them answers. All at the same time.
“People will use whichever channel they think will give them answers. All at the same time.”
If they can’t get through on the phone, they’ll send you an email. Then when that doesn’t work they’ll start a webchat. Where it falls down is when channels and more importantly channel integration fails. It comes down to understanding the profile of the customers in question.
One size does not fit all.
People want answers, not channels.
Myth#3: People want experiences
Really? Even when they’re placing their grocery shop order, they’re having an internal dialogue about what a great experience they want?
If you’re a destination or experience business, then yes, that’s what you’re there for. But I can guarantee that I’m not setting out to have a great experience when I’m buying my insurance, ordering groceries, or changing my utility company. I just want that to be EASY.
“I’m not setting out to have a great experience when I’m buying my insurance.”
People don’t care about “having experiences”, unless it’s a bad one. Then they care a lot and it’s not one they want to repeat. No doubt they’ll tell you. The whiff of a standard response is likely to set them on edge even more. And I’m afraid relentless offshoring has a significant impact as things are easily lost in translation, as well as certain types of queries having to be passed back to someone onshore, or in another site somewhere else. It’s just not joined up.
Disparate services delivered by different providers and the misuse of emerging technologies is likely to send them shouting about their non-seamless experience from the rooftops. Or on Twitter.
So I suppose, yes they do want a “seamless experience” but only because a non-seamless one is such a let down. Come on, it’s what they expect at a human level, not something to be lauded and commended.
People want to be dealt with on a local, human level, easily and seamlessly.
In short, people matter. Technology must be intuitive, you must provide answers not channels and deal with people on a human level, in ways that suit them best.
In my final post of the series, I’ll focus on this final, central idea: People matter.
We are Woven.
Convention making. Industry leading. Market defining.
Find out more: