The voicebot is the easy part. The control plane is the product.

Voice automation platforms ship the agent and ship the API. The thing in between — the company-level configuration, the live operational view, the role separation between super-admin and tenant-admin, the moment-by-moment KPI an ops team needs to know whether the bots are working — is left to the customer to build, badly. That gap is the product opportunity we filled with Voxplane.

Voice agents are commodified. Pick a vendor — Vapi, Retell, Bland, Synthflow, half a dozen others — and the underlying capability is roughly equivalent. Connect to a phone number, run a model, transcribe both sides, do something useful with the output. That's table stakes.

What's not commodified is the operational layer. Multi-tenant boundaries between super-admin and tenant-admin. Role-aware UI. A live call view someone can actually use. KPIs an ops manager reads at 9 a.m. and acts on by 9:05. A way to deploy agent configurations without pushing JSON to a git repo.

That layer is the product, and almost nobody ships it.

Why teams skip it

Operational layers are unglamorous. The demo at the conference is the voice agent answering a customer call beautifully. The screenshot in the deck is the streaming transcript. Nobody asks to see the company-admin onboarding flow.

So teams build the agent first, the demo first, the marketing site first — and then look up six months later when their tenth customer is running production voice ops on a single-tenant admin tool with a session cookie that doesn't expire. Which, to be clear, is a perfectly fine architecture for a five-engineer startup serving one customer. It is not fine for the customer base that lifted the demo into a contract.

The gap between "voice agent works" and "voice product is operable" is what Voxplane fills.

Three scopes from day one

Voxplane models three tenant scopes — super-admin, company-admin, user — from the first commit. Not because we needed all three on day one. Because retrofitting tenancy is the most painful architectural migration a SaaS team can do, and we wanted to never have that conversation.

Each scope has its own routes, its own dashboard, its own server-enforced permissions. A super-admin sees the platform-level concerns: customer tenants, billing posture, system health. A company-admin sees their own agents, team members, and configuration. A user runs day-to-day operations.

On the client side, two wrapper components — `SuperAdminRoute` and `CompanyRoute` — guard the protected screens. They run the role check, redirect on miss, and crucially short-circuit any nested data fetching until the role is confirmed. No screen ever flashes wrong content before the auth resolves. That detail matters more than it sounds.

The Axios interceptor that ended a class of bug

We routed every API call through a single Axios interceptor. It attaches the Bearer token on request, watches for 401 on response, and triggers an auto-logout if the token has expired. There is one place in the codebase that knows about tokens. That place is `src/api/apiClient.ts`. Nothing else.

The class of bug this kills is the zombie session. Customer leaves a laptop open overnight. Token expires at 3 a.m. Next morning, the user clicks a button, gets a silent failure, doesn't realize they're effectively unauthenticated, files a support ticket about "the dashboard not updating." With the interceptor in place, the expired token triggers a logout the next time the user touches anything. They see a login screen. They log in. The session is real again.

Small piece of infrastructure. Eliminates a whole genus of support tickets.

Live calls as a first-class surface

The most-used screen in Voxplane is the live call panel. Streaming transcript on the left, sentiment and intent indicators in the middle, transfer and reassign actions on the right. An ops person can listen in real-time, intervene if needed, hand the call off without dropping the customer.

This is not a feature. It is the operational primitive of voice ops. Without it, the ops team is debugging voice by listening to recordings the next day. With it, they're running ops in real time. The difference is whether the voice product is operable, which is the difference between a working customer and a churned one.

What we'd start with on day one

Multi-tenant scopes from the first commit, not as a retrofit. Route guards that short-circuit data fetching, not just redirects. A single Axios interceptor as the only token-aware code. A live call surface as the primary screen, not an afterthought.

And — if you're building a voice product without a control plane, you're shipping a demo, not a product. The customer will discover this. You can either build the control plane now or watch the customer churn while you build it.

The voicebot is the easy part. The control plane is the product.

Voxplane is in active operation. We can scope an operational layer for any voice-automation product that's outgrown its single-tenant admin tool.