Tag: support

Use the Data You Have: Explanation and Context

Most conference talks are the worst. We can acknowledge that, among ourselves, right?

Many folks don’t properly prepare, they don’t expend any care into their visuals, and they fail to bring anything like the kind of value that they could.

I’m not saying that people who present at conferences are the worst. By and large they’re actually the opposite – they’re some of the best and brightest and most interesting people in an industry, and that’s why they’ve been invited to speak at a conference.

(sometimes they’re even being paid to speak at the conference)

I think it’s more that socially, at least Americans, we conceive of public speaking the same way we conceive of learning mathematics. It’s like a light switch. You’ve got it or you don’t.

“I’m not a math person.”

That’s nonsense of course. But, it’s pervasive, and it unfortunately really sells us short on both ends – folks who have a ton of amazing things to say don’t use their voice because they think it’s simply the way, when it’s more a matter of work, and practice, and preparation.

The other side of the coin are the folks who think they’ve got it, that charisma, and preparation is for squares who don’t have it.

That’s nonsense, too, naturally.

This is a long way of providing context for a series of Posts I’ll be doing over the next few weeks. I’m speaking at SupConf later this month, and I am determined to provide a mountain of value to the folks who have travelled to San Francisco and trusted me with twenty minutes of their time. My talk is called Use The Data You Have. 

It’s about how customer support teams can create value within their companies and for their customers without running experiments or trying new and crazy stuff – just by using the data they already have.

One way I am assuring myself that I can provide some value is by creating the value way ahead of time, in the form of these blog posts, that will serve as a supplement to what I discuss in the talk.

(Don’t worry, they’ll be helpful in their own way as well, I’m not going to keep anything special away from folks who aren’t going to the conference, or are reading this in the future)

In some way this blog series is a way for me to hedge my bets: even if I completely mess up the presentation and look like a total buffoon, I’ll still be able to click through to my final splash slide and cry for redemption; look, look, all hope is not lost!

Plus, this series is going to be somewhat dry, with some screenshots and Google Analytics talk, which is important, but super dry and not at all suited for an in-person conference talk.

Watch this space!

 

 

SupConf Now Accepting Speaker Applications

logo1

 

If you work in hospitality on the internet, or even really UX of any flavor, you should know about Support Driven – it’s a blog, it’s a podcast, it’s a Slack group!

And now, the fine folks at Support Driven (including my dear friends Andrea and Andrew) are organizing an all-new conference, with a really interesting take on the speaker submission and development process. If you work with customers, as a support person or as a data person or really in any form, you should look into this conference – especially if you have something to say!

Talks are only 15 minutes long and are focused on actionable results – do you have a lesson or story that could enrich the experience of other folks in customer-facing roles? You should absolutely submit a talk!

 

Service and Hospitality are Different Things

photo-1417026846249-f31f7e43fc35-1400x862

Let’s talk about service and hospitality.

Relying on one-on-one experiences, on service, to delight your customers when you serve tens of thousands (sometimes millions) of people daily is untenable and inefficient.

Service and hospitality. These are two words that we throw around a lot when we discuss the work of delighting our customer once they have our product. After all, the essential function of every support team in a software company is to be the front line of your post-launch products.

My aim today is to convince you that 1) those two words have important and distinct meanings, 2) that traditional examples of customer service or hospitality do not serve us well, and 3) that we need to shift our focus in a meaningful way.

Let’s get started with some definitions.

Service is any interaction that occurs between an employee of the company and a customer (or potential customer, in some cases.)

Hospitality is the sum of all of the other environmental factors that impact a customer’s experience of your product.

Imagine you’re visiting a new town, and, as someone who cares about coffee, you’ve done some research and are looking forward to taking in an especially well-considered espresso bar. You arrive, and enter the place with a sense of anticipation.

It’s busy inside – music is playing quite loud over the house speakers, and the line stretches nearly to the door. It’s surprising to you since it is an off-hour for a cafe. Upon further inspection, it looks like they must be short-staffed, as the folks behind the counter are moving at a breakneck pace, and with very serious expressions.

Still you wait patiently, and when you arrive at the counter the young man who greets you smiles widely, and the interaction is perfectly fine.

You remember that  you have to shout to be heard over the music and din of the other customers, and speak up. You place your order, pay, tip well, and pick up your drip coffee.

Moving to the condiment station, it’s a train wreck – all of the milk dispensers are empty, one tipped over on its side. The trash is overflowing, and there is white sugar covering easily half of the surface. You decide to enjoy your coffee black and make your way back to the street.

This example is probably not so foreign. Despite receiving solid service from the company’s representative, the overall experience skews negative. A long line, a poorly written schedule, a failure to keep the shop tidy; these are small things but they add up to lackluster hospitality.

By the time you’ve tasted the coffee, you already have a bit of a bad time. Not due to any individual’s behavior exactly, but due to the sum total of small decisions made well before your arrival.

When we think of really outstanding examples of both service and hospitality, we usually think of high-end hotels or expensive restaurants; white tablecloths and Egyptian cotton sheets.These examples have guided hospitality and service very well for a very long time – largely through a focus on the way that representatives of a company interact with customers. This works very well for business that serve hundreds (sometimes thousands) of customers in a day.

Every business from a steakhouse to a social network presents a picture of hospitality to its customers. By virtue of being a customer you collect a sum of experiences with a company that impacts your view of that company and its products.

A hotel, restaurant, or cafe, gets (at the very least) one opportunity to provide excellent service. Often these businesses get more than one opportunity – the host at the front door, the bartender while you wait for your table, the sommelier, the waiter – excellent restaurants have many chances to balance out missteps in hospitality with outstanding service. In this way, investing heavily in those one-on-one encounters can pay dividends that outsize the investment.

For every high-end restaurant we have dozens of small cafes and pubs. Let’s say, conservatively, that traditional companies like this enjoy about one service experience per customer. That is, they have an opportunity to impact their product’s overall hospitality with outstanding service about one time per customer.

Consider WordPress.com – we receive only one support request for every four thousand blog posts published. For every four thousand uses of our product, we get only one opportunity to color that experience with outstanding service. I would imagine that for most software-as-a-service companies, that ratio is not far off.

If I was feeling bombastic, I’d say that for software companies, hospitality is four thousand times more important than service. Since these numbers are fuzzy, and I am nothing if not level headed and measured in my opining, we’ll instead settle on this:

For software companies, hospitality is three thousand, nine hundred and ninety nine times more important than service.

To delight our customers, we need to discard our traditional ideas of how service and hospitality operate, because we are navigating in a new and exciting space. Our traditional ideas will not lead us to success.

It’s time to find some new ideas – I’m excited. Are you?

This post originally appeared on Support Driven, a blog about hospitality on the internet

 

Live Chat and Lean Manufacturing

 

IMG_1883

In the Toyota Production System (TPS) and its ongoing adherence in Western companies (usually called Lean, often mixed in with Six Sigma processes), one of the ways that we are able to reduce waste is moving from batch production to single piece flow, or continuous flow.

The opposing styles here are characterized like so: if Process Zoidberg requires you to perform actions A, B, and C, and you have to perform 100 Zoidbergs, batch production would suggest you do _all_ of your As, then _all_ of your Bs, then _all_ of your Cs. Continuous flow would suggest that you do A, then B, then C, one hundred times.

When we think about supporting a customer base, we can visualize each customer experience as a finished product, with each of their questions or friction points as a discrete component. We could extend this metaphor to the entire product development life cycle, but for the scope of this article, let’s focus on the post-launch product support, by (mostly) dedicated support staff.

Thinking of customer support using the well-trod ground of manufacturing, we can start to use insights that have already provided serious gains for other industries – it can also help us to explain data that we already have, or better understand or phrase our support for new experiments and learning opportunities.

When we consider traditional email support from the side of the customer, a customer sends in a request, they wait, the support staff replies, wait, customer replies again, with a new question or concern, they wait, and so on. If you asked the customer, it looks a lot like an (especially slow) continuous flow model.

From the side of the support staff, we see a different picture: they reply to customer requests as they come in, working with many customers at many different points in that particular customers’ process. Rather than working with one customer from the beginning, through all of their questions, to the conclusion, they move from question to question.

