Follow Up an Unresolved Customer Conversation: Template

An unresolved conversation can mean the team owes an answer, the customer owes information, a third party is pending, or the record is simply stale. Sending the same “any update?” message to all four states creates noise and can hide real service risk.

Copy and fill this conversation record

Conversation/case ID and channel:
Customer issue in verified words:
Current state and waiting party:
Last meaningful event/date/timezone:
Owner and backup:
Approved source/attachment versions:
Risk, urgency and escalation rule:

Evaluation trigger:
Message purpose and approved facts:
Requested next action and due expectation:
Reply and delivery handling:
Exit/closure reason:
Reopen rule:
Completion evidence:
QA owner and cadence:

Estimated completion time: 25–35 minutes once service states, owners and escalation policy are defined. Copy the record into the support workflow or operating document, replace every field, then save or export the approved version with its source versions and policy date.

Field guidance

• Restate the issue from an approved conversation or case source; do not infer a resolution from silence.
• Name who is waiting on whom and what exact evidence is missing.
• Separate a customer-information reminder from an internal overdue escalation.
• Set higher-risk, vulnerable, legal, safety, security and billing cases on a human-owned route.
• Close only with a visible reason and preserve a simple reopen path when appropriate.
• Store the last meaningful event with exact date/timezone; name one owner and backup.
• Version notes, transcripts, attachments and policies that support the action.
• Trigger only while the reconciled waiting state remains unchanged.
• Allowlist message facts and preserve uncertainty.
• Ask for one specific action and state a due expectation without inventing a service promise.
• Define reply/delivery handling, completion evidence and QA for incorrect closure and missed escalation.

Intercom documents a vendor-specific workflow that detects a conversation waiting on the customer, sends a follow-up, responds to a reply, and can close after no response. Use the state pattern, not its product assumptions or timing as a universal policy. Review the documentation.

Fictional filled example: missing delivery photo

Conversation/case ID and channel: S-615; permitted support email
Customer issue in verified words: Customer reports one parcel missing; carrier needs a photo of the received package label
Current state and waiting party: Waiting for customer information; team answer is otherwise complete
Last meaningful event/date/timezone: Agent requested label photo on 14 August 2026, 15:10 ICT (UTC+7)
Owner and backup: Trang; backup: delivery-support lead
Approved source/attachment versions: Case transcript v4, carrier request CR-88, order snapshot O-615
Risk, urgency and escalation rule: Escalate immediately if customer reports unsafe delivery, payment dispute or both parcels missing

Evaluation trigger: One owner-approved interval after the request, only while state remains waiting-for-customer
Message purpose and approved facts: Request the minimum label evidence using case ID and current carrier request. Message: “To continue case S-615, please reply with a photo of the label on the parcel you received. Do not include payment details. If you cannot provide it, reply HELP and Trang will review another route.”
Requested next action and due expectation: Photo or HELP reply before owner review at 17:00 ICT on 16 August 2026; no promise of carrier outcome
Reply and delivery handling: Attach replies to S-615, cancel pending follow-up and notify Trang; ambiguous content stays human-owned. On delivery failure, alert the owner and do not switch channel without permission
Exit/closure reason: Exit on reply, owner action, state change, duplicate merge, invalid contact, escalation or closure. After the approved no-response step, close as “awaiting customer information,” not “resolved”
Reopen rule: Customer reply restores the case to Trang's queue with history intact
Completion evidence: State, source, message, delivery, owner action and closure reason stored
QA owner and cadence: Support lead reviews incorrect closure, missed escalation and reopen handling weekly

Every ID, person, date and case in this example is fictional. The interval is intentionally left to the service owner.

Quality checklist

• The current state and waiting party agree with the latest source.
• The message asks for one specific safe action.
• Internal overdue work is escalated, not sent as a customer reminder.
• New replies cancel scheduled actions and retain the original thread.
• “Closed awaiting information” is not reported as resolved.
• High-risk cases remain under accountable human ownership.

Common mistakes

Mistake	Safer correction
Treating all stale cases as waiting on the customer	Reconcile the latest event and accountable party first.
Asking for broad or sensitive data	Request the minimum field and state what not to send.
Closing silence as success	Store a distinct no-response closure reason.
Starting a new thread on reply	Reopen the same case with evidence and owner history.

Frequently asked questions

How many reminders should an unresolved case receive?

There is no universal count. Choose from issue risk, customer expectation, channel policy and service capacity; make the close state explicit.

Can AI decide that the issue is resolved?

It may suggest a state from permitted evidence, but consequential closure should follow the approved policy and expose uncertainty to the owner.

What if the team owes the next action?

Do not ask the customer for an update. Create an internal overdue alert, preserve the promise already made, and route escalation to the accountable owner.

Should a closed case reopen automatically?

A new customer reply can be a clear reopen event when policy allows. Restore context, cancel obsolete actions and avoid making the customer repeat the issue.

What to do next

Copy the record into a document and fill the current issue, waiting party, and owner first. After a verified resolution—not merely a no-response closure—the case may enter the customer-feedback request workflow.

Evidence and limitations

This template does not define service-level commitments, legal handling, channel permission, a product integration, resolution outcomes, or Easy AI capability.