Human handoff is part of the product.

A lower transfer rate can hide a worse service

Imagine two agents. One handles a reschedule correctly and the patient never needs reception. The other makes it difficult to reach reception, so the patient hangs up. Both can reduce the transfer rate. Only one has improved the service.

That is why containment is an incomplete target. Measure what happened to the request: resolved by the agent, resolved after human involvement, still waiting, abandoned or closed at the patient’s request. The cost and quality of those outcomes are different.

Let the agent offer useful help while making the human option clear. If a patient asks for a person, do not put them through repeated qualification questions to prove they need one. Do not invent a queue time to persuade them to stay. Being transparent about availability is compatible with offering immediate assistance; making the exit harder is not.

Not every handoff is a failure to automate

A patient may want a person because they prefer one. The agent may lack access to an administrative action. The conversation may require a clinician. Those are different reasons for human involvement, and treating them as one category makes the service harder to improve.

Patient preference calls for a respectful transfer. A missing administrative capability may call for better tools or permissions. Clinical judgement stays with the treating team. You should not try to reduce all three categories by making the agent more persuasive.

The same distinction applies to urgency. A request that needs prompt clinical attention should follow the clinic’s approved escalation protocol. It must not sit in a general commercial follow-up queue because that is the only inbox the system knows how to create.

Transfer the work, not just the transcript

A transcript is evidence, but it is not a work assignment. The receiving person needs to know why they are needed, what has already happened, what is still unresolved and what the patient expects next. Give them access to the underlying conversation so they can verify the summary.

Include the relevant record, the requested action, failed attempts or tool errors, any promise already made, the callback preference and the assigned queue or person. Separate what the patient said from what the agent inferred. Share only the information the recipient is authorised to access.

Then manage the transition. If automated follow-up would conflict with the human response, pause it. Do not resume simply because a timer expires. Resume only after an appropriate resolution or explicit release, with the updated state.

“Transferred” is not the same as “taken care of”

A transfer can fail. The care team may be closed, a call can disconnect or the receiving queue may not accept the request. If the system records the handoff as successful merely because it tried, the patient is left waiting while the dashboard looks healthy.

Define the fallback before launch. Explain that a person is not available, agree the next contact where possible and place the unresolved request with an accountable team. The request needs to remain visible until accepted, resolved or explicitly closed. Do not make a callback promise the staffing model cannot support.

Reconcile the task with the existing patient record. A human request should not create a duplicate lead, restart a sales sequence or erase a cancellation. These are ordinary operational details, but they decide whether the handoff actually feels joined up.

The human team needs capacity, not just a button

The clinic’s care team can receive the handoff. Wilco can also provide a human care team to assist with patient follow-up. Either way, agree which requests that team can resolve, which actions need approval, when it is staffed and where clinical questions go.

Deploying an agent does not remove the need to plan this capacity. Look at the volume and type of cases likely to need people, the time they take and the promised response. A queue without staffing is an unresolved dependency, not a complete human-in-the-loop service.

Put human handling into the economics. If the model resolves routine requests but the exceptions require specialist attention, both parts belong in the cost and quality comparison. The right question is whether the combined service is better, not whether every case can avoid a person.

Turn the resolution into a better system

After the care team resolves a case, capture the reason for the handoff and what made resolution possible. Was the knowledge missing? Was the appointment rule ambiguous? Did a tool fail? Did the patient simply prefer a person? Those answers point to different improvements.

A missing policy should become approved knowledge. A tool failure needs an engineering fix. A confusing response may need a new conversation pattern. A person’s preference may require no change beyond honouring it. Do not force every resolved case into a training-data pipeline.

Where a correction should change behaviour, turn it into a reviewed test case. Remove or minimise personal data, confirm the expected action with the appropriate owner and test the change against existing scenarios before rollout. Human feedback is evidence for an improvement, not permission for a live agent to rewrite its own rules.

This is the loop worth building: a better service for the patient now, and a specific, tested improvement for the next patient with the same problem.