When Should a Resolved Customer Request Be Reopened?

The client replies to a closed request: it still does not work. Someone opens a new task, someone else reopens the original and the team now has two owners investigating one problem. The opposite happens too: a genuinely new request disappears into an old case.

Reopen a resolved customer request when new evidence shows that its agreed resolution is incomplete or the same issue remains active. Create separately assessed work when the requested outcome has changed. If the relationship between the two is uncertain, keep a linked review record until an authorised owner decides.

A woman wearing a headset at a computer, with other headset users behind her.

Start with what was actually resolved

Find the original request, acceptance condition, delivered result and resolution message. A status saying closed is not the whole agreement. Check whether the original action was completed or whether the team simply stopped waiting for a reply.

Ask the client what is wrong now and what evidence they can provide through the appropriate channel. Do not make them repeat the full history if the business already holds it. Preserve the earlier result rather than rewriting it to fit the latest information.

A reopen-or-new-work decision card

  • Original outcome and evidence of its recorded resolution.

  • New observation, received date and current operational effect.

  • Relationship: same unresolved issue, recurrence, changed requirement or clarification.

  • Evidence needed to distinguish those possibilities.

  • Chosen route, decision owner and reason.

  • Case owner, next action and client update.

  • Reporting treatment, including retained original dates and linked references.

A software status rule may constrain what can be reopened. Check your actual platform before configuring it; this is an operating decision framework, not a claim that every help-desk system offers the same controls.

Three examples that should take different routes

In an illustrative reporting service, a corrected file still excludes an agreed section. The owner reopens the issue, preserving the original correction and identifying the failed check. If the client instead asks for a new analysis period, the team assesses that as new work linked to the earlier case.

A message asking where the accepted file is stored may only need clarification. It should not automatically become a service failure or a new production assignment. Record what was provided so another colleague can see why the case remained resolved.

Keep reporting honest when a case returns

Decide how reopened work affects resolution measures and the rework record. Do not erase the original resolution event to improve the figures, or count a reopened case as a new success without explanation.

If the same reason repeatedly causes reopening, record it in the process exception log and assign an improvement question. Closing the individual case again does not establish that the underlying cause is fixed.

If your team has no shared rule for a returning client issue, Hili Consulting can help clarify case states, evidence and ownership without adding another approval loop.

Previous
Previous

A Customer Complaint Intake Checklist for a Small Service Business

Next
Next

Can Your Project Meet a Fixed Deadline? Work Backwards Before You Promise