Insurance ERP with WebRTC Contact Center

Industry

Insurance distribution / agency ops

Type

Multi-tenant ERP + in-app PBX

Role

Architecture + full-stack + telephony

Calling

Asterisk · WebRTC · Twilio / SIP trunks

Stack

Next.js · NestJS · PostgreSQL

Walkthroughs

SuperAdmin 13:56 · Agent 15:06

Insurance teams shouldn’t have to manage leads in one application, quotes in another, and phone calls in a separate PBX. This architecture brings insurance workflows, agency/DSA tenancy, quote questionnaires, CRM, WebRTC calling and contact-center operations into one system. Asterisk is a screen in the ERP — not a second product. This is software, not a licensed insurer.

Lead
 ↓
Insurance Questionnaire
 ↓
Quote
 ↓
Agent
 ↓
WebRTC Call
 ↓
CRM / Policy Workflow
 ↓
Follow-up

Who could use this architecture?

Already have a CRM/PBX? We can also integrate WebRTC, Asterisk, SIP trunks, click-to-call and contact-center workflows into an existing insurance application—see Custom CRM/ERP, WebRTC and Asterisk.

The insurance business problem

Insurance distribution is four jobs that usually sit in four tools:

• A brochure site that takes a quote
• A CRM that stores the lead
• A PBX the agent alt-tabs to
• A spreadsheet for DSA / agency hierarchy and commission

When the phone is a separate app, the supervisor cannot see which policy a live call belongs to. When quotes are not versioned questions, every new product is a frontend rewrite. When tenants are not first-class, a DSA sees another agency’s book.

Before vs after

Website + CRM + Spreadsheet + PBX + WhatsApp
→ Agent switches between systems

Insurance Platform
                   │
    ┌──────────────┼──────────────┐
    ▼              ▼              ▼
   CRM            ERP          Contact Center
    │              │              │
    └──────────────┼──────────────┘
                   ▼
             Agent Workspace

One identity. One lead record. One communication context.

Why integrate contact center directly into insurance ERP?

The strongest differentiator is not “another insurance ERP.” It is: the phone is part of the business application.

Traditional architecture

Insurance CRM ── Lead
Separate PBX ── Phone
Agent juggles: CRM · PBX · Spreadsheet

This architecture

INSURANCE ERP
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
     Leads          Quotes        Policies
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                 Agent Desk
                      │
                WebRTC / SIP
                      │
                   Asterisk
                      │
                 SIP / PSTN

The agent does not leave the lead record to make a call.

Business requirements

One public path: category → questionnaire → quotes → talk to an agent. One SuperAdmin path: tenants, users, categories, providers, aggregators, products, questions, carriers, trunks, DIDs, Asterisk health. One agent path: queue, Dial, softphone, appointments. Scoring of risk stays in questionnaires and rules — the model is not the underwriter of record on this page.

The solution

Next.js for the public site and signed-in consoles. NestJS and PostgreSQL as the documented API and system of record. Asterisk for SIP, peers and CDRs. A browser softphone (SIP.js against Asterisk WebSocket in this lab) so the agent does not leave the ERP. Carriers (Twilio in the form) and SIP trunks are admin objects, not .env folklore.

Roles in the user table from this session: customer, agent, agency_admin, dsa_admin, underwriter, manager, superadmin. Tenants are typed DSA or AGENCY.

See the system in action

Evidence first—two recordings already live as watch pages (one video per URL). This case study is the screenshot map; the demos own VideoObject.

A third recording covers the Agency Admin ERP desk for agency owners.

Agent desk in this capture: work queue with Dial, presence Available, pace/calls/connect still at a baseline (zeros). 555 numbers are demo leads, not published customers.

Insurance contact center use cases

Lead qualification

Incoming leads can be assigned with source, product type, location, agent, agency, DSA, priority and status—then worked from the same queue that dials.

Click-to-call

Agent clicks Dial / Call Customer; the application initiates the WebRTC/SIP call against Asterisk.

Quote follow-up

Quote Generated → Lead Assigned → Agent Notification
  → Click-to-Call → Conversation → Disposition → Follow-up

Renewal campaigns (pattern)

Policies Nearing Renewal → Campaign → Dialer
  → Agent / AI Voice (optional extension) → Renewal Outcome → CRM

Missed-call follow-up (pattern)

Missed Call → CRM Lead → Task / Notification → Agent Callback

Insurance lines of business

Public categories already include Health, Motor, Life, Travel, Property and General. Workflows stay questionnaire-driven rather than hardcoded per product UI.

• Motor — quote collection, vehicle information, renewal, lead follow-up, agent calling
• Health — qualification, plan comparison, quote workflow, agent consultation, renewal
• Life — lead qualification, advisor assignment, appointments, follow-up, CRM history
• Travel — trip information, quote, payment workflow, customer communication
• Property — property questionnaire, quote, agent consultation, document workflow

