On-hold workflow

This workflow is a central part of the support process in Zendesk. The purpose is to ensure that no cases risk being overlooked when they are temporarily put on hold. By combining the immediate reactions of triggers with the time-controlled actions of automations, an intelligent and self-running system is established. The system ensures that a case is either reopened when an update is expected, or automatically returned to the queue as a safety measure if a due date has been overlooked.

The purpose of an On-Hold Workflow

Putting a case on the status On-hold is a necessary part of support work. You may be awaiting a response from a customer, a third-party supplier or an internal clarification. Without a structured workflow, there is a risk that cases disappear into the mass. The on-hold workflow is designed to reduce this risk and create predictability. The workflow ensures that:

• Customers do not experience unnecessary waiting times: Cases are followed up proactively.
• No cases fall through the cracks: A 7-day safety net catches cases without a due date.
• Agents save time: Manual follow-ups are minimised, and the focus can be kept on active cases.
• High service quality is maintained: The systematic handling of waiting time strengthens customer trust.

The workflow's architecture: Triggers and Automations

The on-hold workflow is built around a synergy between four core components, which together ensure an overview:

• 2 Triggers: Reactive components that act immediately when an agent makes a specific change to a case.
• 2 Automations: Proactive components that run at regular intervals and perform time-based actions based on specific conditions.

Together, the components create a dynamic system that adapts to the agent's actions and ensures that the case always has a planned route back to the active queue.

Components in detail

Below, each component and its role in the workflow is reviewed.

The reactive components: Triggers

Triggers are activated the moment a condition is met, and immediately perform a series of actions.

Trigger 1: The safety net - identifying cases without a due date

This trigger acts as the primary safety net. It is activated when an agent puts a case on the status On-hold without specifying a due date.

• Condition: Status changes to On-hold AND Due date is Not set.
• Action: Add the tag due_date_is_not_set.

Purpose: The tag systematically marks the case as a case without a specific follow-up date. The tag acts as a signal to the 7-day automation, which can recognise it and act on it. This reduces the risk of a case being overlooked because a due date has not been specified.

Trigger 2: The dynamic adjustment - removing the safety net

This trigger ensures that the system remains adaptive. It is activated if an agent subsequently adds a due date to a case that is already on hold.

• Condition: Status is On-hold AND Due date is set.
• Action: Remove the tag due_date_is_not_set.

Purpose: Once a due date has been specified, the 7-day fallback mechanism is no longer needed for that case. By removing the tag, it is avoided that the 7-day automation reopens the case at the wrong time. The specific due date thereby takes top priority.

The proactive components: Automations

Automations run at regular intervals (typically every hour) and scan cases to identify whether the conditions are met.

Automation 1: Precise reopening - follow-up on specific due dates

This automation handles cases where there is a specific expectation of a follow-up time. It is designed to reopen the case at 08:00 on the specified due date, so that the case is ready in the queue at the start of the working day.

• Conditions:
  • Status is On-hold
  • Due date is less than 8 hours ago (> -8 hours)
• Actions:
  • Status to Open
  • (Optional but recommended): Add an internal note such as "Reopened automatically due to due date."

Important technical explanation: Zendesk treats a due date without a specific time as 12:00 on that day. The condition > -8 hours means that the automation runs when it is within the last 8 hours before the due date's 12:00. This ensures that the automation is activated once in the morning (from approximately 04:00 onwards) on the due date itself, so that the case is ready in the queue when the working day starts at 08:00.
Note: This automation must be configured to run at least once an hour to function optimally.

Automation 2: The ultimate failsafe - reopening after 7 days

This is the last line of defence for cases that are put on hold without a clear timeframe. It ensures that no case can lie dormant for more than a week.

• Conditions:
  • Status is On-hold
  • Contains at least one of the following tags: due_date_is_not_set
  • Case is updated less than 168 hours ago (> 168)
• Actions:
  • Status to Open
  • (Optional but recommended): Add an internal note such as "Reopened automatically after 7 days on hold."

