I was working on an outbound voice agent for a technical service visiting restaurants in Spain. The call needed familiar local language, a way to find the right person and a useful next step if the restaurant needed the service.
One draft offered a free technical visit. That was the wrong offer: the visit was a paid service. I corrected it and asked for the conversation to establish a real need instead of booking a free visit the business didn't provide.
That correction made the review concrete. A smooth opening wasn't enough. The agent also needed to say the right thing about the service and know who it was speaking to.
A transfer changes the person, even if the restaurant stays the same
A restaurant call can begin with one person and continue with another. The final prompt asks the agent to establish the speaker's role at the beginning and confirm it again after a transfer.
For example, this is a sanitized illustration of the instruction, not a recorded call:
First speaker: Un momento, te paso con la encargada.
New speaker: ¿Sí?
Agent: Hola. ¿Con quién hablo? ¿Se encarga usted de este tema
en el restaurante?The restaurant context can still be useful. What doesn't carry over automatically is knowing who the new person is or whether they can arrange the visit. Continuing the old booking branch would skip that check.
A transfer starts another role check
- 01Role confirmedThe current speaker has been identified
- 02Call transferredSomeone else joins the call
- 03Role unconfirmedDo not inherit the previous answer
- 04Check againConfirm who can arrange the paid visit
The prompt also covers a transfer to the wrong person and a person who isn't interested. These are different branches, rather than instructions to repeat the pitch until somebody agrees.
Compare the parts of the prompt
I supplied ElevenLabs examples and its prompting guide, then brought in another model's draft. I asked for an honest section-by-section comparison before choosing the final version.
I could then compare the offer, role discovery, handover, objections and closing separately. A useful opening in one draft didn't settle whether its booking instructions were useful too.
The technical boundary mattered as well. The agent can collect a description of the need and arrange a visit. The technician makes the diagnosis. A fluent answer about the problem should not become an invented technical conclusion.
Asking for a booking isn't the same as making one
The final flow uses get_availability to find options and create_visit to request the booking. It includes a short spoken acknowledgement before using a tool, so the caller isn't simply left with unexplained silence.
The result of the tool determines what can be said next:
| What happened | What the conversation can establish |
|---|---|
| Available times returned | Offer those times |
| Booking succeeds | Confirm the visit |
| Booking tool fails | Explain the problem without saying the visit is booked |
This table summarizes the intended behavior. It isn't evidence that the final agent has passed these cases in a live call.
I finished with a Markdown prompt and a comparison document containing those rules and examples together. The next meaningful result has to come from hearing the agent handle actual transfers, refusals and tool failures. So far, the completed work is the prompt design; I don't have a measured booking success rate to attach to it.
Project sources & checks
The source includes supplied ElevenLabs examples and prompting guidance, the paid-visit correction, another model draft and a request for honest section-by-section comparison.
The saved prompt includes role verification, confirmation after transfers, technical limits, availability/booking tools, spoken tool acknowledgements, failure handling and closing examples.
The short exchange below is a sanitized illustration of the prompt rule, not a call transcript or a verified model response.
A final Markdown prompt and comparison analysis. No verified live booking rate, latency result or recorded call suite.