Report a customer issue that may affect several users

Separate the report from what you know

Reflect the customer’s concern in plain language: they have reported that the issue may affect multiple users. That is different from confirming that it does. This distinction protects trust and keeps the investigation open to new information.

State what you can verify so far, if anything, and say plainly what remains unknown. For example, you might have one affected user’s report but not yet know whether colleagues can reproduce the same behavior. Avoid describing an incident as company-wide, widespread, or resolved until evidence supports that wording.

A useful acknowledgment does not need to sound defensive. Thank the person for flagging the possible broader impact, confirm that you are assessing it, and explain that you will share what you learn. Do not imply that investigation guarantees a particular outcome or resolution time.

Ask about teams and functions, not just headcount

The number of affected people is useful, but it rarely explains the operational impact on its own. Ask which teams, departments, locations, or business functions are seeing the problem. A shared issue affecting a customer-facing team may need different coordination from one limited to a single person’s workflow.

Request a rough count only if the customer can provide one, and make clear that an estimate is fine. Ask whether the affected users share a role, device, workflow, or other relevant condition. These details can help distinguish a common pattern from several reports that happen to sound similar.

Keep questions focused. A long questionnaire can slow the exchange and burden someone who is already coordinating a problem. Start with the details most likely to clarify scope, then ask follow-ups if the answers point to a useful next step.

• Which teams or functions are affected, and which appear unaffected?
• How many users have reported the issue, approximately?
• What action were users taking, and what happened instead?
• When did it start, and is it continuing?

Collect examples that can be compared

A short, concrete example is often more useful than a broad description such as “everyone is having trouble.” Ask for one or two representative cases: what the user expected, what they observed, and when it occurred. If different teams see different symptoms, ask the customer to keep those reports distinct.

Request only information relevant to investigating the issue. Do not ask the customer to send passwords or one-time passcodes. If they provide sensitive or unrelated details, avoid repeating them unnecessarily in a wider update. Summarize the pattern rather than forwarding personal information to people who do not need it.

Use neutral wording. “Two users in the billing team reported that the save action did not complete” is easier to assess than “the billing system is broken,” provided those are the facts the customer supplied. Label customer-reported details as reports until independently confirmed.

Give a bounded update while assessment continues

A bounded update tells the customer what is happening now and what they can expect next, without pretending to know the final impact. Include the current assessment status, the information you still need, and a time or milestone for your next communication.

Choose a commitment you can control. You may be able to promise another update by a stated time, even when you cannot promise a fix by then. If a new finding changes the picture before that point, send it sooner. If you cannot yet give a meaningful resolution estimate, say so rather than offering a speculative deadline.

Make the boundary explicit: the scope is being assessed, and the update is not a confirmation that all users are affected. This helps the customer relay your message accurately to colleagues and reduces the chance that an early hypothesis becomes treated as fact.

Subject: We’re assessing the reports from your teams

Hi [Customer name],

Thanks for flagging that this may affect several users. We’re assessing whether the reports share the same cause; we have not confirmed the full scope yet.

Could you tell us which teams or functions are affected, approximately how many users have reported it, and what each group was trying to do? One representative example and its approximate time would also help.

We’ll send you another update by [day and time], even if the assessment is still in progress. We can’t yet confirm a resolution time.

Regards,
[Name]

Coordinate the customer’s next step

Ask who will coordinate information from the customer’s side and whether one contact can consolidate reports. This avoids sending duplicate questions to different people and gives the customer a clear route for adding new details. If several functions are involved, ask whether a short summary by team would be easiest for them to provide.

Where appropriate, agree how the customer should report a change in scope—for example, if another team begins seeing the same symptom or the issue stops occurring. Do not ask them to perform disruptive workarounds or make changes unless you have a sound, approved instruction to give.

Check that the exchange is working

After sending the reply, confirm that it reached the intended contact and that the requested questions are understandable. When the customer responds, reflect the scope back in a concise summary: which teams have reports, which have not reported the issue, and which details are still unconfirmed. Invite correction so an assumption does not silently become part of the record.

Before each promised update, check whether you have new verified information. If not, still send the update you committed to: say that assessment continues, note what has or has not changed, and give the next update point. The process is working when the customer knows what is confirmed, what remains uncertain, what information is needed, and when to expect contact—not only when a fix is available.