Purpose: If a case has been on hold for 7 days (168 hours) without a due date being set, it is assumed that the case may have been overlooked, or that the waiting time has become unnecessarily long. The automation brings the case back to the active queue so that an agent can assess the status, contact the customer or escalate the case.

Application in practice: Scenarios and recommendations

Correct application of the workflow requires an understanding of when the different mechanisms should be used.

When should a specific due date be used?

A due date should be used when there is an estimate of when an update can be expected. This creates precision and predictability.

• Scenario 1: Waiting for information from the customer
  A customer has reported an error, but log files are missing in order to diagnose the problem. The agent puts the case on hold with an internal note: "Waiting for log files from the customer. Expected to be received tomorrow morning." and sets the due date to tomorrow at 09:00.
• Scenario 2: Waiting for a 3rd party supplier
  A case has been escalated to a technical partner. The partner has confirmed that the case is being investigated and has promised a response within 3 business days. The agent puts the case on hold with an internal note: "Escalated to [Partner]. Waiting for feedback." and sets the due date to 3 business days ahead.
• Scenario 3: Scheduled task or release
  A system update is awaited, which is implemented next Tuesday night to resolve a known error. The agent puts the case on hold with an internal note: "Waiting for the release of version X.X, which resolves the problem." and sets the due date to Wednesday morning.

When should a due date be omitted?

The 7-day rule is used as a fallback when the time horizon is uncertain, and an estimate would be misleading.

• Scenario 1: Unresolved and rare problem
  A customer reports an error that cannot be reproduced, and it is the first report of its kind. You are waiting to see whether more customers are affected before the case can be escalated to development. A due date is judged to be meaningless here, and the 7-day automation handles the case.
• Scenario 2: Waiting for internal clarification about a future feature
  A customer asks about a feature that is not on the roadmap. The product team has been asked, but there is not yet an answer. The case is put on hold without a due date, and the automation ensures follow-up after a week.

Best practices for effective case handling

• Always write a clear internal note: When a case is put on hold, a short and precise internal note should be added about why the case is on hold, and what is being awaited. This is important both for the responsible agent and for other agents who may later take over the case.
• Prefer specific dates: Although the 7-day rule acts as a safety net, a specific due date is typically better, as it provides more predictability and a better customer experience.
• Update the due date proactively: If the waiting time becomes longer than expected, the due date should be updated so that the case is not reopened too early. It is better to adjust the date once than to reopen and put the case on hold again.
• Review the On-Hold queue regularly: Although the workflow is automated, a weekly review of the On-Hold queue by a team leader or senior agent can identify unnecessarily long waiting times or cases where a more appropriate due date could have been set.

Troubleshooting and frequently asked questions (FAQ)

Question: Why was the case not reopened at 08:00 on the due date?
Answer: First check whether the automation is running as expected (typically at least once an hour). Then verify that the case's status was still On-hold, and that the due date was specified correctly. The automation is activated when the condition > -8 hours is met, which happens during the morning on the due date. If the automation runs at 04:00, the case will be reopened and ready in the queue at 08:00.

Question: What happens if a due date is set on a case that has already been on hold for 5 days?
Answer: The workflow is designed to handle this. When the due date is set, Trigger 2 removes the tag due_date_is_not_set. This cancels the 7-day automation for that case. The case is instead reopened on the new, specific due date.

Question: The case was reopened even though it had just been put on hold. Why?
Answer: This can happen if the case is put on hold with a due date that has already passed, or that is very close to the current time (within 8 hours before 12:00). In that case, the automation condition > -8 hours immediately meets the criteria, and the case is reopened. The due date should always be set to a time in the future.

Question: What happens if a customer replies to a case that is on hold?
Answer: When a customer replies, the case's status is automatically changed to Open via Zendesk's standard function, and the case appears in the active queue. In that situation, the on-hold workflow becomes redundant, as the customer's comment is the primary reason for reopening. This ensures that customer enquiries are handled quickly.

By implementing and following this workflow, a high and consistent service quality is supported, the risk of forgotten cases is reduced, and an efficient and structured support function is maintained. The workflow acts as a system that supports the ongoing follow-up and prioritisation of cases.