01 / Situation
The situation
Support for a connected product rarely begins with a clean problem statement. A customer describes a symptom; the underlying issue may sit in installation, hardware, firmware, connectivity, cloud state, configuration or expected product behavior.
Retrieval helps, but it does not decide which observation matters next. The hard part is separating what was reported, observed and inferred, then choosing the next question or tool call without crossing the customer’s authority.
02 / Responsibility
My responsibility
I define how the investigation should work across documentation, product telemetry, diagnostic tools, evaluation and human support.
I keep diagnosis tied to observable product state and make the handoff useful when the available evidence is not enough.
03 / Complexity
What makes the work difficult
- Customer descriptions are incomplete and product state changes over time.
- Evidence can be distributed across devices, cloud services, installation history and support records.
- Some tool actions are observational; others can change product state and require tighter permissions.
- A useful escalation needs to preserve hypotheses, evidence and uncertainty—not merely hand over a transcript.
04 / Principles
How I approach it
Keep more than one explanation alive
A plausible first answer can still be wrong. I want the investigation to show which observation would strengthen or weaken each explanation.
Ask a question for a reason
Each question should narrow the investigation. More text is not necessarily better product evidence.
Test against work people actually did
I use representative support cases and a measured human baseline, including the quality of escalation and recovery when the first answer is wrong.
Build the handoff first
High-risk, ambiguous and permission-sensitive cases need an intentional route to a person, with the useful work already preserved.