Sedgwick: Mapping the Service Behind an On-Demand Inspection App

Sedgwick wanted to bring additional people into insurance-adjustment work after major weather events, including hurricanes and tornadoes. An on-demand app would need to help people understand their assignments, collect the right information and return it to the claims process. Supporting that model also required connections between data held in different systems.

My consulting assignment was to understand the work, map those connections and organize the app's decision logic. I delivered a service blueprint and an app decision tree, then walked an internal employee through the research and design so he could take ownership of the work.

Process at a glance

• Discovery: Three days with marketing, technology and sales, walking through their processes and mapping the systems together.
• Field research: A day following an adjuster, plus phone interviews with two or three experienced adjusters, to understand the work and its practical constraints.
• Service blueprint: Traced the information alongside people's actions, identified manual handoffs and recommended changes to how the work was organized.
• App decision tree: Organized inspection variables and conditional choices into a step-by-step path for the proposed app.
• Handoff: A full-day walkthrough of the blueprint, decision tree and research with the internal employee taking over the work.

Tracing the data connections took about three weeks, with field research during that investigation.

Establish how the process actually worked

I began with three days of discovery involving marketing and technology leads, along with sales. Each participant walked through their process while we mapped the systems on whiteboards. The teams understood their own responsibilities, but they hadn't laid out the complete process together.

As we tried to follow information from beginning to end, several connections were unclear. People knew information reached the next stage, but the systems we were drawing did not explain how it got there. Tracing those connections took about three weeks. During that investigation, I paused the data work to spend a day following an adjuster in the field.

I watched the sequence of measuring, reviewing damage, taking photographs and recording notes. I also conducted phone interviews with two or three experienced adjusters to understand the details of their work. One adjuster in Kansas had developed a particularly organized process and could explain steps that others tended to leave out when describing familiar tasks.

Those details mattered for an app intended to guide people who might not already know the work. An experienced adjuster could fill gaps from habit; the app's process needed to make the relevant steps explicit.

The interviews also made practical constraints clearer. An adjuster in New York described managing photographs and notes while working at height and wanted to be able to speak into his phone. That was a concrete input into understanding how information capture needed to fit fieldwork.

Make the human handoffs visible

I mapped the adjusters' actions alongside the information they collected and the systems that used it. This formed the service blueprint: a view of the people, systems and handoffs involved in sending an assignment out and bringing the completed work back.

View the original service blueprint (PDF) (opens in a new tab)

One gap remained after the field information returned. We could not account for its transfer into the final part of the process serving the insurance companies. We eventually found a team of three employees copying information between systems.

That work had not been visible in the earlier process discussions. Copying, pasting and emails were providing connections that the systems themselves did not have. Including those activities in the blueprint explained how information actually moved and where further integration would be needed.

The discovery also led to an operational recommendation. I proposed moving those employees' work earlier in the process, using their knowledge to prepare workflows and assignments for people going into the field. The intended benefit was to apply that knowledge before the work began and reduce the need for later copying. This was a recommendation; I did not oversee its implementation.

Turn the inspection variables into a decision tree

The service blueprint established the wider process. The app also needed a clear sequence for the decisions within an inspection.

I organized those variables into a large decision tree. The information architecture separated inspection areas and then followed the choices relevant to each one. An interior inspection, for example, led to room-specific details: a kitchen included items such as cabinets and counters, while a bathroom included a toilet, bathtub and shower. Roof, siding and contents inspections followed different branches.

The aim was a straightforward path through a complex set of choices. Getting there required untangling the conditions behind each step and putting them in an order that made sense for the person doing the work. The decision tree documented that logic for the app's development.

The project was divided into two phases: starting the app first, then addressing the deeper data connections and APIs. Both were substantial pieces of work, with the data integration expected to be more demanding. As I recall, the product manager chose that division to manage the two lines of work.

Hand over the model and the reasoning

I spent a full day with the internal employee who would carry the work forward. We went through the service blueprint first, then the app's decision tree, discussing the research and answering his questions. He had already seen some of the work; the walkthrough brought the pieces together and gave us time to work through the details.

The completed consulting work made the operational handoffs visible and translated the inspection variables into a documented app structure. The handoff included the reasoning behind those artifacts so an internal owner could maintain and develop them further.

About a year later, the product manager told me they were still working on the project and that it was going well. My direct contribution ended with the research, recommendations, blueprint, decision tree and handoff; I don't have a confirmed launch or measured operational results to report.