The customer support queue is a great place to collect feedback and hear directly from your users. It also tends to be a place where a lot of your feature requests and bug reports come in. Many teams have some kind of process in place for tracking those requests and adding them to a backlog or a support escalation queue, but very few have a reliable way to close the loop and let those customers or users know when their request has been addressed.

We all want to keep the feature request backlog clean and up-to-date with what’s been resolved and what hasn’t. But closing the loop with users is also an amazing way to build relationships, engender trust, and make the folks who rely on your product feel special. Sure, they could find out from your marketing email blasts and changelog, but why not give it a personalized touch and use that opportunity to show that your team is listening?

This post will walk through how our startup team (a B2B SaaS company called Reclaim.ai) uses a combination of Linear and Intercom (along with an excellent integration built by the Linear team) to track and map requests in the support queue to tickets in the backlog, as well as automatically know when we need to close the loop when a ticket gets resolved. It’ll also show you how to set the integration up as well as include some best practices and tips for how to put it into practice with your team. 

And by the end of the post, you should be able to get a killer process in place for doing hyper-targeted outreach to users when you fulfill their requests!

How we arrived at this solution

At Reclaim, we offer real-time chat support for our hundreds of thousands of daily users to ensure they get the best experience possible with our product. 

Intercom

We use Intercom exclusively for communicating with our users in support, and have since 2020. We also purposefully don’t have a separate place for users to make feature requests, report bugs or ask for improvements, and instead use a custom bot flow that allows people to make feature requests or let us know if they’re running into a bug directly in our support queue. We could do a whole other blog post on how we use custom bots, but we’ll set that one aside for now.

Linear

On the engineering and product side of the house, we’ve been happy users of Linear since 2020. Linear is a simple (but incredibly fast and powerful) issue tracker and project management system that we use to manage all our engineering tasks as well as a lot of our marketing work. We also use it for feature request tracking.

Connecting support & product

Since the day we started using Intercom, we were hoping to have a nice way to track requests and bug reports when they came in via support, and to make it easy on ourselves to map them to chats so that we could easily reach back out to those users. We tried a bunch of different systems, but none of them seemed to stick because they involved a lot of manual work. 

For example, one system we tried out involved us tagging the conversation in Intercom, which would add it to another system where the feedback would have to be triaged and mapped to a feature request. Not only did this mean we now had another queue to manage (feature requests) it also didn’t work that well for bug tracking, where a customer would write in with an issue and we wanted to be able to associate it with a backlog or triage item in our issue tracker so that we could remember to let the user know when we’d fixed it. 

My co-founder was the first to discover the integration that Linear built with Intercom, which I believe was only a few months after we started using Linear to track issues. We installed it and used it for a few days, and we were sold: this was the process we were looking for. The integration allowed us to seamlessly access our Linear tickets directly from Intercom, and use a workflow state to close the loop without having to manually comb through old support chats in Intercom. 

Basics of using the integration between Linear and Intercom

Let’s start with a basic overview of how the integration works. On its face it’s very simple to use, but as we’ll cover down below, operationalizing it comes with some important best practices that we recommend observing to get the most out of the integration and process.

Once you’ve got the integration set up (we won’t cover that in this post, since it’s pretty straightforward and the Linear folks did a great job of documenting it) you’ll see a new app appear in your Intercom sidebar next to any chat in your queue. 

From any chat, you can now either create an issue or link to an existing one. In both cases, it will associate the chat and the customer from Intercom with that issue in Linear. You can always unlink issues as well in case you change your mind or want to associate the chat with a different issue. 

Once you’ve associated a chat with an issue in Linear, you’ll see it as an attachment in the issue itself from within your Linear workspace. You can click into any of the attachments if you want to see the chat that it came from:

When an issue is moved to any of the “Completed” or “Canceled” states in Linear, it automatically reopens the chat in Intercom. That’s the part where you close the loop and update users who requested the feature:

