Create Happiness in Face-to-Face Customer Service With Data

This article first appeared on Dana Hooshmand’s personal website, but it was so good, we had no other choice but to publish it in our blog. Please check out Dana’s blog, but do complete the article first.

---

It started with my then boss telling me this:

“We’ve been building these things called Hubs. We have one in Seattle, and are about to open another one in San Francisco. Can you find out if Hubs are a good idea and if so, how to build more?”

That was my directive on day one of my last job, which ended with me being Head of Hub Operations at Lyft, running ops for all our flagship retail sites, as well as the tech and process stack for all our 200+ retail sites around North America.

Lyft Seattle Hub, which I visited in my first week to size up this Hubs thing. This team was really into Halloween. (Well, the manager at the time was…)

Day 1. What on earth? How would I decide if they were a good idea? And weren’t we doing them anyway?

I was being asked a time-honoured question faced by every company offering face-to-face service: What is the return on investment (ROI) of in-person service? Should we be doing it, or focus on other channels?

Is here any ROI in retail (face-to-face) customer service?

The question of retail service ROI is not limited to one industry. Any industry that serves customers—whether it’s your neighbourhood coffee shop, glasses dispensary, clothing shop, bank or bookstore—has to consider the pros and cons of the channel in which they choose to meet the customer.

Retail service sites are obviously an expensive idea. When we add up the rent, the personnel hours, the training and the build-out costs, in-person sites are a lot more expensive than other contact channels like email or social media. In places like San Francisco and New York it’s even more expensive as the costs for all those things could be two to five times as much as in other regions of the United States.

No wonder physical sites are anathema for many otherwise online-only businesses. Lyft, Uber and other physical marketplace businesses are primarily organised around an online funnel, with customer support done entirely over email and the app. Companies are constantly trying to innovate around the in-person model by doing things like minimising shipping and returns through trying to get closer to what customers want, like Thirdlove’s lingerie sizing quiz or Warby Parker’s box of glasses (also backed by a quiz), or by having a person wait around while you try on clothes, a technique used in some mid-market clothing businesses in China, where delivery is cheaper.

But even in 2016, when we started experimenting with offline, other major online businesses were starting to explore physical channels. We took notice. Warby Parker, which started as an optician dispensary by mail, had opened dozens of retail stores. Bonobos had opened dozens of display stores where people could try things on, experience amazing service and then have the goods shipped in two days. Even Amazon, the original online-only store, now has over a hundred physical locations, including bookshops, the very business model it originally displaced.

The difference between face-to-face retail and customer service is that customer service has no sales metric by which to measure performance. There’s no better metric than net sales for a business. But in industries where we don’t sell stuff as our main business (though I hear in some Uber locations you can buy a t-shirt if you wish), we have to be more creative about what we measure.

What exactly does one gain through physical customer service? And how much of that makes them a “good” idea? It became my mission to find out.

Quantifying happiness in retail service

Hmm… if I could prove that a customer that visits a retail sites increases in value because of the visit, then I can justify building more sites purely based on financial ROI.

In the early stages of our physical sites rollout, someone had decided to create a feedback form, which used NPS (Net Promoter System). The rudimentary rollout (not that I’m pointing the finger—all first rollouts should be rudimentary) was flawed. It required agents to choose to send out a survey after an interaction, which was a generic form that asked the visitors to identify themselves. This process was prone to bias, error and lack of specificity, but it gave us enough information to want to get better data and thus consider how to improve the process.

Flaws with the original system included:

• Bias: Agents would avoid sending surveys after bad interactions to skew results up (preventing us from getting useful feedback)
• Lack of granularity: We could only identify visitors, not interactions, let alone purpose of a visit. So we wouldn’t be able to distinguish between the first and tenth times a visitors came to a site.
• Errors: Visitors responding would fail to identify themselves correctly (e.g. typing in their phone number wrong), which meant we couldn’t identify them. The early systems were also prone to duplicate responses (and usually more negatives than positive ones)
• Internal inconsistency: The surveys were inconsistent between locations, with question wording and order not the same
• Vagueness: We couldn’t tie to a survey result the visit reason, the agent or other visit characteristics (time of day, length of interaction, resolution)
• Asked questions we should know the answer to: A taboo in surveys, e.g. asking someone’s name when we know their name already. Annoys a lot of people and reduces response rates.

