Petros Amoiridis

All customer support teams receive out of scope support requests. What sets a team apart is how they handle them.

When I worked at GitHub Support, we used to have a special label for out of scope support requests. We used not-github to mark them.

A few examples of people asking:

• about a project hosted on GitHub,
• a framework or programming language they were using at the time,
• about a competitor.

One example I handled was someone asking which files to keep out of their repository in their Visual Studio project. That was back when GitHub didn’t have the nice .gitignore files you can use nowadays. One might argue this is not an out of scope request. You have to know though that GitHub is hosting projects based on hundreds different platforms, frameworks, and programming languages. It’s not easy, or even possible, for one person to know everything. That’s why I consider it borderline out of scope. Here’s what I did back then. I researched and figured out which files should be kept out, and I shared that with our customer. I could have easily saved me the trouble by letting them know what they were asking was beyond the scope of GitHub Support.

Another example was someone asking about one of our competitors. I could have dismissed them, and pointed them to our competitor’s site. Instead I helped them with their question by visiting our competitor’s documentation, learning how to do what they were asking for, and sharing it with them. Needless to mention the impression that made on them. Again, it would be perfectly justified for me to not help a competitor. But I would have missed a great opportunity to make a lasting impression on that fellow.

Here’s an example from a company I admire. It’s a quote from Tony Hsieh, the CEO of Zappos. A company that was obsessed with customer service:

Once, at a shoe sales conference in Santa Monica, after a long night of barhopping, a small group of us headed up to someone’s hotel room to order food, but room service had closed at 11. When we couldn’t find a place that delivered food after midnight, a couple of us cajoled a woman (who didn’t work at Zappos) into calling a Zappos rep for help while we listened in on speakerphone. The rep was a bit confused by the request, but she quickly recovered and put us on hold. Two minutes later she told us the five closest places in Santa Monica that were still open and delivering pizzas.

Tony Hsieh

How many reps would do that? Especially if they are under the pressure of following scripts, and meeting response and resolution time expectations?

The company has to empower them by letting them be themselves, and spend as much time as they feel is necessary to work with a customer. Easier said than done of course.

The company has to cultivate an environment of finding opportunities. Not solving problems. One has to constantly ask themselves. What is this customer asking me? Maybe they are not a customer yet. It doesn’t matter. What opportunities are there for me as a support person? For the company I work? How can I offer them a human service that’s not based on scripts and numbers? How can I go out of my way, even if that means I have to spend more time helping them?

Spending more time to learn how to help someone is time well spent. It is an opportunity to learn something new. Even if it’s how many pizza places are open in the area after 11pm.

What about your team? Would you help someone asking for a pizza? Someone asking how a competitor product works? Someone asking about something you don’t know? What things do you feel is not your job to do?

What are you up to Petros?

Working as a software writer during the day. Making games during the night. Streaming and vlogging. Building Calm.jobs on the far side. Check what I am doing now and talk to me.