“It's not working” is a perfectly understandable first report when something goes wrong during a service. People are waiting, the screen is blank, and you want somebody to fix it. But the next few details can make that request much more useful.
Before we start rebooting equipment or changing settings, I want us to pause long enough to describe what we actually see. You do not need to be a network engineer to give the technical team a good starting point.
Name the device and the missing result
“The network is down” is a diagnosis. “The tablet at the audio desk will not connect to the console” is an observation. Start with the observation.
Identify the device, its location, and what you were trying to do. Include any message on the screen, using its actual wording if possible. A photograph can help, provided it does not expose passwords, personal information, or other sensitive details.
Describe what still works, too. If the console is passing audio and its local controls work, say so. That does not identify the cause of the tablet problem, but it keeps everyone from assuming the entire audio system has failed.
Find the edges of the problem
Is one device affected, or are several people reporting trouble? Is the problem limited to one room? Did it happen once, or does it happen every time you try the same action?
Answer what you can observe safely. Do not interrupt another operator or disconnect working equipment just to complete your report. “I haven't checked the other rooms” is useful information. It tells the person investigating where your knowledge ends.
Keep the timeline simple
Record approximately when the trouble started and when the device last worked. Include changes you know about: a cable was moved, a different tablet was brought in, or an application was updated. Avoid turning a guess into a fact.
A change happening before a problem does not automatically mean it caused the problem. Still, a clear sequence gives the person troubleshooting something concrete to investigate.
Protect what is still working
During a live service, a reboot can affect more than the device in front of you. Follow your team's approved recovery procedure and involve the person responsible for that system before changing network settings or restarting shared equipment.
If you have already tried something, write it down along with the result. That prevents the next person from repeating the same step without realizing it. It also helps separate the original symptom from anything that changed afterward.
Use a report someone can act on
- Where and what: device name and location.
- Expected result: what you were trying to do.
- Observed result: what happened, including the exact error.
- Scope: what else is affected and what still works.
- Timing: when it started and when it last worked.
- Actions: what has been tried and what changed.
For urgent problems, contact the responsible person immediately rather than relying only on a form or message thread. The report supports that conversation.
This week, choose one familiar device and write a sample trouble report using those six prompts. Keep it somewhere your volunteers can find it. A calm, specific handoff is a skill we can teach before the next problem arrives.