In short, it was basically just a pulse.

In considering whether and how to improve the system, my main hypothesis for our retail sites became this: if I could prove that a customer that visits a retail sites increases in value because of the visit, then I can justify building more sites purely based on financial ROI.

This would mean proving, with reliable data:

1. That physical sites deliver a better service experience than other service channels

2. That higher NPS means higher value customers, thus leading to company growth

3. That NPS could be improved by closing the loop, both internally and externally.

Foundation: get reliable NPS data at any cost

The entirety of the above relies primarily on getting reliable and actionable NPS data.

Firstly, I had to make it so the surveys would send automatically. Secondly, I had to make them easier to fill out for drivers. Thirdly, I had to collect all the survey data in one place.

Sending surveys automatically using APIs and magic

APIs are not something most people in operations teams talk about. It’s the domain of engineers, or at least people who occasionally pretend to be (like me). But luckily, with ten years of experience behind me doing a plethora of ungodly things for fun and sometimes profit, I am no operations person fresh out of grad school (I never went) who only thinks in Excel (Google Sheets and Google Scripts, tyvm). So I totally ❤️ APIs.

Enter Qminder, its API and its unexpectedly cool development team.

Qminder’s interface

We had recently started using Qminder as a way of organising the queue at retail sites, but it started to become the backbone of our retail operations—with solving queueing as the gateway drug.

Queueing is a source of pain in any retail environment. When people sit around in a foyer, they have no idea how long they’ll have to wait and generally are annoyed easily by the perception that others around them are being served earlier than them, not knowing if it’s true (and if it is, why it’s happening).

Qminder is an Estonia-based startup built with the mission of reducing the pain of waiting in line. Qminder does this by first letting people check in via an iPad. It lets visitors see their queue position on a screen, and lets agents call them up and take notes, kind of like a basic CRM (but not really, but we used it that way anyway).

The wonderful thing about Qminder is the engineering team who built a robust API that they use themselves for accessing all of Qminder’s functions. (For a quick primer on APIs, see here.) You can use the API to create tickets, modify tickets, create agents, destroy locations, get notified when a ticket is created, get notified when one is served, download data about… wait, what was that one about getting notified when a ticket is served? Aha!

Qminder’s API. Look at all those functions!

Qminder sends out a “webhook” event whenever a ticket is served. A webhook (also in my guide to APIs if you want more on this) is a notification that something has happened, like a doorbell announcing a guest has arrived and that you should go to the door.

All I had to do was connect this webhook notification to something that sends out a survey automatically.

This meant I had to connect it to an SMS-sending service. I chose Twilio, because it was a global standard, I had used it before and we already had an enterprise account with them. I also used the Google URL-shortening service (now sunsetted; I later moved to Bitly).

Artist’s representation. Would that it were this pretty. The flow was basically:

1. Ticket is marked as served
2. –>Qminder notifies my service
3. –>Builds a short URL and customized message
4. –>Send SMS to visitor to fill out survey

For example, a visitor named Johannes Adultman would visit a location and be marked as served.

The JSON payload from Qminder would be:

{
“type”: “ticket_created”,
“data”: {
“id”: “70198382”,
“status”: “NEW”,
“source”: “MANUAL”,
“line”: 393783,
“firstName”: “Jonannes”,
“lastName”: “Adultman”,
“phoneNumber”: 536433248,
“created”: {
“date”: “2018-11-18T10:04:11Z”
},
“extra”: [
{
“title”: “Email”,
“value”: “johannes@example.com”
}
]
}
}

I knew from this:

• The visitor’s name, Johannes
• His phone number to send him a text
• An interaction id, that I could tie to other data. (More on this later).

Processing the events

There are number of ways of capturing and processing events. You can use Zapier if you want, but this causes a few problems. They’re not an enterprise-grade service, and so can’t scale if you need them to.

You can also run API processors on Google Scripts. I’ve done this for tiny projects (including ones on this own website, like my generic logger). But these are limited, I think to 50,000 requests daily, and I figured I’d blow through this pretty soon as we projected serving tens of thousands of customers daily at some point.

Prepare for scale!

