Call flows
A call flow defines what Julian must establish on a call, not a script. He holds real conversations, handles objections, and transfers live with full context.
A call flow defines the objective of a conversation, not a script. Julian picks up inbound calls in real time, holds a genuine two-way conversation — asking qualifying questions, handling objections, and adapting to what the prospect says — then books a meeting or transfers to your team. The call flow tells him what needs to be true before he acts.
This is not an IVR tree and not a script. You're specifying what must be established, and Julian decides how to get there in conversation. Writing a call flow as a rigid decision tree fights the design.
What a call flow defines
| Element | What to specify |
|---|---|
| Opening | How Julian identifies himself and why he's calling or answering |
| Discovery | The facts he must establish, in rough priority order |
| Knowledge boundaries | What he answers directly, and what always transfers |
| Objection handling | Responses to the objections you actually hear on inbound |
| Outcomes | What happens on qualified, nurture, disqualified, no-answer, escalate |
| Recording disclosure | Your notice, where required |
Real-time personalization
Calls are personalized using the details the prospect submitted on the form. Julian opens knowing why they raised their hand, rather than asking them to re-explain.
This is the single biggest credibility factor on an inbound callback. A prospect who filled in a form thirty seconds ago and is then asked "so what prompted you to get in touch?" has learned they're talking to a system that didn't read their submission.
Discovery: keep it minimal
Define the facts Julian must confirm before booking. Keep it to the minimum that makes the meeting worth a rep's time.
Typically:
- Need — the problem they're trying to solve
- Timing — whether anything is actually happening now
- Authority — whether they can buy, or who can
- Any disqualifying constraint specific to your product
Every additional required question is a chance to lose a qualified lead on a callback. Ask what a rep genuinely cannot start the meeting without — not everything a rep would like to know.
Knowledge boundaries and live transfer
Julian answers from your knowledge base — the same source Alice uses. Where a question falls outside it, he transfers the call live, with full context, so the rep understands the prospect and the conversation history without the prospect repeating themselves.
Make these unconditional transfers:
- Pricing beyond your published posture
- Contract, legal, or procurement terms
- Security and compliance specifics
- Roadmap or delivery commitments
- Anything from a named strategic account or existing customer
Outcomes
Define what happens in each case. Every path must terminate somewhere and be written to the CRM.
Recording, transcription, and tuning
Every call is recorded, transcribed, and summarized. That gives you a direct tuning loop: review what Julian actually said and adjust the instructions.
Read transcripts, not just outcomes
The outcome tells you what happened; the transcript tells you why.
Sample both qualified and disqualified calls
Disqualifications are where the expensive mistakes hide — nobody reports a good lead that was quietly turned away.
Look for questions he couldn't answer
Each one is either a knowledge base gap or a boundary that needs setting.
Adjust instructions, then re-sample
Change one thing at a time so you can attribute the effect.
Call recording is subject to disclosure and consent requirements that vary by jurisdiction. Configure your notice in the call flow per your own policy and legal advice — see security and compliance.
One flow per motion
Build a separate call flow for each distinct motion. An inbound demo request and a post-trial expansion call have different objectives.
Reuse the ICP definition across them; don't reuse the flow.