Ground with
Conversation, customer, device, version, telemetry, and knowledgeSend engineering the evidence, not a paraphrased ticket.
Connect the customer report, affected environment, telemetry sequence, and source conversation to a reviewed GitHub issue and the customers it affects.
BTX gives support a structured path from customer report to engineering work. The operator verifies the customer, affected app or device state, recent events, related support history, and relevant knowledge before preparing an editable GitHub issue. Repository permissions and an explicit confirmation still control issue creation and closure.
Review in
BTX or the bound Slack workflowTrack through
The connected GitHub repository and linked sourceBuild the escalation from verified records.
Preserve the customer language
Keep the original report and attachments available instead of rewriting away the symptom.
Name the affected environment
Include only the device, software, flag, and account context relevant to the problem.
Show the event sequence
Use stable event names, timestamps, error codes, and bounded properties that engineering can interpret.
Link related customer evidence
Keep other affected conversations discoverable without claiming they share a root cause before it is verified.
Review the engineering action before it runs.
BTX can prepare an issue title and body from grounded evidence, expose the connected repositories and eligible assignees, and preserve a source link back to the customer work.
The operator reviews the content and selects the action. GitHub remains the owner of repository access, issue state, and assignee permissions.
Bring the result back to the customer workflow.
A linked product issue gives the support team a durable way to understand what engineering is investigating and which customers may be affected.
Closing engineering work does not automatically prove a customer recovered. The team still needs the customer reply or new product evidence that confirms the fix reached the affected experience.
What belongs in a support-to-engineering handoff
| Evidence | Include | Avoid |
|---|---|---|
| Customer report | Original symptom, context, attachments, and source link | A generalized summary that changes the customer’s meaning |
| Product environment | Relevant app, firmware, device, and feature state | Unrelated profile data or secrets |
| Telemetry | A short event sequence with stable names and timestamps | An unbounded dump of raw logs |
| Scope | Related customers or conversations presented as evidence | An unverified claim that every report has the same root cause |
Frequently asked
Does BTX create GitHub issues without review?
The current workflow prepares an editable issue and requires an explicit operator action within the configured integration boundary.
Can support see whether other customers are affected?
Support can inspect related conversations and product evidence. Similar symptoms should remain evidence for investigation until a shared cause is verified.
Does this replace engineering observability?
No. BTX provides the customer-facing slice of evidence. Engineering should continue deeper tracing, metrics, reproduction, and infrastructure diagnosis in its own systems.