BidPilot Voice

Inspiration

An RFP can tell a business what a buyer needs, but it cannot confirm whether a supplier is available, how quickly they can deliver, or which locations they serve. Those unanswered questions can delay a bid decision or lead to assumptions that later prove costly.

We built BidPilot Voice to connect procurement analysis with an authorized phone conversation—and bring the resulting information back into the decision workflow.

What it does

BidPilot Voice lets an operator review a procurement opportunity, enter a consenting supplier contact, and approve the exact questions an AI agent may ask.

The application uses CALL-E to conduct the call and return structured information about:

• Availability
• Lead time
• Geographic coverage
• Certification or qualification status
• Indicative pricing
• Required human follow-up
• Additional notes

BidPilot displays the returned values, including unknowns, for human review. The agent is instructed to identify itself as AI and avoid purchases or commitments.

A clearly labeled no-call preview lets visitors explore the result interface without credentials or telephone calls.

How we built it

We extended our existing BidPilot AI procurement application with a new CALL-E verification workflow. The hackathon contribution adds the phone integration, authorization controls, result presentation, error handling, refresh recovery, and downloadable verification evidence.

The application uses React and TypeScript for the interface, Express and Node.js for the backend, and Vite for the frontend build. The backend invokes the CALL-E Developer API and retrieves call status and results. CALL-E credentials remain on the server.

We deployed the hackathon branch to a separate Render service, preserving the existing BidPilot deployment. The sample procurement opportunity works without a fresh Gemini request.

Challenges we faced

A phone request can time out without making it clear whether the provider accepted it. Automatically retrying could create duplicate calls. We introduced stable request identifiers, duplicate-request handling, a one-request demo budget, and explicit instructions to check provider history after an ambiguous outcome.

We also encountered a provider rejection for English calls to Canada. The English-only interface now defaults to the United States and disables Canada based on that test.

Our first completed phone attempt reached voicemail. A later consenting supplier role-play test returned structured answers. Losing tracking information after a browser refresh also exposed a recovery gap, so we added browser-session task tracking and an evidence download.

What we learned

Making a call is only part of the integration. The application must preserve uncertainty, distinguish task completion from factual accuracy, and display the supplier-level result rather than a task-level completion count.

For the completed role-play test, we compared the downloaded API fields with a BidPilot screenshot. All seven recipient fields matched exactly, and the provider’s completion-confidence score of 0.86 correctly displayed as 86%.

The returned availability was unknown, so we kept it unknown. That is useful information for the operator—not a value the application should invent.

This comparison validates the response-to-interface mapping for that test. It does not independently verify supplier claims or establish accuracy against every spoken detail.

Accomplishments we’re proud of

• Integrated CALL-E into an existing procurement workflow.
• Completed a consenting live role-play test and verified its returned fields against the interface.
• Passed TypeScript checking, production build, backend integration tests, error-redaction tests, and browser checks.
• Added explicit authorization, recipient restrictions, duplicate-call safeguards, and evidence export.
• Prepared a community contribution with reproducible setup and a no-call preview.

Our demonstration video is under three minutes and clearly labels its replay of captured live-result fields. Private contact details and credentials are excluded.

What’s next

We plan to add durable call tracking across server restarts, transcript-linked evidence, clearer handling of partial answers, and stronger connections between supplier responses and the original procurement requirements.

The goal is to help businesses make better-informed bid decisions while keeping consequential decisions with the human.

Built With

• call-e
• express.js
• gemini
• google
• node.js
• playwright
• react
• render
• tailwind
• typescript
• vite