Getting Started with Insurance Servicing in FSO
Objective
This article orients you on the FSO framework for Insurance Servicing. After reading it, you will understand how the FSO data foundation represents who insurance carriers serve (policyholders, household members, agents, brokers, employer groups), what is being serviced (policies, coverages, participants, insured property), and why customers contact the carrier. You will be able to use this understanding to define the case types, service definitions, and data foundation that set up the FSO platform for an insurance servicing implementation.
This article also covers key considerations for new Insurance Servicing implementations, including platform capabilities, required plugins, and enablement resources to help set your program up for success. Use this foundation to prepare for the deeper functional and architectural articles in subsequent series.
Overview
Insurance Servicing on Financial Services Operations gives carriers a single platform to manage service requests across the policy lifecycle. It provides data architecture, workflow patterns, and pre-built capabilities that let carriers modernize their front, middle, and back office operations on one platform.
This article focuses on platform fundamentals and getting started. Related articles in the series cover:
- Preparing an Insurance Servicing Data Model: Customer Data Foundation, Service Model Foundation, FSO Core Insurance, Remote Tables
- Insurance Servicing Applications Overview: Personal Lines, Commercial Lines, Individual Life, and Group Life Servicing in detail
- Building Custom Insurance Applications: Key implementation considerations for configuring FSO Insurance Servicing according to your needs
What Is Insurance Servicing?
Insurance servicing is everything that happens to a policy after it is sold. Life events keep happening; policyholders buy a new car, move, add a beneficiary, hire a new employee, expand to a new location, or simply ask about their bill. Each one creates a service request the carrier needs to handle quickly, accurately, and consistently.
Servicing sits between distribution and claims. It is the daily work of keeping policies current, helping policyholders make changes, and supporting agents and brokers. If done well, it drives loyalty and retention. If not, the carrier has a high probability of losing customers at renewal.
Insurance Servicing in FSO is a purpose-built solution built on the ServiceNow Platform and Customer Service Management (CSM). It extends CSM with insurance-specific capabilities, UX components, personas, data models, and workflows tailored for carriers.
It ships as four dedicated applications, each focused on a line of business:
- Personal Lines Servicing: for property and casualty servicing on policies held by individual policyholders, including auto, homeowner, condo, renter, and personal umbrella
- Commercial Lines Servicing: for property and casualty servicing on policies held by businesses, including commercial fleet, commercial property, general liability, and commercial umbrella
- Individual Life Servicing: for servicing on individual life and disability policies
- Group Life Servicing: for servicing on employer sponsored group life and disability plans
All four applications sit on the same FSO Core foundation. Once you understand how one of them works, the others follow a consistent pattern. Insurance Servicing is not limited to out-of-the-box lines of business. The same concept can be extended to other lines of business as well.
Why Insurance Servicing on FSO?
Carriers adopt FSO Insurance Servicing to consolidate fragmented service operations onto one platform, get to value faster with insurance-specific capabilities out of the box, and embed AI directly into the work their teams already do. The benefits below capture what comes up most often in carrier conversations.
| Benefit | Description |
|---|---|
| Unified servicing across lines of business | One platform handles personal lines, commercial lines, individual life, and group life on a shared data foundation. Carriers stop fragmenting their service operations across siloed systems. |
| Purpose built for insurance | Pre-configured policy data models, personas, playbooks, and service definitions cut months of build work compared to building on a generic CRM or BPM platform. |
| AI embedded in the workflow | ServiceNow Otto powers case summarization, intelligent routing, document validation, and virtual agent deflection inside the servicing workflow itself, not as a separate bolt-on. |
| Omnichannel service experience | Consistent experience across self-service portal, contact center, agent portal, and virtual agent. Case context follows the customer across every channel. |
| Integration with the carrier ecosystem | Remote Tables and IntegrationHub connect FSO to policy admin, document management, e-signature, HRIS, rating, and other systems without rebuilding what those systems already do. |
| Auditable, governed operations | Every case carries SLA enforcement, full work history, and an audit trail. Compliance teams get visibility without manual reporting cycles. |
| Low-code extensibility | Carriers adapt workflows, UI, integrations, and AI behavior using declarative tools. TCO stays predictable as the business evolves. |
Foundational Data Models
The FSO data model is the core foundation of the platform. Before going deeper, it is important to understand the key tenets behind it. Every carrier needs clarity on four fundamental questions: Who is being served; What is being serviced; Why they are contacting the carrier; How the work gets done.
These four questions shape everything in the platform: the data model, the personas and roles, the intake channels, the playbooks, the SLAs. The sections that follow walk through each foundation area in detail.
Figure 1. The Insurance Servicing data foundation in FSO. Four areas that together govern every service interaction.
The "Who": Policyholder and Servicing Ecosystem
Customer Data Foundation (CDF)
Customer Data Foundation answers the question of who the carrier is servicing externally. CDF provides the data structures to represent your customers in the way an insurance carrier actually needs them:
- Consumer: Individual policyholders in B2C relationships. This is the structure for personal lines and individual life policyholders.
- Account: Business policyholders in B2B relationships. This is the structure for commercial lines policyholders and for employer groups in group life.
- Contact: Individuals associated with a business Account such as the risk manager, CFO, or HR administrator, who actually handles servicing requests on behalf of the business.
- Household: Groups of related Consumers. Useful for representing family relationships with shared policies or billing arrangements.
Learn more: Customer Data Management
Service Model Foundation (SMF)
Service Model Foundation extends CDF with the structures carriers need to model service delivery in insurance. In insurance, the carrier rarely services the policyholder alone. Agents, brokers, MGAs, TPAs, and carrier branches all participate. SMF gives you the data structures to represent these relationships and the access controls that go with them.
Use the Service Model Foundation framework to:
- Build the carrier's service organization, including internal branches, regional service centers, agencies, MGAs, and external TPAs like Sedgwick or Gallagher Bassett
- Assign processors, underwriters, and service agents to specific business locations and grant them visibility to the cases and customer information in their location hierarchy
- Establish relationships between agents or brokers and specific policyholders so they can submit and manage cases on their clients' behalf through the contributor flow
Learn more: Service Model Foundation Overview
The "What": Policies, Coverages, Participants, and Insured Property
FSO Core Insurance Data Model
The FSO Core insurance data model answers the question of what is being serviced. It represents the policies a customer holds, the coverages those policies carry, the participants tied to each policy, and the property insured under each one.
- Insurance Policy: the parent record for any policy a carrier holds, regardless of line of business. Extends the platform's Sold Product model with insurance-specific attributes.
- Line of business policy tables: Personal Auto, Homeowner, Commercial Property, Individual Life, Group Life, and others. Each one extends Insurance Policy with the fields and behaviors specific to that LOB.
- Policy Coverage: the specific coverages on a policy. Bodily injury and collision on an auto policy, dwelling and personal property on a homeowner policy, term coverage amount on a life policy.
- Policy Participant: individuals or entities associated with a policy beyond the primary named insured. Co-insureds, additional drivers, beneficiaries, loss payees.
- Insured Property: the physical assets covered under a policy. Vehicles on an auto policy, dwellings on a homeowner policy, scheduled locations and equipment on a commercial property policy.
Together, these components give agents and processors the full picture of what the customer has and what they need help with. This policy data can be stored locally in ServiceNow or accessed remotely through Zero Copy.
Learn more: FSO Core Data Model | FSO Core Insurance Tables | FSO Remote Data
The "Why" and "How": Case Management
Why Are Customers Contacting the Carrier?
The Why is the business reason behind every servicing interaction, and it varies significantly by line of business. The most common scenarios that drive an Insurance Servicing implementation:
Personal Lines Servicing
- Add or remove a driver, add a vehicle, change garaging address
- Adjust coverage limits or deductibles
- Billing questions and payment method changes
- Renewal questions and rerate requests
Commercial Lines Servicing
- Certificate of insurance requests (high volume)
- Schedule changes (locations, vehicles, equipment)
- Endorsements and mid-term coverage modifications
- Premium audit submissions
Individual Life Servicing
- Beneficiary changes (document and signature heavy)
- Address updates and payment method changes
- Coverage increases that may trigger underwriting
- Term to permanent conversions and reinstatements
Group Life Servicing
- New hire enrollments and terminations
- Dependent additions on qualifying life events
- Open enrollment changes
- Evidence of Insurability submissions
- Disability claim initiation
Each of these is a candidate for a Service Definition in FSO.
How Does the Work Get Resolved?
Case Types, Service Definitions, and playbooks turn those Why scenarios into governed, auditable work.
- Case Types: Extended case tables that represent specific categories of servicing requests. Insurance Servicing applications ship with pre-built case types that include insurance-specific fields, workflows, and business logic. Case Types allow you to tailor the data model, UI, and process for each type of work.
- Service Definitions: Define the specific services available within each Insurance Servicing application. Service Definitions connect the "what" (the service a customer needs) to the "how" (the case type and workflow used to fulfill it). They drive intake experiences like record producers and help categorize work for reporting and routing.
- Playbooks: Stage-by-stage SOPs that guide processors through every step. You can create your own playbooks using Workflow Studio and Flow Designer to fit your own SOPs without changing the core platform.
- Supporting capabilities: Document Processor carries the load on document-heavy scenarios like Individual Life beneficiary changes and Commercial certificates. ServiceNow Otto provides case summarization on long-running cases and intelligent routing on high-volume scenarios like Commercial certificate requests.
Learn more: Case Types in FSO | Service Definitions in FSO
Core Tables and Case Inheritance
With the four foundation areas in mind, here is a closer look at the anchor tables that come up in almost every Insurance Servicing conversation, and the inheritance chain that every Policy Service Case follows. This is not the full schema. The dedicated data model article in this series covers field-level detail, extension patterns, and the rest of the tables.
Core Tables to Know
| Table | Label | Purpose |
|---|---|---|
| sn_bom_ins_policy | Insurance Policy | Parent policy record across all lines of business. Extends Sold Product. |
| sn_bom_auto_ins_policy | Personal Auto Policy | Personal lines auto. Extends Insurance Policy. |
| sn_bom_homeowner_ins_policy | Homeowner Policy | Personal lines homeowner. Extends Insurance Policy. |
| sn_bom_indiv_life_policy | Individual Life Policy | Individual life and disability. Extends Insurance Policy. |
| sn_bom_group_life_ins_policy | Group Life Policy | Employer sponsored group life. Extends Insurance Policy. |
| sn_bom_policy_coverage | Policy Coverage | Coverages carried on a policy. |
| sn_bom_policy_participant | Policy Participant | Insureds, beneficiaries, and other participants on a policy. |
| sn_bom_insured_property | Insured Property | Physical assets covered under a policy. Vehicle, home, business site. |
Case inheritance chain. Policy Service Cases follow a layered hierarchy:
- Task [task]: the platform base task table
- CSM Case [sn_customerservice_case]: service management foundation
- FSO Base Case [sn_bom_case]: financial services domain layer
- Policy Base Case [sn_ins_policy_b2c_base or LOB equivalent]: insurance servicing layer
- Application Service Case (e.g., Individual Life Service Case [sn_ins_indiv_life_case]): LOB specific logic and fields
Every level adds capability without breaking what the parent provided. A field added at FSO Base Case is available to every application below it. A business rule on Policy Base Case runs on every policy service case regardless of LOB. This is what makes extending FSO sustainable.
A Service Request from Start to Finish
The easiest way to internalize the model is to trace a real request through it. Here is what happens when Marcus Rivera calls Alectri Insurance to add his newly licensed son as a driver on his DriveShield personal auto policy.
| Stage | What Happens | Foundation Area |
|---|---|---|
| Intake | Marcus calls the Alectri contact center. The agent opens FSO Workspace. Marcus's record surfaces as a Consumer. His DriveShield policy surfaces from Personal Auto Policy via Remote Tables. An Interaction record is created. | Who (CDF) + What (FSO Core) + How |
| Case Creation | The agent selects the Add Driver Service Definition. A Policy Service Case is created, referencing Marcus, the DriveShield policy, and the selected service. The playbook is instantiated. | Why + How |
| Document Collection | The playbook collects the new driver's license and any supporting documents. Document Processor validates inbound documents and triggers e-signature when required. | How |
| Underwriting Review | The new driver is under 25. The playbook routes an Underwriting Task to an underwriter. The underwriter reviews the risk and approves the change. | How (conditional branch) |
| Processing | Once approved, IntegrationHub writes the endorsement back to the policy system of record. Document Processor generates the updated declarations page. | How |
| Closure | Marcus receives an email confirmation. He can track the request on the Consumer Portal. The case closes with full audit trail, SLA metrics, and analytics captured automatically. | How |
Five object types across four foundation areas. Every Insurance Servicing request follows this same shape, whether it is a beneficiary change on an individual life policy, a certificate request on a commercial policy, or a new hire enrollment on a group policy. The data foundation stays constant. What changes is the service definition, the playbook, and the data carried on the case.
The Insurance Servicing Application Landscape
FSO ships Insurance Servicing as four separate applications instead of one universal app, and that design decision is deliberate. Each line of business has a materially different profile across Who, What, and How. Packaging them separately lets each application carry the right data model, the right default service definitions, the right playbooks, and the right persona assignments without compromise.
| Application | Who | What | Anchor Persona |
|---|---|---|---|
| Personal Lines Servicing (sn_ins_policy_b2c) | Consumer (B2C) | Personal auto, homeowner, condo, renter, umbrella | Marcus Rivera. Holds DriveShield auto and HomeGuard homeowner policies. |
| Commercial Lines Servicing (sn_ins_policy_b2b) | Account + Contact (B2B) | Fleet auto, commercial property, general liability, commercial umbrella | Diana Tran, Risk Manager at Riverstone Construction. Manages FleetProtect and PropertyShield policies. |
| Individual Life Servicing (sn_ins_indiv_life) | Consumer (B2C) | Individual term life, permanent life, individual disability | Priya Kapoor. Holds an individual term life policy. |
| Group Life Servicing (sn_ins_group_life) | Account as employer + Consumer as member (B2B2C) | Group life, group disability, employer sponsored coverage | Benefits administrator managing enrollment and member changes for an employer group. |
Each application comes with its own processor, manager, and contributor roles, plus a dedicated underwriting operations extension where underwriting touchpoints are significant. Personal Lines and Commercial Lines share a common underwriting app. Individual Life and Group Life have their own. You install and activate only the applications the carrier needs. FSO Core is the common foundation underneath all of them.
Implementation Planning: Key Considerations
Reading about FSO is different from building it. The areas below are what implementation teams need to think through before configuration starts.
- Persona and role design comes before configuration: Workspaces, playbook activities, record producer access, SLA visibility, and portal surfaces are all driven by role. Get this right at the start. Refactoring access control mid-build is painful.
- Leverage platform capabilities to model the carrier's business processes: Baseline playbooks and service definitions are starting points, not endpoints. Every carrier has its own SOPs, regulatory posture, distribution model, and operational philosophy. Use the platform's flow and orchestration tools to reflect those differences.
- Set the integration architecture right: How deeply FSO integrates with the carrier's policy data source shapes workspace performance, reporting depth, integration effort, and long-term maintenance. Decide upfront; changing mid-implementation is expensive.
- Focus on data quality: AI readiness is a data quality conversation. ServiceNow Otto, AI Agent Studio, and Document Intelligence depend on the quality of data flowing into FSO. Treat data quality as a pre-implementation workstream, not a post-go-live cleanup.
- Involve operations teams during the implementation: Change management for operations teams is consistently underestimated. The platform is the easier part. Adoption is the harder part. Agents and processors moving from email queues and legacy systems need deliberate support.
Plugin Reference
Below is a reference list of the key FSO plugins for Insurance Servicing. Install based on your implementation scope. FSO Core is the foundation. Every Insurance Servicing application depends on it.
| Application | App ID | Description | Depends On |
|---|---|---|---|
| Financial Services Operations Core | sn_bom | FSO data model foundation. Required by every Insurance Servicing application. | CSM, Install Base |
| Personal Lines Servicing | sn_ins_policy_b2c | P&C personal lines: auto, homeowner, condo, renter, umbrella. | sn_bom |
| Commercial Lines Servicing | sn_ins_policy_b2b | P&C commercial lines: fleet, property, general liability, commercial umbrella. | sn_bom |
| Commercial Lines Underwriting | sn_ins_uw_b2b | Underwriting task routing for commercial lines. Auto-installed with Commercial Lines Servicing. | sn_ins_policy_b2b |
| Individual Life Servicing | sn_ins_indiv_life | Individual life and disability servicing. Five baseline service flows. | sn_bom |
| Individual Life Underwriting Operations | sn_ins_indiv_uw | Underwriting task routing for individual life. Install after Individual Life Servicing. | sn_ins_indiv_life |
| Group Life Servicing | sn_ins_group_life | Group life and disability servicing for employer sponsored plans. Includes Group Life Underwriting. | sn_bom |
| Financial Services Remote Tables | sn_bom_remote | Real-time read access to external policy systems. Evaluate Full Remote vs Hybrid vs Local before installing. | sn_bom |
| FSO Process Mining Content Pack | sn_bom_po | Process Optimization for FSO. Requires Process Mining entitlement. | sn_bom + Process Mining |
| Performance Analytics Content Pack for FSO | sn_bom_pa | Pre-configured PA dashboards for insurance servicing. Install early so baseline data collection begins at go-live. | sn_bom + PA entitlement |
| ServiceNow Otto for FSO | (platform) | AI case summarization, document intelligence, virtual agent. Install last. Data quality must be stable before enabling. | sn_bom + LLM entitlement |
Learn more: ServiceNow Store
Learning and Enablement Resources
Review the FSO Learning and Enablement Resources article for more information on training paths, certification tracks, and enablement assets across the FSO suite.
What's Next
Explore additional Insurance Servicing capabilities:
- Exploring Personal Lines Servicing
- Exploring Commercial Lines Servicing
- Exploring Individual Life Servicing
- Exploring Group Life Servicing
- Preparing an Insurance Servicing Data Model (Coming Soon)
- Building Custom Insurance Applications (Coming Soon)
Get involved:
- Subscribe for updates on the FSO Community Forum
- Review videos on the Financial Services Operations YouTube Playlist
Happy implementing. Comment below for questions, additional assets, or to share your Insurance Servicing success stories.
