How to Reply When a Customer Says the Fix Didn’t Work

When a customer says your fix did not work, acknowledge the result, take ownership of the next step, and ask only for the information needed to continue troubleshooting.

A useful first reply can be as simple as:

Thanks for trying that, and I’m sorry it didn’t resolve the issue. I’d like to take a closer look. Could you send me the exact error message you see now, along with the steps that lead to it? If possible, please also include your browser or app version. I’ll review those details and update you by [time or date].

This response works because it does not argue with the customer, repeat the same instructions, or claim that the problem should be fixed. It turns an unsuccessful attempt into a clear next step.

Start by acknowledging what happened

The customer has already spent time following your instructions. Recognize that effort before asking them to do anything else.

Good opening lines include:

• “Thanks for trying those steps.”
• “I’m sorry that didn’t resolve it.”
• “Thanks for confirming the problem is still happening.”
• “I can see why this is frustrating, especially after you already tried the suggested fix.”

Keep the apology proportional. You do not need a long statement or an admission about the cause before you have investigated it. A brief, sincere acknowledgment is usually more helpful.

Avoid responses such as:

• “It works on our side.”
• “You must have missed a step.”
• “That should have fixed it.”
• “Nobody else has reported this.”
• “Try the same steps again.”

These phrases can sound dismissive and provide no useful direction.

Confirm what changed—and what did not

“Didn’t work” can describe several different outcomes:

• Nothing changed.
• The original error disappeared, but a new one appeared.
• The fix worked briefly and then failed.
• One part of the feature works, but another does not.
• The customer could not complete the instructions.
• The customer’s expected result differs from the product’s current behavior.

Ask a focused question to determine which case applies:

When you tried the fix, did you see the same error as before, a different error, or no error at all?

You can also restate your current understanding:

Just to confirm: after reconnecting the integration, new records still do not sync, while existing records remain visible. Is that correct?

This gives the customer an easy way to correct a misunderstanding before you investigate the wrong problem.

Ask for the smallest useful set of details

A failed fix does not justify sending the customer a long diagnostic questionnaire. Start with the information most likely to separate one cause from another.

Depending on the product, request:

• The exact error message or code
• The steps immediately before the failure
• The expected and actual result
• When the problem last occurred, including the time zone
• The affected account, workspace, record, or feature
• The app, operating system, device, or browser version
• Whether the issue happens every time or only sometimes
• A screenshot or short screen recording
• Whether another browser, device, account, or network shows the same behavior

Microsoft’s support guidance similarly recommends collecting reproduction steps, error details, screenshots, frequency, affected environments, prior troubleshooting, and customer impact. It notes that complete context helps support teams route and investigate an issue more effectively (Microsoft Learn).

Do not request information you can inspect yourself. If your product records the customer’s plan, app version, recent activity, or account status, check those details before adding more work for the customer.

Use a structured troubleshooting reply

A clear response usually contains five parts:

1. Acknowledge the failed attempt.
2. Summarize the remaining problem.
3. Explain what you need next.
4. State what you will do with that information.
5. Give a realistic update time.

Here is a reusable template:

Hi [name],

>

Thanks for trying that. I’m sorry the issue is still happening.

>

From your message, it sounds like [brief description of the remaining problem]. To narrow this down, could you send me:

>

- [specific detail]

- [specific detail]

- [screenshot or exact error, if useful]

>

Please remove any passwords, access tokens, or other sensitive information before sending the files. Once I have those details, I’ll check [relevant area] and update you by [specific time or date].

>

Thanks,

[name]

Only include requests that are relevant to the case. Three precise questions are generally easier to answer than ten broad ones.

Give the customer a reason for each unusual request

Customers may hesitate when asked for logs, recordings, or browser files. Briefly explain what the requested item will help you determine.

For example:

Could you send the exact time of the last failed attempt, including your time zone? That will help me find the corresponding event in our logs.

Or:

If you can reproduce the issue in a private window, that will help us determine whether stored browser data or an extension is involved.

A reproducible test case helps isolate where a software problem originates. MDN’s bug-reporting guidance recommends recording expected and actual results, software versions, screenshots, and a minimal case that reproduces the behavior (MDN Web Docs).

Handle logs and recordings carefully

Ask only for diagnostic data you genuinely need. Tell the customer how to remove or hide sensitive information, and use your approved upload method rather than an informal public link.

HAR files require particular care because they record browser network requests and may contain account or session information. Microsoft explicitly warns that HAR and diagnostic files can contain personal or sensitive data (Microsoft Learn).

A safer request might say:

If the basic details do not reveal the cause, I may ask for a browser network log. I’ll send precise capture and redaction instructions first, because these files can contain sensitive account information.

