Playbook

Alert your team when issues are reported on channels like GitHub, Stack Overflow, and Reddit

Help your team triage issues posted to any channel.

Start for free

Teams:

Developer Relations

Sources:

GitHub logoGitHubReddit logoRedditStack Overflow logoStack Overflow

Overview

Nowadays, support-related product questions come from all directions.

Whether an issue is reported through your preferred channel (think support platform Zendesk) or just thrown to the ether (think a social platform like Reddit or Twitter), the requester expects a prompt response.

In this playbook, we’ll show you how to monitor issues and send alerts to your response team so they can prioritize triage by the standing of the submitter (e.g., a customer vs. a student).

What you’ll need

Common Room — to monitor activity where support-related issues are submitted (Sign-up for free to follow along).
Access to the channels where requests are submitted (e.g., GitHub, Reddit, Stack Overflow.)

Step 1: Define the surface area (channels) to monitor support requests

For this playbook, let’s imagine we’ve developed open-source software with a lot of traction. And we also offer a managed SaaS service that supports our OSS.

To start, we’ll want to connect to external sources outside of our support ticketing system using Common Room.

Let’s start with GitHub since we know that many issues are reported by our community on that channel. First, we’ll select to Connect GitHub as a new source in our Common Room workspace:

Connect GitHub to Common Room
Note: connecting to GitHub requires approval from one of your org admins. If you are not an org admin and proceed through the integration setup, GitHub will email your org admins requesting their approval. Common Room will begin importing activity from your repo once an admin approves the request.

Once approved and authenticated, you’ll see activity data from GitHub in your Common Room instance after a few minutes.

We can then follow a similar pattern and connect other sources where issues are reported, like Stack Overflow, Reddit, and Twitter. For the sake of brevity, we’re not going to walk through how to connect to each of these sources in this playbook. You can find comprehensive instructions on how to connect sources in our docs here →


Step 2: Detect when issues are submitted

After connecting to sources where user-submitted issues arise, we can begin adding filters to narrow down member activity to support-related issues.

For our main channel, GitHub, this is pretty straightforward. We can head over to the Members view and narrow our view by adding a filter that shows members with a GitHub issue in the last 28 days.

Filter members by GitHub issues

This narrows our view to just a handful of members and feels like a good starting point for triage.

So, we’ll select all members who qualify and add them to a new segment named “Issue Triage.”

Add members to a new Segment

Now that we have our initial segment of open issues, we can go ahead and start filtering + adding new sources to triage support tickets.

Let’s walk through one more example together—Stack Overflow. For that, we can reset our filters and add a new filter that includes Stack Overflow as our source, along with at least 1 question submitted in the last 28 days.

Filter members with Stack Overflow questions

We’ll then go ahead and select all of these members and add them to our newly created triage “Issue Triage” segment. From here, we can jump into the Segment view in Common Room for our next step.


Step 3: Set your stages for triage management

In this step, we’ll create a few statuses for group members to triage issues accordingly. We’ll click on + Add status and create three—Needs ReviewWorking, and Resolved.

Create and edit status of a segment

Because this is our first time going triaging issues, we’ll want to review all. We can add all members to the Needs Review status by selecting all members and changing their status.

Change the status of members

From here, we can work with our devrel or support teams to work through each issue reported in Common Room.


Step 4: Resolve a few issues for testing

For our next step, we’ll want to resolve a few issues to get a feel for the process so we can automate it.

Let’s start by sorting our list by impact points.

Note: Impact points are an automated Common Room attribute to help you quickly understand which members have the most influence/relevance. More on how we weigh impact score here.
Sort members by impact points

We can click into member and get an overview of their attributes and activity—more on what’s included on member profiles here.

See an overview of the member profile

From here, we can scroll down and find the submitted issue. And we can click to view it on GitHub.

Activity from GitHub open issue

Let’s pretend we’ve verified this as a real issue that needs to be resolved. We can click on the activity and tag it as Issue Pending.

Tag GitHub activity

Now, this is the part where you (or your support team) will have to actually resolve the issue.

After resolving, we can jump back into the same GitHub activity and add a new activity tag for Issue Resolved.


Step 5: Add automation to member status as issues are resolved

We’re almost done. We just need to add a bit of automation to the mix.

To do that, we can click on the Member management tab of our segment and select Set criteria to auto-update the “Working” status.

Set criteria for segment status automation

To set our criteria, we’ll add a filter for Activity tag = Issues Pending (remember this is the action we took to create a burn-down list for triage in the step above).

We’ll see a preview of members who qualify. And we can click Save.

We can run through a similar process to automate the Resolved status. But this time, we’ll add an activity filter for Issue Resolved.


Step 6: Send notifications for your team to review

Phew! We’ve made it to the last step. Here, we’ll want to send a notification when a new issue is ready for review.

Set criteria with powerful filters

To do that, we’ll click Set criteria for the “Needs Review” status.

And we’ll just use our initial criteria from above — members with a GitHub issue in the last 28 days or with 1 Stack Overflow question submitted in the previous 28 days.

Filter criteria to automate member status

Our list looks good, so we’ll locate the Notifications menu item in this segment view and turn on notifications for member additions and status changes.

And that’s it! We now have an automated way of tracking issues and alerting the team responsible for resolution and triage.

rocket ship blasting off

Try Common Room for free

Start for free

Wanna learn more? Book a demo