Multi-Tenant AI Receptionist & Voice Operations Platform

Industry

Home services · clinics · appointment-driven desks

Type

Multi-tenant AI receptionist SaaS

Use cases

Inbound capture · callbacks · voice workflows

Roles

Platform admin · tenant owner · staff

Stack

Vue 3 · FastAPI · PostgreSQL · ESL

Honest split

SaaS control plane · not the PBX media engine

Working-system video

The recording is the live portal — tenant workspaces, agents, leads and platform administration. Same product surfaced on the AI receptionist product page.

Watch on YouTube → · Duration 5:54 · Dedicated demo page →

Owner overview from the live portal (Growth Plumbing tenant). KPI tiles and activity rows are product chrome on that host — not a published SLA, recovered-job count or uptime figure.

The business problem

Missed calls often mean lost jobs, delayed callbacks and incomplete customer records. Traditional voicemail does not classify urgency, capture structured requirements or give staff a reliable follow-up queue.

The van is on a job, two calls arrive at once, lunch and after-hours go to voicemail, notes live on paper, and the owner reconstructs the day at 10pm. The next plumber or clinic gets the work.

The platform is designed to connect the first customer conversation to the next business action: capture the inquiry, create a lead, request a callback, coordinate an appointment or escalate the call according to configured rules.

Platform capabilities

Business use cases: home services, clinics, appointment-driven businesses, multi-location service organizations, and teams building an AI receptionist SaaS in front of a PBX they already run.

Visual workflow builder

Operators configure conversation paths in the tenant agent workspace: a Vue Flow canvas (with a simple-list fallback), graph validation, publish, version rollback, test-lab runs and voice preview. Implemented node types are start, speak, collect, condition, action, knowledge, fallback and end. Action types include create lead, transfer, book, notify staff and end call. Conditions can branch on intent, caller input, phone presence, emergency flags and business hours.

Screenshots captured from the live ZenTech portal host (October 2026), not generated mockups. They show configuration UI; they are not proof of live graph execution on an inbound call.

flowchart LR
  Start[start] --> Speak[speak]
  Speak --> Collect[collect]
  Collect --> Cond{condition}
  Cond -->|emergency| Notify[notify_staff]
  Cond -->|quote| Lead[create_lead]
  Cond -->|closed hours| Fallback[fallback]
  Notify --> End[end]
  Lead --> End
  Fallback --> End

How a call becomes a business action

1. A customer calls the business’s existing phone number.
2. The configured telephony route directs the call to the appropriate handling path.
3. The receptionist workflow gathers the caller’s intent and relevant information.
4. Configured AI and business logic determine the next permitted action.
5. The system records the call outcome and creates or updates the relevant business record.
6. The owner or staff member reviews the inquiry and follows up from the workspace.

The exact path depends on the tenant’s configuration, available integrations and the capabilities enabled for that deployment.

flowchart TD
  Ring[Inbound DID on existing PBX] --> Route[FreeSWITCH / FusionPBX route]
  Route --> ESL[ESL park / handling path]
  ESL --> WF[Receptionist workflow]
  WF --> Logic[Configured AI and business rules]
  Logic --> Rec[Call outcome record]
  Rec --> Job[Lead, callback, booking or escalation]
  Job --> Owner[Owner Vue workspace]
  Job --> Staff[Staff follow-up list]

Platform architecture

Face, API, adapters. Isolation is an auth and row rule, not a shared spreadsheet with a company column.

flowchart TB
  Portal[Vue 3 owner / staff / platform admin]
  API[FastAPI JWT tenants workflows records]
  DB[(PostgreSQL SaaS tables)]
  FS[FreeSWITCH / FusionPBX ESL]
  AI[AI and speech provider adapters]
  Portal --> API
  API --> DB
  FS --> API
  API --> AI

An Asterisk ARI adapter and webhook still exist for development and legacy paths. Do not read this page as “we ripped Asterisk out of the source tree.” Read it as: the live telephony contract for this product is ESL + Fusion CDR, with the PBX you already have.

Platform administration and operational visibility

The control plane is designed to support the operational responsibilities of a multi-customer voice platform:

• Create and manage customer tenants and user access.
• Assign plans and review usage and cost allocation.
• Configure AI providers and telephony connections.
• Register PBX instances and test connectivity.
• Review application health, provider status and operational incidents.
• Inspect audit events associated with important administrative changes.
• Manage access policies and monitor security-related configuration.

