Pacific Specialty Insurance — Gen AI-Powered Call Categorization & Root Cause Analysis

Customer Case Study · Amazon Connect · Gen AI

Insurance · Contact Centre

Amazon Bedrock · AWS Connect SDP

Live Deployment

Pacific Specialty Insurance Company · California, USA · Est. 1976

Pacific Specialty Insurance processes over 30,000 customer calls every month through Amazon Connect. Every call was manually listened to, categorized, and logged — a process so error-prone and slow that leadership had no idea what was actually driving customer contacts. P3Fusion replaced the entire workflow with an LLM-powered post-call analysis pipeline, delivering richer categorization, root cause identification, and QuickSight dashboards — all from the call transcript alone, with zero disruption to existing call centre operations.

LLM Multi-Label Categorization

RAG Reasoning Layer

Amazon Bedrock Flows

Amazon Connect · Transcribe · Athena

Root Cause Analysis

QuickSight Dashboards

Zero Disruption Deployment

Outcomes

Monthly call volume: 30,000 calls · Input source: Call transcripts only · LLM platform: Amazon Bedrock · Orchestration: Bedrock Flows · Ops disruption: Zero

Case Study Summary

Pacific Specialty Insurance (PSIC), a California-based insurance provider handling home, motorcycle, watercraft, and specialty coverage, operates a high-volume Amazon Connect contact centre. With 30,000 calls per month and no automated way to understand why customers were calling, the operations team was flying blind. P3Fusion designed and deployed a Gen AI post-call analysis engine that consumes only the call transcript, runs each conversation through an LLM reasoning pipeline powered by Amazon Bedrock Flows, extracts rich business-specific categories and subcategories, identifies the root cause, generates a summary, and recommends system improvements — then stores everything in a structured database feeding live QuickSight dashboards. The only input is a transcript. The output is business intelligence.

01The Challenge

30,000 Calls Per Month. Zero Visibility Into Why Customers Were Calling.

Pacific Specialty Insurance had migrated to Amazon Connect and gained a scalable cloud infrastructure, but the process for understanding what those calls meant had not evolved. Agents and analysts were manually listening to recordings, assigning categories from a limited two-category taxonomy, and logging results by hand. At 30,000 calls per month, this was not just inefficient — it was structurally incapable of producing the insight the business needed.

🎧

Manual Listening at Scale

Agents spent hours listening to recordings and manually assigning categories. At 30,000 calls per month, meaningful coverage was impossible. Most calls went uncategorized or were assigned the first available label regardless of accuracy.

Error-prone + incomplete

🏷

Only Two Categories

The existing taxonomy had just two broad categories — far too coarse to reveal any actionable signal. The real question — which specific issue is driving the most repeat contacts this month? — was simply unanswerable with the existing process.

No business specificity

🔁

Repeat Callers Unidentified

Because root causes were never captured, the same underlying issues recurred month after month. Customers called multiple times about the same unresolved problem. Leadership had no mechanism to identify which issues were driving repeat contacts.

Repeat contact rate rising

📊

No Real-Time Insight

Because categorization was manual and weeks behind, business leaders could never see what was happening now. They were always reacting to last month's patterns. Data-driven decisions were effectively impossible — the data simply wasn't there.

Always reactive, never proactive

"We knew thousands of customers were calling us every month. We had no idea what they actually needed — or which problems were sending the same customers back again and again."

— Pacific Specialty Insurance Operations Team

02The Architecture

One Input: The Call Transcript. Eight Layers of Intelligence.

P3Fusion designed the solution around a single constraint: it could not touch existing Amazon Connect call flows. All agent workflows, call routing, IVR menus, and contact handling remained exactly as they were. The Post-Call Analysis Engine taps in after a call ends — consuming only what Amazon Transcribe had already produced — and builds a complete intelligence layer on top.

// Post-Call AI Pipeline · 8-Stage Architecture · Zero Disruption to Connect● Production · PSIC

Amazon Connect + Transcribe

Call Ingestion — Existing Infrastructure, Zero Changes

Amazon Connect handles all inbound calls as before, generating event metadata and audio recordings. Amazon Transcribe converts each call's audio to a timestamped text transcript automatically. No changes were made to any Connect flow, IVR, or agent configuration. The AI pipeline is purely additive — it listens to what already exists.

Amazon ConnectAmazon TranscribeZero ops disruption

Amazon S3

Central Data Lake — All Transcripts Stored and Queryable

All call transcripts, contact metadata (Contact ID, agent ID, timestamp, queue name), and event records are stored in Amazon S3 as the system's single source of truth. S3 serves as the durable, scalable foundation for all downstream processing — nothing is processed until it is safely persisted here.

Amazon S3Contact metadataTranscript storage

Amazon Athena

Transcript Retrieval — Serverless SQL Over S3

