Free and Open-Source Voice Interview Bot Tools

Updated 10 November 2026 · Standard formula, shown below

You can build a voice interview bot with free and open-source speech recognition, text-to-speech, dialogue, and calling components, but there is rarely one package that handles everything. A practical stack combines a bot framework, speech services, an interview script, and—if needed—a phone or web audio interface.

What a voice interview bot needs

A voice interview bot asks questions aloud, captures spoken answers, and decides what to say or do next. For a basic prototype, the conversation can run through a browser microphone; a phone-based interviewer also needs telephony or a voice-over-IP connection. The core functions are distinct, so choosing tools by role makes trade-offs clearer:

Speech-to-text (STT): turns a recorded answer into text.
Dialogue management: tracks the question, response, retries, and branching rules.
Text-to-speech (TTS): reads questions and prompts aloud.
Audio transport: records or streams audio from a web page, app, or phone call.
Storage and review: saves transcripts and, if appropriate, audio for human assessment.

These components can run locally, on your own server, or through hosted services. “Open source” describes software licensing, not necessarily the training data, model weights, hosting, or operating costs. Check each component’s license and deployment requirements separately.

Open-source tools by role

For speech recognition, Vosk is an offline speech-recognition toolkit with models for multiple languages. It can suit constrained devices or applications where audio should remain on the user’s machine, though recognition quality depends on language, model, microphone, and speaking conditions. whisper.cpp is a C/C++ implementation for running Whisper models locally; it offers a route to transcription without sending audio to a hosted transcription API. Model size affects resource use and speed, and local execution still requires suitable hardware and model files.

For speech synthesis, Piper is a local neural text-to-speech system with voice models. Available voices and their licenses can differ, so verify the particular model’s terms before using it in a product. eSpeak NG is another open-source option; it is compact and supports many languages, but its synthetic voice may sound less natural than neural speech.

For dialogue, Rasa Open Source provides a framework for building conversational assistants, including intent handling, dialogue policies, and custom actions. It can manage structured interview flows, but it does not by itself provide every audio, telephony, or speech-model component. A simpler interview with fixed questions and explicit branching may need only a small application that stores the current question and evaluates defined rules.

For browser-based audio, the standard WebRTC APIs enable real-time audio communication between browsers and other compatible endpoints. WebRTC is a transport layer, not a bot or speech recognizer. A browser app still needs code for microphone permission, audio capture, streaming or upload, and the response loop. For phone calls, an open-source PBX such as Asterisk can provide telephony infrastructure, but configuring call routing and connecting it reliably to speech services takes more operational work than a browser prototype.

How to assemble a simple system

A useful first version uses a fixed interview script and avoids open-ended dialogue until the basic audio loop works. For example, a job-screening prototype might ask for a candidate’s preferred work schedule, transcribe the answer, and then ask a permitted follow-up based on a clearly defined rule. A research interviewer might instead ask the same questions in the same order and let a human review uncertain transcripts.

Write the flow. List each prompt, expected response type, follow-up rule, and end condition. Decide what the bot should say when it cannot understand an answer.
Choose the input path. Start with browser recording or uploaded audio if live phone calls are not essential. Confirm that the target browser and device can record audio with the required permissions.
Transcribe and inspect. Send a short test recording to the chosen STT engine. Check punctuation, names, accents, interruptions, and whether silence or background noise creates misleading text.
Connect dialogue logic. Store the interview state, such as question number and retry count, separately from the transcript. Use explicit rules for moving forward rather than assuming every answer matches a recognized intent.
Speak the next prompt. Pass the selected response text to a TTS engine, then play it or send it through the call interface. Allow a pause before recording the next answer.
Test with realistic conditions. Try different microphones, speaking speeds, noisy rooms, pauses, and incomplete answers. Provide a way to repeat a question or reach a human when the flow breaks.

Choosing a stack and understanding costs

For an offline prototype, Vosk or whisper.cpp can handle transcription, Piper can speak prompts, and a small application can manage the script. For a more complex assistant, Rasa can help organize dialogue. A telephone service adds a PBX or other call connection. These are examples of compatible roles, not a guarantee that any combination works without integration: audio formats, streaming interfaces, latency, language support, and hardware requirements must be checked.

Free software does not mean zero cost. Self-hosting uses computing capacity, storage, maintenance time, and monitoring. Local models may need memory and processing power; phone access may involve separately charged connectivity or carrier services. Hosted speech services can be convenient, but may charge by usage and send recordings or transcripts to a provider. Read their data-handling terms before using them.

Compare candidate tools using the actual languages and accents in your audience, expected response length, acceptable delay, deployment environment, and license. Run a small, consent-based test with representative audio before selecting a model. A benchmark or demonstration may not reflect performance on your microphones and interview conditions.

Accuracy, privacy, and interview design

Speech recognition can mishear names, technical terms, accents, quiet speech, and overlapping voices. A transcript is not proof that a person said exactly those words. If answers affect a consequential decision, keep a human review process, make uncertainty visible, and avoid treating automated transcription or inferred sentiment as an objective assessment.

Tell participants when they are speaking with an automated system, what is recorded, why it is collected, who can access it, and how long it is kept. Collect only information needed for the stated purpose, protect recordings and transcripts, and set deletion and access controls. Local processing can reduce transfers to third parties, but it does not remove the need to secure devices, backups, or logs.

Design questions to be clear, neutral, and easy to answer aloud. Avoid asking the system to infer sensitive traits from voice. Offer repetition, a non-voice alternative, and a human contact where practical. These choices improve accessibility and give participants a way forward when speech recognition fails.

Common problems and alternatives

Long pauses, clipped recordings, and echo often come from audio capture or turn-taking rather than dialogue logic. Check microphone permissions, input-device selection, recording boundaries, and playback volume first. If the bot responds slowly, measure transcription, dialogue processing, and speech synthesis separately; replacing the whole stack before locating the delay can create needless work.

If building and maintaining every component is too much, alternatives include a human-led interview with speech-to-text transcription, a form followed by a recorded voice prompt, or a hosted conversational platform. These may reduce setup effort, but they are not necessarily open source or free, and their privacy and licensing terms still need review.

Frequently Asked Questions

Can I build a voice interview bot entirely offline?
Yes, a local speech recognizer, local TTS voice, and locally running dialogue application can work without cloud speech APIs. You still need compatible models, adequate hardware, and a way to capture audio; phone connectivity may add separate requirements.

Is Rasa a speech-recognition tool?
No. Rasa is for conversational dialogue and assistant behavior. Pair it with an STT engine for spoken input and a TTS system for spoken output.

Which open-source tool is best for transcription?
There is no universal best choice. Compare language and accent performance, latency, hardware needs, licensing, and privacy using representative recordings from your intended setting.

Can a browser interview bot answer over the phone?
Not by itself. A browser audio interface and a telephone call are different transport paths. Phone interviews need telephony infrastructure and integration with the bot’s speech and dialogue components.

Does open source mean commercial use is automatically allowed?
No. Software and model licenses can differ, and a voice model may have terms separate from the software that runs it. Review the specific licenses and attribution or usage conditions before deployment.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.