Building a Multi-Tenant AI CRM and Business Automation Platform

Product class

Multi-tenant AI CRM + automation SaaS

Personas

Platform admin · tenant admin · staff

Scope authority

EAIBAP-SCOPE-001 (baseline blueprint)

Voice

FreeSWITCH ESL · call sessions in product DB

Honest limit

Not a generic “AI replaces your CRM” claim — modules are scoped and verified per release

Business problem → engineering approach

1. Business problem: revenue and operations teams lose traceability when CRM, dialers, campaigns and AI pilots are separate products with ad-hoc integrations.
2. Engineering response: a modular monolith (Go API + PostgreSQL domain schemas) with session-bound tenancy, integration hub, workflow engine and optional voice-orchestrator beside FreeSWITCH—not replacing the media switch.
3. Verified capabilities: IAM/tenant paths, CRM + leads APIs, integration webhooks, workflow/campaign CRUD, AI agent lifecycle UI, ESL smoke path—see status matrix below.
4. Remaining gaps: streaming STT/TTS at scale, full RAG ingestion, enterprise OIDC SSO—tracked per requirement ID until Verified / Production Ready.
5. Delivery roadmap: phased acceptance (discovery → foundation → workflows → AI/voice → production readiness) aligned to modules selected on the product page.

The problem (technical framing)

Revenue teams run CRM, dialers, campaigns and AI experiments in separate tools. Integrations are one-offs; tenant isolation, consent and audit trails are inconsistent. Voice is often bolted on without shared call-session state in the product database.

EAIBAP targets a modular monolith: one PostgreSQL system of record, persona-specific Vue 3 surfaces, and a voice orchestrator that does not pretend to be the PBX.

Seven product pillars

• AI CRM and work management (accounts, opportunities, cases, tasks)
• Voice and conversational AI (agents, orchestration, handoff)
• Lead generation and engagement (imports, consent, routing)
• Workflow and process automation (graph designer, runs)
• AI knowledge and assistance (tenant-scoped RAG)
• Integration hub (connections, mappings, webhooks)
• Analytics and governance (audit, metering hooks)

Documentation authority (beyond UI)

The product is governed by EAIBAP-SCOPE-001 (full scope blueprint). Engineering docs in the solvedRevOps repository describe architecture, APIs, and delivery gates — the public site summarizes them; a scoped engagement includes the living doc set.

• ARCHITECTURE.md — system context, components, migrations, request flows
• DOMAIN_MODEL.md — entities and state machines (leads, workflows, campaigns, tenants)
• PRODUCT_REQUIREMENTS.md — requirement IDs (TEN-, IAM-, CRM-, VOICE-, …) with priority and release phase
• VOICE_TELEPHONY_DESIGN.md — SIP → FreeSWITCH → ESL → orchestrator; degradation paths
• GAP_ANALYSIS.md — what is wired in code vs still production-hardening
• API_CONTRACTS.md + OpenAPI — REST surface for Vue UI and integrations
• DEPLOYMENT.md, RUN_LOCAL.md, SRE runbooks — operability

Capabilities are not “done” because a screen exists — each requirement carries status: Planned → In Progress → Implemented → Verified → Production Ready.

System architecture

Modular monolith in Go (Gin); PostgreSQL schemas per domain; async work via RabbitMQ workers and scheduler. The Vue 3 SPA talks HTTPS + Bearer JWT to the API. Voice is isolated in apps/voice-orchestrator (ESL to FreeSWITCH, internal port).

flowchart TB
  subgraph clients [Clients]
    Web[Vue3_Web_UI]
    FS[FreeSWITCH]
    Ext[External_webhooks]
  end
  subgraph eaibap [EAIBAP]
    API[apps_api_8080]
    Voice[voice_orchestrator_8090]
    Worker[worker]
    Sched[scheduler]
  end
  subgraph data [Data]
    PG[(PostgreSQL)]
    Redis[(Redis)]
    MQ[RabbitMQ]
  end
  Web -->|REST| API
  API --> PG
  API --> Voice
  Voice -->|ESL| FS
  Voice --> PG
  Worker --> PG
  Worker --> MQ
  Ext -->|integrations_inbound| API
        

Logical modules

Deployable processes

Key request flows

• Sign-in — POST /api/v1/auth/login → IAM session → Bearer token for all tenant APIs.
• CRM — Handlers enforce crm.record.* permissions; every row carries tenant_id from session (not a trusted client header).
• Outbound test call — UI → API → voice orchestrator → ESL originate → comm.call_sessions.
• Inbound — FreeSWITCH dialplan → HTTP callback to orchestrator → session state + ESL CHANNEL_* updates.
• Integration webhook — POST /integrations/inbound/:provider with dedupe on provider event ID.

Domain lifecycles (examples)

• Lead: new → validating → qualified → assigned → working → converted / closed
• Workflow run: queued → running → waiting_approval → succeeded / failed / dead_letter
• AI agent version: draft → validated → published → deprecated
• Campaign: draft → scheduled → running → paused / completed
• Tenant: provisioning → active → suspended → closed

Voice and telephony

Media path: SIP → FreeSWITCH → ESL adapter → voice-orchestrator → STT/LLM/TTS adapters → tool layer → async persist to CRM, audit, billing. Real-time loop avoids blocking DB or long LLM calls on the media thread. ESL is not exposed publicly; recording/transcript access uses separate permissions (COM-008).

Degradation examples: STT failure → DTMF/transfer; LLM failure → fallback model or scripted response; object storage failure → disable new recordings only.

Industry packs (scope)

Insurance, banking/collections, cross-industry outreach, and general business operations packs are versioned modules — not hard-coded tenant conditionals in core CRM.

Implementation status matrix

Statuses are engineering gates—not marketing labels. “Implemented” means wired in codebase; “Verified” means agreed test evidence; “Production Ready” means operational checklist for your environment.

Gap analysis summary

From repo GAP_ANALYSIS.md: streaming speech at scale, full RAG ingestion, enterprise OIDC SSO and many requirement IDs remain Planned until verified. UI screenshots do not imply Production Ready.

Explicit non-goals (initial core)

Not a core banking system, policy admin, universal ERP replacement, or autonomous approver for regulated credit/claims decisions. Platform features do not by themselves prove legal compliance — customer policy and jurisdiction still apply.

Screenshots (running UI)

Captured from local demo stack — regenerate from the EAIBAP web app when UI changes.

FAQ — buyer & architecture questions

Ten questions teams ask when evaluating custom AI CRM and automation platforms — phrased the way procurement and engineering search.

Related offers

• Home
• Content cluster hub — industry pages & implementation guides
• EAIBAP product page & scope estimator
• VoIP CRM & power dialer (dialer-centric CCaaS)
• FreeSWITCH CCaaS case study
• Multi-tenant AI receptionist (narrower FastAPI SKU)
• SaaS development services
• Custom CRM & ERP development
• AI workflow automation · AI call center
• All projects · All products

Compliance (GDPR/HIPAA) and industry packs require explicit customer policy and jurisdiction — the scope document defines posture; legal sign-off remains the customer’s process.