Before We Go

Title

Inspiration

For a business handling incoming calls, online enquiries and callback requests, responding is only part of the job. Each customer brings a different question, and the answer may depend on information that is not immediately available. Customers can be left waiting, repeating their needs or deciding without enough detail. Staff need a way to preserve the conversation and identify what requires their attention.

Before We Go explores how CALL-E could support that workflow: a focused callback that understands the enquiry, explains known information and prepares unresolved questions for human follow-up.

The prototype focuses on restaurant visits because a seemingly simple enquiry can carry real personal significance. A family planning lunch may need to know whether a wheelchair user can reach a table and toilet without being lifted. A general accessibility label does not resolve those specific questions. The useful outcome is a clearer basis for planning the visit.

What it does

The intended workflow begins with a customer's restaurant enquiry. CALL-E calls that consenting customer as a disclosed AI restaurant representative, using a bounded, versioned fact sheet. The conversation captures visit needs, explains available information and identifies questions that staff must resolve.

The prototype uses The Courtyard, a fictional restaurant. Its entrance and ground-floor dining area are step-free, but a ground-floor table still requires confirmation. A ground-floor toilet exists, while the complete route, doorway width and turning space remain unverified. Those gaps stay visible rather than becoming promises.

The implemented application supports four labelled synthetic scenarios, transcript inspection, separate customer and AI excerpts, human review and a JSON handoff export. It does not book a table, promise availability, certify accessibility or automatically deliver follow-up to staff.

Why CALL-E matters

Many enquiries repeat familiar questions whose answers already exist in a business system: product features, service options, opening information or the status of a request. With an authorised connection to accurate, current business data, a CALL-E application could handle routine conversations with a patient, attentive tone and consistent explanations, while escalating missing information and exceptions to a person.

CALL-E does not automatically gain access to a company's systems. Before We Go uses a fixed fictional fact sheet, not a live CRM, inventory or booking integration. Whether customers experience a conversation as empathetic would need evaluation with real users.

For customers, the intended benefit is less repetition and a clearer understanding of what still needs checking. For businesses, the opportunity is to focus staff attention on decisions and missing information rather than repeated information gathering.

How it was built

The application uses React 19, TypeScript, Vinext Worker routes and D1 persistence, with a server-side CALL-E adapter. It saves a reviewed call plan, tracks dispatch and status, and prepares results for human review. Customer excerpts and AI explanations remain separate so the assistant's words cannot become evidence of a customer request.

The project was developed with AI coding assistance. Fifteen automated application tests and two public-deployment guard tests pass. The application tests include a built Worker HTTP test with isolated storage and mocked CALL-E responses. These checks establish controlled application behaviour, not actual phone delivery.

A portable reference example was contributed to CALL-E's community repository. PR #430 was accepted and merged on September 11. The maintainer added phone-output masking and reported 14 passing community tests.

The public judging site runs on Cloudflare Workers and requires no login. It supports sample exploration, transcript review and reviewed report downloads. Live endpoints are disabled and no CALL-E credentials or customer database are configured on that deployment. The full source repository remains private at this draft stage; the community contribution is public.

Integration status and challenges

Real CALL-E requests were submitted during development, but no successful phone conversation has been demonstrated. Three accepted tasks initially reported failure without transcripts. The two application callback attempts did not ring the configured mobile. A separate minimal diagnostic also failed without a transcript; ringing for that attempt was not independently verified.

Subsequent alternate-recipient and official-hotline requests were rejected with HTTP 429 before a new task was accepted. The latest controlled retry on September 12 returned an account concurrency error. A later read-only check showed two original tasks still failed and one reporting queued despite retaining its old completion timestamp, with no transcript. This inconsistent state is not evidence of repair or successful delivery.

The issue is documented in provider investigation #124. Its cause and repair remain unconfirmed. The public demo therefore demonstrates the working sample review workflow, not a completed live call. The main video illustrates the product vision; the supporting video shows actual app captures with synthetic examples.

What was learned

A fast answer is not necessarily a useful answer. Customer preferences, supplied business facts and unanswered questions need to remain distinct. Preserving those distinctions makes the next staff action clearer and reduces the risk of presenting uncertainty as reassurance.

A timeout must not become an automatic new call. Uncertain dispatch requires reconciliation, and incomplete conversations must remain incomplete. Application test results must also be distinguished from service availability and real-world outcomes.

What's next

If the account becomes available, the next step is a controlled service test followed by a consenting customer callback and review of its actual transcript against the fact sheet. Evaluation with customers and restaurant staff would then examine whether the handoff preserves important questions, avoids repeated explanations and supports resolution.

A real deployment would require maintained business information, appropriate recipient onboarding and staff ownership of follow-up. The ambition is a consistent enquiry experience in which customers feel understood and businesses receive a clear next step. The current scope remains one restaurant scenario, implemented and tested as a prototype.