When we consider live chat support, it looks to be much more in line with the continuous flow model – as a customer arrives, they are picked up by a support team member, and they are moved through each of their questions in turn, to the point of completion.

It would be interesting to see some data on how these two processes look side-by-side, especially in terms of efficiency of production – which here would mean customer-questions-answered. I acknowledge that it might be tricky to suss out exactly when a question is answered, especially in an automated way. Tricky, but interesting.

My hunch would be that providing support in the continuous-flow model would gain similar efficiency gains to the adoption of that model in other industries, but, that’s just a hunch.

Documentation, Support, and Customer Success

oIpwxeeSPy1cnwYpqJ1w_Dufer-Collateral-test-1400x1136

I’ve had a bunch of conversations recently around the role of documentation in hospitality on the internet. My friend and colleague Andrew posted about documentation recently, and of course my love for Buffer requires I point out their approach to documentation – documentation is such a big deal in support communities that we even have a conference dedicated to it.

When it comes to documentation, I am of two minds. Software development, especially code languages and learning code languages, involve a lot of documentation, and a lot of referring to documentation, and so forth. We need to recognize, though, that when we use code to build really awesome things, we are building those things for an audience who is perhaps not as steeped in a documentation-heavy culture.

Working in support for WordPress.com, I am grateful every day for the documentation that we have – for little things that folks can work out for themselves if they have a guide (like, say, a custom menu or static front page), and certainly for big things that are challenging even for me (intricate Theme setups especially).

Lately, though, I have been shifting my thinking on documentation. Part of this comes from doing some deep dives in our Google Analytics account for our docs, finally getting a real bite of how huge our docs base is, and seeing for the first time how much traffic they really get (about 60,000 visitors per day). Recently I’ve started to see documentation as a psychological band-aid, and as a sidestep to improved products. Here’s what I mean:

Docs as a Psychological Band Aid
When a member of our staff recognizes that we have a flow, or a feature, or some other piece that requires additional education, and they invest their time and brainpower in creating documentation for that flow or feature, we can breathe a sigh of relief, right? Now, when a customer asks about that flow or feature, we have a resource for them. That problem is solved. Here you go – read this. We’ve scaled. We can check that box.

The problem here, is that when ever we feel like that box is checked, we calcify our thinking on that issue – we think it’s taken care of. A question about X? Here’s our documentation about X. Especially in a company where staff feels overworked and understaffed (ie, all of them), this becomes the path of least resistance, which then becomes habit. A habit of deferring replies to documentation has two unfortunate psychological consequences: first, it calcifies us in a place where critical thinking no longer takes place. More on this in the next point.

Second, it (inappropriately!) shifts the responsibility from us, as hospitality professionals, onto our customers. It is no longer our job to create an excellent environment where they can accomplish their goals – now it is the customer’s job to read the documents we created for them – time spent in documentation is time spent not accomplishing their goals.

Docs as Sidestepping Product Improvement
Every support document is an admission that a flow or feature doesn’t Just Work. When we create a long series of nested documentation on how to accomplish something is an indication that something is hard to do. A great company makes its customers feel smart, safe, and powerful. Taking someone out of your features, out of your flows, out of the path to their success, to refer to documentation represents a point of friction, an obstacle.

If you want to take the principles of Growth Engineering and apply them to doing hospitality right at your company, take a look at the top search terms in your Support page. Take a look at how people use those documents. Those are break points, those are places where a document is acting as a band aid to a better UX, or a better product (in this, we could learn a lot from modern computer and video games, but that’s a post for a different day).

So What Then?
I don’t hate documentation. I think for a lot of use cases it’s necessary, and it can be done really, really well. I do think that serving our customers to the very best of our ability, however, means reducing our documentation, approaching problems with ownership and a critical mindset – not “Well why don’t they read the guide?” but rather “Why does embedding this require a guide?”

Documentation can be a great tool in the Internet Hospitality Toolbox, but it’s only a temporary stopgap – Docs should be the clamp that holds two boards together while the glue cures, not the permanent solution.