From Customer Message to GitHub Issue in 3 Seconds

A customer says: "The app crashes when I try to upload a file larger than 10MB."

Three seconds later:

• A GitHub issue exists with the bug details
• The customer got an acknowledgment
• Your engineering Slack channel has a notification with the issue link

Zero manual effort. The customer feels heard, the engineer has the bug in their workflow, and you did not have to context-switch to make it happen.

The Setup

Step 1: Connect GitHub. OAuth connection, select the repository where issues should be created.

Step 2: Create the routing rule.

Trigger: intent = bug_report, confidence > 80%

Actions:

1. Create GitHub issue:

• Title: Auto-generated from the message
• Body: Customer's full message + metadata (confidence, priority, timestamp)
• Labels: "customer-reported", priority level ("P0", "P1", "P2")

1. Auto-reply to customer: "Thanks for the report. We have logged it and our team will investigate."
2. (Optional) Post to Slack with the GitHub issue link

Step 3: Configure labels and assignees. Map priority levels to GitHub labels:

• Critical priority: "P0" label + auto-assign to on-call engineer
• High priority: "P1" label
• Medium priority: "P2" label
• Low priority: "P3" label

Issue Quality

The auto-created issue should include everything an engineer needs:

• The customer's exact words (unedited)
• When it happened (timestamp)
• What the classifier thinks the issue is about (intent and confidence)
• The customer's priority level
• A link back to the support conversation (so the engineer can ask follow-up questions)

This is often more useful than a manually created issue because the customer's raw message contains details that get lost when someone summarizes it.

Handling Multiple Reports of the Same Bug

When a second customer reports the same issue, you ideally want to add a comment to the existing GitHub issue rather than creating a duplicate. This requires a deduplication step.

Simple approach: the routing rule always creates a new issue. An engineer reviews new issues during daily triage and merges duplicates. This works fine for low to moderate volume.

Advanced approach: search existing issues before creating a new one. If a similar issue exists (matching labels, similar title), add a comment instead. This requires custom webhook logic but reduces noise in your issue tracker.

The Feedback Loop

When the engineer closes the GitHub issue (bug is fixed and deployed), the support system can automatically:

1. Update the support conversation status to "resolved"
2. Send the customer a message: "The issue you reported has been fixed. Please let us know if you are still experiencing it."

This closes the loop without anyone manually updating the customer. The engineer just closes the issue like they normally would, and the integration handles the rest.