Summarize Content With:
Famulor updated warm transfers on August 29, 2026, so an assistant can return to the caller with a classified outcome when a handoff does not complete. If the supervisor answered and spoke, optional Consultation Notes can also provide the relevant message. This changes the part of a transfer that happens after the target is called, without changing the basic hold, brief, and connect sequence. For the broader distinction between transfer types, see the guide to transferring an AI call to a human.
Key Takeaways
- An incomplete warm transfer always returns a classified outcome:
busy,declined,no_answer, ortemporarily_unavailable.- Consultation Notes are optional for Flow Builder and the Warm transfer tool. Loop Recall keeps them enabled.
- The supervisor-side transcript remains in the Call Record even when Notes sharing is off.
- If nobody answers, no Consultation Notes exist. The assistant receives only the outcome.
- A
failedevent records transfer state. The classified reason belongs to the provider-neutral failure object.
What changed on August 29
The update addresses the moment when a warm handoff stops before both parties are connected. The assistant no longer has to treat every incomplete attempt as an undifferentiated failure. It receives one of four classified outcomes and is explicitly instructed never to invent a statement the supervisor did not make (August 29 changelog).
| Situation | What the assistant receives | Consultation Notes |
|---|---|---|
| Target is busy | busy |
None because nobody spoke |
| Target declines | declined |
Available only if the supervisor spoke and sharing is enabled |
| No answer before timeout | no_answer |
None because nobody spoke |
| Target is temporarily unreachable | temporarily_unavailable |
None because nobody spoke |
This behavior applies to the Flow Builder warm-transfer node, the Warm transfer tool, and Famulor Loop Recall. In Flow Builder and the tool, the setting Share supervisor conversation with the AI (consultation notes) determines whether the assistant sees the supervisor-side conversation. Loop Recall has no separate transfer form, so Notes are always enabled there. The earlier warm-transfer product guide remains useful for the basic handoff concept; this update focuses specifically on the return path.
How the complete warm-transfer sequence works
A warm transfer still follows four core steps. The caller is placed on hold, the assistant calls the destination, the destination receives an AI-generated summary, and both parties are connected only after acceptance. The Flow Builder node reference documents the target, outbound number, caller messages, summary instructions, timeout, hold music, and fallback fields.
If the connection is not completed, control can return to the original conversation. The assistant then uses the classified outcome and, when allowed and available, the Consultation Notes. A supervisor might say that they cannot take the call and ask the caller to try again later. The assistant may relay that message. It must not add a reason, promise, time, or instruction that the supervisor never stated.
Warm transfer and assistant-to-assistant handoff are different actions. The latter changes which AI continues the call, as explained in the live handoff to another assistant update. Consultation Notes in this update concern the supervisor-side conversation during a human warm-transfer attempt.
Practical configuration checklist
Configure the return path as deliberately as the successful connection:
- Choose the transfer entry point. Use the dedicated warm-transfer node for a deterministic visual flow, or assign the Warm transfer tool when the assistant should decide from the conversation. The Flow Builder product overview provides context for node-based routing.
- Decide whether to share Consultation Notes. Enable the option when the assistant should relay a supervisor's relevant message after an incomplete handoff. Leave it off when the return conversation should use only the classified outcome. The transcript is still stored in the Call Record.
- Set the ringing timeout. The allowed range is 5 to 120 seconds, with 30 seconds as the default. Test the value against the destination team's real pickup pattern.
- Select a fallback. The configured choices are to continue the conversation, end the call, or perform a blind transfer when the target does not answer or declines. A return message requires the conversation to remain active.
- Monitor events and failure details. Warm transfers record
started,completed, andfailedevents. When a transfer fails while the original call remains active, the event log includeswarm_transfer_failed; its provider-neutral failure object carries the classified code (inbound and outbound call results).
Do not use the failed event itself as the caller-facing reason. Read the failure code, apply the configured fallback, and keep any spoken supervisor message separate from carrier classification.
Five tests before rollout
Run these cases on every destination and fallback combination you plan to use:
| Test | Setup | Expected result |
|---|---|---|
| 1. Accepted handoff | Supervisor answers and accepts | Both parties connect; event sequence reaches completed |
| 2. Declined with Notes on | Supervisor speaks, asks for a later callback, then declines | Assistant returns, receives declined, and relays only the relevant stated message |
| 3. Declined with Notes off | Supervisor speaks, sharing is disabled, then declines | Assistant receives declined but no Notes; supervisor transcript remains in the Call Record |
| 4. Busy destination | Destination returns busy | Assistant receives busy, no Notes are created, and the configured fallback runs |
| 5. No answer and unavailable | Run once through timeout and once with a temporarily unreachable target | Codes are no_answer and temporarily_unavailable; neither run produces Notes |
Also verify hold audio, the connected message, timeout boundaries, and that a continue fallback returns to a coherent point in the original flow. The assistant should never tell the caller that the supervisor rejected the request, promised a callback, or gave a reason unless that statement is present in shared Notes.
Why the separation matters
The update separates three records that serve different purposes. Transfer events show lifecycle state. The failure object normalizes provider outcomes. Consultation Notes carry only the supervisor-side conversational context that the assistant is allowed to use. Keeping these layers separate makes fallback behavior easier to test and prevents a telephony result from being presented as a human statement.
It also preserves reviewability. Turning Notes sharing off does not remove the supervisor transcript from the Call Record. Teams can therefore inspect what happened after the call without automatically exposing that conversation to the assistant during the live return path.
Frequently asked questions
Does the assistant always see the supervisor transcript?
No. In Flow Builder and the Warm transfer tool, Consultation Notes control whether the assistant receives that conversation. The transcript is still saved in the Call Record. Loop Recall keeps Notes enabled.
What happens when nobody answers?
The assistant receives the classified outcome, such as busy, no_answer, or temporarily_unavailable. There are no Consultation Notes because no supervisor-side conversation occurred.
Is failed the reason the assistant should tell the caller?
No. failed is a transfer event status. The provider-neutral failure object contains the classified reason. The assistant should describe that outcome accurately and relay a supervisor message only when shared Notes support it.
Next step
Review every active warm-transfer configuration, decide where Consultation Notes are appropriate, and run the five cases above before relying on the return path. To evaluate the behavior with your own call flow and destinations, book a personal demo.
About the author
Sarah Müller writes product and implementation updates for Famulor. For questions about this update, contact Support. Information about data processing is available in the privacy policy.
Writer at Famulor
