Every call answered. Nothing invented.

Vox Front AI is an AI receptionist for small, service-based businesses in the United States — dental practices, salons, law firms, and home services companies that lose bookings when nobody can reach the phone. It answers calls around the clock, books appointments straight into the business's existing calendar, and answers questions using only the FAQ and policy documents that business has uploaded.

The company was founded by Kainat Kiran Rashid, who runs it as a founder-led operation: she configures and tests every deployment personally. Vox Front AI is remote and serves businesses across the US.

Kainat founded Vox Front AI and configures and tests every deployment herself, rather than handing that work to a generic onboarding flow. The testing described across this site — a qualification checklist that skipped questions, a pricing regression, a call transfer that didn't complete — came from her own test call transcripts, not from vendor documentation.

That's a deliberate choice about how this company works: before an agent goes live for a business, someone has actually tried to break it on a real phone call.

The failures from that testing get published rather than buried. The write-up of what broke on our own test calls — an agent that wouldn't overwrite a corrected email address, a qualification checklist that skipped questions — is on the blog, with the transcripts, alongside what was changed to fix each one.

She is also the person who answers if you use the email or the phone number at the bottom of this page — no sales team in front, no support tier behind. That is a constraint as much as a feature: it is why deployments are configured one business at a time rather than through a self-serve signup.

Every deployment is tested the same way before it goes live: real calls placed to the agent's own number, recorded, and then reviewed against the transcript rather than from memory. The calls are deliberately the awkward ones — a caller correcting an email address halfway through a booking, someone pushing for a price the agent isn't allowed to give, a storm emergency that has to interrupt the booking flow. If the transcript shows the agent doing something a business owner wouldn't accept, that counts as a defect whether or not the call ended in a booking.

Fixes go into the prompt or the tool call, not into a demo script. When a booking silently dropped a caller's confirmed email address, the fix was one prompt instruction plus a regression test pinned to that call's ID, so the same defect can't come back unnoticed.

Then the scenario gets called again. A change isn't finished when the code is edited; it's finished when the same call is placed a second time and the new transcript shows the new behaviour.

The agent does not have to succeed on every call, but it does have to be honest about failing. When a caller asks something the uploaded documents don't cover, it says it doesn't know and offers to take a callback request. When a call needs a person, it says so and captures the name, number and reason — it will not say "putting you through now" into silence.

Emergencies come ahead of the booking flow. In our own testing of a storm call — a tree against a power line — the escalation triggered correctly, but the transfer itself didn't complete in the test environment. What mattered was what the agent did next: it gave the caller the safety instruction to contact the utility company, then took callback details without being asked to. Live transfer is only described as working for a deployment where it has actually been configured and tested.