So the basics of the integration are pretty straightforward – you set it up, you link chats to issues, and when the issues get marked complete or canceled, the chats reopen and you close the loop. But after now having used the integration for several years, we’ve learned some important bits that have been really helpful for us to optimize our process and prevent it from creating confusion or issues across our team. 

Best practices for using the Linear and Intercom integration

We’ve figured out a bunch of cool ways we can use this process to our advantage – and we’ve also learned how to specifically not use it – over the years. Below is a non-exhaustive list of best practices, tips, and tricks for making the most out of the Linear / Intercom integration.

1. Make sure the integration is visible to everyone in Intercom

This is a basic-but-important one. We learned that when you add integrations to Intercom, they don’t automatically show up in the Details sidebar for all users in Intercom unless they’re “pinned” there. This threw us off initially because we thought there was an issue with the installation, but it turned out part of our team just hadn’t added it to their Details sidebar in Intercom. 

To do this, you need to scroll all the way to the bottom of the Details sidebar in Intercom, click the Edit apps button, and then pin the Linear integration item in the list. Then you’ll see it on any customer chat in that sidebar view. 

2. Know when to Triage and when to Backlog

When creating a new issue (most commonly for us it’s a bug report or a niche feature request we hadn’t heard of previously) via the integration, you have the option to set a “Status” on it in Linear. By default, it will use Triage, which is a great feature in Linear that makes it easy to sift through your more recent issues and decide whether they need action taken or should move to the backlog.

We generally try to encourage our team to only put bug reports or escalations into Triage so that that list is almost exclusively stuff that demands our immediate attention. Feature requests typically will go into the Backlog directly from Intercom, unless it’s a feature that we’re actively working on. This keeps our Triage list clean and makes it significantly easier to manage.

3. Use parent issues and sub-issues correctly

This is also just good project management practice, but we learned early on that using parent issues to capture a broad feature request (e.g., “Better sharing capabilities for Scheduling Links”) is a nice way to map to customer chats in cases where a user hasn’t described a super-specific version of their request, and using sub-issues with more granular requirements (e.g., “iFrame embeds for Scheduling Links”) is a nice way to map chats where the user has provided an exact outline of what they want. 

This ensures that when you close tickets and they reopen chats, you can be confident in how you message the release around what the user originally asked for.

We had a couple of cases early on in our use of Intercom where we’d let a number of users know we’d delivered their feature request, only to be told “Well, that wasn’t exactly what I was looking for.” So having this kind of hygiene for your tickets helps to make closing the loop even more reliable.

It also has another more procedural benefit: by using parent tickets, you can create sub-issues for the actual engineering work so that as engineers close tickets, it doesn’t reopen a bunch of tickets. We like to assign the parent ticket to the person who will do the notifying (often it’s one of the founders) so that they can close it when they’re confident that the feature is fully ready.

4. Make your issues easy to search

The search experience in Linear (and via the integration) can be a little finicky in terms of how it matches keywords, and – through no fault of Linear or Intercom’s – users also love to explain the same thing to you in many different ways, and internally the working title of a feature request can morph over time. 

That means that you may hear a request for something like “Calendar Sync filtering” that is actually the same thing as “Selective Calendar Sync” which may also be the same thing as “Calendar Sync sync rules”. 

For this reason, we tend to use a simple strategy for managing feature requests: overloaded titles. Think of it like any other search optimization exercise – you want to provide as much surface area for keywords as possible so that you can make something easy for even someone without the context of the feature to be able to map it properly. Here’s a silly example:

It makes for some funny titles…but your users don’t care about that! As long as your team can track it, who cares if the title is a little weird?

5. Get clear with your team on Linear workflow states

As we mentioned above, the Linear / Intercom integration will automatically reopen chats when an issue in Linear gets moved to Completed or Canceled. It’s super powerful…and also a little scary when someone inadvertently marks something as Completed or Canceled that has a ton of chats attached to it, and it reopens them all at once.

