Start with
The customer message and current deviceFind the failure before asking the customer to repeat it.
Start with the customer message, the product surface it came from, the affected device, and the recent events that led to the problem.
BTX troubleshooting begins with evidence already attached to the customer: stable identity, messenger launch context, connected devices, app and firmware versions, and recent structured telemetry. The team can answer from that evidence and use new events or the customer reply to verify recovery.
Investigate with
Recent events, firmware, app version, and logsClose with
New evidence that confirms recoveryFrom vague symptom to specific cause.
Identify the product state
Attach the relevant device, model, firmware, app version, connection state, and customer identity.
Read the sequence
Review the product events immediately before and after the reported problem.
Respond from evidence
Give the customer a next step grounded in what the app and device actually observed.
Verify the result
Use fresh telemetry or a follow-up message to confirm that the device recovered.
Built for problems that cross app and hardware.
Pairing and connectivity
Separate permission, network, transport, firmware, and device-state failures.
Battery and charging
Connect customer reports with recent battery, charging, and usage events.
Firmware and configuration
See whether a problem clusters around a release, model, setting, or migration.
Setup and onboarding
Find the exact step where activation, account linking, or device discovery stopped.
See the complete investigation without disguising a demo as proof.
The pairing sequence on this page is a representative BTX product demonstration based on the fictional Mocking Bird hardware scenario. It shows the intended workflow, not a customer result or performance claim.
A real evaluation should repeat the flow with one of your products, your event schema, and an issue your team already understands.
The host product controls the evidence it sends.
Product teams choose which structured app and device fields are useful for an authorized support purpose. Sensitive values, secrets, raw credentials, and unnecessary personal data should not be sent.
Workspace access and product identity boundaries continue to apply when telemetry appears beside the customer conversation.
Learn from one issue across every affected device.
A confirmed root cause should not stay trapped inside one conversation. BTX can connect the issue to other customers and devices with the same model, firmware, app version, or telemetry pattern.
That gives the team a path from reactive support to targeted research, proactive help, and product improvement.
Evidence used in device troubleshooting
| Evidence | Question it answers | Example |
|---|---|---|
| Device identity | Which physical product is affected? | Model, device ID, ownership |
| Software state | Which release combination is running? | Firmware and companion-app version |
| Recent telemetry | What happened before the symptom? | Permission, connection, battery, or sensor events |
| Customer history | Has this happened before? | Prior conversations, devices, and outcomes |
| Recovery evidence | Did the proposed fix work? | Healthy connection or successful follow-up event |
Frequently asked
Does the customer have to reproduce the problem?
Not always. If the app already captured the relevant structured events, the team can start from the evidence recorded before the conversation began.
Can BTX troubleshoot smart-home and IoT devices?
Yes. The workflow applies to connected products that can report useful app or device context, including network, permission, firmware, setup, and state changes.
Does BTX automatically control the device?
No general device-control claim is required. BTX brings authorized context into the support workflow so the team or approved product automation can choose the right next action.