How to Reply When a Customer Reports Missing Data

When a customer says their data is missing, reply promptly, acknowledge the impact, and begin investigating—but do not confirm permanent data loss before you have evidence.

A useful first response should do five things:

1. Recognize the problem.
2. State what you know without guessing.
3. Ask for the minimum details needed to investigate.
4. Explain the next step.
5. Say when the customer will hear from you again.

Here is a concise template:

Hi [Name],

>

I’m sorry you’re unable to find [missing data]. I understand how disruptive that can be.

>

We’re investigating now. Could you send us:

>

- The account or workspace affected

- What appears to be missing

- When you last saw the data

- The page, device, or app version you were using

- Any recent actions that may be relevant, such as importing, deleting, changing filters, or switching workspaces

>

Please do not include passwords, API keys, or other sensitive credentials.

>

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

>

Thanks,

[Name]

This response takes the report seriously without claiming that the data has been deleted, corrupted, or permanently lost.

Treat “missing” as a symptom, not a diagnosis

Customers naturally describe what they can see: records have disappeared, an import is empty, or a dashboard no longer shows previous results. The underlying problem may be quite different.

Possible explanations include:

• A filter, date range, or search setting
• A different account, workspace, project, or environment
• Changed permissions
• A delayed import or synchronization job
• A temporary display or indexing problem
• An unsuccessful save
• An accidental deletion
• A retention or lifecycle rule
• Genuine corruption or data loss

Do not lead with a speculative explanation such as “It is probably just a sync issue.” Even intended as reassurance, that statement may sound dismissive and can create a false expectation.

Say what you can verify instead:

I can see that the records are not appearing in the location you described. We have not yet determined whether this is a display issue, a delayed operation, or a problem with the stored data.

Ask for details that narrow the investigation

For a small SaaS team, a focused first reply can prevent several rounds of email. Ask only for information that helps identify the affected data and reconstruct the timeline.

Useful questions include:

• Which account, workspace, project, or organization is affected?
• What type of record is missing?
• Can the customer provide a few non-sensitive record names or IDs?
• Approximately how many records appear to be affected?
• When was the data last visible?
• When did the customer first notice the problem?
• Does the issue affect every team member or only one user?
• Does it occur on another browser or device?
• Were any imports, bulk edits, permission changes, integrations, or deletions performed recently?
• Is the data absent from exports and API responses, or only from the interface?

Avoid asking customers to send an entire database, unrestricted export, password, session cookie, or API key. If diagnostic files are necessary, explain exactly what is needed and provide an approved secure transfer method.

Preserve the customer’s original report

Record the initial message, timestamps, affected account, examples, and subsequent actions. This creates a stable timeline and reduces the chance that important details are lost across support, engineering, and security work.

If your product has relevant logs, preserve them before normal retention or rotation removes useful evidence. Avoid making broad production changes merely to test a theory. Investigation steps should not create additional risk for the affected data.

For a small team, a simple internal record can contain:

• Time the report arrived
• Reporter and affected account
• Reported symptoms
• Known scope
• Examples of missing records
• Investigation actions and results
• Customer updates sent
• Recovery or remediation actions
• Final cause, if established

If the missing information includes personal data, the event may require a formal privacy assessment. For example, the UK Information Commissioner’s Office explains that destruction, loss, alteration, or unavailability of personal data can constitute a personal data breach. Its guidance tells organizations to start a log, gather the facts, assess the risk, and report qualifying breaches within the applicable deadline—generally 72 hours after awareness under UK rules. Requirements vary by jurisdiction, so involve the person responsible for privacy or obtain appropriate legal advice rather than making a regulatory conclusion in a support email. See the ICO’s guide for the first 72 hours after a personal data breach.

Give a specific update time

A customer should not have to ask whether anyone is still investigating. Promise the next communication, not the resolution:

We’ll send you another update by 15:00 CET today, even if we have not completed the investigation.

This is more reliable than:

We should have this fixed soon.

A resolution estimate may not be possible during the first investigation stage. Atlassian’s incident communication guidance recommends acknowledging an issue early, summarizing the known impact, and providing continuing updates. It also emphasizes clear, consistent communication across the channels being used. See Atlassian’s incident communication tips.

Choose an update interval that reflects the severity of the problem and your team’s capacity. The important point is to set an expectation you can meet. If nothing material has changed, say so directly:

We are still investigating and do not yet have a confirmed cause. We have checked [brief factual summary], and the next step is [next action]. We’ll update you again by [time].

Escalate when the report may affect more customers

One report can reveal a wider incident. Check for similar tickets, monitoring alerts, failed jobs, unusual deletion activity, recent deployments, and changes involving storage, permissions, or retention.

Escalation is appropriate when:

• Several customers report the same symptom.
• Important or sensitive data may be affected.
• The scope is unknown and could be broad.
• Logs suggest corruption, deletion, or unauthorized access.
• A backup or recovery operation may be necessary.
• The issue prevents customers from performing essential work.

When multiple customers are affected, use one source of truth for public updates, such as a status page. Keep individual replies consistent with it while protecting account-specific information.

An initial incident message can be brief:

