How can I describe an intermittent product problem so customer support understands it?
Quick answer
Keep a brief log each time the problem occurs, noting the date and time, what you were doing, relevant conditions, what happened, and any exact error wording. If useful, also record a comparable occasion when it did not happen. Stick to what you observed; don’t attempt repairs or recreate anything unsafe. Send support the log with the product’s identifying details and a clear request for the help you need.
The question, the details, the next step.
The problem comes and goes, so I’m not sure how to explain it. What should I write down when it happens?
Write down the event while the details are fresh. Use the same headings each time so support can compare one occurrence with another. Record:
- Date and approximate time.
- What you were doing just before and when the problem appeared.
- Relevant conditions, such as the selected setting or whether the product had just been turned on. Include only details you actually observed.
- What the product did, in plain language.
- Any message or indicator, copied exactly, including punctuation or numbers if visible.
- What happened next, such as whether the problem stopped on its own or continued.
It can also help to note a relevant occasion when you used the product in a similar way and the problem did not happen. Don’t guess at a cause; separate observations from theories.
Can you give me a log I can copy? I don’t want to write a long report every time.
Use a short entry like this and duplicate it for each occurrence:
Product/model: [as shown on the product or packaging] Problem first noticed: [date or approximate date] Entry number: [1, 2, 3…] Date/time: [date and approximate time] What I was doing: [brief description] Conditions/settings: [only relevant details I observed] What happened: [plain, specific description] Exact message or indicator: [copy it exactly, or write “none seen”] What happened afterward: [brief description] Other useful observation: [optional]
Keep each entry factual and concise. If you don’t know a detail, write “not sure” rather than filling it in. Leave out unrelated history so the pattern is easy to scan.
What would a good entry look like if it happened once, then didn’t happen the next time?
Here’s a fictional example using placeholders. It demonstrates the format, not a diagnosis:
Product/model: [product], model [as shown on label] Entry number: 1 Date/time: [date, approximate time] What I was doing: Selected [setting] and pressed start. Conditions/settings: Product had been off for about [time]; other conditions not noted. What happened: It stopped about [time] after starting. Exact message or indicator: [copy the message as seen, or write “none seen”] What happened afterward: I stopped using it and recorded the message.
Comparison, [date, approximate time]: Selected [same setting] and pressed start. It ran for about [time] without stopping or showing a message. I did not note other conditions.
Those entries let support compare a problem event with a similar occasion when it did not occur, without claiming to know why. Use your own details, not the example’s.
How should I send it to support, and what should I avoid doing?
Put the brief log in your message and make your request explicit. For example:
“Hello, I’m reporting an intermittent problem with [product/model]. I’ve recorded the occurrences below. On [date/time], [what happened] and the display showed ‘[exact wording]’. On [comparison date/time], [what happened]. Could you advise what information you need next and what safe next step you recommend? I have not tried to repair or open the product.”
Add any identifying details support asks for, using their requested format. Keep the original wording of messages and distinguish what you saw from what you suspect. Don’t open, alter, or try to repair the product to make the problem happen again. If recording an event would require unsafe use, don’t do it; simply tell support what you already observed. Save a copy of your notes so you can refer to the same dates and wording if support asks a follow-up.
A practical checklist
Create one entry per occurrence and record the date and approximate time.
Describe what you were doing and relevant settings or conditions you actually observed.
Copy any message or indicator exactly; note when none appeared.
Record what happened afterward and, when useful, a comparable occasion without the problem.
Separate observations from guesses, avoid unsafe attempts to reproduce or repair the issue, and state what help you are requesting.
A few more useful answers
Should I include a possible cause in the log?
You can mention a theory separately, labeled as a guess, but lead with what you observed. Support can more easily assess a clear timeline than a conclusion presented as fact.
What if I don’t know the exact time or a condition?
Use an honest estimate, such as “around 8 p.m.,” or write “not sure” or “not noted.” A clear gap is better than an invented detail.
Should I keep recording the problem until I have several examples?
Record what has already happened; don’t keep using or recreate a situation if doing so could be unsafe. You can contact support with the information you have and ask what they need next.