Enterprise architecture

How VoxDesk becomes an operational system

VoxDesk is organized around one canonical Conversation record. A customer can arrive through simulation, Web Voice, or telephony; every authorized action and outcome converges on the same domain model for CRM, reporting, and recovery.

The four-layer boundary model

Channels

Web Voice, simulated sessions, inbound PSTN, outbound campaigns.

Orchestration

Authenticated session, policy checks, tool authorization, idempotency.

Canonical domain

Conversation is the source of truth; calls project into it.

Controls

Tenant isolation, secrets, leases, webhooks, audit events, recovery.

Request-to-CRM pipeline

Each boundary has an explicit owner and failure mode.

Simulation-safe default

Customer

Channel

Policy gate

Conversation

Authorized tool

CRM projection

Evaluation

sequenceDiagram
  participant C as Customer
  participant V as VoxDesk
  participant P as Provider or Simulation
  participant D as Conversation domain
  participant CRM as CRM projections
  C->>V: authenticated session
  V->>P: provider/session request
  P-->>V: transcript and events
  V->>D: idempotent upsert
  D->>CRM: contact, lead, opportunity, task
  CRM-->>V: durable outcome

Provider responsibilities

ElevenLabs: Speech/conversation runtime and authoritative provider transcript after completion.
Telnyx: PSTN transport, numbers, carrier events, and controlled call initiation.
VoxDesk: Authorization, policy, persistence, reconciliation, CRM actions, and tenant isolation.

Failure containment

Before a call: missing secrets or an unverified agent fail closed.
During a call: tool authorization and idempotency keys bound side effects.
After a call: provider events reconcile into one conversation.
During outages: durable events and retryable jobs preserve recovery context.

Explore the CRM model