Why Bland Builds Its Own Voice AI Models

When your voice AI vendor's underlying model changes, someone has to test the replacement, decide when it reaches your callers, and fix anything it breaks.

Bland builds its own voice AI models so we can own those decisions. That is a substantial engineering commitment, but it gives us direct control over both the behavior we fix today and the version we run next month.

Control includes the next model release#

Model providers retire versions and move customers to newer ones. Google Cloud's model lifecycle guide lays out retirement and migration for its services. A phone workflow that worked yesterday still needs someone to check the replacement.

Before choosing a voice platform, establish who picks the replacement model, tests it against your calls, approves the release, and can roll it back. Clearly divide what your team does and what the vendor owns.

Owning our models lets Bland make those changes directly. We still have to compare the new behavior with the current version and decide whether it is ready for production.

Call quality has to survive where callers work#

In our logistics deployments, drivers call from cabs, yards, and places with barely any signal. Noise and poor connections are part of the job. The agent has to recover the identifier or location it needs while preserving the rest of the conversation. Sometimes that means asking the caller to speak up.

A common voice AI system turns audio into text, decides what to say or do, and generates the spoken reply. The caller experiences those parts together. A beautifully spoken answer to the wrong account would be an expensive demonstration of voice quality.

Bland runs its own models rather than sending the conversation through outside model APIs. Our self-hosting overview explains the approach. Control across those layers lets us investigate where a failure began and work on the behavior causing it.

A vendor should show you the completed job#

Ask a vendor to show you what happened between picking up the phone and completing the work. In one Bland deployment, a vehicle remarketing company was calling body shops to find out whether vehicles were ready for pickup. Its previous automation struggled with latency and phone trees. After rebuilding the calls on Bland, phone-tree navigation success rose from 60% to 95% across the first 100-call test set. Overall call success reached 97%, and review time fell from two minutes per call to 30 seconds.

A mortgage lender had a legacy phone system with high latency and limited routing. It moved borrower calls and messages to Bland across more than 10,000 calls a day; 80% of those calls required no manual data entry, with reported latency below 400 milliseconds.

These are the measures a vendor should be able to explain: how often the agent reached the right person, completed the task, and handed off work to someone else. Ask to see the calls behind the numbers.

The enterprise voice AI security guide covers the rest of the supplier and incident review; for the model itself, agree on release notice, review access, and rollback before launch.