Care Call AI

Start page
Dashboard
Operator panel
Approval Gate
Сall results
Orders
Carecall AI Assistant

Inspiration

Care Call AI was inspired by a very ordinary operational problem: charities and non-clinical support organizations often spend hours contacting beneficiaries who live at home with severe illnesses or disabilities, asking what everyday help they need, writing down the answer, and then trying to turn those conversations into real support.

The call itself is only half the work. A coordinator has to notice who is safe to contact, listen carefully, capture the person's request, decide whether it is suitable for fulfilment, and pass it to the right team: food delivery, medication pickup, transport, cleaning, laundry, home help, companionship, small repairs, documents support, or another practical service.

The risk we kept coming back to was not just "a missed call." It was the moment after the call, when a real request can be delayed, duplicated, routed to the wrong team, mistranscribed, or simply lost.

Our research into accessibility and practical support needs also made the problem feel more human. People living with severe illnesses or disabilities may need slower pacing, shorter questions, trusted answerers, longer pauses, or human handling instead of automation. This context changes how an outreach conversation should be conducted; it is not used for clinical assessment. The needs CareCall coordinates are everyday and non-clinical: food, medication pickup, transport, home access, household tasks, companionship, leisure activities, and other social support.

That became the product line and design rule:

Care seen. Needs heard. Help delivered.

We wanted to build a CALL-E-powered workflow where automation helps with repetitive outreach, but the coordinator still owns safety, approval, review, and fulfilment.

What it does

Care Call AI is a practical support outreach and fulfilment coordination workflow for charities and support organizations, built with CALL-E.

Coordinators can review a daily care population, see who is eligible for automated outreach, identify blocked or operator-only cases, inspect recipient care cards, run a no-call preflight, explicitly approve a safe CALL-E batch, import structured call results, and turn confirmed needs into service requests and printable fulfilment orders.

The core workflow has three parts:

Care seen - the dashboard shows readiness, safety categories, urgent callback pressure, service demand, condition mix, and cases that need human attention.
Needs heard - CALL-E check-ins are prepared from recipient context and only started after coordinator approval.
Help delivered - completed calls become structured requests, review rows, order history, and print-ready handoff sheets.

Recipient cards carry operational context such as contact details, delivery area, safety category, condition profile, communication rules, trusted answerers, and practical needs. The system is designed so critical, blocked, repeated too recently, or operator-only recipients are not dialed automatically.

We also added an urgent callback workflow. A registered recipient can request a callback through the production-verified Siri Shortcut path, and Care Call AI routes that request into the same eligibility, daily-limit, approval, and result-import model used for scheduled outreach. This is for urgent practical support routing, not emergency medical response. The callback entry point is separated from the protected CareCall and CALL-E workflow, so future adapters for Alexa, Google Assistant, Yandex Alice, and other voice assistants can be added without bypassing the existing safeguards. Siri is available now; those additional voice-assistant adapters are planned integrations.

Finally, the product includes a secure text and voice assistant pattern for coordinators and public users. Browser clients talk to same-origin routes, assistant credentials stay server-side, text streaming is supported, and the voice assistant path can use the shared assistant runtime without exposing secrets in client JavaScript.

How we built it

Care Call AI is built as a web application with a protected Next.js and React frontend, TypeScript contracts, a Python backend, server-side API routes, database-backed workflow state, and a guarded CALL-E integration.

The coordinator console includes:

a scan-friendly operations dashboard;
recipient list and detail pages;
editable care cards;
a preflight approval gate;
an operator call panel;
urgent callback queue;
order history and printable fulfilment sheets;
public pages and support/contact flows;
a Care Call AI assistant with text and voice capabilities.

The browser never sends CALL-E credentials, backend tokens, or assistant service credentials directly. The frontend talks to same-origin server routes. The backend builds the CALL-E task from approved operational data: safety category, condition profile, communication rules, language and locale, trusted answerers, care needs taxonomy, escalation policy, daily limits, and the structured result schema expected back.

For the hackathon, CALL-E is the real phone-agent runtime. It receives the approved task, handles the live conversation, and returns structured results, transcript evidence, and summary data. Care Call AI then imports those results conservatively: explicit practical requests become fulfilment items, unclear or restricted requests become coordinator-review rows, and "no requested items" outcomes remain visible instead of disappearing.

