Choosing the right LLM for function calling
Not every function call needs the same model class. Match the model to the complexity of the function flow:Booking appointments
Use this prompt on any Call Flow step where the agent should book a meeting. Compatible with any PulsyAI booking integration — including Cal.com today. The prompt is universal: the function names (isDateAvailable, confirm_booking, etc.) work the same way regardless of which booking backend powers the integration.
Setup checklist before using this prompt
- The integration is configured at the agent level (see the integration’s setup page).
- The Call Flow step where this prompt lives has the “Should the agent book a meeting in this step?” checkbox enabled.
- The integration is attached to the step via + Connect Action in the Call Flows tab.
- The agent’s LLM is set to GPT-4.1 or smarter.
The prompt
Customizing this prompt
Keep fixed: the function names, the CRITICAL RULES block, the conversation flow structure, the time-pronunciation rule. Adapt freely: the opening sentence (“For the free quote…”), the service vocabulary (“estimator”, “representative”, “specialist”), the confirmation phrases, the language.Warm transfer to a human representative
Use this prompt when the agent should hand off the call directly to a human team — typically a closer line standing by during business hours. This is the pattern documented in Principle 9: The AI prequalifies, the human closes.Setup checklist before using either transfer prompt
- At least one recipient is configured in the agent’s Transfers tab — name + phone number with country code (for example +14385551234 for Canada/US, +33612345678 for France).
- The trigger directive (one of the two prompts below) is written directly in the Call Flow prompt of the step where transfer should be possible.
- No + Connect Action is needed for transfers — the directive in the prompt fires the transfer function call directly.
- The agent’s LLM has function-calling enabled (4o-mini and up all work fine).
Single recipient — straightforward warm transfer
Use this directive when there’s only one transfer destination configured (a single closing team, a single shared support line). The agent listens for any signal that the customer wants a human, asks for confirmation, then fires the transfer.Multi-recipient — department-based routing
Use this directive when you’ve configured multiple recipients in the Transfers tab (for example James for technical, Louise for billing, Maria for sales). The agent first identifies which department the customer needs, confirms the transfer to that specific recipient, then fires the function call.Customizing transfer prompts
Keep fixed: the ⚠️ CALL TRANSFER PROTOCOL ⚠️ structure (TRIGGER CONDITIONS → MANDATORY RESPONSE → UPON CONFIRMATION), the ask-then-fire pattern, the requirement that the customer explicitly confirms before the function call fires. Adapt freely: the recipient names (replace James, Louise, Maria with your actual recipient names from the Transfers tab), the department labels, the customer-facing response wording, the language. For department-routing, add or remove departments based on how many recipients you’ve configured. For multi-recipient routing details — including how to map customer keywords to recipients, how to handle ambiguous intent, and best practices for naming recipients — see the Transfers page.Send SMS during a call
Use this prompt pattern when the agent should text the caller during a live call — typically a menu link, an ordering link, a booking confirmation, or any pre-defined piece of content. Compatible with any conditional SMS configured in the agent’s SMS Configuration tab.Setup checklist before using this prompt
- The conditional SMS messages are defined in the SMS Configuration tab with the Send Live option checked.
- The Send Condition ends with the word “immediately” (this is what tells the agent to send live during the call, not after).
- The agent’s LLM has function-calling enabled (4o-mini and up all work fine).
The prompt
Customizing this prompt
Keep fixed: the ask-confirm-send pattern for any SMS the caller might not want, the[SEND SMS: ...] syntax that maps to your SMS Configuration entries, the auto-send pattern for order confirmations (no permission needed — the caller already implicitly agreed by completing the order).
Adapt freely: the menu items, the conditional branches (you can have 2, 5, or 20 IF branches), the after-send confirmation lines, the language and tone.
For the full SMS configuration setup, see the SMS Configuration page.
General customization principles
Across all three prompt examples, a few principles stay constant:- Ask before you fire. Every function call needs a yes/no question first, the user’s confirmation, then the directive that fires the function. Without the confirmation step, function calls misfire or fire on wrong intent.
- Use explicit trigger words in your directives. “If the customer agrees… transfer the call immediately.” The word “immediately” matters. Same for SMS: “Send this SMS if the caller asked for the link and agreed to receive it immediately.”
- Keep the agent’s spoken lines short. Long explanations break conversational flow and increase hangup risk. Save the detail for the human callback or the SMS content itself.
- Test on a real call before going live. Function-calling behaviour can vary slightly between LLMs and between configurations. Use Test Chatbot for fast iteration and Test AI for final validation.
Next step
Build a Script
The methodology behind why these prompts work — the four-step structure, the nine PulsyAI principles, and the full PulsyAI Plumber example script.
Working with End-Clients
The reseller playbook for handling client conversations — pushback patterns, expectation setting, and when to override your defaults.