Inspiration
An urgent clinic shift can fail because a qualified professional never sees a message. ShohojSheba Voice turns a human-confirmed staffing need into a trusted shortlist, then uses CALL-E as the automation engine that reaches consented professionals one at a time.
The goal is not autonomous hiring. It is dependable last-mile coordination: CALL-E obtains a bounded decision over the phone, the application reacts safely, and a clinic coordinator remains responsible for the final assignment.
What it does
- A professional manually enters structured experience, registration, skills, availability, rate, language, and optional standing consent for relevant opportunity calls.
- A clinic coordinator manually confirms the staffing requirement.
- Deterministic rules enforce profession, reviewed registration, required skills, full-shift availability, and budget before scoring eligible candidates.
- The coordinator approves a sequential CALL-E campaign.
- CALL-E contacts one consented candidate at a time through a published Goal with a fixed input and result contract.
- A verified decline advances the queue exactly once. Acceptance, callback, unclear output, opt-out, or unconfirmed identity pauses it.
- Acceptance notifies the clinic, but only a human coordinator can confirm the assignment.
If every candidate declines, the coordinator can broaden the original requirements and regenerate the eligible pool instead of silently lowering a safety rule.
Why CALL-E is essential
This workflow is not a chatbot with a phone button. CALL-E owns the identity-before-disclosure conversation policy and produces the structured event that drives the queue.
The published ShohojSheba Structured Shift Dispatch Goal accepts exactly ten trusted, server-built staffing variables. It returns one bounded decision—accepted, declined, callback requested, identity not confirmed, or unclear—plus identity and follow-up flags. ShohojSheba never infers a decision from a transcript or free-text summary. Missing or invalid structured output fails closed for human review.
Verified live competition proof
On 20 August 2026, we completed an owner-authorised two-recipient campaign using the published CALL-E Goal:
- Candidate one returned a completed, identity-confirmed decline with no follow-up required.
- ShohojSheba reacted to that structured result and automatically started candidate two.
- Candidate two returned a completed, identity-confirmed acceptance with no follow-up required.
- The campaign paused and exposed the human assignment-confirmation action.
The judge-facing page retains only masked Goal Run references and bounded decisions. It does not retain destinations, transcripts, summaries, notes, tokens, or raw provider identifiers.
How we built it
- CALL-E TypeScript SDK and API
- Published CALL-E Goal via
goals.runAndWait() - Next.js App Router, React, and strict TypeScript
- Vitest and Testing Library
- Cloudflare Workers deployment through Vinext
- Deterministic fictional data for repeatable, privacy-safe judging
The browser can submit only known fictional entity identifiers and controlled recipient fields. The server reconstructs the invitation, validates consent and eligibility, accepts only globally valid E.164 numbers for the English judge test, verifies a private timing-safe judge token, and applies recipient-scoped idempotency before CALL-E can run. Judges can therefore use a number they own anywhere CALL-E has carrier reachability.
Safety and responsible automation
- Voice-contact consent is optional, purpose-limited, visible, and revocable.
- CALL-E confirms identity before disclosing the fictional clinic, schedule, rate, or required skill.
- The agent cannot negotiate credentials, clinical scope, duties, or pay.
- Duplicate-call protection is recipient-scoped.
- Ambiguous results never trigger another call.
- A positive phone response never creates an autonomous assignment.
- No patient data is used anywhere in the project.
The public workflow uses clearly labelled deterministic simulation so every judge can test the full decline-to-accept path without credentials, payment, or a real phone number. Devpost's private testing instructions separately provide a protected path for authorised real-call testing.
Challenges we faced
Telephone clarity turned out to be a product requirement, not copy polish. An early test used dense phrasing and 24-hour time. We revised the Goal to use short English sentences, twelve-hour AM/PM time, deliberate pauses, and offers to repeat critical details.
We also discovered that the connected account rejected per-call JSON result schema variants on the generic Calls API. Instead of parsing free text, we moved the final integration to a reusable published Goal where CALL-E owns and materialises the structured result. The application still fails closed if that result is missing.
What we learned
The safest automation boundary is also the clearest product boundary: CALL-E decides what happened during the call, deterministic application logic decides the next allowed transition, and a human decides whether anyone is assigned.
What is next
Production work would add authenticated organisations, durable storage, registry integrations, notification channels, attendance and dispute workflows, and broader locale testing. For this competition build, we deliberately prioritised one complete, testable, privacy-safe CALL-E workflow over a wide but fragile feature set.
Try it: Open the no-login judge guide
Built With
- call-e
- cloudflare-workers
- next.js
- react
- typescript
- vitest

Log in or sign up for Devpost to join the conversation.