I created a server on DigitalOcean. These are $5 a month, which I put on my own credit card, figuring I’d worry about transferring it later. (Short story: I got it up to $40/month by the time we had scaled to hundreds of sites. I never used it to store data in any way, though.)

I did enjoy having a hacker-like display up on my screen.

This was me, regularly.

Next, I created a Node (Express) server to process the events. I decided to do this in NodeJS over Python for a few reasons:

• I had done it before in Node
• Node is fast
• I didn’t know Python. (I still don’t, and at this stage, doubt I’ll ever need to, because Javascript is a Swiss Army tool while Python is more of a chef’s set of knives.)

The thing about Node is it can do anything and most people have done something with it. It is based on Javascript, which is probably the most hacky language I’ve ever come across. There’s many versions, a new framework being deployed every day, and it’s used to run servers, web applications and little scripts in web pages and in google apps… it’s amazing. It’s the most versatile language I’ve ever come across. That’s why I think of it as English for the internet.

ExpressJS makes things even easier. This is the entire app for a server:

var express = require(‘express’)
var app = express()
// respond with “hello world” when a GET request is made to the homepage
app.get(’/’, function (req, res) {
res.send(‘hello world’)
})

I mean I didn’t stop there. I added authentication, security and made sure it wouldn’t just do whatever some enterprising hacker would ask it to do. (I do, after all, have a strong background in internet security from INRIA in France.)

But it was easy. I could now listen to events, muck around with the data a bit, and send text messages using Twilio.

What next?

Make forms easy peasy to fill out (and more reliable) with Typeform

I really hated asking visitors to tell me their phone number so we could identify them even though we clearly knew their phone number because we had just sent them a text message.

I figured out how to populate Google Sheets using UTM parameters. I was pretty proud of that. But it was ugly.

Enter Typeform. (Exit Typeform, a while later, because they got hacked and didn’t deal with it too well.)

Using Typeform gave us a few advantages

• Beautiful interface, beautiful forms
• Easy to connect with other services via Zapier
• Lets us collect a whole bunch of other data - including attachments if we needed it Hidden URL parameters!

(Later, we added more requirements for our data collection services, including a data retention policy, enterprise-grade security and service levels, and that killed Typeform for us. They just didn’t have enterprise-grade options available.)

Decide what questions to ask

We already knew a lot about each visit thanks to Qminder. We knew their name, when they had arrived, how long they stayed, their phone number and could also collect (using Qminder’s drop-down interface) things like the reason for their visit.

After consulting with the dozens of people interested in asking questions, we narrowed it to three crucial questions.

1. About Lyft: “Based on your experience, how likely would you be to recommend Lyft to a friend?” The classic NPS question, with a twist as it’s based on a transactional; thus tNPS or Transactional NPS. This tells us how we’re doing as a company, and lets us compare the performance of channels. We also collected some free text pertaining to the NPS question.

2. About the solution: “Did we resolve your problem?” Resolution rate from the perception of the customer.

3. About the agent: “How satisfied were you with the service you received from the Lyft expert?” Yes, we borrowed the term ‘expert’ from Apple.

Once we started collecting all this data, of course, we had to put it all in one place so we could compare channels and map performance over time.

Collect the data in one place with Zapier

Google Forms sends information to a Google Sheet out of the box. Typeform now does as well, but it didn’t originally.

The problem we thus had to solve was: how do we get all the different forms to send their results to one master sheet?

The sheet would ideally be formatted like:

At first, I took Typeform webhooks (they have a pretty good API too) and used a Node package to write directly to a Google doc. This was fine, but it created high-maintenance code that sometimes failed (if too many responses came within too short a span of time). So I moved it to Zapier. For each form, we’d send data to one Google sheet.

We had to do a little data manipulation to make sure it was clean for upload, but more on that another time.

Step 1: Show that physical sites deliver a better service experience than other service channels

With reliable data, an important part of proving we even need physical service is to prove that it is a better service experience than through other channels.

This is done in two parts: by asking whether people even want a physical customer service option, and then seeing if it is in fact better.

1. Do people even want a physical service experience?

Before we asked, we had no idea why people would show up to sites for customer service. I mean, we told people it existed. They knew it existed if they had visited for something not related to service (like an inspection or for lost and found). But every form of customer service could be done online, via the app or via self-service.