Our advice here is pretty simple: talk to your engineering team and let them know you have this process and integration in place, and make sure they understand that if they move a ticket to Completed or Canceled, and it has Intercom chats attached to it, it will reopen all those tickets (and will be a signal to our support folks that those users need to be notified). 

It’s not the end of the world if you do this accidentally a few times – as we have – because you can very easily bulk-edit and close open chats in Intercom, and then just move the issue back to any other state besides Completed or Canceled, and then it will be primed to reopen those chats again in the future. But it’s good practice to get into to give the people on your team a heads up when you’re doing that:

6. Do the same thing for tags

Again, mostly just good project management practice in general, but tags are another great way to make your customer request backlog discoverable and searchable. We use tags that are a mix of feature areas (e.g., “Tasks”, “Habits”) and simple modifiers to describe what kind of thing it is (e.g., “Bug”, “Improvement”, “Frontend, “Backend”). 

Again, tags should be a bit like titles for tickets: they should be easy to search for and intuit based on even a cursory understanding of the product or request. And a really nice practice, especially for when you’re linking to stuff in the Backlog or creating something that’s going there, is to tag so that you can get stuff sorted into all your nice categories in Linear:

7. Use the integration to gather early feedback and run betas

Another huge benefit of having tickets attached to customer chats: it’s super easy to reach out to customers or users when you’re trying to get feedback early in a project. You can read exactly how they described the feature in their own words, and also identify people who you might want to reach out to and ask to participate in a beta. 

We use this workflow a lot when we’re doing early design research on a new feature, or when we’re opening up something that is very unpolished to a small handful of people. Our design team also uses it when coming up with functional use cases to help them understand the scenarios that people have been referencing when asking for a feature.

Another neat use of Linear here is to track overall request volume. We have this handy view in Linear that shows us all our issues sorted by Intercom attachment count, which is a great way to see your request backlog sorted by “popularity”:

8. Make your outreach as personalized as possible

Perhaps the most important tip of all: the whole reason you’re doing this (or at least the reason we do) is because it lets you give your users an experience they never get from software vendors – personalized outreach to let them know that a thing they asked you for days, weeks, months or even years ago is finally available. 

I cannot tell you the number of times we’ve gotten replies that look like this when we close the loop with a few hundred people who requested something:

Sending personalized “close-the-loop” outreach takes us maybe 10-15 minutes at most. Here’s how we do it:

1. Mark the request complete and it’ll open all the chats associated with it
2. In Intercom, select all the chats that just opened and bulk-edit them
3. Write something like the paragraph below, add an action to Close the chat, and reply
4. All the tickets will close, all the chats get sent, and just like that…you’ve closed the loop!

Nothing crazy, right? Doesn’t need to be hyper-tailored, just acknowledging (with confidence) that this was someone who requested the feature, and sending them a one-off, non-marketing email about it goes a long way. This works well for bugs or non-features too!

This isn’t easy, but it’s worth it

It took us a while to work out all the kinks in our integration between Linear and Intercom – moreso in terms of data integrity and process than the integration itself – but it has been so worthwhile. 

Have we occasionally made some mistakes and let a few people know about a feature who didn’t request it? Heck yeah we have. But the benefits vastly outweigh the costs here (especially cost of Intercom). It’s given us a really nice process for tracking requests. It’s forced us to invest in our project management system (Linear) because we recognize that it’s tied to actual customer conversations. It’s made everyone on our team – including those who don’t do customer support – much more aware of what users are experiencing and asking for.

More than anything: it’s built our brand up in some incredibly positive ways. When you do little things like this that go around the normal marketing channels, your users start to think of you as a team that really, actually listens to them, that doesn’t forget to follow up, and that makes personal, human connections. It’s been worth it ten times over.

Don’t let a few stumbling blocks keep you from implementing this in your team. So much good stuff happens when you just close the loop.