My Webstock talk in Wellington this year is now available on video at the Webstock website or read on for a written version.
I have young children, so I don't travel too much, but a couple of times a year I go to conferences like this one, and I normally stay in whatever hotel is close by.
After I've been travelling for 20 hours and have struggled into the room, assuming the key card thing eventually works, I normally just want to have a shower and a sleep. I'm not a stupid man, I'm normally fully capable of using a shower. But hotels don't use normal showers with a hot tap and a cold tap.
They use these unmarked almunium blobs with no obvious purpose. So you have to waggle around whatever moves and hope to eventually hit on the one spot between scalding and freezing, and if you're lucky that's at a water pressure which doesn't risk serious eye damage.
Last year in San Francisco I was seriously reduced to choosing between calling down to the front desk and googling for instructions. I'm sure it's super obvious once you build an accurate mental model of what the controls are actually doing, but for me it became a kind of ritual - I'd just try to set the shower to the exact spot each time and wait while it decided whether or not to grant me warm water.
I eventually did mention it to the front desk staff, and they say "oh yes, a lot of people find it tricky!". Somehow though I doubt that information has ever made it's way back to the people who choose the fittings for 600 room hotels.
I'm sure the hotel's staff get measured on customer satisfaction and complaint rates. But "Guest's ability to operate shower competently" probably isn't appearing in the monthly metrics.
Now I realise you all didn't come here to listen to me complain about showers (and I promise, I have actually showered successfully today). What I'm talking about is how much valuable information is stuck, trapped on the frontline of your website or app or product.
I don't know what all you guys do. Designers? Developers? Product managers? Any customer service people?
Alright, so what I want to do today is to explore this idea, that there's important information about your customers, about your potential customers, and your products and services, important information that you just don't have access to right now.
I want to look at what you might be missing out on, why it happens, and then give you some ideas on how to unlock those secrets and really get the most out of your customer service team.
Part 1: The problem
Can we do a quick survey here: If you're in the design or product / dev areas, stick your hand up. Ok, now leave it up if you think that your customer service team, if you have one, are at least competent.
Great. Now leave it up if you think you know as much about the important information about your customers as they do.
So there you go. So we're going to look a little into what sort of information is locked up in support heads and ticket systems. I want to be clear who I'm aiming this at.
If you look around for information on customer service you'll generally find two extremes.
Incompetent: insurance , banks, telecoms (really means powerless and undervalued) Heroic: zappos, happiness heroes, above and beyond, diving catches
I'm going to assume that if you are here today, you're probably not from a company with incompetent support. Maybe you are...I'm sorry! But this talk won't save you.
I want to talk more to the companies who have that ideal of the super hero support as their target, because I think that's actually part of the problem.
Heroes are great! Who doesn't like wearing a cape? Sometimes you do need your customer service people to make the amazing effort to save the day, and you look awesome and it's on the news.
Fighting super villains and monsters is by nature very reactive; the problem shows up and you whip out the lycra and fly in to the fight. All you can do is keep fighting and hope that the don't have whatever your version of kryptonite is.
What I am suggesting is that you also need someone back at HQ who spends their time working out why there are so many lab accidents and nuclear leaks in this town, and maybe taking a look at the safety protocols.
This analogy has gotten away from me a little.
What I'm saying is that if you plan your customer service around heroic moments, you reward that above and beyond behaviour, and you can rely on them saving the day, you might be missing out on their most valuable contributions.
Your support team can do a lot more for you than just "make people happy" or "save the day", if you let them.
Like what? You say:
- Categorising and tagging customer feedback in a way that's much more accessible to your product managers
- Recording feature requests with context about which type of customer is making that request and where in the lifecycle they are
- Surfacing all those myriad irritations that your CS team "just handle" over and over every day
- report on cringe factors that are not visible
- tell you about customers using the product in unexpected ways
- Noticing that your biggest customer is asking about integrations with a competing product.
So one part of the problem is just missing out on information that would be really useful. It can also be actively costly to you.
You might waste time and money:
- building a product that people don't actually use because you didn't really understand what they wanted, only what they voted for.
- Focusing on big wins that take months to build but bleeding to death by 1,000 tiny-issue churns in the meantime.
- Building the right thing but misunderstanding how to explain it to customers and having it not be used because they don't "get it".
Alright, that makes sense. Don't want that. But can't you just ask your customers directly? Yes you can, and of course you should.
Surveys, customer interviews, in-app recording of usage, these are all valuable things. There are a couple of reasons you may not want to rely on your customers direct responses:
- Customers don't always say what they mean
- They don't know what they don't know
At Campaign Monitor we don't have public request system, because having a list of "possible features" is just asking people with no investment in the effort or opportunity cost to vote for things that sound cool.
That does not mean they'd ever use them, or consider them worth paying for. If you ask someone "do you want any of these things" they'll probably say yes.
But then when you build that feature....they don't use it because their actual need hasn't caught up.
And the second point; they don't know what they don't know. This is the famous Henry Ford quote about people just asking for faster horses. Though to be fair...pretty awesome.
So a quick recap. Your customer service team have a bunch of valuable information about your customers and your product, information you probably can't get from your customers directly.
So what's the problem, why aren't they just telling you this information? Good question, I'm glad I'm pretending that you asked.
Part 2: Why are the secrets locked up?
In my time at Campaign Monitor I've answered a lot of tickets (I stopped counting years ago when it crossed 50,000). I must have answered essentially the same question about more than 100 times before I finally made enough time to think about the underlying issue and try to get it fixed.
To understand why your customer service team might not be telling you everything they know, you need to think about the context they're in.
You know those horror stories where everybody in the village knows about this beast, it's never on camera but everyone feels it? That's how customer service people talk about "the queue".
The endless, Sisyphean task of the queue. Every conversation with customer service teams ends with "Tickets are Coming".
It's very hard to break away from "one more ticket" to make some space to share information in a useful way. The queue is relentless, but there's also that little dopamine hit of success every time you resolve a ticket.
I always knew, intellectually, that if I took time out of the queue to write up some suggestions for the product guys that I could eventually save myself a lot of work.
I knew it to be true. I just couldn't make myself do it. The queue is an insatiable beast, but, like, a friendly one.
So that's the biggest reason, I think, that customer service people default to just answering more questions rather than doing the things that will ultimately reduce the questions coming in.
I talked to a bunch of other people from similar companies to mine, and asked them what stopped them from sharing more information with the people who could do something about it.
Here are some of the top reasons:
- CS people don't have time to share information
- Don't have power or access to tell anyone influential
- They don't realise that other people don't know
- Don't have tools to record information
- Don't have authority or encouragement to ask questions as well as answer them
- Are not respected as an organisation
- lip service to "customers are our most valuable" blah blah
- You aren't paying enough / there's no reward
- Communication about problems is read as complaining
- CS people are measured on the wrong metrics so there's a disincentive to listening
- We celebrate the heroic moment and not the long term improvements
- They are told to pass on information, but every process and measure actually dissuades them
- They've been ignored in the past
- They don't know who to tell
- They don't know about your future plans and so miss opportunities to ask the right questions
- a poor attitude towards the customer is obvious
- It's being recorded and then ignored
- Being involved too late in the process
- Not understanding what the development process is / where feedback fits
- Aren't shown work in progress early enough
Chances are that one or more of these apply to your company too. Not so long ago at Campaign Monitor we released our new email editor. It had been many, many months of work and was a massive project on a core part of our product.
It was super slick and modern and made a whole bunch of new things possible. We had a video. With a custom written song. About an email editor.
We pushed it live and hit publish on that blog post and the comments started arriving. "We love it, except we need to change fonts and colors" - essentially that same comment in many variations.
And in our internal hipchat discussions the customer service team were saying "of course! We knew that would be a problem!". They had asked the same question themselves in the pre-release demos for support, but by that stage the decision was long made to leave it out at least for version 1.
So the comments kept coming in and support had to keep trying to answer, explaining the philosophical reasoning and recording the feedback until eventually we added that feature. That's a good way to reduce customer service morale, incidentally - make them really feel the pain of a mistake they saw coming but couldn't prevent.
And I know from experience that there is frustration on both sides of the situation. The product team are always disappointed when what they release is affcted by these sorts of missing pieces. It takes some of the impact away of the stellar work they've done.
Everyone is realistic enough to know we'll never get it 100% right - there is no 100% right - but there are times when a mistake becomes apparent immediately.
That's just my most recent example, but there are many others from every team out there. I know of a team who removed what was a minor piece of under-used functionality, not realising that a super high value customer was absolutely relying on it.
I've also seen the affects of changing an inconsistent piece of behaviour that turns out to be a critical work-around our support team had been promoting for years.
Sometimes the affects of information blockage aren't so visible. I won't use names here, but we had a really high profile customer, worth a lot of money.
They'd been loving the support they received, the satisfaction ratings were amazing. They paid their money on time. All the metrics looked great.
In fact, they'd given us excellent feedback about the quality of our support team. It turned out though that the reason they knew we were providing great support was that they kept running into an edge case issue, and we kept heroically leaping in to fix it up and save the day.
The support team had recorded the feedback, but for whatever reason it didn't get to the right people, or it got to the right people but without enough information for them to understand.
This customer eventually left; at that point we finally connected the right people but it was too late. A double pain because not only had the right information not got to the product and dev teams, but in fact one of their main issues was already on the roadmap to be fixed; support just didn't know that.
Just a little bit of information exchange could have made all the difference, letting support give reassurance that a proper fix was coming, and getting it prioritised earlier.
So that really hurts, but it's also an example of when we actually found out about what the communication gap had cost.
How many more times must it have happened without us ever knowing? Too scary to ask.
So what's the answer? How can we, and you, do better about exchanging information?
Part 3: Unlocking the secrets
So far I've covered the problem, and why it can happen, and I hope you're still with me. Let's talk about what we can do about it. I want you to go away today with some really practical, implementable options that could make your support team much more valuable to you and ultimately to your customer.
Tell your customer service team what it is you're looking for
- Let them know about the upcoming areas of interest, so they can ask smarter questions and give you answers with more context.
- Include support staff in your planning meetings and triage
- Be explicit: "pass on feedback" is not as helpful as "we want to understand why our customers are trying to upload this type of file".
Give them the tools and skills to find and share insights
- Give your team information about your customers. Not every feature is intended for every customer. Help your support staff understand which questions to ask which customers. Personas, example customers, share interviews.
- Give them some question patterns or examples of how to find the reason behind the question. They may not have the product management background to know where to dig in, and what's important.
- Share examples of great information gathering, to encourage the right behaviours.
- Include support on customer calls so they can hear how your product and sales team talk to customers. This is a different sort of support you're asking them to do.
Create an environment that encourages sharing
- Be open about acknowledging feedback. At Campaign Monitor we maintain a support cringe list - things which aren't necessarily "problems" but that are hard to explain or feel wrong.
- Give them clear, accessible tools that make it faster and easier to record information. See our suggestion tracker for example. It's a front end to JIRA just for support to use.
- Measure the information sharing behaviour. What you measure determines what will change. We have a simple leaderboard tracking the number of suggestions / bugs / information added.
- Acknowledge contributions internally, to reinforce the idea that sharing knowledge is valued.
- Actually use the information, or give your team feedback as to why not. They need to know they are not wasting their time.
- Allow time and space to dig for more information, and celebrate time spent in that way.
- Consider all-team support to understand the context support people are working in so you can build the right tools and processes.
You can probably come up with 100 other ways to encourage your own team to find out more and to share it more effectively, it will obviously depend on what the factors are that are holding them back.
I can tell you that for my team, when I surveyed them specifically it was so much about involvement in the product road map. We had, and still have to a lesser degree, a pretty tightly held plan about what was happening when, and that has meant support not having an opportunity to contribute useful details to the product planning.
So for us, the solution is to share the roadmap, to involve support earlier and to be specific about what sort of information the product team would like to know.
For you, it may be a different problem, and you'd pick an appropriate measure. The point is that the truth is out there, you just have to find a way to get at it.
- Your customer service team know things you don't
- It's hard for them to tell you about it
- Make it easier
You can find the slides and notes on this very page: trackydacks.com/webstock
Go unlock some secrets Webstock!