How we think about customer experience at Linear
We believe in extending our product philosophy across all aspects of our company — especially customer support. We interviewed our in-house CX team to share how Linear uses Linear.
Give us an overview of how Linear thinks about customer support
I like to think of support as an extension of the product and another opportunity to build your brand. That's why we call it "customer experience" (CX) and not "support". Whatever the product's feelings and features, your support experience should emulate that.
- Linear is fast, so our responses and bug fixes should be quick.
The app is designed to be simple and straightforward, so our replies to customers should be the same way. - People use Linear to get their work done, so we want to answer their questions immediately and let them return to it.
- We still make sure to include thoughtfulness, care, and a little magic, too. It’s the little details that make the product feel magical. Similarly, the little details in a customer interaction make it a memorable experience.
What does the daily routine of a
CX rep at Linear look like?
Every morning, I go through my Linear inbox to review updates to issues I’m subscribed to. Any issues I filed to triage will probably have comments or status changes I should know about so that I can check back in with customers in Slack or Intercom. I have my inbox set to show me only things I have yet to read.
Then I'll usually go to Intercom and start working on the oldest customer problems. I use the Linear integration in Intercom to create issues as needed, though sometimes I’ll create an issue in Linear first to take advantage of the formatting tools in Linear’s editor and to upload files. Let me show you how it works:
Once I’m done with Intercom — which takes most of the day — I'll be bouncing between my messages with customers, communicating about their problems. We have shared Slack channels set up with our largest customers, so I often use Linear’s Slack integration to create issues directly from messages in Slack. Customers can see that I created an issue which is a nice touch — they don’t have to take my word for it!
What happens when a customer
writes in about a bug?
There are a couple of different ways users can get in touch with us: The “Contact support” form, email, and our customer Slack channel.
Most users reach out via the in-app contact form where they can specify if they are writing in about a problem, a question, or with feedback. Depending on what they select, the issue routes into a separate Intercom view on our side. This helps us prioritize for urgency.
Emails to support@linear.app also go to Intercom, but first land in a triage view where we can then sort them appropriately.
When we start working through tickets in Intercom, we start with problems and work our way down by who’s been waiting longest for help. If there’s an unexpected behavior that we can reproduce, we’ll file a bug in Linear via the Intercom integration. The bug will go to the Linear team triage, which is the first destination for everything that comes in from a customer.
Bugs that are reported in our Customer Slack go directly to the Linear team triage (via our Slack integration).
Let me quickly explain the Triage feature for those unfamiliar with it:
Triage is a special inbox in Linear that helps you manage unplanned work such as bug reports or feature requests. It creates a clear process that centralizes all incoming tickets in one place, where they can be reviewed, prioritized, and routed to the correct team.
Here is what the process looks like from an engineering perspective:
Once a bug is in the Linear triage inbox our engineering team takes over. We have a weekly rotating Triage captain who monitors and reviews all incoming customer issues filed by the CX team. We recently added a triage notifications feature to notify the Triage captain whenever a new issue gets filed in triage.
Each new Triage issue gets reviewed:
- If it’s an urgent bug that needs fixing immediately, we’ll try to resolve the issue directly. The Triage captain doesn’t have any other work that week, so if it’s possible to fix the issue in a few hours or half a day, we will fix it.
- If we don’t know how to fix it or if the bug is part of an ongoing project, we’ll assign it to the responsible person or project lead.
- If the issue is unclear, we’ll ask CX to get back to the user who reported it to collect more information. We’ll snooze the issue in the meantime to keep the Triage inbox clean.
- Issues that have been reported before will be marked as duplicates
- Invalid issues will be declined.
When the issue is fixed, the responsible engineer puts out a PR. Once it gets approved, the GitHub integration will automatically close the Linear issue and reopen the Intercom ticket. It will come up with an internal note saying the issue is resolved, and whoever is in Intercom can then communicate that with the customers. That's the life cycle of a bug.
At the end of week, the Triage queue should be empty.
Since we launched SLAs, every incoming bug now gets a dedicated time window in which it has to be fixed, depending on the priority of the bug. If it's urgent, it's a 24-hour SLA. High priority is 7 days, and medium priority is 14 days. In the current setup, it’s rare for any bug to still be open by the SLA deadline.
How do you process incoming feature requests?
To preface this with a bit of essential Linear knowledge, a Linear workspace is composed of different teams (so you can organize issues, projects and cycles within your workspace).
Within our own Linear workspace, we created a “Feature Requests” team to help us organize incoming feedback.
Inside that team, we use a custom view containing a parent issue for each part of the product, where each individual feature request is a sub-issue under its area.
Under this team’s workflow settings, we also have the “auto-close stale issues” toggle enabled, so if no other customer requests the same feature in the following 6 months the request will close.
When we’re working with a customer, we have a low bar for what we file as a feature request. If it’s something we’ve already discussed and decided not to do I’ll explain why, but if we haven’t discussed it I’ll file it under its product area parent issue, copy the new issue’s ID and use the Linear integration in Intercom to associate the customer ticket with that issue.
Then I let the customer know that I’ve filed a request and that we’ll get back to them if we build the feature, and close the ticket. I can commit to that as our Intercom tickets reopen if that issue is marked Done. If other users ask for the same thing, we'll get a more balanced perspective on the use-cases for the feature, and suggestions from our customers about implementation. If no one else asks for it in 6 months, it’ll be closed by the team automation so we can maintain a reasonable list of recently requested features.
Anyone at Linear can go into the feature request team and see what our customers are asking for without needing to wade through individual conversations. New feature requests also get piped into a Slack channel as alerts to help with visibility.
If a feature request ships, we follow the same workflow as a bug fixed: The issue closes, the Intercom ticket reopens, and then we reply to the customer and let them know that the feature they requested is now here. We don’t have to send those emails, but it’s just delightful when you get to tell someone we built something that they asked for.
We also create a monthly CX report to summarize and bubble up commonly asked feature requests that aren’t currently being worked on.
What upcoming Linear feature are you most looking forward to?
We’re working on a couple of improvements to Triage. As we talked about earlier, each week a different person on the team is responsible for managing the Triage queue. We want to turn this concept into a Linear feature.
This means you’ll be able to assign specific people to manage the Triage queue for your team. There will be different assignment options, tailored notifications, and some clever integrations and automations.
The biggest blocker right now is actually the name. Internally, we’ve always called this person the “goalie”, which doesn’t feel like the right name. We’ve also considered “Triage captain” and “First responders”, but I don’t know … what do you think we should call it?
Join our Slack community and send us your naming ideas!