Amazon Athena enables serverless SQL queries directly over the S3 data lake. The pipeline queries transcripts by Contact ID, date range, agent, or queue — filtering only the calls relevant to the current processing batch. No data movement is required. This is how the system fetches individual transcripts for on-demand analysis or pulls batches for overnight processing runs.

Amazon AthenaSQL over S3Contact ID lookupBatch filtering

Amazon Bedrock Flows + Lambda

LLM Analysis Engine — Multi-Label Categorization with RAG Reasoning

This is the core intelligence layer. Each transcript is passed to an orchestrated Amazon Bedrock Flow that runs a multi-stage LLM pipeline. Unlike the previous two-category manual taxonomy, the LLM generates business-specific categories and subcategories — the kind of granular labels that reveal real operational patterns. The flow is stateless, invoked via the Bedrock Agent Runtime API, and receives both the call transcript and the existing set of known call drivers as context — enabling RAG-style reasoning where the model matches new calls against established patterns before proposing new classifications. The full Bedrock Flow is invoked via a FastAPI service running on AWS Lambda.

Amazon Bedrock FlowsBedrock Agent RuntimeMulti-label LLM categorizationRAG reasoning against call driversAWS Lambda · FastAPI

LLM Output Schema

Structured LLM Outputs — Five Fields Per Call

For every call, the LLM returns five structured fields: Category (the primary classification), Sub-Category (the specific issue within that category), Primary Call Driver (the root cause of the contact), Summary (a concise plain-language description of what happened), and System Improvement (a recommended action to prevent similar future calls). These five fields are extracted from the Bedrock response and validated before storage.

Category + Sub-CategoryRoot cause identificationAI-generated summarySystem improvement recommendation

Amazon RDS (MySQL)

Structured Storage — All Outputs Written to Relational Database

The structured LLM output is written to a relational MySQL database on Amazon RDS with a normalised schema: calls, categories, sub_categories, and call_drivers. The system auto-creates category and driver records as new classifications emerge — so the taxonomy grows organically from what customers are actually saying, not from what someone pre-supposed they might say. Idempotency is enforced: if a call has already been analyzed, the stored result is returned immediately without re-invoking Bedrock.

Amazon RDS MySQLAuto-growing taxonomyIdempotent processingNormalised schema

Amazon QuickSight

Real-Time Dashboards — Business Intelligence for Leadership

QuickSight connects directly to the RDS database, generating live dashboards that show call category distributions, root cause trend lines, repeat-contact patterns, and agent-level insights. Business analysts see what is happening now — not what happened last month. Leaders can drill from a top-level trend ("billing inquiries up 22% this week") to specific root causes ("automated payment portal timeout") to recommended actions — all within the same dashboard.

Amazon QuickSightReal-time trendsCategory distributionRoot cause drill-down

FastAPI REST API

Analysis API — On-Demand and Batch Processing Endpoints

A FastAPI service exposes three endpoints: analyze by contact ID (fetches transcript from Athena, runs Bedrock analysis, returns results — or returns cached result if already processed), analyze raw transcript (direct text input for real-time use cases), and batch analysis (asynchronous background processing of all unanalyzed calls). Basic authentication, structured logging with daily log rotation, and full error handling are included.

FastAPIContact ID lookupAsync batch processingResult caching

03LLM Output

What the LLM Extracts From Every Single Call.

Before this system, a call would be manually assigned to one of two broad buckets — often incorrectly, always slowly. After, every call produces five structured fields generated by reasoning over the full transcript. The example below shows a real-world type of interaction the system handles: a billing dispute where the customer's underlying issue is confusion about a policy change they were never notified about.

Bedrock Flow Analysis · Contact ID: PSI-20240315-48291 · POST /api/v1/analyze/contact-id

● Analysed

// Call Transcript (input)

"Hi, I'm calling because I just got my renewal notice and my premium went up by almost $200 and no one told me about this. I have the same policy I've always had. I didn't change anything. The website said the new rate was because of a coverage addition but I never asked for that… I've been with you for 11 years. I'd like to understand why this happened and if there's something I can do about it."

// LLM Structured Output (5 fields)

CATEGORY

Billing & Premium

SUB-CATEGORY

Unexplained Premium Increase

PRIMARY CALL DRIVER

Coverage added at renewal without proactive customer notification

SUMMARY

Long-term customer (11 years) calling about $200 premium increase on renewal. Coverage was added to policy at renewal cycle without prior notification. Customer was unaware of change and requests explanation and potential reversal.

SYSTEM IMPROVEMENT

Implement proactive renewal notification email that itemises any coverage or premium changes 30 days before renewal date. Expected to reduce this call driver by 60–70%.

The manual process would have categorized this call as "Billing" — one of two options. The LLM identifies the specific sub-category (Unexplained Premium Increase), the root cause (coverage added without notification), and a concrete systemic fix. At 30,000 calls per month, the ability to aggregate these root causes and improvement recommendations across thousands of calls gives leadership a precise repair list — not just a category count.

04RAG Reasoning Layer

The LLM Reasons Against Existing Call Patterns Before Classifying.

