We used foresight to define the future of claims at enterprise scale: 10 years out, across tech, people, and process, for five operating companies at once. The work started as two teams, property and auto, and I added a third, commercial, and led all three as one. I taught the combined team to build 19 scenarios, because the vision had to hold for every kind of claim: a deer hit, a two-car accident, hail, a sump-pump overflow, a break-in at a boutique. Some pushed further: autonomous vehicle crashes, proactive hurricane evacuations, AI-enabled empathy (this was in 2018). Then we reverse-engineered the infrastructure that would make that future possible.

You can't redesign an operation for the future without some idea of what it will need to deliver. If we had only considered the status quo, we couldn't have designed a claims operation that would stand the test of time. So the team created eleven new-to-market product and service concepts based on current customer needs and emerging technological capabilities. Launching them was a separate decision, well out of scope for the upcoming board meeting. Their first job was to give the processes and roles we designed next something to test against.

We sketched the future-state processes for a tech-enabled claims operation that balanced customer empathy, adjuster support, and cost efficiency. This was a true marriage of operational fluency and long-range vision, designed to deliver both business impact and human value.

The vision covered organizational redesign too. My team wrote the long-term workforce recommendations: rethinking adjuster roles for one cross-enterprise team, re-skilling programs, and new roles, like teaching AI and explaining AI decisions.

We built three things: a blueprint of the proposed technology, a sketch of the financial case, and a multi-year roadmap to reach both.

I drew the blueprint with engineers and claims experts in the room, drafting versions until they had nothing left to interrogate. Then I drew the final version of our proposed technical architecture clear enough that the board approved it and engineering built from it. (I started my career drawing technology for the people who build it: products and components for manufacturers and installers. The claims architecture called for the same skill at a bigger scale.)

The blueprint included both the consolidated platform and a new “claims engine” that ran three models on four defined data sets, and it checked for fraud from the start. It made room for compliance and state rules without letting them stall the vision. And it rested on how people would act: adjusters, customers, and five operating companies keeping the best of each.

With the blueprint defined, we sketched the start of the financial case and reverse-engineered a high-level, staged roadmap, so the transformation, and its financial benefits, were tangible enough for the board’s decision.

All three were clear enough to align around and practical enough to build from.

Clear and practical wasn't enough. The board had to remember it, too. So we built the communication strategy on executive narratives: short sci-fi stories featuring futuristic claims scenarios, from climate disasters to AI-enabled repair logistics (again, 2018). We paired those stories with visual artifacts: cartoon-style illustrations of the “claims engine” we envisioned, a solution later named Fabric, in action with customers, partners, and employees. I hired Andy Bernier, an illustrator I knew from college, to draw them.

Nobody had seen a deck like it. It was a plan for a more supportive, scalable, and human-centered future, told in a way people could see, feel, and choose to believe in.

The front line was part of this from the start. Claims employees were among the experts we learned from in discovery, we checked in with them along the way, and several of our team members had worked the front line themselves. After the board said yes, I went “on tour” with the chief claims officer to show claims teams at major offices across the country what we'd built with their help. They would have to learn the new system and defend it to customers on top of their regular jobs. We made sure they wouldn't have to guess at why it mattered. A Know-Share-Do document carried it to the rest of the organization.