One Framework or Many? Standardizing Service Management at a Regional Insurer
Meridian Mutual is a regional insurer with three business lines-life, auto, and commercial-serving 1.2 million customers. Its 120-person IT group supports 45 internal services through seven ticketing instances and three configuration management databases. The CIO has mandated a single service management framework by the end of Q3, arguing that fragmentation causes the 18% ticket backlog and the drop in customer satisfaction from 78 to 64. Business-line leaders resist, saying their products need different speeds and controls; one product team has already built a lightweight workflow outside IT. The board wants one version of the truth, but no one has defined what value means for each business line or which decisions must stay central. A tool vendor is proposing a consolidated platform, and the CIO is ready to sign. The next governance meeting must decide whether to standardize processes, tools, or outcomes first.
1. Using VeriSM's concept of service management and value, diagnose why the CIO's single-framework mandate is likely to fail. What should be defined before selecting tools or processes?
Read the worked answer
VeriSM treats service management as a set of capabilities used to deliver value to customers, not as a fixed process library. Value is co-created with consumers and depends on context, so a mandate that starts with 'one framework' assumes the problem is process variation. The symptoms-18% backlog, CSAT falling from 78 to 64, seven ticketing instances-show both fragmentation and capability gaps. Before tools, Meridian must define, per business line: the customer and outcome, the service boundaries, the risk appetite, and the decisions that must be consistent. For life insurance, regulatory evidence may dominate; for auto, speed of quote changes may dominate. A single taxonomy and common incident/knowledge practices can be shared while product teams tailor workflows within guardrails. The CIO should also separate 'one version of truth' for reporting from 'one way of working'. Otherwise the vendor platform will standardize the wrong things and business units will keep building shadow workflows.
2. Recommend how to scope the transformation so the three business lines share governance while retaining appropriate autonomy. Include decision rights and success measures.
Read the worked answer
Use the VeriSM management mesh to tailor, not homogenize. Establish a light central governance group that sets risk appetite, data classification, service taxonomy, and minimum evidence for critical services. Give each business line a product-oriented service owner accountable for outcomes and a local improvement backlog. Decision rights: central for critical-service changes, shared platforms, and vendor risk; local for standard changes, knowledge content, and team-level practices. Create a shared service desk and CMDB as common resources, but let teams choose flow practices if they meet evidence requirements. Run one business line as a 90-day pilot, then extend. Measures should include outcome and capability indicators-backlog age, first-contact resolution, CSAT by journey, percentage of services with a named owner, and audit exceptions-not just tool consolidation. This preserves speed where risk is low and control where it matters, which is the point of VeriSM's governance-plus-mesh approach.