Transfer calls to a person or department

The Call Transfer skill lets your AI agent hand an active call over to a person: a colleague, a department, or an external partner.

You can set up one destination for every transfer, or several and let the agent pick the right one based on what the caller has said.

When to use it

Add Call Transfer when a call should sometimes end up with a human:

• The caller asks to speak to a person.
• The caller needs a specific department: sales, support, billing, shipping.
• The conversation reaches a point where a person has to take over: finalising a purchase, authorizing something, handling a complaint.
• The caller has a problem the agent is not meant to solve.

The two decisions behind every transfer

This is the part that determines whether transfers work well, so it is worth two minutes.

A transfer involves two separate decisions, and they are made by two different pieces of your configuration.

The agent first follows your Main Objective to decide that a transfer is the right next step. Only then does it look at your list of numbers, read the Description you wrote for each, and pick the one that matches.

This is also how you troubleshoot. When transfers misbehave, the symptom tells you exactly which of the two to fix:

What happens automatically

A good part of the transfer conversation is built into the platform and runs the same way on every agent. You do not need to write any of this, and writing it anyway causes problems.

• The agent always asks permission first, using the destination's name: "I can transfer you to ___. Would you like me to do that?" It then waits for the caller to answer.
• It always asks, even if the caller says "just put me through to a human right now". There is no way to skip the confirmation.
• It reads the answer generously. Right after the permission question, any positive or acknowledging reply, including a simple "thanks", is treated as a yes, not as the caller winding the call up.
• It connects straight away and silently. Once the caller says yes, the agent puts the call through in the same breath. There is deliberately no "I'll transfer you now" in between.
• It asks which department when it cannot tell, rather than guessing.
• It never reads out phone numbers, SIP addresses or anything else internal.
• If the connection fails, it says so and retries: "The transfer didn't go through. Let me try again."

⚠️ Do not add these to your Main Objective. "Ask the caller if they want to be transferred", "confirm before transferring", "tell the caller you're connecting them", "if the transfer fails, say…": all four already happen. Adding them either does nothing or makes the agent say the same thing twice.

One thing this does put in your hands. The caller hears the destination's name in that permission question. So name your destinations the way you would want a receptionist to say them out loud: "our service department", not "SVC-2 overflow".

Setting it up

1. Go to Agent → Skills → Add Skills.
2. Click Add New Transfer (or edit an existing entry).
3. Transfer Number: the destination, in full international format including the country code: +31201234567, not 0201234567.
4. Description: tell the agent when to use this specific number. See the next section.
5. Toggle Enable Skill on.
6. Click Create.

Repeat for each destination. One entry per number: if two teams need two different numbers, that is two entries with two Descriptions, not one Description that tries to explain both.

⚠️ An entry that exists but is not enabled does nothing. If transfers stopped working after you added a new destination, check the toggles first.

Writing the Description

The Description is not a note for your colleagues. The agent reads it during the call to choose between your numbers. Write it as information the agent needs at that moment.

✅ Include

• Who is on the other end: the department, team or role, in the words your business actually uses. Start with this sentence.
• What kinds of calls belong there: concrete topics, phrased the way callers phrase them. "A warning light on the dashboard" beats "diagnostics enquiries", because that is what people say.
• The boundary: when you have more than one number, say what this one is not for and where those calls should go instead. This is what stops near-misses.

Two to five sentences is the right length. Long enough to tell the numbers apart, short enough to be read carefully.

❌ Leave out

• Anything about how to behave. "Be polite", "speak clearly". Your agent is already instructed to be calm, polite and concise; repeating it here changes nothing.
• Anything from "What happens automatically" above: asking permission, confirming, announcing the connection, handling a failure.
• The trigger. "If the caller asks for a human, transfer them" belongs in the Main Objective. Written here it will not cause a transfer, and it does not help pick a number.
• The phone number. It already has its own field. A second copy here will eventually disagree with the real one.
• Notes for humans. Opening hours, "rings over to reception after six rings", "ask for Marco". The agent cannot see any of this and cannot act on it.
• Anything that fits every entry. "For general enquiries", "for customers who need help". If the description would be equally true of your other numbers, it does not help the agent choose.

Example: a car dealership with three numbers

Sales

Sales team, showroom floor. Use this number when the caller is asking about getting a vehicle: whether a model is available, delivery times, a price or lease quote, the value of their current car as a trade-in, financing, or booking a test drive. Also use it when the caller already has a written quote from us and wants to go ahead with it. Do not use it for a car the caller already owns: repairs, warranty work and booked workshop appointments go to Service.

Service

Service and workshop reception. Use this number for a vehicle the caller already owns or leases: a fault, a warning light, a noise, a breakdown, warranty work, changing or cancelling a booked workshop appointment, or asking whether a car currently with us is ready to collect. Also use it for inspection and roadworthiness test dates. Do not use it for buying a vehicle, and do not use it for ordering a part the caller intends to fit themselves: those are Sales and Parts.

Parts

Parts counter. Use this number when the caller wants to order or ask about a specific component, accessory or consumable: a wing mirror, roof bars, wiper blades, a part number, or whether an item is in stock for collection. If the caller wants us to fit the part, that is Service, not Parts.

