Your voice agent doesn't have to wait. Functions fire mid-call, before your customer hangs up.

Picture this on your line.

A bloke named Dave rings your brokerage on a Tuesday afternoon. He's selling his Sydney panel-beating business. Wants to know what it's worth.

Three minutes into the call, your agent's already captured revenue, EBITDA, sector, asking price, owner motivation.

Asks one more clarifying question. Dave finishes his answer.

Your agent says, "Cool Dave, I'm just sending a personalised valuation report through to your email now. Should land in about 90 seconds. Have a flick through and we'll book a follow-up call once you've had a read."

Dave hangs up. Walks to his desk. Refreshes his inbox.

Report's already there.

A 6-page PDF with comparable transactions in his sector, an EV/EBITDA range, and a likely buyer profile. His name and his business at the top.

Three minutes later, your phone rings him back. Senior partner. They've already read the report.

By the time Dave gets home that night, he's signed an exclusivity letter.

That's a function call firing mid-conversation. Want to know how it works on your line?

Why mid-call beats post-call every time

This is Playbook 2 from the voice agent column we have been running.

Five playbooks beyond the AI receptionist. This one's the most-misunderstood by operators in your space. Most stop short of it.

The standard voice agent flow on your line:

The agent answers. The agent talks. The agent ends the call.

A human in your team reads the transcript 15 minutes later. Maybe sends a follow-up email an hour after that.

That's the slow version. Customer momentum dies between the call and the follow-up.

Mid-call functions cut your gap to zero.

The agent fires a function during the call. While the customer is still on the line. Pulls data, sends an email, takes a payment, books a slot, queries your CRM.

The customer hangs up. The action's already done in your system.

Same agent on your line. Same minute pricing. Same 800ms first-token reply. New trick.

Function 1: Send a personalised document mid-call

Dave's story above is the lead example. A US business broker built it with a comparable-transactions API on the back end. You can run the same play.

Want the Auckland version? An ABC Business Sales broker takes the same call.

Agent: "Cool Sarah, can you tell me roughly what your last full year's revenue and EBITDA looked like?"

Sarah says it.

Agent: "Sweet. And your asking price ballpark?"

Sarah gives a number.

Agent: "Great, one moment, I'm just generating a comparable-transactions report based on what you've told me. Should be in your inbox in about 90 seconds. Should we book a follow-up call once you've had a flick through?"

The function call fires. Pulls comp data from a sector database.

Renders a branded PDF. Emails it via your transactional email provider. All before Sarah's even hung up the phone.

You've gone from "send me your numbers and I'll get back to you" to "the report's in your inbox" in one call.

The conversion lift on serious sellers? Massive.

They're not waiting three days for the broker to maybe-call-them-back. They've got the goods. They're ready to talk price.

Function 2: Take a payment on the line

A US casino-hotel runs $600k a month through a voice agent that takes the deposit on the same reservation call.

Your agent captures the booking details. Reads back the total. The customer confirms.

Agent: "Right, I'll just take a payment now. What's the long card number?"

Customer reads it. Agent reads it back. Customer confirms expiry and CVV.

Function fires. Stripe charges the card. Receipt lands in the customer's inbox before they put the phone down.

Want the Queenstown chef-driven restaurant version? Same flow.

Booking call lands at 5pm Friday. Agent confirms the table for 12 at 7pm Saturday. Captures dietary requirements. Confirms the $50/head deposit.

Agent: "Brilliant, just going to take a deposit of $600 now. What's the long card number?"

Card processed. Booking locked. The kitchen knows the deposit's in before the customer hangs up.

What's the cost of NOT doing this?

You take the booking. Saturday morning, 4 of the 12 cancel.

Your kitchen's bought the food. You've turned down a walk-in for the table. Your loss is $400 on the food and another $300 on the missed table.

Deposit-on-the-call is the difference between profitable Saturdays and the kitchen quietly losing money on no-shows.

Function 3: Book a calendar slot mid-conversation

A 400K-follower author handed his "what do you charge?" calls to a voice agent that books straight to his Calendly mid-call. He built it in under an hour.

