When Is a Support Request Finished? Specify Resolution, Closure and Follow-Up

A support portal needs a clear answer to “what happens if the customer replies after we say this is solved?” Decide that before choosing status labels. A resolution can end the current piece of work while leaving room for the customer to report that it did not help. A final closure can preserve that history and route later contact into a linked follow-up. These are different product decisions.

This guide concerns the lifecycle of a customer support case, not the audience of internal notes, staff assignment or a contractual service-level guarantee. The recommended workflow must be agreed for your business; it is not a claim that every helpdesk implements the same rules.

Define who needs to act next

Begin with the work rather than a colourful status menu. Is the team investigating? Is it waiting for information from the customer? Is an outside supplier holding up progress? Has the team proposed a solution? Who watches the case while it waits?

Avoid calling every inactive request “pending”. A case awaiting a customer answer needs a different next action from one awaiting a replacement part. Record what is missing and who should follow up. Waiting should not mean ownership disappears, and a customer-facing explanation should not expose private supplier or staff commentary.

As a concrete example, the Zendesk Tickets API reference lists new, open, pending, hold, solved and closed as allowed ticket status values. It also explains that when custom ticket statuses are enabled, the status property contains a status category, with a separate identifier for the custom status. This demonstrates why an integration cannot safely infer the whole workflow from one visible label. It does not prescribe the right labels or transition rules for your portal.

Make resolution something a person can understand

Before staff mark a request resolved, decide what they must record. A short explanation of the answer or action is usually more helpful than a blank status change. If the outcome was a workaround rather than a permanent fix, say so. Do not make a customer confirmation appear when no customer has confirmed anything.

Choose whether customers can mark their own request resolved and whether the team can do so without explicit agreement. If a reply window is part of your design, explain it in the resolution message. State how to continue the conversation if the proposed solution does not work. Do not invent a universal number of days: choose a period appropriate to the service and check any contractual or legal obligations separately.

A satisfaction survey is another action, not evidence of resolution. Failing to answer a survey should not be recorded as agreeing that a problem is fixed.

Decide what a later reply does

There are several sensible behaviours, but they should not be accidental.

During a defined review period, a customer reply might reopen the same case and put it back in the team's active queue. Alternatively, the system might flag it for staff to assess. After final closure, a new linked case can preserve the earlier history while recording the new work separately.

Zendesk's reference includes a field for creating a follow-up ticket from the identifier of a closed ticket. That supports the existence of a linked-follow-up mechanism in that API. It does not establish your desired reopening window, nor prove that a custom portal automatically routes every late email correctly.

Decide how unrelated messages are handled. If a customer replies to an old repair conversation to ask about a new purchase, staff may need to split or link a new case rather than repeatedly reopening the repair. Preserve enough context to explain the relationship without copying private material into a wider audience.

Do not let automation close unseen work

If you plan reminders or automatic closure, define the conditions carefully. A case waiting on a supplier should not close merely because the customer has not replied. An incoming message just before a scheduled closure should be considered when that closure actually runs, not only when it was first scheduled.

Use a hypothetical test: staff propose a solution, an automatic closure is queued, and the customer then reports the same problem persists. The application should apply your agreed rule to the current case state. It must not send a cheerful closure message based only on an old snapshot.

Separate a customer's actual reply from an automated delivery failure or unrelated notification. Agree how those inputs are handled and keep uncertain cases visible for staff. This is a requirement to implement and test, not a promise that a particular classifier can interpret every message correctly.

Keep reporting faithful to the work

Choose what reopening means for your reports. Do you measure the first proposed resolution, the latest resolution or the final closure? If a linked follow-up is created, should staff be able to see that the same issue continued? Name each measure accurately rather than calling all of them “time to solve”.

Preserve dated transitions and reasons needed to explain the case. You do not need a second copy of every private message in a reporting export. Decide access and retention separately, and do not present an operational report as proof of a contractual target you have not defined.

Acceptance cases worth paying attention to

For a customer-portal project, include the following in your acceptance tests:

• A case waiting on the customer is distinguishable from one waiting on a supplier.
• A resolution message explains the action and how the customer can respond.
• A reply within the agreed window reaches the correct active queue.
• Contact after final closure follows the agreed linked-case rule.
• An unrelated request can be separated without losing the original relationship.
• A scheduled closure rechecks the current case after an intervening reply.
• Reports distinguish first resolution, reopened work and final closure as specified.

The useful outcome is not a larger collection of statuses. It is that customers and staff can tell whether work is finished, who must act and where the next message will go.

Source and scope

The Zendesk API reference supports the listed status values, custom-status category distinction and closed-ticket follow-up field. The resolution record, reply window, automation conditions and reporting choices above are proposed commissioning requirements. They are not verified default Zendesk behaviour, a legal closure rule or a response-time promise.