Field Notes · Practical Support
People usually call support with the part they can see: an error message, a report that looks wrong, a printer that will not cooperate, or a system that seems confusing. That symptom matters, but it may not be the real problem.
Ask what the person is trying to accomplish
“What happened?” is useful. So is “What were you trying to do when it happened?”
The second question can reveal that the workstation is fine but the person lacks access, the software is functioning but the workflow is unclear, the report is accurate but does not answer the business question, or several tools are forcing staff through an unnecessary handoff.
Trace the work around the symptom
Good troubleshooting follows the process in both directions:
- what information came in;
- what the user expected;
- which system or person handled it next;
- where the result became confusing or unusable;
- what a successful outcome would allow the person to do.
Sometimes the answer is a repair. Sometimes it is clearer access, documentation, training, configuration, or a better tool. The technical symptom is evidence, not always the diagnosis.
Solve the actual problem
This approach matters most in unusual environments, where technology supports specialized work and the support person cannot rely on a canned checklist. We have seen that pattern across ordinary offices, field work, home offices, and specialized technical systems.
Computer 911’s service lanes reflect the same idea: fix what is broken, improve what no longer fits, or build what is missing. The job is to understand the practical outcome and help the technology serve the work.
Describe what is getting in the way
Leave a comment