The agent qualifies the enquiry. Confirms the budget range. Then triggers the booking function.

Agent: "Looks like a good fit. I'm just looking at his calendar now. He's got Tuesday at 10am or Thursday at 2pm next week. Which suits?"

Customer picks Thursday.

Agent: "Sweet, I'm sending the calendar invite to your email now. You should see it in about 30 seconds. Anything else I can help with?"

Calendly invite fires. Lands in the customer's inbox. Already accepted.

Want the Wellington solo consultant version? Same setup.

Voice agent answers booking enquiries in a voice that sounds like the consultant. Captures intent. Books the discovery call straight to her calendar. Sends the invoice link.

She sleeps.

What's the cost to your business of NOT doing this?

The customer says "yeah I'm interested, can you send me an email with some times?". You send the email. They open it three days later.

By then they've cooled or they've been to your competitor.

Mid-call booking captures the intent at peak heat. Email-back captures it at room temperature.

Function 4: Query a system and read back live

The most underused mid-call function. Pull data from your own systems while the customer's on the phone.

A Hertz-style proactive call comes into a US insurer. The agent's calling about a renewal. The customer asks: "Hang on, what about that claim I lodged last month, has anything happened?"

The agent fires a function. Queries the claims system. Reads back the status.

Agent: "Yep, looking at it now. Looks like your claim 4-2-1-7 is in assessor review and should be assigned an outcome by Friday. I'll add a note to chase the assessor for you. Sound good?"

Customer says yes. Agent logs the chase request.

Want the Wellington property management version? Same trick.

Tenant rings the after-hours line about a leaking tap. Agent qualifies the urgency. Then fires a function: queries the maintenance schedule. Reads back the next available tradie slot.

Agent: "We've got Pete the plumber free at 9am tomorrow morning. Want me to book him in?"

Tenant says yes. Maintenance ticket created. Pete's calendar updated. SMS confirmation sent to the tenant.

The tenant hangs up knowing exactly when their tap gets fixed. You've turned a complaint call into a closed ticket.

(Tenants don't ring back to thank you for the closed ticket. They just renew the lease without drama.)

What every mid-call function needs

Three things. None of them are exotic.

An API to call. Most modern systems have one. If yours doesn't, you've got a different problem.

A latency budget. Functions need to complete in under 8 seconds, ideally under 4. Otherwise the customer notices the awkward silence.

A graceful fallback. What happens when the API times out? The agent needs a polite "let me get a human to follow up on that" pattern. Without the fallback, your agent sounds broken.

We covered the technical stack in detail in how to extract variables and trigger external actions mid-call. Get that wrong and your agent stalls on every fourth call.

Honest moment: when mid-call functions go wrong

Me: "What's the worst mid-call function failure you've shipped?"

Builder: "Sent a customer's payment receipt to the wrong email. Customer's email had a typo. Receipt went to someone else."

Me: "How did you fix it?"

Builder: "Always read back the email before firing the send. Ten seconds of friction. Saves you a complaint."

Two-rule pattern that's saved every operator I know:

Read back any data the customer gives you before you fire the function. Email addresses, card numbers, addresses, names.

Confirm the action verbally before you fire it. "I'm about to send X to Y, sound good?" gives the customer one more chance to correct.

(Most operators skip these because they want the call to feel slick. They're skipping the bit that makes the function trustworthy.)

Your function-shipping checklist

Five questions before you wire one up:

Then two more:

If you can answer all five, you're ready to ship.

If you can't yet, build the function in a sandbox first. Test the read-back, the in-flight script, the fallback. Then take it to a customer call.

Pick the function your customer would feel today

A function fires fast. The customer hangs up with the receipt, the report, the booking, the answer.

Same engine that picks up your missed call at 9pm. Same minute pricing. Different trick.

The competitors who deploy this in your space are quietly turning every inbound call into a closed loop. Your customer notices. Their customer notices.

Pick the one function that would change the most calls in your business this month. Wire it up.

Run 60 calls in a sandbox before you ship. Playbook 5 will cover why.

Then watch the next caller hang up impressed.

Far out, that's a long article. Pick one function. Ship one experiment.