Multi-tenant insurance CRM architecture

Platform
                       │
          ┌────────────┴────────────┐
          ▼                         ▼
       Agency A                  DSA B
          │                         │
     ┌────┼────┐               ┌────┼────┐
     ▼    ▼    ▼               ▼    ▼    ▼
 Agents Users Leads          Agents Users Leads

Tenant isolation

Each agency/DSA can isolate users, leads, customers, quotes, policies, calls, recordings, campaigns, commissions and reports. This session: four tenants (two DSA, two Agency), all active—lab book, not a published SLA.

DSA & agency commission workflow

Lead → Quote → Policy → Premium → Commission Rule
  → Agency → DSA → Agent → Settlement / Reporting

Commission and hierarchy are why this is not a generic CRM: DSA/agency structure sits beside quotes and calling, not in a side spreadsheet.

Insurance CRM vs insurance ERP

This project combines CRM + ERP + communication infrastructure because insurance distribution requires all three.

Insurance CRM / ERP architecture

The phone is a panel. Quotes are rows. Tenancy is a join, not a hope.

CUSTOMER
                            │
                            ▼
                    Insurance Web App
                     Next.js / PWA
                            │
                            ▼
                       NestJS API
                            │
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
       Identity          Insurance          CRM
       / RBAC            Workflow           / Leads
          │                 │                 │
          └─────────────────┼─────────────────┘
                            ▼
                       PostgreSQL
                            │
                ┌───────────┼───────────┐
                ▼                       ▼
          Aggregator APIs          Call Control
                                        │
                                        ▼
                                  Asterisk / SIP
                                        │
                                  WebRTC / SIP
                                        │
                              Twilio / SIP Trunks

flowchart TB
  Public[Public Next.js quotes]
  Desk[Agent desk queue Dial]
  Admin[SuperAdmin catalog PBX]
  API[NestJS RBAC]
  PG[(PostgreSQL tenants policies)]
  AST[Asterisk SIP CDR]
  Carr[Carriers Twilio SIP]
  Public --> API
  Desk --> API
  Admin --> API
  API --> PG
  API --> AST
  AST --> Carr

Key components

What the public product covers

• Hero — agencies, DSAs, agents and customers; quote + call CTAs. The “500+ / 10,000+ / 1M+” line stays marketing copy on that homepage—not a published outcome here
• Categories — Health, Motor, Life, Travel, Property, General with Get Quote
• Roles — agency (agents, leads, campaigns), DSA (hierarchy, commissions, bulk), agent (softphone, leads, quotes), customer (quotes, policies)
• How it works — questionnaire → instant quotes → connect with agent

Feature cards advertise WebRTC/SIP calling, CRM, AI-powered underwriting questionnaires, campaign dialer analytics, DSA/agency hierarchy and an AI chatbot. This page treats underwriting AI as product copy on that grid—not a published clinical or actuarial model, and not a RAG claim.

SuperAdmin: tenancy, catalog, quotes

Left nav map: Dashboard, Tenants, Users, Categories, Providers, Aggregators, Products, Questions, Rules, Carriers, SIP Trunks, DIDs Marketplace, DID Assignments, PBX Monitoring, Billing & Usage, CMS, Policies, System Logs, Settlements, CDR.

• Seven categories — GENERAL, HEALTH, LIFE, MOTOR, PROPERTY, TECH, TRAVEL (TECH had 0 questions / 0 providers in this session)
• Five providers tagged Health / Life / Motor
• Aggregator form — base URL, client id/secret, webhook secret; capabilities: Catalog Sync, Quote Generation, Policy Binding, Policy Status (secrets not echoed)
• Product create — name, category, optional aggregator, external product code
• Underwriting questions — full name, DOB, property type, address; types text / date / single_choice

Insurance aggregator API integration

Insurance ERP
                         │
                  Aggregator Adapter
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
          Catalog      Quote      Policy
           Sync       Generate     Status
              │          │          │
              └──────────┼──────────┘
                         ▼
                   External APIs

• Credentials are not exposed to the SPA
• Provider-specific adapters and format normalization
• Webhook handling, retries and error normalization
• Status synchronization and audit logging

PBX, carriers and the agent desk

Telephony is not a footer link. SuperAdmin can add a carrier (Twilio in the provider dropdown: voice, SMS, recording, transcription) and a SIP trunk (host, port 5060, UDP, max channels). This page does not reprint account SIDs, auth tokens or passwords.

PBX Monitoring in this capture: Asterisk Connected v1.0, 0 active calls, 7 of 7 peers online, Telnyx backup + Twilio main as registered peers, plus agency/DSA/agent extensions. Those numbers are this session’s book, not a published SLA.

Browser calling architecture (WebRTC)