The depth of each control depends on the implemented integration and the deployment’s current capabilities. Usage reporting is not billing collection. Health indicators should reflect real probes rather than manually entered status values.

Platform overview from the live admin workspace. Usage and margin tiles reflect that host’s data — not a published finance or uptime claim.

Tenant list: onboard a company, assign a plan, pause if they stop paying or go on holiday, compare call volume and cost. A plumber does not use this screen every day. A franchise, MSP or SaaS operator does. Later admin screens — PBX registry, security policy, live-call board — exist in the product and are not shown in this older capture.

Owner and staff — same shop, different keys

The owner’s question: “What happened on the phones while I was on a job?” The staff question: “What do I call back this morning?”

Owners add a coordinator, change a role, or disable access when someone leaves. You should not share one office-PC password. Evaluation names stay on the glass; they are not listed here as credentials.

Staff home looks like the owner’s home on purpose — they still need calls, leads and bookings. Look at the left menu: there is no Users item. They cannot open head-office screens. If they try, the API sends them back to their own shop.

A different business, the same product

City Clinic in this evaluation wants follow-up appointments, not leak emergencies. Latest call is booked, not escalated. Whose data? Only the clinic. Growth Plumbing never sees patient bookings. That is how you run many businesses on one platform and still stay professional. Isolation is enforced at login and API first; PostgreSQL row-level security exists as optional SQL, not as the default fleet guarantee.

Lead management lifecycle

Call outcomes become structured leads with caller details, service requirements, urgency, assignment and status. Status is not a free-form PATCH: the portal uses an explicit transition API and records history.

Supported statuses: new → qualified → assigned → contact_attempted → contacted → booking_pending → converted. Terminal states are converted, closed and lost. closed and lost may move to reopened. converted has no outbound transition.

flowchart LR
  N[new] --> Q[qualified]
  N --> A[assigned]
  Q --> A
  A --> CA[contact_attempted]
  CA --> C[contacted]
  C --> B[booking_pending]
  B --> V[converted]
  C --> X[closed / lost]
  X --> R[reopened]

Production readiness

Engineering focus now is end-to-end workflow execution, reliable call-to-lead processing, explicit lead lifecycle transitions, PBX adapter consistency, tenant isolation and operational observability.

Production readiness requires validating real calls, AI provider behavior, fallback paths, persistent records, access boundaries and recovery procedures — not just a successful portal demonstration.

Local evaluation can still run without live phone or AI keys (mock providers and seed data). That is useful for a portal review. It is not evidence that a given host is answering real callers with a published graph.

My role

Architecture + Vue portal + FastAPI SaaS plane + FreeSWITCH/FusionPBX ESL adapter wiring, with JWT/RBAC tenancy and provider interfaces. Evaluation logins and live provider secrets stay off this page.

Architecture Vue 3 FastAPI PostgreSQL ESL JWT / RBAC

What this system established

No invented faster-percent claims. What is actually on the glass and in the APIs:

• A signed-in portal for platform operators, tenant owners and tenant staff
• Two isolated evaluation workspaces — field service vs clinic — on the same product
• Owner can manage team access; staff cannot
• Calls written up as leads, bookings or escalations instead of a voicemail pile
• A visual conversation graph with validation and publish, distinct from live call execution
• Provider adapters so evaluation does not require live AI or phone keys
• A clear split from the Asterisk RTP turn-engine case

What “good” looks like after a pilot is the team opening this website instead of reconstructing the day from voicemail. Exact recovered-job counts depend on your volume, scripts and how fast people work the list.

Architectural insight

If the voice agent answers and the office still has no queue, you built a talking voicemail. If two companies share a login, you built a leak. The receptionist product is the tenant OS — roles, isolation, the morning list and the workflow graph — with the PBX and the model as adapters behind it.

Related: Asterisk voice AI (RTP turn engine), production AI voice agent, and AI call center when the buyer is a seat-selling CCaaS, not a two-van shop.

Project engagement

This architecture is relevant to teams building AI receptionist products, vertical voice automation, multi-tenant communication SaaS or integrations between an existing PBX and a business application.

Engagements can begin with an architecture review, a telephony integration assessment, a workflow prototype or a staged implementation.

Discuss your AI receptionist or voice automation project

FAQ — buyer and architecture questions

Ten questions about this case, the PBX split, and how an engagement starts.