Start with
A customer question or product decisionUse product evidence to change the outcome.
See how connected-product teams use BTX to prevent avoidable returns, hand verified evidence to engineering, understand customer feedback, and support releases.
BTX is useful when the customer outcome depends on evidence outside the message itself. It connects the conversation to customer identity, device and app state, structured telemetry, feedback sources, knowledge, and bounded team actions while keeping each source and ownership boundary visible.
Investigate with
Identity, versions, device state, events, and historyAct through
Support, product, engineering, and connected systemsChoose the workflow by the decision the team needs to make.
Can we fix this before a return?
Inspect the affected device and recent product events before treating the problem as a hardware failure.
What should engineering investigate?
Carry verified customer and product evidence into an editable GitHub issue workflow.
What are customers telling us?
Keep Community, focused feedback, app reviews, and support conversations distinct but visible together.
Who received the affected release experience?
Use app version, firmware, feature state, and telemetry to explain a customer report.
Keep the evidence connected after the first answer.
A useful resolution becomes more valuable when it can inform the next conversation, the next affected customer, and the product decision behind the recurring issue.
BTX keeps the source conversation and product evidence available instead of reducing the outcome to an isolated ticket summary.
Use the source system for the work it owns.
BTX adds customer and product context without pretending to replace engineering observability, the public app stores, GitHub permissions, or a commerce system that owns an order or return.
Availability remains explicit when a workflow depends on a packaged integration, controlled rollout, or project-specific connection.
Match the evidence to the decision
| Use case | Evidence to inspect | Decision |
|---|---|---|
| Prevent avoidable returns | Customer report, device state, versions, recent events, and commerce context when connected | Resolve remotely, continue investigation, or proceed with the return |
| Support to engineering | Conversation, affected environment, telemetry sequence, and related customers | Create reviewed engineering work with the source attached |
| Understand customer feedback | Community, focused feedback, support conversations, and public app reviews | Prioritize research, support guidance, or product work |
| Release and rollout support | App version, firmware, feature state, events, and reported symptoms | Identify scope, give a specific workaround, and verify recovery |
Frequently asked
Does every use case require hardware?
No. The same evidence model can support software products, but BTX is most differentiated when customer outcomes depend on app, device, release, or product-state context.
Does BTX automate every final action?
No. Consequential actions stay bounded by the configured integration, source-system permissions, and explicit operator review where required.
Can a team start with one workflow?
Yes. Start with the customer decision that currently requires the most manual investigation, then add other evidence and workflows as they prove useful.