Post-Bind Operational Improvement

Challenge

[Corporate Insurance Company]’s JD Power customer satisfaction scores were the lowest in the industry. After a rapid succession of CEOs and reorganizations, the company lost long-time clients and failed to win new business. Customer dissatisfaction centered around delays in post-bind operations. My role involved identifying the source of these delays.

Approach

Research

I attempted to gather VOC to verify that service-level agreement (SLA) failures were the cause of dissatisfaction, but the risk-averse climate prevented me from talking to customers directly. Instead, I parsed through complaint tickets and interviewed frontline agents who described their clients’ negative experiences. Even from this secondhand perspective, it was evident that SLA failures were a massive problem, but how they originated remained unclear.

I arranged meetings with the division managers, who provided details about the post-bind stages and the KPIs they reported on. They also agreed to have me conduct an ethnographic study of their operations.

I set about blueprinting the post-bind process, and over several weeks, I shadowed staff from all divisions within the post-bind operation, including late-night sessions with the offshore teams in Chennai and Manila. I cataloged a spectrum of data, from procedures and systems to opinions about the process.

 

While employees were eager to help, operational inefficiencies worked against them.

Synthesis

As a conglomerate of business acquisitions, the company’s operations had become a patchwork of processes and networks, which became evident as I coded instances of unconnected systems, broken interfaces, duplicative and manual tasks, and outdated procedures — issues resulting in teams distrusting and refusing to work together.

Once I resolved gaps and discrepancies, the blueprint contained roughly 300 touchpoints over 28 teams. I highlighted places where SLA failures were most prevalent, especially the manual handoffs. The blueprint was the first time division managers saw the post-bind flow apart from idealized process maps. The inefficiencies took them by surprise.

Until now, the division managers blamed staff issues for the company’s problems. However, with the post-bind orchestration in full view, it was clear that customers played the most significant role in SLA failures. When a customer delayed their response to a request, it caused downstream events, not just for them but also triggered work stoppages throughout the system for all customers.

 

A lack of response to a permit request would strand an AIG team already en route to the customer’s overseas location.

Exploration

With the core issues identified, I facilitated workshops with the division managers and members of the UX team. We reviewed the customer touchpoints, and I prompted the group to devise ways to help customers become aware of their responsibilities and entice them to complete tasks.

Of the ideas generated, four had the most potential. First was a customer self-service portal. The second was assigning data entry tasks to the customer. Third was a status indicator that showed where a request was in the process. And fourth was an alert that notified the customer of any required input.

Each idea relied on a customer-facing portal, which gave the division managers pause. At the time, customers conducted business only through a personal agent, and there was concern that removing this concierge-level service would cause the customer experience to fall short of expectations.

I acknowledged the division managers’ concern, but having interviewed the frontline agents, I showed that, in nearly every case, customers relied on their support staff to maintain the insurance relationship. It was reasonable to ask them to handle their accounts online, but we would test this assumption. I received approval to evaluate the concepts.

As we entered prototyping, my senior designer was eager to build out the wires. However, I recalled the UI manager saying his team had componentized the UX design system in Angular and could assemble a production-ready prototype in minutes. So, I had the designer sit with a UI engineer, and together, they produced a fully functional contact center prototype within the week.

 

The concepts revolved around a customer-facing portal, which the stakeholders were uncertain about.

Evaluation

When it became time to test the contact center concept, I remained barred from interacting with customers. With consent from Operations leadership, I arranged for the frontline agents to act as our proxy, walking customers through the prototype and asking questions on our behalf. It wasn’t optimal, but customer feedback was critical.

The agents exceeded expectations. Being close to their customers, the agents easily persuaded them to participate in the walkthrough and to be candid about their experiences. However, the findings were not as hoped.

Customers liked the interface, but as a concept, the contact center was yet another admin site. They were already overwhelmed by the number of service providers they kept up with. Considering this negative feedback, the project lost support.

However, a significant insight arising from the walkthroughs was the degree to which customers preferred emailing the company. It occurred to me that the self-service portal idea wasn’t flawed, just the channel.

I met with our internal Salesforce development team and demoed the contact center prototype. A week later, they returned with a Salesforce-based email automation that adopted the escalation logic, friendly reminders, and status prompts.

 

Even a simple UI is too much for customers with numerous service provider accounts.

Outcome

Between this new email system and fixes based on insights from my service blueprints, Operations alleviated many of the post-bind SLA problems. CSAT scores increased in response. After my stint, the company eventually released the online self-service portal I spearheaded.