How to Reply When You Don’t Have a Fix in 10 Minutes

A customer reports a broken integration while you are halfway through a deployment. You check the logs, reproduce nothing, and realize there is no chance of finding the fix within ten minutes.

You should still reply.

HubSpot research found that 90% of customers consider an immediate support response important or very important, while 60% define “immediate” as ten minutes or less. That does not mean customers expect every bug to be solved in ten minutes. They want to know that someone has seen the problem and taken responsibility for it. (HubSpot)

Your first reply therefore has a simpler job than delivering a solution:

Confirm that the report reached a real person, show that you understand the impact, and explain what will happen next.

For an indie developer or small SaaS team, that is a much more realistic standard than promising instant resolution.

The difference between a fast reply and a fast fix

First response time and resolution time measure different things.

• First response time is how long the customer waits before receiving a useful acknowledgment.
• Resolution time is how long it takes to diagnose and solve the underlying problem.
• Next-update time is the deadline you give the customer for hearing from you again.

You directly control the first and third. You may not control the second.

A failed payment could take five minutes to understand. A race condition that only appears under a customer’s production load might take days. Treating both cases as if they require an immediate fix encourages rushed patches, weak testing, and promises you cannot keep.

A quick acknowledgment buys you investigation time without leaving the customer in a support void.

What to include in the first 10-minute reply

A useful holding reply needs five elements.

1. Acknowledge the specific problem

Avoid generic openings such as:

Thanks for reaching out. We are looking into this.

That message proves only that an inbox exists. Instead, name the actual issue:

Thanks for reporting this. I can see that newly invited team members are reaching the confirmation page but cannot finish joining the workspace.

The second version tells the customer that you read their message and understood the failure.

If the report is still unclear, state what you do know:

I understand that exports started failing after this morning’s update. I have not confirmed yet whether this affects every export format or only CSV files.

This is specific without pretending you have completed the diagnosis.

2. Recognize the impact

Technical accuracy is not enough. A broken feature may be stopping someone from billing clients, presenting a demo, or completing a time-sensitive migration.

Mention that consequence when it is reasonably clear:

I realize this is blocking today’s payroll export, so I’m treating it as urgent.

Do not exaggerate or copy the customer’s frustration back to them. One direct sentence is usually enough.

3. Say what you have checked—or will check next

Customers do not need a stream of internal debugging notes. They do need evidence of forward movement.

Useful examples include:

• “I’m checking the deployment logs and recent authentication changes.”
• “I’ve reproduced the error on Android 15 and am narrowing down the cause.”
• “I’m comparing your webhook delivery history with our provider’s status.”
• “I haven’t reproduced this yet, so I’m testing with the account conditions you described.”

This is better than saying “the team is investigating,” particularly when the team is just you.

4. Ask only for information you genuinely need

Do not turn your acknowledgment into a questionnaire. First use the details already available from logs, account history, screenshots, and the original message.

If one missing fact would materially speed up the investigation, ask for it:

When you have a moment, could you send the approximate time of the last failed sync and the workspace name? Please do not include passwords or API keys.

Explain what is safe to share. Customers under pressure may otherwise paste secrets, personal information, or an entire production configuration into an email.

5. Promise the next update, not the final fix

This is the most important part.

If you do not know when the issue will be fixed, do not invent an estimate. Commit to a communication checkpoint instead:

I’ll update you by 3:00 p.m. UTC, even if I have not found the cause by then.

That promise is credible because it depends on an action you control.

Use exact times and include the time zone. “Soon,” “ASAP,” and “later today” mean different things to different people.

A reusable reply template

Use this as a starting point, then adjust the level of detail to the severity of the problem:

Hi [name],

>

Thanks for flagging this. I understand that [specific problem], which is currently [customer impact].

>

I don’t have a confirmed fix yet. I’m checking [next investigation step]. If you can share [one necessary detail], that will help me narrow it down. Please don’t send [relevant sensitive data].

