Robot context
Model, device ID, release, connectivity, sensor state, and recent actionsPut robot state beside the operator conversation.
Connect the operator’s report to the exact robot, release combination, connection history, product-defined diagnostics, and recent actions.
Robotics support needs more than a ticket because the product has state, location-dependent behavior, software, firmware, sensors, and a history of actions. BTX gives the team a customer-facing view of that evidence beside the conversation.
Operator context
Who was using it, what they attempted, and what outcome they sawFleet context
Whether the pattern is isolated or shared across similar robotsKeep the human impact attached to the machine state.
Engineering observability can explain a robot process. Support also needs to know which customer was affected, what they were trying to accomplish, what guidance they received, and whether the issue changed their ability to use the product.
BTX connects those views without requiring the operator to translate every technical detail into a ticket.
Connectivity
Network, transport, reconnect, and last-known online state.
Software and firmware
Release combinations, updates, configuration, and rollback context.
Sensors and diagnostics
Product-defined health events and stable error codes that support can act on.
Operator workflow
The action attempted, the observed outcome, and any recovery step already tried.
Move from one robot to the affected fleet.
A confirmed issue can define a device cohort by model, firmware, app version, configuration, or telemetry signature. Teams can investigate the scope before more operators file the same report.
Support evidence is not remote control.
BTX makes authorized product context available to support. Any remote command, safety-critical action, or automated recovery remains governed by the robotics product and its own approval and safety controls.
Robotics support questions
| Question | Evidence | Outcome |
|---|---|---|
| Is this robot online? | Last connection, transport, and reconnect events | Restore connectivity or escalate network state |
| Did an update cause this? | Firmware, app version, configuration, and event timing | Identify regression or rule it out |
| Is the hardware unhealthy? | Product-defined sensor and diagnostic events | Recover configuration or begin service workflow |
| Who else is affected? | Matching model, release, configuration, and telemetry cohort | Investigate fleet scope and communicate precisely |
Frequently asked
Does BTX replace robotics observability?
No. BTX complements engineering observability by bringing the customer-facing slice of robot and app evidence into the support and product workflow.
Can BTX send commands to a robot?
BTX does not make a general remote-control promise. Product-specific actions must remain inside the robotics system safety and authorization model.
Can robotics teams use BTX before they have a large support team?
Yes. It can give founders and engineers a shared customer-device history before support volume justifies specialized roles.