A key design decision in the P3Fusion solution is that the LLM does not classify in isolation. Before generating a category, subcategory, and call driver for any new transcript, the Bedrock Flow retrieves the existing set of known call drivers from the database and injects them as context. This is a RAG pattern applied to structured analytical output — the model grounds its reasoning in established taxonomy while retaining the ability to propose genuinely new categories when no existing pattern fits.

// RAG Reasoning Architecture · How Each Call Is ClassifiedBedrock Flow · Agent Runtime API

Inputs to the LLM

Call TranscriptFull text of the call, retrieved from Athena by Contact ID

Existing Call DriversAll known call drivers retrieved from the RDS database — injected as context so the LLM reasons against established patterns

Business ContextInsurance domain, PSIC product lines, policy terminology

LLM Reasoning Steps

Step 1 — UnderstandParse the call transcript for intent, emotional tone, and key topics

Step 2 — MatchCompare against existing call drivers — does this call match an established pattern?

Step 3 — ClassifyAssign Category + Sub-Category using insurance-specific business taxonomy

Step 4 — Root CauseIdentify the underlying reason driving the contact

Step 5 — RecommendGenerate a system improvement to prevent similar future calls

Structured Output

CategoryBusiness-specific primary label — far richer than the previous 2-option taxonomy

Sub-CategoryPrecise issue within the category — reveals the actual pattern

Primary Call DriverThe root cause — feeds the "why are people calling us?" analysis

SummaryPlain-language description stored for analyst review

System ImprovementProactive fix recommendation written to the database for leadership dashboards

The RAG reasoning layer is what makes the taxonomy self-improving over time. When enough calls match a new pattern, it surfaces in the call driver distribution automatically — without anyone manually updating a category list. Leadership sees emerging issues in their QuickSight dashboards before they become volume problems, because the model identifies the pattern as it forms.

05Before vs After

What Changed — and What Stayed the Same.

✕ Before P3Fusion

🎧

Agents manually listened to recordings and assigned categories. Hours of analyst time per week with no scalable coverage of the full call volume.

🏷

Only two broad categories available — far too coarse to reveal any actionable insight about what customers actually needed.

❌

No root cause identification. The underlying reasons driving contacts were invisible. The same issues recurred month after month.

📅

Reports were weeks behind the current state. Leadership was always reacting to past problems, never anticipating emerging ones.

⚠️

Inconsistent labelling between analysts. The same call type could receive different categories depending on who reviewed it.

✓ After P3Fusion

⚡

Every call is automatically analyzed from its transcript within minutes of completion. No agent time required for categorization.

🎯

Business-specific categories and subcategories generated by LLM reasoning — the taxonomy grows organically from what customers actually say.

🔍

Root cause identified for every call. Systemic issues are visible within the week they emerge, not months later when they've become volume problems.

📊

Real-time QuickSight dashboards. Leadership sees category trends, root cause distributions, and improvement recommendations updated continuously.

✅

Consistent LLM classification across all 30,000 monthly calls — the same reasoning applied every time, with no human inconsistency.

06AWS Stack

Built Entirely on AWS — Integrated, Not Bolted On.

Every component of the solution runs on AWS, integrating natively with PSIC's existing Amazon Connect infrastructure. No third-party services. No custom ML models to train or maintain. No infrastructure to manage outside the AWS ecosystem PSIC already operates in.

Amazon Connect

Amazon Transcribe

Amazon S3

Amazon Athena

Amazon Bedrock

Bedrock Flows

Bedrock Agent Runtime

AWS Lambda

Amazon RDS (MySQL)

Amazon QuickSight

07Results

The Outcomes Pacific Specialty Insurance Measured.

45%

Improvement in call classification accuracy — eliminating inconsistency from manual categorization

70%

Reduction in time spent on call categorization — analysts redirected to higher-value work

30%

Drop in repeat customer contacts — root causes identified and addressed proactively

Beyond the headline metrics, the most significant change at Pacific Specialty Insurance was organizational: for the first time, leadership had a language to describe what was happening in their contact centre. Not "billing calls were up" — but "unexplained renewal premium increases from unrenotified coverage additions are driving 18% of all billing contacts this month, and here is the recommended fix." That specificity — generated automatically from 30,000 transcripts — is what transforms a contact centre from a cost centre into a business intelligence asset.

P3Fusion

AWS Generative AI Competency Partner and Amazon Connect Service Delivery Partner. P3Fusion builds AI solutions on top of existing contact centre infrastructure — adding intelligence without disrupting operations.

Gen AI Competency

Connect SDP

InsightBot

FusionReport

Post-Call AI

Want post-call intelligence on Connect without changing agent workflows?

Financial Services · InsightBot

InsightBot — 80% search time reduction across 10,000 documents

Construction · MetroNational

RAG on bid archives — hidden MEP underpricing patterns discovered

Insurance · FusionReport

Generative BI eliminates insurance reporting backlog