We built repeat-call safeguards and callback limits because even a useful automation should be scarce and intentional. The system tracks call runs, provider run IDs, callback requests, approval decisions, import history, and order state so the coordinator can see what happened after a call and what still needs review.

The deployable pattern is intentionally straightforward: frontend application -> protected backend API -> database-backed workflow state -> call queue/orchestrator -> CALL-E. The public repository contains a working frontend and backend that judges can run locally. A more extensive working version is deployed at care.alexraixon.com, with a separate judge login and password provided directly to the judging team.

Challenges we ran into

The hardest part was balancing automation with safety.

It was not enough to build a list of phone numbers and call them. The product needed to understand when automation is inappropriate, when a caregiver or trusted answerer may respond, when a coordinator should intervene, when a repeated call should be blocked, and how to make explicit approval feel like a natural part of the workflow instead of a bolt-on warning.

We also had to design for the gap between conversation and action. A useful call must become a concrete care task, but not every sentence should become an order. We had to separate confirmed fulfilment needs from uncertain notes, prohibited requests, no-request outcomes, and human-review cases.

Another challenge was turning a hackathon prototype into something close to a real product experience: authentication, protected backend access, server-side assistant proxying, callback ingestion, real CALL-E execution, result import, print workflows, public repository packaging, tests, and a dashboard that feels useful for an actual coordinator rather than a demo shell.

The frontend also evolved a lot during the project. We redesigned the public landing experience around the Care Call AI visual identity, added a theme toggle, made the dashboard more scan-friendly, improved print layouts, and fixed dark-mode surfaces in the assistant so the interface remains readable for operators working in different environments.

Accomplishments that we're proud of

We built a working end-to-end care outreach workflow rather than a generic calling demo.

Care Call AI includes a coordinator dashboard, recipient safety categories, editable care cards, trusted answerers, no-call preflight, protected backend APIs, urgent callbacks, daily-limit and repeat-call safeguards, real CALL-E execution, structured result import, printable order sheets, and a secure assistant path.

We are especially proud that the experience keeps the coordinator in control while still showing how CALL-E can reduce repetitive phone work. The project demonstrates a full loop:

review care -> approve safe calls -> hear needs -> import results -> prepare handoff -> deliver help

We also prepared and pushed a sanitized public repository so judges and the community can inspect the CALL-E workflow without exposing private infrastructure or secrets.

What we learned

We learned that phone AI becomes much more valuable when it is embedded inside a real workflow. The call is only one part of the job. The surrounding system matters just as much: consent, safety category, condition-aware prompts, trusted answerers, operator approval, duplicate-call prevention, summaries, transcript evidence, structured outputs, service requests, fulfilment history, and human escalation.

We also learned that responsible automation in care work is an operations design problem, not just a model problem. A small rule such as "do not call this person automatically" is only useful if the UI, backend, tests, approval flow, and call-run state all agree with it.

The research also made one product principle clear: the system should not ask "what is wrong with this person?" It should ask what matters to this person, what support they need today, who may safely speak for them, and what action must not be lost after the call.

Technically, we learned a lot about building AI features as product infrastructure rather than isolated widgets: streaming assistant responses through a server route, keeping credentials out of the browser, normalizing provider results, making idempotent callback APIs, preserving audit history, and writing tests around safety behavior instead of only happy paths.

What's next for Care Call AI

Next steps include stronger role-based authorization, richer operator audit logs, better condition-specific conversation policies, admin tools for managing operators and monitoring activity, and real-world testing with charities and support organizations.

We also want to expand the product beyond scheduled delivery rounds. Future versions could support more accessibility-aware practical-needs check-ins, family or trusted-answerer update workflows, companionship and community-activity requests, and more recipient-triggered callback paths under human-reviewed safeguards. The Siri callback is already available; the adapter-based callback architecture is intended to support planned Alexa, Google Assistant, Yandex Alice, and other voice-assistant triggers.

On the technical side, the roadmap includes scalable queue workers for retries and busy numbers, CRM/help desk integrations, volunteer dispatch integrations, multilingual outreach in CALL-E-supported regions and languages, deeper reporting, and improved tablet/mobile workflows for coordinators and field teams.