Handoff to your systems: every call ends as a record

“Integrate with our practice system” isn’t a plan. “Book a visit for this pet, at an opening the caller chose, with the reason in their words” is. Each action has its own details, its own permission and its own consequence, so name them one at a time, starting with the one your callers ask for most.

Then name the system that owns the result.¹ The calendar owns the appointment. The practice system owns the patient record. The order system owns the shipment. The conversation explains why something changed; the owning system is where it changed, and it is the one the agent asks.

Separate reading from writing. Looking up a visit needs the right caller and nothing more. Changing it needs a readback and a yes.

An action contract is a short agreement between the people who run the calls and the person who owns the system: what the caller wants, which details the action needs, what the system returns when it worked, what it returns when it didn’t, and who owns the exceptions. It fits on one page, like Linden’s book_visit above, and in Zumu it becomes the action itself.

Keep the promise the caller hears no bigger than the response. book_visit returns a visit and a start time, so a visit and a start time are what the agent confirms. “The vet will sort out his ear on Thursday” is a different promise, owned by a different step.

Decide which actions run on their own and which wait for a yes.² Reading an opening can run freely; booking one waits for the caller’s agreement, asked for in words the caller can’t mistake.

The order never changes: check, read back, write, tell.

An opening that was free at 00:43 can be gone by 00:54, given to someone at the front desk in the eleven seconds between.

When a customer asks later what was agreed, open the conversation record.³

Your system will say no: an opening taken a second earlier, a pet it can’t find on the account, a moment when it’s busy. Decide now what each no sounds like to a caller. In the contract above, every error maps to one of two things: try again, or tell the caller plainly and offer the next option, so a lost opening still ends the call booked.

A timeout is the one no that isn’t an answer: the write landed or it didn’t, and nobody knows which yet. Look before writing again: find the booking by the caller and the time, and only book if it isn’t there. If your API accepts a request key, send one with every write, so the same request can never book twice.

Some calls finish with a person: a quote only the practice manager gives, an owner who wants to talk it through with a vet, a question that needs clinical judgement. When that happens, the work goes with it: who called, what they wanted, what was checked, what is already booked and what is left.

Decide for each action whether the handover is live or queued. Live is a warm transfer: the caller holds while the agent briefs your person, and the call connects only when they accept; the after-hours guide has the card that decides who gets woken for one.

Queued is the summary above: the booking and the open question named, so nobody does the first half twice.⁴

Before a customer calls, run the action end to end, including every no in the contract. A scripted test plays the caller’s side and mocks your system’s response, so the opening that disappears at 00:54 can disappear on purpose, as often as you like.

Widen one action at a time. When a tool, a permission or an instruction changes,⁵ the same tests run again before the change reaches a caller. Once it is live, quality checks read every conversation for the same things; the evaluation guide shows how to score them.