Just over three years ago, we embarked on a journey with a simple goal in mind. The software world was moving quickly in the direction of rented servers, hosted solutions, and outsourced vendors, all in service of allowing teams and companies to move quicker and to be more nimble than ever before. What used to be built and maintained internally was now delegated to other services or vendors.
And although every service provider and vendor strives for perfect uptime and operations, the data around availability tell us what we already know. Unexpected problems happen, and they happen to everyone. From Amazon Web Services, to Salesforce, to Comcast phone service this week, nobody is safe from things going wrong (even Pokemon Go!).
This new world was great, but it was missing a core component in the relationship between companies and their service vendors. That component, of course, was status communication.
Before we got started, status communication was very costly to build and maintain, and in most cases just didn’t exist. Our simple goal was to provide the ability for every software company in the world to build and maintain their own custom status page. Having felt this pain ourselves, we were as equipped as anyone to build the right solution, and the timing couldn’t have been better. From a handful of customers in early 2013 to thousands of customers today, it’s been amazing to watch all different types of companies build trust with their customers and their colleagues, saving everyone lots of time and money in the process.
Today, we’re super excited to announce that we’re joining forces with Atlassian to accelerate our progress and our continued march toward transparency across the web.
This is a guest post from Alistair Mclachlan. Alistair is Head of Support at FiveStars Loyalty, a San Francisco based startup that helps businesses and communities thrive by turning every transaction into a relationship.
To hear ‘Server Down’ is to hear two words which instill fear into the heart of any Support Leader. System outages are unavoidable but while Engineering is scrambling to fix the issue, there are certain things we can do in Customer Support to mitigate the impact on paying customers.
During normal circumstances, FiveStars Support carefully treads the tightrope, balancing call deflection with issue resolution in a way that doesn’t negatively impact Customer Experience. But if you have a Support Team staffed to take 20 calls per hour, a sustained increase to ten times that volume is going to sink the ship unless you have effective outage planning.
We’re half way through 2016. It’s hard to believe. We wanted to mark the occasion by celebrating the best reads we’ve seen this year so far. Today we’re looking at the best writing on startups and entrepreneurship. Enjoy.
We’re half way through 2016. It’s hard to believe. We wanted to mark the occasion by celebrating the best reads we’ve seen this year so far. Today we’re looking at the best writing on customer support. Enjoy.
Let’s meet at 8 a.m.
Yes, that’s Okay.
With writing, it’s the one thing that’s not debatable. Especially when you’re writing on behalf of an organization.
There's been a lot of focus on “self service” in customer support over the last several years. Support teams are seeing fewer “easy” support questions and more complicated problems because customers are solving the easy stuff on their own.
I have a few thoughts on why this might be. For one, design and product teams continue to improve their craft. Products are simply better than they used to be. Navigation paths are more clear, experiences are more intuitive. Secondly, the users are more sophisticated and skilled at interacting with technology tools. People are spending a lot more time with software and interfaces than ever before. Our brains are drawing connections between all the different apps we use every day.
Designers call these UX patterns. The idea being that most software users have come to recognize and expect an interface to behave certain ways. So even brand new users have some subconscious familiarity with your product.
In other words: most people can figure out how to change their password.
They’ll lock eyes on your booth. They’ll have lanyards and fists full of swag.
“So,” they’ll say. “Whaddya you guys do?”
This is a learning moment. They’ll learn about your company, you’ll learn about yourself.
It should be an easy task. This is the company you work for every day, maybe the one you helped build. Here you are, sitting at a conference, ready to show the world (or at least a few hundred people) what you do. What you’re made of.
You should nail this. You won’t.
So you’re going to launch a product. Maybe even a whole company.
There are a lot of schools of thought on product launches. It pays to do your research, pick the right channel, and tailor your strategy according to that channel. A lot of founders take the "spray and pray" approach, simply blasting their new product out to every website and social network they can think of.
It might work. But it probably won't. And even if it does work, you won't know why. You won't know what to replicate when you need to launch a new feature, grow, or scrap everything and start over. It's better to go in with a solid plan, and to build your launch strategy according to the outlet you're targeting.
We dove in to some of the different channels for launching and put together some case studies of launches that worked.
Hiring is one of the most time-intensive and critical things we do.
We’ve added nine people to the team in the last year, four of them software engineers. We’re currently hiring for three more engineering positions.
We plan to be adding even more than that in the next few years.
This means time is precious. We can’t waste any on interviewing or hiring the wrong people. That’s why every engineering candidate we talk to goes through a set of coding challenges.
We know there are different schools of thought on this (and some pretty passionate opinions) but it works for us.
If someone is going to get weeded out of the hiring process, best to weed them out early. It seems to be better for everyone involved.
We’ve been through several iterations of coding challenges to get where we are now. It’s definitely still a work in progress. But this is what’s working for us right now.
Here’s the problem with your customer support team’s policies and guidelines. They are policies and guidelines.
Policies and guidelines look great on paper. They make for a nice slide deck for management. In a perfect world, everyone on your team will default to policy-driven actions in all situations.
Too bad that doesn’t happen.
At some point, someone will not have the time or energy to run according to the rules. Habit takes over.
Habit always wins.