Seen enough to have a conversation?
No sales deck. Just a direct conversation about your problem.
Talk to an engineerInsurance · Custom Software Development
Deflecting 61% of inbound service calls through a policyholder self-service portal built for a carrier processing 18,000 contacts per month
A regional P&C carrier fielding 18,000 inbound service contacts per month — policy queries, certificate requests, payment updates, and claims status checks — was running a contact centre at 94% capacity with no headroom for growth. We built a secure, mobile-first self-service portal that gave policyholders direct access to their policy data, documents, and service actions in real time. At 90 days post go-live, 61% of previously phone-handled contacts were being resolved through the portal without agent involvement, and average API response time across all portal actions was 310ms.
The Problem
Their contact centre wasn't understaffed.
It was handling work that shouldn't require a human.
The carrier had 22 agents handling inbound service contacts across phone and email. At 18,000 contacts per month, that was roughly 820 contacts per agent — a volume that left no capacity for complex queries, upsell conversations, or anything that actually required human judgment. The breakdown of contact types told the real story: 34% were policy document requests (ID cards, declarations pages, certificates of insurance), 28% were payment-related (balance enquiries, payment method updates, autopay enrolment), 21% were claims status checks, and 17% were coverage queries and endorsement requests. Three of those four categories required zero agent judgment. They required data access.
The carrier had a policyholder-facing web presence — a marketing site with a login button that led to a third-party billing portal. That portal handled payment collection only. It had no policy data, no document access, no claims visibility. Policyholders who wanted anything beyond paying their bill had one option: call. The carrier knew this was a problem. They had evaluated two off-the-shelf policyholder portal products in the prior 18 months. Both required replacing their policy administration system — a Majesco-based platform they had no intention of migrating away from. Neither evaluation went anywhere.
The constraint was not budget or intent. It was integration. Their policy administration system exposed a partial REST API that had been built incrementally over four years — well-documented in some areas, undocumented in others, and missing endpoints for several high-volume actions entirely. Any portal had to work with what existed, fill the gaps with purpose-built middleware, and do it without touching the core PAS.
The operational cost of a phone-first service model
- 18,000
- inbound contacts per month
- $11.40
- fully-loaded cost per phone contact
- 7.2 min
- average handle time
83% categorised as self-serviceable — no agent judgment required
vs. $0.18 per self-service digital transaction at comparable carriers
For document requests that take 8 seconds to fulfil digitally
Scope of Work
What we were asked to build
Policyholder authentication and identity layer
Secure registration and login with MFA (TOTP and SMS). Identity verification against policy records at registration — no manual approval queue. Session management with 15-minute idle timeout and device fingerprinting for anomaly detection.
Policy dashboard and document centre
Real-time policy summary pulling live data from the PAS API — coverage details, effective dates, named insureds, vehicles or properties. On-demand document generation for ID cards, declarations pages, and certificates of insurance, delivered as PDF within seconds of request.
Payment management
Balance display, payment history, one-time payment, autopay enrolment and management. Stripe integration for card processing with PCI DSS SAQ-A compliance. ACH/bank account support for recurring payments.
Claims status tracker
Read-only claims timeline pulling status, adjuster assignment, and next-action milestones from the claims system. Push notifications (email and SMS) on status changes. No claims filing — read access only, scoped to avoid touching the claims workflow.
PAS middleware and API gateway
Purpose-built middleware layer bridging the portal to the Majesco PAS. Filled three missing API endpoints with direct database read replicas (read-only, no write path to production DB). Rate limiting, request signing, and audit logging on every PAS call.
Constraints we worked within
- Majesco PAS could not be modified — all integration had to use existing API endpoints or read replicas
- PCI DSS compliance required for all payment flows — Stripe SAQ-A scope enforced throughout
- SOC 2 Type II audit scheduled for Q1 2025 — all access controls, logging, and encryption had to be audit-ready at go-live
- No claims filing or policy endorsement write-back in scope — read and payment actions only
- Mobile-first requirement: 68% of the carrier's policyholder base accessed their billing portal on mobile
- 6-month delivery window — carrier's open enrolment period created a hard go-live deadline
Explicitly not in scope
- Claims filing or FNOL submission
- Policy endorsements or coverage changes
- Agent or broker portal (separate system, separate engagement)
- PAS migration or replacement
- Live chat or co-browse support tooling
System Architecture
One portal. One middleware layer. Zero changes to the core PAS.
How We Worked
6 months. 4 phases. One hard deadline.
Discovery & API Audit
Full audit of the Majesco PAS API surface — documented 47 available endpoints, identified 3 gaps requiring middleware, mapped data models for policy, claims, and billing. Security architecture defined. PCI scope confirmed with carrier's compliance team.
Core Platform Build
Authentication layer, policy dashboard, and document generation built and tested against PAS staging. Middleware layer built for the three missing endpoints. Stripe integration completed and PCI SAQ-A scope validated. Internal security review at end of month 3.
Claims Tracker, Payments & Pilot
Claims status tracker integrated with claims system. Payment management completed including ACH. Soft launch to 800 policyholders — monitored API performance, error rates, and support ticket volume. Average API response time at pilot: 340ms. Tuned to 310ms before full rollout.
Full Rollout & Hardening
Rolled out to full policyholder base (41,000 accounts). Penetration test completed — 3 medium findings resolved before go-live, 0 critical or high. SOC 2 evidence package prepared. On-site for go-live week. Handoff and runbook documentation completed.
Working rhythm
- CadenceTwo-week sprints, bi-weekly steering with CTO and COO
- Decision ownerCTO (technical), COO (scope and timeline)
- Security reviewsInternal at month 3, external pen test at month 6
- Escalation SLA24 hours with written recommendation
- On-siteMonth 1 discovery and go-live week
Results
Measured at 90 days post go-live.
of inbound service contacts deflected — handled through the portal without agent involvement
Document requests (ID cards, declarations pages, certificates) deflected at 89%. Payment actions deflected at 74%. Claims status checks deflected at 58%. Coverage queries remain predominantly phone-handled — by design, as they require agent judgment.
average API response time across all portal actions at production load
Achieved through middleware-layer response caching for policy summary data (5-minute TTL), read replica routing for the three gap endpoints, and connection pooling on all PAS API calls. P99 response time: 780ms. Zero timeouts recorded in the first 90 days.
policyholder accounts migrated to the portal — 34% activated within the first 30 days
Activation driven by a post-go-live email campaign and an IVR prompt added to the contact centre phone tree. Policyholders who activated in the first 30 days had a 91% retention rate on portal usage at 90 days — they did not revert to calling.
projected annual contact centre cost reduction based on 90-day deflection rate
Projection based on 61% deflection rate sustained at current contact volume. The carrier has not reduced headcount — the freed capacity is being redirected to outbound retention calls and complex service queries that previously went unanswered due to queue pressure.
Is This Your Situation?
The self-service layer we built here is not unique to this carrier.
It applies to any P&C operation where policyholders have no digital access to their own policy data — and where the contact centre is handling volume that doesn't require a human.
- Your contact centre handles thousands of document requests, payment queries, and status checks every month — none of which require agent judgment
- You've evaluated off-the-shelf portal products but can't replace your PAS to make them work
- Your policyholder-facing digital experience is a billing portal — and nothing else
- Your contact centre is at capacity and you have no headroom to grow the book without growing headcount
This engagement was scoped as an additive layer — the Majesco PAS was not touched, the contact centre was not restructured, and policyholders were not forced to migrate. Six months from kickoff to 41,000 accounts live.
Seen enough to have a conversation?
We scope every engagement before we quote. No sales deck. Just a direct conversation about your problem.
More Work
Cutting new agent ramp time from 11 weeks to 4 using AI voice roleplay training
Read case studySame-day P&C claims resolution for 70% of cases — down from a 14-day average
Read case studyReducing lead response time from 47 minutes to under 90 seconds across five acquisition channels
Read case study