How WebRTC calling integrates into an insurance CRM: the browser SIP/WebRTC client connects to Asterisk while the application backend owns authentication, tenant context, lead identity and workflows.

Agent Browser
     │
 SIP.js / WebRTC
     │
     ▼
Asterisk WebSocket
     │
     ▼
Asterisk
     │
     ▼
SIP Trunk
     │
     ▼
PSTN

• Browser authentication and SIP registration
• WebSocket signaling; RTP/SRTP media
• STUN/TURN and NAT for corporate agent browsers
• Codec negotiation, transfer, conference
• Recording hooks via carrier/admin configuration
• Agent presence on the same desk as the queue

Why WebRTC matters for insurance agents

• Remote and distributed agency agents
• No physical handset requirement for many desks
• Click-to-call with CRM context
• Easier provisioning and centralized monitoring
• Faster onboarding onto the same product login

Insurance contact center analytics

Agent metrics

Calls attempted, connected calls, connect rate, average handle time (AHT), follow-ups, conversion and disposition—shown on the agent desk (baseline zeros in the lab capture).

Campaign & business metrics (product surface)

• Campaign: leads, calls, answered, unreachable, conversions
• Business: quote-to-call, call-to-quote, quote-to-policy, agent / agency / DSA performance

AI capabilities — honest scope

The marketing grid mentions AI-powered underwriting copy and chatbot. This case study does not claim a published actuarial or underwriting model. Useful extensions when workflows are defined:

• AI Voice — receptionist, renewal calls, lead qualification, appointment booking (see AI Voice)
• Agent assist — suggestions, policy lookup, call summaries
• Call intelligence — transcription, intent, disposition suggestions, QA scoring
• Automation pattern — Call → Transcript → Intent → Lead score → CRM → Workflow → Follow-up

Call → Transcript → Intent → Lead Score → CRM → Workflow → Agent Follow-up

Architecture challenges & how they were solved

• Four user types — customer / agent / DSA / agency / SuperAdmin on one schema with RBAC
• Dynamic questionnaires — new products without a frontend rewrite; questions are data
• Aggregator integration — different provider APIs behind adapters; secrets stay server-side
• PBX inside ERP — call state stays connected to lead identity
• Multi-tenancy — Agency A must never see Agency B’s data
• Browser telephony — NAT, WebRTC and SIP coexist with business workflows
• Honest marketing — landing metrics vs what admin actually contains in a lab session

Tenants and roles are tables. Categories own questions and providers. Products can point at an aggregator code. Carriers and trunks are admin forms. The agent queue Dial button is the same identity as the Asterisk peer list. The model is not the owner of hangup or of a bind.

Technology decisions

My role

• Solution architecture — system design, multi-tenancy, integration boundaries, telephony plane
• Backend — NestJS, PostgreSQL, APIs, RBAC, workflows
• Frontend — Next.js public site, agent desktop, admin console
• Telephony — Asterisk, SIP, WebRTC / SIP.js, carrier integration
• Product engineering — requirements through deployment and troubleshooting

Technology stack

NestJS and PostgreSQL are the documented backend. Twilio and Telnyx appear as carrier/peer labels in this capture. This page does not invent a RAG stack that was not on these screens.

Production considerations

• WebRTC and click-to-dial share lead id with ERP quotes
• Agency tenancy on policies, users and recordings
• STUN/TURN for corporate agent browsers
• Correlate PBX, API, database and browser failures in ops

Engineering outcomes

No invented conversion rates. What this system actually established:

• A public quote path beside a SuperAdmin that can change categories, questions and providers
• DSA vs Agency tenants with role-scoped users
• Aggregator capabilities as an admin contract (sync, quote, bind, status)
• Asterisk visible inside the same product as policies and CMS
• An agent queue that dials without leaving the ERP
• Two watch-page recordings for SuperAdmin and the agent desk

Screenshots & evidence

Related writing: Why I designed an Insurance ERP as a multi-tenant operating system · Why most insurance CRMs get telephony wrong.

Architectural insight

An insurance CRM that “has calling” is still two products if hangup and quote live in different databases. If PostgreSQL owns the lead and Asterisk is a screen that shares that user, you have one operating system.

Disclaimer: Insurance ERP is software for distribution and operations. It is not an insurance company, not IRDAI-licensed advice, and not a promise that a quote on the demo binds a live policy. Twilio, Telnyx and Asterisk are described as they appear in this admin configuration.

Related work & services

• Insurance ERP product page — configure / request path
• VoIP CRM & predictive dialer — CRM+telephony sibling
• Multi-Tenant CCaaS — contact-center platform proof
• Telecom manufacturing ERP — custom CRM/ERP ops
• Custom CRM & ERP · Full-Stack · Contact Center · SaaS · VoIP · Multi-Tenant PBX · AI Voice