Tag: hospitality
Last week, I spent my Friday evening at the Saratoga Performing Arts Center (the #1 outdoor music venue in the United States). I blasted the Support Driven Slack with a mind dump soon after, and that’s grown into this Post.
Continue reading “Dep Leppard, $12 Beers and the Expectation Band”
As I write this, I’ve just LinkedIn connection request blasted my incoming colleagues from Woo – Welcome aboard, all! – and it brings front-of-mind something that I’ve been thinking about for some time; the way that we offer hospitality not just to our customers, but to our colleagues.
I’ve written before about how Hospitality and Service are different ideas, and should be thought of as different tools in a broader toolbox. Another distinction, and one that I think is even easier to miss, is the paired concepts of internally and externally directed Hospitality, and internally and externally directed Service.
The distinction between internal and external is a line drawn around your customers. Any hospitality or service efforts that are in place for the sake of your customers are external efforts. In general, this is where many people and companies stop thinking about hospitality and service – after all, it is called customer service, right?
The way that your company, your employees, treat everyone outside of the customer bubble, that is internal. That means that the way you interact with your vendors? External, both hospitality and service. Let’s talk through some examples.
Let’s say you work for a dairy company. There is a real us vs. them divide, with folks who work in the office generally behaving somewhat rudely to the delivery drivers and warehouse staff. That’s poor internal service. If that bad attitude spills over into internal systems and processes – say, forms that are difficult to use or requiring new and cumbersome busy work – that then becomes poor internal hospitality.
Let’s say you work for a top restaurant in your city. Servers are required to take ‘Kitchen Courses,’ which expose them to how the back of house staff work, and in turn spending time with the servers improves the kitchen’s understanding of the stresses of the serving floor. The interactions between the two teams are considerate and generous – excellent internal service. However, the company has a strict no-side-jobs culture, strongly discouraging employees from pursuing employment elsewhere – I’d argue that is pretty poor internal hospitality.
Let’s say you work at a small software startup. Your software is hugely popular, and you’re hiring staff as quickly as you can. These new folks are onboarded into a highly collegial and tight-knit community that is happy to have them (good service), but the administrative, HR and process debt is adding up, meaning that the internal tools that do exist are shoddy and poorly maintained, and the company is weeks behind on 401K paperwork – poor internal hospitality.
I would argue that not only is there more to hospitality than your customer facing efforts, I would also argue that, of the people to whom you want to offer outstanding hospitality and service, your customers should be the last in line. But that’s a topic for another time.
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
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.
It’s always a funny thing when you find a problem you weren’t expecting – especially when spending time with usage data, taking a moment to blink once or twice and consider why something looks odd can really bear dividends.
When doing a fairly standard rundown of the support statistics for our in-app support, I noticed that, despite making up about 40% of our userbase, our Android app users were submitting as many support requests as our iOS users. This meant that an Android user was almost twice as likely to contact support as an iOS user.
This seemed strange – I did some digging. Was the Android app more difficult to use? The app store rating for the Android app was actually higher than that of the iOS app. It was also noteworthy that the Android users accessed the in-app FAQ about half as much as iOS users – perhaps for some reason Android users tended to speed past the FAQ and go directly to support? Perhaps the FAQ wasn’t displaying properly?
Like anyone feeling stumped, I brought the question to the team, hoping someone would find some insight where I didn’t – and it turned out that our Android application in fact offered more points of access to support than the iOS app – that is, the Android app offered folks a chance to reach support at points of failure and error messages, whereas the iOS device did not. All of these additional access points did not require a customer to go through the usual flow of FAQ before reaching out to support.
Mystery solved. We’re increasing the number of access points to support in the iOS app.
Working on the mobile apps has revealed to me again and again that the lower the barrier to entry is, the better you’ll be able to hear from your customers. They have a lot of valuable things to say – given the opportunity, they’ll help you to make better things.
If you’re keeping track, yes, this is the second story about working with the mobile team where I end up increasing the number of incoming support requests. Yes, I am the worst.
Simon Ouderkirk 