We are investigating reports that some customers cannot access [data type]. We are currently determining the scope and have not confirmed permanent data loss. We will provide another update by [time].

Atlassian’s incident template guidance similarly separates the acknowledgment of a problem from later identification and resolution updates.

Avoid promises you cannot support

Do not say:

• “Your data is safe” before confirming that it is.
• “Nothing was deleted” based only on the interface.
• “We will restore everything” before checking recovery options.
• “This affects only your account” before assessing the scope.
• “The problem was caused by our provider” before establishing the cause.
• “This cannot happen again” after applying a single fix.

Safer alternatives include:

• “We have not found evidence of deletion so far.”
• “We are checking both the interface and the underlying records.”
• “We have identified the affected records and are evaluating recovery options.”
• “The issue appears limited to [scope] based on our current investigation.”
• “We have applied a fix and are monitoring the affected operation.”

Words such as “currently,” “so far,” and “based on our investigation” make the limits of your knowledge clear. They should not be used to hide uncertainty; they should define it accurately.

Reply templates for each stage

When you need more information

Hi [Name],

>

Thanks for reporting this. I’m sorry the [records/files/items] are not appearing as expected.

>

We’re looking into it. To identify the affected data, could you send the workspace name, one or two non-sensitive record examples, when you last saw them, and whether other members of the workspace have the same problem?

>

Please do not send passwords, API keys, or confidential data that is unrelated to the issue.

>

We’ll update you by [time and time zone].

When the investigation is ongoing

Hi [Name],

>

We’re still investigating the missing [data type]. We have confirmed [known fact], but we have not yet determined [remaining uncertainty].

>

We’re now checking [next investigation step]. You do not need to take any action at this point.

>

We’ll send another update by [time and time zone].

When the data is hidden rather than lost

Hi [Name],

>

We found the cause. The data was still stored in your account, but [a filter/permission setting/synchronization delay] prevented it from appearing.

>

We have [action taken]. You can now verify the records at [location or instructions].

>

No restoration was required. If anything is still absent, please send us the relevant record IDs so we can compare them with our findings.

Only state that no data was lost if the investigation supports that conclusion.

When data has been recovered

Hi [Name],

>

We confirmed that [description of affected data] became unavailable because of [verified cause]. We restored [scope] from [recovery source or point, if appropriate] and completed checks at [time].

>

Please verify [specific items]. Changes made between [relevant times] may require review because [brief explanation].

>

We have also [factual corrective action]. We’ll continue monitoring [system or process] until [time or condition].

Be precise about the recovery point and any gap that may remain. “Restored” should not imply that every record is complete unless you have verified that.

When recovery is incomplete or impossible

Hi [Name],

>

We completed our investigation and confirmed that [specific data] was lost between [times or events]. We recovered [what was recovered], but we could not recover [what remains missing].

>

I’m sorry. We understand the impact this has on [customer’s stated task].

>

The available next steps are [practical options]. We have also [verified measures taken to address the cause].

>

We’ll keep this case open until [remaining action] is complete.

Do not bury the result in technical detail. State what happened, what was recovered, what remains missing, and what the customer can do next.

Close the case with evidence

Before describing the issue as resolved, verify the relevant layer of the system. A successful database query does not necessarily mean the customer can see the data, and a working screen does not necessarily prove that the underlying records are complete.

Depending on the incident, verification may include:

• Comparing expected and actual record counts
• Checking representative record IDs
• Confirming timestamps and relationships
• Testing the customer-facing view
• Checking exports or API results
• Confirming permissions
• Monitoring the affected job or service
• Asking the customer to verify specific items

A clear closure reply summarizes the cause, scope, action, and result:

We confirmed that the records were present but excluded by an incorrect date filter introduced during the latest interface update. We corrected the filter, checked the affected workspace, and verified the records in both the interface and export. The issue is now resolved.

If the cause remains unknown, say that. Restoring service and identifying a root cause are separate outcomes.

Review AI-drafted replies before sending

An AI support assistant can help a small team produce a structured first draft, but missing-data reports require human review. The sender should verify every statement about scope, security, deletion, recovery, and timing against the current investigation.

This is especially important when reusing past replies. Two customer messages may sound similar while involving different accounts, retention rules, or underlying causes. A human-in-the-loop process—such as SupportMe’s supplied workflow, in which drafts are reviewed before sending—helps keep responsibility for factual claims with the person handling the case.

A practical final check

Before sending any missing-data response, confirm that it:

• Acknowledges the customer’s impact
• Distinguishes observed symptoms from confirmed facts
• Avoids speculation and unsupported reassurance
• Requests only necessary, non-sensitive details
• Explains what will happen next
• Gives a specific time for the next update
• Matches any incident or status-page communication
• Has been checked for privacy or security implications
• Does not promise recovery before recovery is verified

Conclusion

The best response to a missing-data report is calm, specific, and honest about uncertainty. Acknowledge the problem, gather precise details, preserve the timeline, investigate the scope, and provide scheduled updates. Confirm deletion, recovery, or resolution only when the available evidence supports it.

References

• Atlassian: Incident communication tips
• Atlassian: Incident template library
• UK Information Commissioner’s Office: 72 hours—how to respond to a personal data breach