Each one names who is on the other end, lists real caller topics, and says where the neighboring calls go instead.

Give your fallback a Description too

If your Main Objective sends anything unmatched to a catch-all (a front office, a reception desk, a general line), that destination needs a Description like any other, and it needs to say that it is the fallback.

This is the one entry people write last and vaguest, and leaving it undescribed does more damage than you would expect. We have seen a live agent stop transferring entirely because of it: the Main Objective routed three topics to three departments and everything else to the front office, the three departments had good Descriptions, the front office had nothing identifying it, and no transfers happened at all, not even for the three that were set up correctly.

A fallback entry is allowed to be broad. That is its job. It just has to say so:

Front office: our general reception desk. This is the fallback destination: use it for any caller whose request does not clearly belong to Sales, Service or Parts.

Read through your Main Objective and underline every destination you have named in words. Each one must be findable in one of your Descriptions, under that same name.

A quick way to check your own

Write down ten things a real caller might say. Show someone only your Descriptions (not the numbers, not the department names) and ask them to sort the ten sentences into the right entries. If a person cannot do it from your Descriptions alone, neither can the agent.

Only one number? You still write a Description. Keep it short, but still say who is at the other end: "should I transfer?" and "is this the right place for this caller?" are not quite the same question.

Telling the agent when to transfer

The Descriptions handle routing. Your Main Objective has to handle the trigger, or the agent will never get as far as choosing a number.

Include:

• The conditions that make a transfer the right next step, written as things you can observe the caller saying or wanting.
• Anything the agent must collect before transferring. This matters more than it looks; see "What the agent cannot do" below.
• What to do if the caller says no.

Leave out the phone numbers and the department routing. Those live in the skill.

Example Main Objective text:

Offer to transfer the call when any of these is true:
 - the caller asks to speak to a person;
 - the caller wants a price, a quote, or to go ahead with a quote we have already sent;
 - the caller reports a vehicle that is not drivable.

Before transferring, ask for the registration number of the vehicle the call is about.
If the caller declines the transfer, ask whether they would like a callback and note a time that suits them.

⚠️ Do not put the numbers in the Main Objective. Writing "transfer to +31 20 555 0142 for sales" there creates a second copy of your routing. When the two copies disagree (and they will, as soon as someone edits one), the agent's behavior becomes unpredictable.

What the agent cannot do

Three limits. Each one is something builders regularly try to solve in the prompt, and it cannot be solved there. Instructions of these shapes look like they work and quietly do nothing.

It never finds out how the transfer went

Once the call is handed over it leaves the agent entirely. The agent does not know, and will never know, whether a person picked up, whether it rang out, or whether the caller was helped.

This is different from a transfer that never connects in the first place. If the connection attempt itself fails, the agent is still on the call, and the platform already handles it: it says so and retries. But once the call is through, the agent is gone.

• Do not write post-transfer fallbacks. "If nobody answers, offer a callback" is dead text. The agent is not on the call to notice, and not there to offer.
• Collect what you need before the handover. A callback number, a reference, the reason for the call. After the transfer it is gone.
• If it is important that a caller reaches a person, solve it in your phone system: rollover to another extension, or to voicemail. That is a telephony setting, not a prompt.

It cannot tell whether you are open

The agent is given the current date and time, and it can tell a caller your opening hours perfectly well. That is not the same as reliably checking the clock and branching on the answer. Do not write conditions that depend on it.

Handle this where it is normally handled, in your telephony: during business hours, forward the number to the agent; outside business hours, forward it to voicemail. The agent then only ever answers calls it is meant to answer, and no prompt logic is needed.

Opening hours still belong in Business Information. They are a fact the agent can state. They are not a condition it can act on.

It does not use your words for the handover

The permission question, the confirmation, the silent connection and the failure message are all built in; see "What happens automatically" above. Scripting them in your Main Objective either does nothing or makes the caller hear the same thing twice.

Example use cases

• Sales handoff: the agent qualifies the lead, then transfers to a salesperson to close.
• Verification: the agent collects the initial details, then transfers to a person for identity checks.
• Support escalation: the agent handles the common questions and transfers the rest straight to a live agent.
• Department routing: one published number, several teams behind it, the agent sorting callers to the right one.

Before you go live

• The Main Objective says, in plain observable terms, when to transfer.
• The Main Objective contains no phone numbers and no department routing.
• Every Description names who is at the other end.
• Every Description lists real caller topics in caller language.
• Every destination named in the Main Objective is findable in one of your Descriptions, under that name.
• If you have a fallback destination, its Description says that it is the fallback.
• No Description contains behaviour instructions, opening hours, or notes for humans.
• Every number is in full international format, with the country code.
• Every entry is enabled.
• Nothing in the Main Objective depends on the agent checking the time or your opening hours.
• Nothing in the Main Objective asks permission, confirms, announces the connection, or handles a failed transfer: the platform does all four.
• Nothing in the Main Objective describes what happens after a completed transfer.
• Each destination is named the way you would want it said out loud to a caller.
• Anything you need from the caller is collected before the transfer.
• Your telephony forwards to the agent during business hours and to voicemail outside them.
• You have made a test call for each destination and heard it connect.