A notification is easy.
A handoff needs an owner.

An assistant offers to connect an interested lead to a specialist. The phone rings. Nobody answers. From the workflow’s perspective, a transfer happened. From the customer’s perspective, the company disappeared.

This is an illustrative scenario. It is the kind of failure I would put at the centre of an automation review.

The important question is not whether the system triggered an action. It is whether someone accepted responsibility for the next commitment.

A transfer is a proposed next step, not a completed outcome

I would distinguish transfer offered, transfer attempted and transfer accepted. Those are different events, even if a dashboard could group them under one reassuring status.

Before offering a live transfer, define availability and the relevant team. A scheduled appointment can be more useful than another unanswered call.

Do not promise a response window that the organisation cannot keep. The customer hears a business commitment, not a technical workflow instruction.

If nobody accepted the next step, the handoff is not finished.

Decide what happens when that step fails

A failed connection needs a defined alternative. That might be an appointment, an agreed callback window or a request assigned to a named owner.

The alternative must be recorded with the relevant context. Otherwise the customer has to explain the original request to another person and the recovery creates more work.

Not every exception needs a human conversation. An unavailable calendar may need a new booking route. A specialist question may need judgement. Those are different recovery tasks.

Give exceptions an owner and a useful task

An exception queue should answer four questions: what failed, how urgent is it, who owns it and what must happen next?

I would also record whether the owner acknowledged the task and whether the issue was resolved. A delivered notification answers neither question.

The agreed CRM mapping matters here too. If an outcome cannot be written back, it should remain an open exception rather than silently becoming completed work.

Measure recovery without turning people into the default

Separate specialist judgement, customer preference and avoidable workflow failure. The first two can justify human attention. Repeated manual rescue points to something that needs improving in the process.

Review time to acknowledge, successful recovery and the eventual appointment outcome. Include the effort spent resolving exceptions when assessing the cost of the result.

For Conversion24, I want automation to handle the agreed routine and make exceptions visible. Optional human involvement should have a clear purpose and owner, not compensate indefinitely for an unclear playbook.

Reliable automation makes its failures recoverable, not merely reportable.

Nick BlomFounder, Conversion24Published 1 November 2026

An opinion article by Nick Blom. The examples illustrate process choices and do not establish measured Conversion24 results.