Playbook

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

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:

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.

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.”

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.

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 Review, Working, and Resolved.

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.

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.

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

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

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.

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.

Workflow

Tag new activities

Identify notable new activities happening in your community and tag them based on a set of filters.

Get started

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.

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.

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.

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.