Inspiration
A last-minute cancellation looks like a small scheduling problem, but it creates a real coordination race. Broadcasting the opening can overbook it. Calling people one by one preserves fairness, but an operator can spend the slot's remaining lifetime dialing, waiting, and documenting responses. The useful automation is not “AI makes calls.” It is a bounded workflow that moves quickly without skipping the queue or making a commitment for the business.
What it does
Waitlist Slot Rescue offers one expiring, non-regulated service slot to people who already opted into waitlist calls.
- Validate consent, queue order, destination format, service category, and expiry.
- Call exactly one candidate at a time in that candidate's BCP 47 locale.
- Disclose the AI caller, confirm the intended participant, and ask one short slot question.
- Advance only after a clear decline or provider-verified no-answer.
- Stop on the first evidence-backed yes or any ambiguity.
- Return a privacy-minimized result for human review. The app never books, cancels, takes payment, or promises a reservation.
The included interactive demo shows both paths that matter: a golden path where Candidate A declines and Candidate B accepts while Candidate C remains untouched, and a safe-halt path where an answered call ends without a reliable decision.
Why it matters
This is a specific, reusable phone-work pattern for salons, vehicle and home services, tutoring, and fitness businesses. It protects three interests at once:
- the business: less active operator time while an opening is expiring;
- the waitlist: queue order is preserved instead of creating a fastest-finger race;
- the candidate: no silent consent, blind retry, or automatic booking.
The app deliberately rejects medical, legal, financial, emergency, collections, political, and unsolicited-marketing use.
How we built it
The Python 3.11+ application uses the pinned calle-ai==0.2.0 SDK. In live mode it calls client.calls.create(...), waits for the terminal result, and converts provider output into a deliberately narrow workflow state.
A generated outcome label is never enough to claim acceptance. The completion gate requires:
- completed provider status;
- explicit task completion;
- high normalized confidence;
- provider-authored evidence;
- transcript presence; and
- consistent structured fields for identity, AI disclosure, opt-out, and slot intent.
Silence, interruption, hang-up, missing evidence, or contradictory fields become unknown. Unknown halts the queue for human review. Stable slot-and-candidate idempotency keys prevent a retry from silently creating the same task again, and expiry is checked before and after every call.
Preview and fixture modes require no credentials, network, or phone side effects. Output files use restrictive permissions, phone numbers are masked, and live diagnostics expose bounded booleans and enums rather than raw transcripts or provider evidence.
Real CALL-E verification
We placed one separately authorized CALL-E call to the owner of the test number. It connected for 25 seconds. The participant ended it before enough evidence existed to classify a yes or no.
The honest result was unknown: the queue halted, no booking was created, no automatic redial occurred, and no additional candidate was contacted. That is not presented as a successful acceptance. It is useful evidence that the CALL-E provider boundary works and the workflow fails closed when the conversation is inconclusive.
The live test also revealed a locale mismatch in the test request. We corrected the task builder to use each candidate's locale, ask one question per turn, wait after every question, and never infer agreement from silence or interruption. A regression test now reproduces the participant-ended outcome.
Evidence, not inflated claims
A public GitHub Actions run installs the locked environment on Python 3.12 and passes 23/23 regression tests. The tests cover consent, expiry, duplicate recipients, locale-aware prompting, result evidence, idempotency, redaction, first-acceptance stopping, human-only booking, and the answered-then-ended safe halt.
A deterministic 10,000-trial model compares manual sequential calling with the same queue automated by the app. Under its documented fictional assumptions, mean active operator time changes from 6.56 to 1.25 minutes, an 81.0% reduction. These are reproducible modeled results—not measured customer impact—and every assumption is committed beside the code.
Challenges we ran into
The hardest problem was not placing a call; it was deciding when a call result is safe to act on. Provider output can be incomplete, a participant can hang up, an offer can expire during a call, and a convenient “accepted” label can conflict with the evidence. We designed the state machine around those failure modes and made ambiguity a first-class human-review outcome.
We also kept the zero-call experience complete. Judges can understand and exercise the workflow without credentials, consuming credits, or calling anyone.
What we learned
Phone agents need an explicit commitment boundary. Natural conversation is probabilistic; booking is consequential. The robust architecture keeps conversation adaptive while making queue order, evidence requirements, expiry, idempotency, privacy, and final authority deterministic.
What's next
- provider webhooks for durable asynchronous completion;
- an operator inbox for ambiguous outcomes and final confirmation;
- configurable business-hours and locale policies;
- measured pilots with consenting non-regulated service businesses; and
- adapters for existing scheduling and CRM systems, with every booking mutation still human-approved.