Do not ask a customer to send passwords, authentication tokens, private API keys, full payment details, or unnecessary personal data.

Do not promise another fix before you understand the failure

After one unsuccessful solution, avoid guessing with a rapid series of unrelated instructions. That creates more work for the customer and makes it harder to know which action changed the result.

Instead, separate facts from possibilities:

The first fix ruled out an expired connection. I have not confirmed the underlying cause yet. The next useful check is whether the failed request reaches our server.

This wording shows progress without pretending the issue is understood.

If you have a strong hypothesis, label it clearly:

One possibility is that the browser is using an older cached file, but I’d like to confirm that before asking you to clear any data.

Offer a workaround when one is available

A workaround can reduce the customer’s immediate impact while you investigate the underlying defect. Be explicit that it is temporary.

While I investigate, you can export the report as CSV from Reports → Export. This does not fix the dashboard error, but it should let you access the current data.

Explain any limitations or risks. Do not present a workaround as a resolution, and do not recommend destructive actions—such as deleting local data—without explaining the consequences and confirming that recovery is possible.

Escalate with context, not just urgency

If the issue needs engineering attention, prepare a concise internal summary:

• Customer impact
• Expected and actual behavior
• Reliable reproduction steps
• Environment and version details
• Exact errors and relevant timestamps
• Fixes already attempted
• Results of each attempt
• Relevant logs or record identifiers
• Available workaround
• Next customer update time

The customer-facing reply should explain the escalation without blaming another team:

Thanks for sending those details. I can reproduce the behavior, so I’ve passed the case to engineering with the error and reproduction steps. I don’t have a confirmed fix time yet. I’ll update you by 3:00 p.m. CET tomorrow, even if the investigation is still in progress.

During a broader service incident, early acknowledgment, clear impact information, ownership, and a stated update cadence help keep communication useful. Atlassian’s incident guidance recommends telling customers when to expect the next update rather than waiting silently for a complete resolution (Atlassian Statuspage).

Reply examples for common situations

The customer still sees the same error

_Hypothetical example:_

Thanks for checking. I’m sorry the same error is still appearing. Could you send the exact error text and the approximate time of your most recent attempt, including your time zone? I’ll use those details to locate the corresponding request in our logs and update you by tomorrow at noon CET.

The original error has changed

_Hypothetical example:_

Thanks—that new message is useful. It suggests the first step changed the connection state, but another part of the process is now failing. Please send a screenshot of the new error and tell me which action triggers it. I’ll investigate that stage next.

The instructions were unclear

_Hypothetical example:_

Sorry—the earlier steps were not clear enough. You do not need to delete the integration. Please open Settings → Integrations, select the existing connection, and choose Reconnect. If your screen looks different, send a screenshot with any private information hidden, and I’ll adjust the instructions.

You can reproduce the problem

_Hypothetical example:_

Thanks for the details. I can reproduce the issue, so you do not need to run any more tests. I’ve documented the failure and passed it to engineering. I’ll send the next update by Friday at 2:00 p.m. CET.

You cannot reproduce the problem yet

_Hypothetical example:_

I tested the same workflow but have not reproduced the failure yet. That does not mean the problem is resolved. Could you send your browser version and the exact time of one failed attempt? I’ll compare your environment and the relevant server events next.

Keep AI-drafted replies under human review

An AI support assistant can prepare the acknowledgment, summarize the conversation, and suggest follow-up questions. However, a person should verify the technical instructions, requested diagnostic data, and promised update time before sending.

For example, SupportMe is designed to draft replies from a team’s knowledge base and writing style while requiring explicit human approval. In a failed-fix case, that review matters: the reply may need account-specific context, careful handling of sensitive information, or a judgment about whether to escalate.

Edits to recurring drafts can also reveal documentation gaps. If customers repeatedly misunderstand the same instruction, revise the saved answer so it includes clearer steps, expected results, and a fallback path.

Before sending, check the reply

Make sure the response:

• Thanks the customer for trying the first fix
• Acknowledges that the issue remains
• Accurately summarizes the current behavior
• Avoids blame and unsupported conclusions
• Requests only necessary information
• Warns about sensitive data where relevant
• Explains the next action
• Provides a realistic update time
• Does not describe the issue as resolved before verification

A failed fix is not the end of the support conversation. The best reply treats it as new diagnostic evidence: acknowledge the customer’s effort, clarify the result, gather focused details, and take responsibility for a specific next step.

References

• Microsoft Learn: Help us help you
• Microsoft Learn: Send diagnostics to Microsoft
• MDN Web Docs: When and how to file browser bugs
• Atlassian Statuspage: Incident communication tips