So why would customers show up to a site? Any number of reasons, all of which would be valid for most businesses:

1. Assumption it’s the best way: A customer has visited a site before and thinks it’s the primary way of getting things done, like in a bank.

2. Multiple service issues, one of which requires physical interaction: A customer has to do something like pick up an item or attend a training seminar, and wants to take care of other things while they’re there.

3. Easier to communicate: A complicated or sensitive issue requires face-to-face communication because it takes a long time to explain and requires different forms of evidence, e.g. photos or paperwork, and it’s just easier to get done in person

4. Language barriers: The customer speaks a language not used by customer service but which an agent at the service site speaks (frequently for non-Spanish languages, like Portuguese, Chinese languages, Arabic, Amharic, Punjabi etc. where there are specific ethnic customer populations in an area)

5. Last resort: A customer is frustrated at other service channels for not being able to serve them (whether or not it’s possible) and wants a court of final appeal

6. More convenient: A customer lives nearby or regularly goes through the area and finds it convenient to stop by on off hours

7. More immediate: A customer does not want to wait for a reply, to wait on hold or for an agent on chat.

8. More human: A customer simply prefers looking someone in the eye and conversing face-to-face.

9. Special favors/exceptions: In face-to-face service, customers have come to expect that they can get special favours or exceptions, even to intractable problems. In retail stores, they can get discounts, for example. There’s a perception that if you’re nice to someone, they’ll treat you better. Because it happens sometimes, people believe it can happen all the time. “OK Frank, I’m going to do this for you one time, but just so you know, I really shouldn’t.”

All of these are legitimate, and in fact, add up to one question we had to asked a huge number of customers across many demographics, leading to one clear answer.

A whopping 80% of people would prefer in-person service if it were available and convenient. This reflects the general tendency in customer service (see for example this Accenture report which emphasizes the role of human interactions). Perhaps, more than anything else, this is an indictment on non-human customer support.

2. Is face-to-face customer service better?

With reliable data, we were able to show that yes, it is better.

Higher NPS for each transaction—but boy, did it come at a cost! Even without numbers on that chart I just made up you get a sense of the scale.

So many things about email- and phone-based customer service more cost effective.

• Centralization: Having all staff in one location (for example in one lower-cost city in the same country) means it’s easy to train, maintain standards and identify hot issues. People servicing customers all over the country or world will be in the same vicinity, and can make live comments like “wow, we’re getting a lot of pay issues in Denver, aren’t we!” and thus quickly identify issues without even having to dive into the data.
• Labor cost arbitrage: You don’t have to pay San Francisco, London or Sydney wages to customer service staff. They can work remote from anywhere, for example regionally in the same country, or offshore, and give the same great customer service.
• Automation: People doing service over email in particular can use scripts and shortcuts to answer common questions. Routine questions can be answered by robots instead of people. Not the greatest service experience (people can tell quite often), but good if it works.

All the above is great, but for many people, nothing is better than looking someone in the eye and having them help you.

Step 2: Show that higher NPS means higher value customers, thus leading to company growth

If we look at a visits a hub, then at their behavior 30 days prior and 30 days post visit, can we see any positive change in their behavior?

It’s fairly uncontroversial that a high Net Promoter score is correlated to company growth.

Take this age-old analysis by Bain & Company.

From Bain, my alma mater. I think these slides were made the old-school way from cellophane and Exacto knives though so are probably out of copyright…

This is all fine, but what about for our company? Or yours? A high Net Promoter score is great but it’s an empty vanity metric unless it can be tied to company growth. I had to somehow connect the data that we were collecting from surveys and Qminder to the rest of our company data to answer: How could we tie visitor performance to visit date (and other data about their visit)?

This was my problem. We had no engineers, and almost no budget to spend on this experiment. So we did it first in Excel, to make sure we had numbers that might make sense.

Doing it in Excel took days of manual effort by my then lieutenant Jayson. I didn’t even want to look at the models, it did my head in.

The question everyone wanted to answer was: “If we look at a visits a hub, then at their behavior 30 days prior and 30 days post visit, can we see any positive change in their behavior?”

Easy question to ask, but hard to answer. The way we did it was to

1. Select every single visitor to a location over a period of 30 days.
2. For each individual day, identify individual visitors that had visited a location
3. For each visitor, get their performance pre- and post-visit
4. Do the same for multiple locations with different characteristics.