>

I’ll send you another update by [specific time and time zone], even if the investigation is still in progress.

>

[Your name]

The sentence “I don’t have a confirmed fix yet” is usually better than “I don’t know.” It is honest, but it also makes clear that the investigation is active.

Examples for common indie SaaS situations

A production feature is failing

Hi Maya,

>

Thanks for reporting this. I can see that PDF generation reaches 100% but no download appears. I realize that is blocking the reports you need to send today.

>

I don’t have a confirmed fix yet. I’m checking the export workers and the changes included in this morning’s deployment. You do not need to retry the same reports for now.

>

I’ll update you by 14:30 CET, even if I’m still narrowing down the cause.

This reply confirms the symptoms, recognizes the practical impact, prevents wasted retries, and provides a concrete checkpoint.

You cannot reproduce the bug

Hi Daniel,

>

I’ve tried the steps you sent on the current iOS version, but I haven’t reproduced the crash yet. That does not mean the issue is on your side.

>

I’m checking the crash reports now. Could you send the app version shown under Settings → About and the approximate time of the latest crash? Please don’t send any login details.

>

I’ll follow up by 5:00 p.m. UTC with what I find.

“That does not mean the issue is on your side” matters. Without it, “I can’t reproduce this” can sound like a polite version of “you are wrong.”

A third-party service may be responsible

Hi Elena,

>

I’ve confirmed that your requests are reaching us, but the downstream payment verification is timing out. The issue may involve our payment provider, although I have not confirmed that yet.

>

I’m checking their status and our request logs. I’ll update you by 11:30 a.m. ET. If there is a safe workaround before then, I’ll send it immediately.

Do not blame a vendor before you have evidence. To the customer, the integration is still part of your product.

An app store reviewer reports a serious issue

Sorry about this. I’m investigating the login failure you described on Android 16, but I don’t have a confirmed fix yet. If possible, please email support with your app version and device model so I can match the report to our logs. I’ll post an update here when the cause is confirmed.

App store replies are public. Keep them concise, avoid discussing account details, and never ask the reviewer to post personal information publicly.

What not to say

“We should have this fixed in an hour”

Do not provide a resolution estimate just because silence feels uncomfortable. One hidden dependency can turn an hour into a day, leaving you with both a bug and a broken promise.

Say when you will report back instead.

“Everything looks fine on our end”

This dismisses the customer’s evidence. Your monitoring can be green while one account, browser, region, or data shape is failing.

A better version is:

Our general monitoring is not showing a wider outage, so I’m investigating whether this is limited to a specific account or request type.

“I’ve escalated this to the relevant team”

If you are the founder, developer, and support team, customers can usually tell. Empty enterprise language makes a small product sound less trustworthy, not more capable.

Say what is actually happening:

I’m pausing my current work to investigate this now.

“Sorry for the inconvenience”

The phrase is not inherently wrong, but it becomes meaningless without ownership. Connect the apology to the real effect:

I’m sorry this stopped you from completing the import before your client meeting.

“Try again later”

Give customers a reason, a time, or a safer workaround. Otherwise, you are asking them to become your monitoring system.

When a workaround is useful—and when it is dangerous

A workaround can reduce the customer’s immediate pain while you investigate the real defect.

Good workarounds are:

• Reversible
• Tested under the customer’s conditions
• Clear about their limitations
• Unlikely to damage or duplicate data
• Easy to stop using after the fix

For example:

As a temporary workaround, you can export one project at a time. I tested that path against a copy of the affected data. It will not change your records, but it may take longer than the normal bulk export.

Do not suggest a workaround that involves disabling security controls, editing production data manually, repeatedly charging a card, or deleting and reinstalling an app without understanding what local data might disappear.

The benefit of a workaround is speed. The downside is that it can create a second problem. When the risk is unclear, wait until you have verified it.

Keep updating even when nothing has changed

Missing your promised checkpoint can damage trust more than the original slow response.

