When is a support ticket resolved?
Distinguish work completion, customer confirmation, closure and reopening in a communication platform without assuming that a status button proves a service outcome.
Exploration · Principles and possible approaches inspired by a project context.
- Support workflows
- Ticketing
- Business state
Related context: Business communication and after-sales collaboration. This article proposes a workflow model for discussion; it does not assert existing project states, deadlines or role permissions.
A reply is not proof of resolution
An engineer provides a solution and support forwards it, but the customer still encounters the problem. Treating “replied” as “resolved” would close the service loop too early.
Separate the provider’s completed work, the customer’s confirmation and the organization’s closure criteria.
States should describe business facts
Candidate meanings include work in progress, awaiting confirmation, closed under agreed conditions and reopened for further work. These are not four mandatory labels. Use only distinctions that clarify responsibility, the next action and exit conditions.
If customer confirmation is required, define who confirms and what they accept. If timeout closure is allowed, define reminders and reopening behavior. Silence should not automatically mean satisfaction.
Record why closure occurred
Provider closure, customer confirmation and timeout closure have different meanings. Preserve the reason so later review does not interpret every closed ticket as the same outcome.
Keep conversation and responsibility connected
Chat preserves context; a ticket tracks responsibility and progress. A reply can document progress without every message automatically advancing ticket state.
Split issues when they can be handled independently or have different completion conditions, not simply because several messages exist.
Reopening and new work need a shared rule
An ineffective solution to the original problem differs from a new request. Compare the objective, scope and acceptance criteria when deciding whether to reopen or create another ticket.
Avoid forcing unresolved problems into new tickets to preserve closure metrics. Equally, avoid extending an old ticket indefinitely with unrelated requirements.
Review disputed cases
Consider disagreement about completion, prolonged silence, a failed solution after closure and several owners inside one ticket. Each case should identify the responsible party, next action and evidence to retain.
Status controls represent the workflow agreement; they do not create it.