It involved a lot of look-ups and many data errors. Fortunately, the answer was good enough to warrant creating better systems.

We concluded that

• Customers visiting our sites were better partners for the company
• Customers visiting our sites reported dramatically higher NPS than people who used other support channels
• Visitors reporting high NPS numbers tended to refer more new customers. (A LOT more.)

Made-up data, but indicative. Customers 1-month value increased dramatically post visit, even when we excluded customers we had just onboarded, or accounts with problems that we re-activated. They just were happier.

As I mentioned above, we did some separate survey work and showed, unsurprisingly, that a lot of visitors preferred in-person service if it was convenient, even in a world with great phone or email support.

Seeing the high value of in-person customer service, execs then said:

Can we get this in Mode?

That was what execs would ask me about any metric we claimed we could measure. Visits. Unique visitors. Impact on rides. NPS change over time. If there was a number of any importance, then our execs wanted to be able to query the number on demand, as often as they liked, without any special other places to go log in.

Creating live(-ish) charts in mode: inputs, outputs and spaghetti in between

Qminder gave us full access to their data via their REST API, which let us query tickets. Our output system was Mode Analytics, a dashboard where we could query internal databases. I had to connect these two things. Problem was, there were a lot of interim databases in between, and myriad authentication steps.

As I mentioned above, this was my problem. We had no engineers.

Luckily, my boss was a former engineer and smart cookie and could understand that my proposals weren’t bonkers. I was a former engineer, with just enough Javascript chops to hack things together. So, hack I did.

At first, it looked like this.

With more detail:

1. Download the tickets data every day from Qminder, getting it as JSON
2. Make it into a flat file
3. Query Qminder for missing bits from the flat file, to make one huge database
4. Upload that file daily to a staging area using a CSV import tool
5. Download the separate CSV of survey responses
6. Clean the data for upload using the CSV import tool
7. Upload this file to the staging area
8. Run a script to import data from that staging area to the master database
9. Update reports in Mode

This worked, finally. It did rely on human effort, but that was just 10 minutes of running scripts and checks a day, and was entirely dependent on me or whoever happened to be doing it (in other words, totally unsustainable).

Automate the pipeline… and beyond

The final step (for now) was to automate the above, creating ingestion engines for both survey data and ticket data.

This was in the form of a server that sat beyond the Lyft firewall, listening for events with enterprise-grade authentication and populating live tables.

There are many more steps beyond this, including:

• Creating our own data collection interfaces
• Making the data more dynamically interactive—re-running SQL queries is pretty intensive
• Creating an entire platform for location data collection and management

All of this is part of a standard blueprint for customer service technology.

Step 3: Show that NPS could be improved by closing the loop, both internally and externally

Inner and outer response loops

Said the visitor:

I can’t believe I waited for thirty minutes and you couldn’t even help me! F*** you!

This is the kind of survey response (sometimes just a text message, in response to the survey prompt we text people) that if we receive, we MUST act on.

It raises many questions.

1. Why couldn’t we help them? Was it a training, tools or policy problem? (If policy, could it have been communicated better?) Is there something we could fix to help them?

2. Why did they have to wait for thirty minutes? (an objectively long amount of time for anything)

3. Why did they have to wait for thirty minutes to realize they couldn’t be helped? Was there a way of quickly triaging?

Every response we get from every post-interaction feedback is gold. It lets us be better. Amassed by thousands of responses and properly categorized, it lets us become better in a systematic way, in accordance with our principles and our business priorities.

Create response loops to improve service

Firstly, the problem may be a service one.

• Did the staff member lack the appropriate training to solve the problem?
• Did the agent lack the tools to solve the problem?
• Had the agent simply been overworked, e.g. from doing overtime?
• Is the agent not working out?

It’s up to every individual team managing service staff to proactively monitor their survey feedback and act on it. This has to be done at a macro level, looking at trends and patterns, and at a micro level, responding to every single instance of negative feedback.

Good staff managers (the kind I’ve been blessed to work with) love good data that they can use to fix things. They’ll slice up the feedback data in innumerate ways, including:

