Want help applying this guide?Ask the DripTell team
A customer replies two days after a support case was closed. The replacement still has not arrived. Another customer replies to an old thread, but now asks about a different product. Those messages may look identical in an inbox. They should not produce the same record.
Reopen the original case when the promised outcome is still missing, the new evidence belongs to the same problem, or the earlier fix did not work. Start a new case when the customer now needs a materially different outcome, a separate team or permission boundary, or a fresh service commitment. If the matters are related, link the records. Do not merge them just because the customer reused an old message thread.
Decide what stayed unresolved
The subject line is weak evidence. People reply to the most convenient email or message they can find. Automation may also correlate a reply with an old record even when the words change. Microsoft documents that an incoming email related to a resolved case can be configured to reopen that case, and that the reopen rule must be evaluated before the create-new rule in its resolved case guidance. That is a routing mechanism, not a complete business decision.
Start with the outcome the business promised. Was it a refund, a working login, a corrected invoice, or a delivered replacement? Then compare the affected account or item, the symptom, the evidence, and the time since closure. A different greeting or attachment does not make the work new. A different desired outcome often does.
Write the decision in ordinary language. For example: reopen when the same order is still missing after the case was closed as delivered. Create a new linked case when that customer later asks to change the billing address for future orders.
Reopen when the same promise is still open
Reopening keeps one evidence chain. The earlier checks, messages, owner, resolution note, and customer commitment remain together. This is usually the clearest choice when:
- 1Find the originalOpen the earlier case, resolution note, customer, object, and promised outcome.
- 2Compare the needAsk whether the same outcome is still missing or a different job has appeared.
- 3Check continuityLook for the same evidence, owner, affected item, and recent timeline.
- 4Choose the recordReopen the same work or create a separate case with its own owner and clock.
- 5Keep the linkConnect related records and preserve the reason for the decision.
- the customer says the offered solution did not work;
- a promised action was never completed;
- the same symptom returned shortly after closure;
- new evidence changes the conclusion about the same incident; or
- the case was closed while waiting for information that has now arrived.
Microsoft also documents a configurable waiting period after a related case is resolved. During that interval, a message about the same issue can stay associated with the existing resolved case instead of creating another one, as described in its automatic case rule guidance. Your operation may choose a different window. The useful principle is continuity, not copying a product setting.
Do not reopen automatically on every reply. A thank-you, survey response, or unrelated request should not pull completed work back into the active queue.
Start a new case when the work changed
A new case is better when it needs an independent owner, priority, permission set, service target, or resolution. Common examples include a second product failing, a new order, a different account, a separate security concern, or a request that belongs to another team.
The test is not whether the customer used the same channel. Ask whether one owner can close both needs with one defensible resolution. If not, separate them. This prevents a long case from hiding several jobs and keeps a sensitive matter from inheriting access that belonged to the earlier one.
When the relationship matters, create a linked case rather than a disconnected case. The new record gets its own clock and accountable owner, while the link tells the next person what happened before.
Preserve the link either way
Before changing status, record a short reason. Include the previous outcome, what the customer says is still wrong, the evidence received, the decision, and the next owner. Preserve the original close time. Add a reopen time instead of replacing history.
| Situation | Record choice | Owner action | Reporting treatment |
|---|---|---|---|
| Same promised outcome is missing | Reopen original | Restore the accountable owner or named backup | Keep original history and add a reopened interval |
| Same issue has new evidence | Reopen original | Review the new evidence against earlier checks | Attribute the return to the original case |
| Different outcome or affected item | Create new linked case | Assign the team responsible for the new work | Start a separate clock and retain the relationship |
| Unclear or mixed message | Human triage before routing | Split only after the needs are identified | Record the decision reason and audit exceptions |
A short human review is safer for ambiguous messages. Automation can match customer, thread, case state, product, and time window, but it should leave uncertain cases for a person instead of silently choosing the cleaner metric.
Keep ownership and reporting honest
Reopening should return work to a real owner or a named backup, not merely change a status. Creating a new case should not erase the earlier failure. Review both the reopen decision and the relationship between records.
Teams can bring the conversation and case together in a support workspace, preserve the full exchange in a shared inbox, and connect the person with the right customer record. A controlled automation flow can handle clear rules while exceptions remain visible. Use inbox reports to review reopened intervals and linked new work, and apply appropriate security controls when a new issue changes who may see the evidence.
Track at least the reason for reopening, time closed before return, time to final resolution, linked-new-case rate, and a small audited sample of decisions. Do not punish a team for honest reopens. A falling reopen count can mean better resolutions, or it can mean people are creating fresh cases to protect the number.
The clean rule is simple: preserve one case while the original promise remains open. Start a linked new case when the work has genuinely changed.
Frequently Asked Questions
When should a customer support case be reopened
Reopen it when the same promised outcome is still missing, the fix failed, or new evidence belongs to the same incident. Restore clear ownership and preserve the original timeline.
When should support create a new case
Create a new case when the customer needs a different outcome, another item or account is affected, or the work needs a separate owner, permission boundary, priority, or service clock.
Should every reply to a closed case reopen it
No. Thank-you messages, survey responses, and unrelated requests should not reactivate completed work. Route ambiguous replies to a brief human review.
How should related support cases be reported
Give the new case its own clock, keep the original case history unchanged, link both records, and record why the work was separated.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy