Making Claims Modernization Actionable: Three Frameworks from the Scout Claims Summit

Claims modernization conversations often get stuck in the same spot. Teams rush into discussing tools and debate whether to build or buy before they identify the real problem. And after a new solution is live, teams realize change management was an afterthought - leaving them with fancy workflows with no real adoption.

That was the core tension explored during a recent workshop led by Anna Conger of Kyber and John Harvey of CrashBay at the Scout InsurTech Claims Summit. Rather than present a polished theory of transformation, Anna and John structured the session as a working discussion with the claims leaders present in the room.

There were three key questions explored during the session, leaning on the experience of claims leaders

1. Are we solving the right problem?
2. Should we build, buy, or partner?
3. Who will actually drive adoption once a solution is in place?

The team wanted the session to come outside of theory. The discussion highlighted the actual challenges claims teams face first notice of loss, customer uncertainty, fragmented handoffs, resourcing constraints, and internal resistance to change.

The Industry Context

Modernization in claims is rarely blocked by a lack of ideas. More often, it gets held up because organizations try to tackle too many issues at once.

Claims teams  want better customer experiences, cleaner data, faster handoffs, better coordination, and more efficient workflows. At the same time, they face an influx of new AI tools, point solutions, and internal pressure to “do something innovative.”

This environment makes it easy to confuse activity with real progress.

In the workshop, Anna and John focused the discussion on four common claims pain points that came up during last year's session: first notice of loss bottlenecks, unclear ownership of the customer experience, low customer trust, and fragmented vendor or workflow handoffs. These examples were helpful because they may seem like technology issues at first glance, but often stem from deeper problems.

As shared in previous Kyber Expert Guides, the strongest modernization efforts usually begin by getting more precise about workflow friction before reaching for automation. The same lesson shows up in our broader thinking on claims operations: tools matter, but only after teams are clear on the operational problem they are trying to solve.

Framework 1: Fall in Love With the Problem, Not the Solution

The first framework in the workshop was simple: start with the symptom, identify the root cause, and then determine whether the issue is really about people, process, technology, or data.

Start with what is actually breaking

John kicked off the example with his experience at CrashBay. Because CrashBay sits between carriers and the repair shops in its network, it depends on clean handoffs in both directions, and one was breaking: shops weren't consistently uploading invoices, which slowed claims closure on the carrier side.

On paper, that seemed efficient. In practice, it caused more confusion, increased inbound questions, and led to a worse experience for the shops receiving the calls

The real issue was not a lack of AI. It was a breakdown in communication and workflow design.

Once that was understood, the better solution was not to add AI. Instead, it was to create a clearer upload flow, linked to the right incentive, with a system that integrated smoothly into downstream operations.

Reframe solution requests into problem statements

The room then applied that logic to common claims examples.

Instead of saying, “we need a Domino’s-style claim tracker,” one participant reframed the goal as eliminating periods of uncertainty for customers.

That is a much better problem statement that points to the actual need (which is not necessarily a tracker). It is proactive communication, better expectation-setting, and fewer moments where customers feel left in the dark.

The group also conducted the excersize for FNOL. If a team says it wants voice AI, that may or may not be the right answer. The underlying problem could just as easily be poor intake design, too many handoffs, missing structured data, or lack of staffing coverage during off-hours.

Treat customer preference as part of the operating problem

Another strong insight from the room was that claims teams often support multiple customer preferences when selling a policy, but fail to carry that same flexibility into the claims experience.

Some policyholders want a human immediately. Others want to file digitally and move on. Others are fine with guided automation if it is fast and clear.

That means the problem is not just “how do we automate intake?” It is also “how do we meet the customer where they are without forcing a single path on everyone?”

If the problem statement is weak, the solution discussion will be weak too.

Framework 2: Buy Infrastructure, Build Advantage, Partner for Innovation

Once a team knows what it is solving, the next question is usually whether to build, buy, or partner.

The workshop offered a useful lens here, drawing on Gartner’s pace-layered thinking: systems of record, systems of differentiation, and systems of innovation.

Buy the plumbing

For core systems that run the business, buying is often the right move.

These are long-lived systems of record. They need to be stable, supported, and integrated into the broader operating environment. Most carriers do not gain a meaningful competitive edge from building foundational infrastructure from scratch.

Several attendees noted that internal teams can often spin up something quickly, especially in the current AI environment, but struggle to support and maintain it over time.

Build what differentiates you

The case for building gets stronger when the capability is truly strategic.

Anna shared an example of a carrier that chose to build its own intelligence layer for claims decisioning. The rationale was not that buying was impossible. It was that the carrier believed this layer could become a durable source of competitive advantage as the technology evolved.

Building should not necessarily be the default expression of technical ambition. Rather, it should be reserved for capabilities truly central to how the business wins.

Partner where the last 20% matters

The discussion also highlighted the role of strategic partnership.

Partnership can make sense when a carrier wants more than an off-the-shelf product, but does not want the full burden of building and maintaining the capability internally. In those cases, the value often comes from finding a partner who can cover the common 80% while still allowing room to shape the final 20% around the carrier’s operating model and bespoke needs.

The best partnerships are not just vendor relationships. They are collaborative environments where business context and product capability sharpen each other.

Count the long-tail cost, not just the launch cost

Several attendees made a version of the same point: the hard part is not always getting something live. It is supporting it over time.

That is especially true with AI-enabled workflows, where the cost model is harder to predict and the maintenance burden can be easy to underestimate. A capability that looks cheap to prototype can become expensive to govern, monitor, and improve.

The practical lesson is that build-buy-partner decisions should not be treated as a one-time procurement exercise. They are operating model decisions with long-term consequences.

Framework 3: Adoption Is Not the End of the Project. It Is the Test.

The third framework was only covered briefly in the live session, but it pointed to one of the most important truths in claims transformation.

A solution is not successful because it launches. It is successful because people use it well.

John framed this to the room as a final trivia question: is a subject matter expert the same as a champion?

The answer? Not always.

In fact, the people closest to a process can sometimes be the most resistant to changing it. They know where prior implementations failed. They understand the edge cases. They have practical reasons to be skeptical.

That does not make them blockers by default. It often makes them the right people to engage early.

If a claims organization can turn a skeptic into a champion, that person often becomes far more credible than someone who supported the change from the start.

This is an important reminder for teams evaluating new claims technology. Adoption does not happen because a roadmap says it should. It happens when the people closest to the work understand the problem, believe the solution respects the realities of the job, and can see how it improves the workflow rather than complicating it.

What Best-in-Class Teams Do Differently

The discussion at Scout pointed to a few habits that separate stronger modernization efforts from weaker ones.

1. They define the business problem before debating the tool.
2. They distinguish between infrastructure, differentiation, and experimentation.
3. They evaluate long-term support costs, not just implementation speed.
4. They account for customer preference instead of assuming one intake or communication path fits everyone.
5. They treat adoption as a design constraint from the start, not an afterthought.

The strongest claims modernization work is often less about bold declarations and more about disciplined choices.

If this is top of mind for your team, the next step is probably not to start with a vendor demo or a feature comparison. It is to take one workflow, write the real problem statement as clearly as possible, and evaluate your options from there.

That is where better modernization decisions begin.

About Kyber

Claims modernization gets easier when teams can connect operational problems to the right workflow and communication infrastructure. If your organization is rethinking how claims correspondence, intake, or handoffs should work, book a demo to see how Kyber helps carriers build more consistent, compliant, and adaptable claims operations.

About CrashBay

CrashBay operates as neutral infrastructure for collision claims, a coordination layer connecting carriers to a vetted repair network, without owning shops or performing repairs. And when the workflow in question is collision repair itself. Moving estimates, approvals, and payments cleanly between carriers and shops, that coordination is exactly what CrashBay provides. See how CrashBay connects carriers to a vetted repair network → crashbay.com