Repair customer support triage when the operating model still fits and defects are bounded. Replace it when recurring failures come from structural limits that a reasonable configuration cannot solve. Retire it when the workflow is no longer needed or its risk and cost exceed the value it provides. Make the decision with ticket and configuration evidence, not frustration after one incident.
Establish the decision baseline
Measure intake volume by channel and request type, backlog age, time to first meaningful response, transfer count, reopen rate, unresolved urgent items, duplicate contacts, customer-visible errors, manual handling, after-hours coverage, and agent effort. Segment rather than averaging away high-risk queues.
Atlassian's SLA documentation describes goals and start, pause, and stop conditions, and warns that edits can recalculate or discard ongoing cycles depending on the change. Preserve the metric definition and configuration that produced each baseline; a number without its rule history is weak comparison evidence.
Repair when the core model remains sound
Repair is usually appropriate when intake channels are supported, ownership is clear, data is trustworthy, failures are reproducible, and the affected rule set is limited. Examples include an outdated group mapping, missing field condition, rule-order problem, poorly defined priority, inactive owner, or notification gap.
Zendesk's business-rule analysis guidance shows that assignments, tags, fields, triggers, automations, macros, and views can be inspected as a dependency network. Repair is credible when the team can identify the bad dependency, change it in isolation, test representative requests, and roll back.
Set a repair budget in time and disruption. If repeated repairs exceed it or each correction exposes deeper coupling, reconsider replacement rather than normalizing continuous emergency work.
Replace when limitations are structural
Replacement is warranted when required channels or permissions cannot be represented, audit evidence is inadequate, integrations are chronically brittle, data cannot be exported usefully, peak volume overwhelms the workflow, or essential reporting depends on manual reconstruction. Repeated misrouting caused by an unmanageable rule web is a design limit, not merely a bad rule.
Before selecting a destination, inventory fields, forms, queues, customer identities, organizations, conversations, attachments, SLAs, consent, permissions, rules, automations, integrations, and retention requirements. Run a representative migration with fictional or authorized data. Verify preserved history, customer reply paths, restricted access, and rollback.
Zendesk's audit-log documentation illustrates the value of time, actor, item, activity, and exportable change history, while also showing that capability can depend on plan and permission. Compare evidence coverage explicitly instead of assuming the new tool records every important action.
Retire when the workflow has no defensible owner or value
Retirement may be correct after a product closes, a channel is eliminated, support is consolidated into another verified process, or volume no longer justifies a separate queue. It can also be necessary when the workflow creates unmanaged privacy, security, or customer-response risk and no owner can maintain it.
Retirement is not abandonment. Publish the replacement contact route where appropriate, stop new intake in a controlled sequence, preserve required records, resolve or transfer open cases, notify affected staff, revoke integrations, retain suppression and consent evidence, and monitor old channels for a defined period. Do not delete historical tickets merely to simplify the interface.
Compare options through a reversible pilot
Score repair, replacement, and retirement against customer continuity, accessibility, routing accuracy, auditability, privacy, security, data portability, training, integration effort, downtime, cost, owner capacity, and rollback. Mark unknowns rather than awarding optimistic points.
Pilot the leading option on a limited request type or internal channel. Define acceptance thresholds and stop conditions before the pilot. The decision is ready when an authorized owner can explain the baseline, show why the current failure is bounded or structural, account for open tickets and records, demonstrate the selected path, and recover if the cutover fails.
Sources
- Create and edit an SLA — Atlassian Support
- Analyzing your business rules — Zendesk Help
- Viewing the audit log for changes to your account — Zendesk Help