If you still do not have the answer, send a short progress update:

Quick update: I have ruled out the latest deployment and confirmed that the failure is limited to workspaces with more than 50 custom fields. I’m testing that path now. I don’t have a safe fix yet, and I’ll update you again by 6:00 p.m. UTC.

A good progress update answers three questions:

• What have you learned?
• What are you doing next?
• When will the customer hear from you again?

“No fix yet” is acceptable. Disappearing after promising an update is not.

For longer incidents, increase the interval once the situation is stable. A critical outage may justify updates every 30 minutes. A non-blocking edge case may need one update per business day. Set the cadence according to impact, not anxiety.

Match the response to severity

Not every ticket deserves the same ten-minute interruption.

A simple priority system is enough for most small teams:

| Priority | Typical situation | First response target | Update approach | |---|---|---:|---| | Critical | Data loss, security concern, widespread outage | As soon as possible | Frequent scheduled updates | | High | Customer’s core workflow is blocked | Within 10–30 minutes during coverage hours | Update until a workaround or fix exists | | Normal | Partial failure with another path available | Within the stated support window | Give one clear next checkpoint | | Low | Cosmetic bug, idea, or general question | Normal queue order | Acknowledge without false urgency |

Publish realistic support hours and response targets. A solo founder does not need to imitate a 24-hour enterprise support center. Clear boundaries are more useful than an “always available” promise you cannot sustain.

Security reports require a separate workflow. Acknowledge receipt, avoid confirming exploit details prematurely, preserve relevant logs, and move sensitive discussion to a private channel.

Use AI for the draft, not the decision

AI-assisted support is becoming common. In Intercom’s survey of more than 2,000 support professionals, 76% said their teams had invested in AI, and 85% believed AI tools were raising customer expectations. (Intercom’s 2025 Customer Service Transformation Report)

That makes fast drafting useful, but it does not make unsupervised replies safe.

A 2024 Gartner survey of 5,728 customers found that 64% would prefer companies not to use AI in customer service. Their leading concern was greater difficulty reaching a person. Gartner’s Keith McIntosh summarized the customer’s position clearly: “Once customers exhaust self-service options, they’re ready to reach out to a person.” (Gartner)

For small teams, the sensible middle ground is human-in-the-loop drafting:

• Let AI summarize a long report.
• Use it to extract reproduction steps and missing details.
• Have it draft a specific acknowledgment in your normal voice.
• Check every technical claim and deadline.
• Remove invented causes, fixes, or promises.
• Approve the message yourself.

A tool such as SupportMe is designed around this model: it can draft from your knowledge base and learn from your edits, but nothing sends without your approval. That distinction matters most when there is no confirmed fix. The AI can reduce the time needed to write the response; you still decide what is true, what is safe, and what you can promise.

The more reliable your saved replies and knowledge base become, the easier it is to respond quickly without sounding robotic. Still, templates should provide structure rather than replace judgment.

Turn the incident into better support infrastructure

After resolving the issue, spend a few minutes capturing what would make the next response faster.

Record:

• The customer-visible symptoms
• The affected versions or account conditions
• Safe diagnostic questions
• Sensitive information customers must not send
• Any verified workaround
• The final cause and resolution
• The language that explained the issue clearly

This does not require an enterprise ticket taxonomy or a week-long documentation sprint. A short internal note, saved reply, or automatically updated knowledge base can be enough.

Also review the communication itself. Did you ask for information already present in the logs? Did you miss an update deadline? Did your first message overstate what you knew? Those lessons are often as valuable as the technical fix.

The practical rule

When you cannot fix the issue in ten minutes, do not spend those ten minutes pretending you can.

Send a specific acknowledgment. State what you know, admit what you have not confirmed, recognize the customer’s impact, and promise a time for the next update. Then keep that promise.

Customers can tolerate a difficult bug. What they struggle to tolerate is uncertainty with no owner.