Building a Multi-Tenant AI CRM and Business Automation Platform

Product class

Multi-tenant AI CRM + automation SaaS

Personas

Platform super-admin · tenant admin · staff (/staff role KPIs)

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

Data plane

PostgreSQL migrations 001–022 · Redis · RabbitMQ · S3-compatible object storage (MinIO locally)

Verification

go test ./tests/... · scripts/smoke-crud.sh · scripts/smoke-voice.sh (when API + voice up)

Working-system video

Walkthrough of the EAIBAP RevOps workspace — CRM, workflows, AI agents and platform surfaces on the Go + PostgreSQL stack. Same recording is on the product page.

Watch on YouTube → · Duration 9:15 · Dedicated demo page →

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, role-scoped dashboards (GET /analytics/role-dashboard), tenant production-readiness card, platform console + controlled production route, ESL smoke path—see status matrix and fourteen UI captures 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)

When EAIBAP fits (vs other SKUs on this site)

Documentation authority (beyond UI)

The product is governed by EAIBAP-SCOPE-001 (enterprise_ai_automation_platform_full_scope.md). The engineering workspace (solvedRevOps) holds the living doc set delivered on scoped engagements; this page summarizes what those docs contain.

Architecture & data

• ARCHITECTURE.md · ARCHITECTURE_MAP.md — components, deployables, request flows, UI ↔ API ↔ pkg/*
• DOMAIN_MODEL.md · ENTITY_RELATIONS.md · DATABASE.md — entities, FK lookups, schemas migrations 001–022
• EVENT_CATALOG.md — outbox / domain events (§10 / §15)

Scope crosswalks (implementation status vs spec)

• DATA_ARCHITECTURE_SCOPE_MAP.md — §9 tables, APIs, UI
• DATA_FLOW_SCOPE_MAP.md — §10 DF-1…DF-8
• TELEPHONY_SCOPE_MAP.md — §11 voice, ESL, dialplan, trace APIs
• SECURITY_SCOPE_MAP.md — §12 posture, isolation, incidents
• FUNCTIONAL_SCOPE.md — §5 requirements; live matrix in pkg/scope/catalog.go

Design, API, delivery

• PRODUCT_REQUIREMENTS.md — TEN-, IAM-, CRM-, VOICE-, … IDs and release phase
• VOICE_TELEPHONY_DESIGN.md · WORKFLOW_ENGINE_SPEC.md
• AI_GOVERNANCE.md · DATA_GOVERNANCE.md · SECURITY_THREAT_MODEL.md
• API_CONTRACTS.md + openapi/openapi.yaml (partial; grows with APIs)
• GAP_ANALYSIS.md · IMPLEMENTATION_SLICES.md · ENTERPRISE_UI.md
• RUN_LOCAL.md · DEPLOYMENT.md · SRE_RUNBOOKS/ · TEST_STRATEGY.md · ADR/
• INDUSTRY_PACKS/ (insurance, banking, outreach) — versioned modules, not core CRM forks

Requirement status in code: Planned → In Progress → Implemented → Verified → Production Ready. §5 functional items are exposed via GET /api/v1/tenant/functional-scope (and platform twin) — most P0 rows are still partial or missing; the matrix is for planning, not compliance attestation.

System architecture

Modular monolith in Go (Gin); PostgreSQL schemas per domain (iam, crm, comm, …); async work via RabbitMQ (apps/worker, apps/scheduler). The Vue 3 SPA uses HTTPS + Bearer JWT. Voice is isolated in apps/voice-orchestrator (ESL to FreeSWITCH, port 8090, not public). Redis backs session/cache paths; recordings and artifacts use S3-compatible storage (MinIO in local mode).

Design rules (§8.4): no sync network I/O inside DB transactions; outbox for reliable events (wf.outbox_messages, pkg/events); idempotent ingest; voice path async-persists to CRM; integration secrets by reference; API security headers on all responses.

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]
    S3[Object_storage]
  end
  Web -->|REST| API
  API --> PG
  API --> Redis
  API --> Voice
  Voice -->|ESL| FS
  Voice --> PG
  Worker --> PG
  Worker --> MQ
  FS -->|dialplan_curl_inbound| Voice
  Ext -->|POST_integrations_inbound| API
        

Scope-aligned UI routes (spec hubs)

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 — Dialplan curl to voice-orchestrator (/calls/inbound, optional VOICE_WEBHOOK_SECRET); orchestrator returns quickly; STT/LLM runs async; ESL CHANNEL_* updates comm.call_sessions; trace via GET /call-sessions/:id/trace.
• Integration webhook — POST /api/v1/integrations/inbound/:provider with dedupe on (tenant_id, provider, provider_event_id); worker relay for outbound delivery.

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)

Documented under INDUSTRY_PACKS/ — insurance, banking/collections, cross-industry outreach (ext_outreach ICP profiles). Packs are versioned modules, not tenant if branches in pkg/crm.

§5 functional scope (honest)

Full §5.1–5.16 requirements live in EAIBAP-SCOPE-001. Implementation tracking is in pkg/scope/catalog.go with statuses implemented | partial | missing. Tenant admins and platform ops can browse coverage at /functional-scope (role-filtered). Most §5 P0 items remain partial or missing — use the matrix in discovery, not as a certification.

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 — modules wired in repo

From GAP_ANALYSIS.md: full CRUD wireup + enterprise UI shell + FreeSWITCH ESL path. Production gates still include streaming STT/TTS, full RAG ingestion, enterprise OIDC SSO, Vue Flow as workflow source of truth, TanStack Table pagination UI, HttpOnly cookies, and Storybook/axe CI (see IMPLEMENTATION_SLICES.md deferred list). Screenshots ≠ 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 the local demo stack (demo / owner@demo.local). Regenerate with cd web && npm run capture-usecase-screenshots; Playwright smoke: npm run test:e2e. KPIs are layout proof—not customer production metrics.

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.