Last time we talked about how we use Intercom to understand users. This time we will focus on our support workflow.
We build Codeship on three pillars.
- Stable Technology
- Audience through Education
- Personal and quick support
Everyone in our team does support. To help our users we need to work together and not offload it to one or two singular team member.
We want to make sure that when we discuss new features or improvements there are no wrong assumptions and our whole team understands the current problems our users have. We get everybody on the same page by letting everyone from our team answer support requests.
In the beginning we decided not to automate our support in any way. We want to understand the needs of our users first and had to find a good way to handle support internally, automation would have been premature optimization.
Although it doesn’t scale in the long term we think Paul Graham is correct in his ‘Do things that don’t scale’ blog post. We will introduce some automation to make support quicker and better in the near future.
Keep your Support Flow in one tool
We wanted to have one tool that lets us handle support and send notifications to our users. Intercom additionally provides us with a lot of context about a user when we answer support. This has been very helpful so far.
Contacting the Codeship Crew is easy
Having to search for a contact form on a page is annoying. When people sign up for Codeship they are greeted with our support message. We want to make sure everyone knows how they can contact us.
We’ve got pictures of our team at the top bar so people see the team behind the product. We’ve got great responses for this as it makes the whole onboarding process very personal.
A couple of months ago we introduced more call to actions for support. For example when tests fail we show a link that says Report a problem and prepopulates the message. It is shown right next to the failing command.
Now that we get people to talk to us whenever they have a problem we need to be able to answer those requests quick and thoroughly.
Have a proper Support Workflow in Place
Alex is responsible for assigning all incoming support requests to different people in our team. Before anyone answers a support request we write a summary of the request and response into our support Google Doc.
As soon as the support request is recorded we either answer it directly or send out a quick We are looking into this answer to let our users know we got the request. It is crucial for us that all of our users to get a quick response.
We start every Standup meeting by reading our support requests so everyone is up to date. Although this makes our standup a little longer it is very helpful.
If we need to debug for the support request or send them an update once a feature or fix is shipped we tag the request with debug or follow-up. This allows us to manage and get an overview on how many people are still waiting for an answer.
Optimize your Support
After using our support workflow for a while we understand what our users need and where we can optimize.
We are currently working on better docs and will be linking to them automatically, which should remove a lot of our support and give our users a much faster way to get the necessary information.
Knowledge Base systems like TenderApp are very helpful for this.
Intercom is great for keeping support centralized. We can get additional information about a user while answering the support requests
Sharing all support requests within the team helps focus on the things that actually are a problem for our users. We do not have to guess or assume where we can improve, because our users tell us.
This was the last part of our Workflow series. Please let us know if this series was helpful and if you want us to cover any other topics. We will soon be coming back with another more technical series about deployment and the latest tools and strategies we use.
- Paul Graham: http://paulgraham.com/ds.html
- On the Intercom blog: How to optimize customer support
- On the Intercom blog: Understand your support requests
- The Codeship Workflow part 1 – Developing a new feature
- The Codeship Workflow part 2 – Pull Requests and Code Review
- The Codeship Workflow part 3 – Deployment Pipelines and Zero Downtime Deployment
- The Codeship Workflow part 4 – Immutable Infrastructure
- The Codeship Workflow part 5 – Continuous Deployment of Immutable Build Servers
- The Codeship Workflow part 6 – Understand your users with Intercom
- The Codeship
Want to build tools for other developers and join a well funded startup? Join us and bring Continuous Deployment to every software team. We are hiring!