• By agent (in a team)
• By location (when there are multiple sites under the dominion of one manager)
• Over time (to see trends)
• By issue type (lost and found, complaints, attending events, onboarding)
• By service time (5 min, 15 min, 30+min)
• By customer characteristics (loyalty, value, different product lines)

You can develop a lot of insights by bucketing a few things. For example, you might conclude that your score would be 10 points higher if 5% of your unresolved problems were resolved through better training, or that your score would be 5 points higher if you reduced waiting times by 20%.

Critical to all of this is gathering correct data. For example, how can one correctly group survey responses by issue type? Firstly, you have to connect the survey response and ticket data. Secondly, you have to make sure that the ticket contained information identifying the issue type (possible with Qminder’s custom form designer). Finally, you have to make sure the response pertains to that issue. Visitors often have multiple issues, and they might have been happy with the response to three of them (“I got my new stickers, I managed to log back on and my app now works”), but unhappy with one (”… but they still owe me $250 in arrears.”)

Managers tend to look for magic hacks in solving service, but usually the answers to service issues are blindingly obvious, while also being structurally difficult to resolve. The answer to dwindling survey scores are usually

• Too few staff at crunch times (hire more people, or learn to load balance)
• Poor layout to handle high traffic leading to confusion and attrition
• Not open for long enough hours or on enough days (leads to pent-up frustration… “Oh, so good of you to open up at 11am, now you can’t even fix my thing?”)
• Bad hires, which can become a toxic problem and lower morale
• Inadequate training (out-of-date, ad-hoc, “on the job”) or tools (bad hardware, software or WiFi)

None of these are easy to resolve. They all require investment and time, plus layers of management to agree to their importance. Every time any of them are raised, management will inevitably begin to question the ROI of in-person service at all, and wonder what else could be done—e.g. reduce traffic through better online service or product. So this isn’t to say that obvious means easy; it’s just to say that management is often unaware of the investment cost of in-person service before allowing it to develop.

Create response loops to improve the product

The final way in which in-person survey responses can be used to improve a company is by improving the product.

There is one critical reason why. In-person service is the last resort of the desperate customer, and thus gives you an insight into the most desperate issues.

Think of the last time you went to a bank. Unless you live right on top of a bank and there’s never any line, wouldn’t you have done everything over the phone or internet if it were easy? No. The only reason you go to a bank is because they make it obligatory for some transactions. The minute it became easier to buy airline tickets on the internet, travel agents started going out of business (here, here). Amazon sent Barnes & Noble, the last great bookstore, bankrupt.

When people show up for in-person service, it’s for one of the following reasons:

• They have to. For example for a training session (whether voluntary or mandatory) or to pick something up.
• Online services have failed them in some way—can’t resolve their problem, too complicated or difficult to access because they’re confusing or due to a language issue.
• They have a long list of issues and would rather just go through them one by one with one agent rather than over 50 emails.

These—especially the second one—give us rich insight into the ways in which we’re failing our customers through an inadequate product. This information is vital to the product team, but it has to be delivered in a meaningful way. For example:

Hey guys, we need to fix the glitch where we’re accidentally telling people to pick up a guidebook at our sites one day early. We’re getting crushed on feedback for this, and that’s how we found it, but more importantly it means they’re making a wasted trip, costing them 1.3 hours on average when they could be making money on our platform, so last month it cost the company $248,089.

If there’s one language product teams understand it’s money. They’re constantly ruthlessly prioritising problems by business impact and they’re sizing up whether to throw a stack of engineers at your problem or ten others that are also costing the business money (or preventing the business from making money).

Again, the way to getting to the money data point is data. Number of issues encountered in a week * time spent visiting a service site * average earnings per hour = money lost in a week. This requires counting not just issues, but counting issues by type at check-in, and connecting it to feedback scores and service times (as well as average transport times).

Step 4: Results & epilogue

So where does this all go? More NPS, of course. (And more profits!)

Illustrative numbers, but actual quote from management.

The final horizon is to watch quantified service quality increase over time, and hopefully with it, business.

Keep watching NPS numbers and make sure it keeps rising, and also periodically check in on high-NPS scoring customers to make sure that they’re more loyal and higher value for the company.

Even if at times it can seem correlative rather than causative, ask yourself: is there any harm in serving your customers as best you can, and getting their feedback to make a product that’s as good as possible?

Try Out Qminder