When a problem appears only occasionally, a customer may not remember the details by the time they report it. Asking them to record a few observations the next time it happens can help narrow down what is going wrong—without asking them to collect everything about their account or device. Keep the request specific, explain why each detail matters, and make it easy to reply. Just as important, tell the customer what not to send. A useful capture request gathers enough context to investigate while keeping private information out of ordinary email.
The useful bits
- Ask for observations from the next occurrence, not a full account history.
- Request the time, action, visible result, and whether the issue repeats.
- Explicitly rule out passwords, one-time codes, and unrelated private content.
Make the request about the next occurrence
Start by acknowledging that the issue is intermittent and that you are not asking the customer to recreate it repeatedly. Ask them to note details if it happens again during their normal use. This sets a reasonable expectation and avoids making the customer feel responsible for diagnosing the cause.
Explain the purpose in plain language: the timing and sequence can help distinguish a one-off interruption from a repeatable pattern. Avoid naming a cause before there is evidence. For example, do not tell the customer that a particular device, network, or setting is responsible unless that has actually been established.
Ask for observations, not guesses
The most useful account is usually a short timeline. Ask what the customer was trying to do immediately before the issue, what they expected, and what they saw instead. If they remember the wording of an error, ask them to quote it exactly rather than interpret what it means.
Request the local date and time, including the time zone if they know it. This helps avoid confusion when the customer and support team are in different regions. If the issue appears again, ask whether the same steps produced the same result or whether anything was different. A single observation is still useful; make clear that they should not spend time trying to force the problem to happen.
- What action were you taking just before it happened?
- What did you expect to happen, and what happened instead?
- When did it occur? Include the time zone if known.
- Did you see a message? If so, what did it say?
- Did it happen again during normal use, and were the circumstances similar?
Keep the capture lightweight
A simple note is often enough. Customers can write down the details in a reply or use a brief record they keep until the issue recurs. Do not ask for a long device inventory or a broad history of unrelated activity unless a specific investigation makes that information relevant.
Screenshots can help when the visible screen is part of the problem, but they may contain names, message previews, addresses, or other private material. Ask for one only when it would clarify what appeared, and invite the customer to crop or obscure unrelated details before sharing it. Do not ask them to forward unrelated messages just to provide context.
Subject: Details if the issue happens again Hello [Customer name], I understand this does not happen every time. If it occurs again during your usual use, could you note what you were doing, what you expected, what appeared instead, and the local time and time zone? If there is an error message, please copy its wording. One example is enough; please do not try to trigger the issue repeatedly. A short reply is fine. Please do not send your password, one-time codes, payment details, or unrelated message contents. If a screenshot would help show the error, remove any information that is not relevant before sharing it. Thank you, [Support agent name]
Set a clear boundary around sensitive information
State directly that passwords and one-time codes are not needed. Also discourage sending payment details, private content from unrelated messages, or full screenshots that expose more than the issue requires. Customers may include these details when they are trying to be helpful, so a specific warning is better than a vague request to omit sensitive information.
If an investigation later requires additional material, explain what is needed and use an appropriate, approved way to receive it. Do not ask a customer to bypass a warning or share account access. If they send sensitive information anyway, follow your organization’s handling process rather than quoting or redistributing it in routine correspondence.
Tell them how to reply—and what happens next
Make the reply simple: invite them to respond to the message with the brief observations, and tell them that an approximate time is acceptable if they cannot recall the exact minute. Do not promise that the information will identify the cause or guarantee a fix. You can say it will give the team a clearer account of what happened and help determine what to examine next.
After they reply, confirm that you received the details and restate the key observations accurately. If something essential is unclear, ask one focused follow-up question rather than sending a new, broad questionnaire. This gives the customer a chance to correct misunderstandings and confirms that their effort has been useful.
Check whether the request worked
A capture request has worked when the customer can provide a concise account that ties a specific action to a visible result and gives a usable time reference. The information may still be incomplete, and the issue may not recur. Treat that as a limit of an intermittent problem, not a reason to pressure the customer to keep testing.
Before closing the exchange, verify that you understand what happened, when it happened, and whether it repeated under similar circumstances. Confirm any uncertainty explicitly. If the customer has not seen the issue again, acknowledge that no new observation is available and agree on how they can contact you if it returns.
- Can you describe the action and the unexpected result in one or two sentences?
- Is the time or approximate time clear enough to distinguish the occurrence?
- Have you avoided collecting or repeating unnecessary private information?
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction