Live Chat and Lean Manufacturing. My co-worker Simon ponders the similarities between live chat support and continuous-flow manufacturing. Beyond number of questions answered the piece which intrigues me is completed problem sets. In other words, define a complete customer problem set as ABCD. What percentage of live chats work through that complete set versus what percentage have the customer bail midway through? And, how does that compare to email support?
Tag: customer service
The greatest wildcard
But the greatest wild card of all in all the data, and the most precious piece of information for any happiness engineer hoping to solve any ticket, is the customer’s own perception of what is wrong. And the gap between what people think is wrong and what is actually wrong can be quite far indeed.
Scott Berkun – The Year Without Pants.
How to Collect Customer Feedback That’s Actually Valuable. A look inside how the team at Intercom collects and synthesizes customer feedback.
2014 was a good year for Basecamp support. Noah Lorang recaps what last year looked like for the Basecamp support time. Their median response time astounds me. Pretty impressive work from a relatively small team.
Verizon Live Chat
I shared this on Twitter earlier but wanted to log visually here. Verizon’s live chat support has three shockingly poor things wrong with it.
The text is large, blue, and Comic Sans.
The form is broken in Safari as you get this big bar over the text field.
The tab title is “Engagement Window.” Eww.
I reported each issue to them, of course. Unfortunately they said, “we do have issues with the Safari browser” and suggested I use Internet Explorer.
Documentation, Support, and Customer Success. Simon writes about how documentation is a psychological band-aid in how it calcifies habits and shifts responsibility.
People will read
Last July Ryan Pitts and Sara Schnadt led a session at SRCCON about human-driven design. It wrapped up with a discussion of various maxims that guide design processes. Someone in the room said it was important to remember that, “users won’t read, ever.” That rubbed me the wrong way at the time and I went on a mini-rant in the session. I was thinking back to this recently and wanted to sketch the idea out into a longer post.
The perception that people don’t, and won’t, read documentation is not uncommon. There’s a reason we have the acronym RTFM after all. I think it’s a perception that’s horribly misguided and short-sighted for your product.
People will read. What they won’t do is unquestioningly read on your terms.
Treat docs as product
When you’re developing a product you don’t ship something and passively wait around for it to become popular. If what you shipped isn’t gaining traction you iterate. You tweak and adjust until your product fits its addressable market.
For some reason we don’t approach documentation with the same mindset. Our predominant expectation is that we can ship docs and expect every person to read them. If the docs have up-to-date screenshots, are detailed, and are searchable then that’s enough. If people don’t read, that’s their fault not yours. That’s a fundamentally broken expectation.
Most importantly, if you react to support requests by wondering why people can’t read the docs then you are missing a golden opportunity. You are directly blaming the person using your product instead of blaming your product for requiring documentation in the first place.
Exploratory & Prompt-Driven Users
Part of the RTFM-mindset stems from an assumption that everyone is an exploratory learner. That’s wrong. It’s arguably true for many tech folks. That doesn’t make it true for many people using our products.
Exploratory people will find their own way. They are comfortable with uncertainty. They’ll use a confusing product and feel confident relying upon documentation for answers. To them this is part of the appeal. Each awkward setting or obtuse workflow is an opportunity to master the intricacies of yet another product.
Prompt-driven people will read docs, but it’s not their default. They will first look to your support team for help. You could also think of them as human-reliant people. Interactions with your support team may prompt them to read and reference docs. So it’s not that they won’t read. It’s more that they prefer human interactions to help guide them.
Here’s the thing about prompt-driven people: they are a potential gold mine of qualitative feedback. There is no better source of information to help guide your product teams. Yes, this means your support team has more tickets to respond to in the short-term. That’s a great thing.
Every one of those interactions is an opportunity to learn more about how people use your product. If you choose not to take advantage of that and instead blame people for not reading your docs and leaving you alone in your cave, then that’s your loss. The next time you find yourself blaming a customer for overlooking the “obvious” answer in your docs, ask yourself whether you’re reading enough of what they’re telling you. More often than not I think it’s those building a product that don’t read, not our customers.
Thanks to Simon for helping clarify some of the wording in this post.
Four Million to One. How Brian Cervino handles support for Trello. What stood out most to me was that 4 million users generate just 300 support threads a week.
Task-centered support
In the past I’ve written about focusing on the particular task a customer is stuck on. Reading The Design of Everyday Things reminded me of that mindset. Donald Norman writes:
In their work, designers often become expert with the device they are designing. Users are often expert at the task they are trying to perform with the device.
Norman’s description is apt, I think. It got me thinking about the role of support, too. In many ways the support experience starts when a customer’s ability to complete a task breaks down.
A product is more than the sum of its menus and settings. A product is ‘Hello World’, not the code which generates that. A lot of what defines support is how you take someone from being stuck to finishing whatever it is they wanted to do.
People are unlikely to poke through every setting just because they are there. You do that when you are mastering a device, not when you are completing a task.
Nerds are great at digging through the layers of a product. Customers are unlikely to be nerds. Rather than understand an entire system they want to get something done. Less time with a product means more time for their project.
Next time a customer writes in and is stuck, try to stop yourself from wondering what about the product they missed. Instead, think about what task they are trying to complete. Think about how your product helps them get there. Your customers will thank you.
Support as creation
Too many companies pigeonhole customer support as just answering questions. It’s a cost center they believe exists only to maintain the status quo of customer happiness. This definition misses something powerful. Great support is an act of creation.
Whether you focus on the practical elements, or prefer the intangible values, support has more to offer when viewed through the lens of creation. From documentation to personal experiences, support turns a faceless product in to a product that these people made for me.
Your goal is to craft joy. Out of a frustrating customer experience your team will create a memory of happiness, helpfulness, and appreciation. Instead of a cost center your support team becomes a department which creates and educates loyal customers. Where once resided a team just answering questions now lives the frontlines for creating your tribe of happy, repeat, and profitable customers.