Key Facts
• In claims adjusting, sending compliant letters is not only an important legal requirement, but critical in keeping customers informed about what is happening in their claim.
• The client wanted to enhance their homebuilt solution to better manage letter templates, allow the system to generate letters for adjusters to save time, be more accurate in customer communications, and ensure compliance with various state-by-state requirements.
• The product shipped a month early thanks to close collaboration with multiple teams, and reduced average time writing a letter by 75%, from ~1 hour to ~15 minutes in the most common cases.
The Problem
A large part of the regulatory requirements focus on sending letters with the correct language and information to customers when certain events happen on a claim, or at standard intervals while the claim is being worked. However, the system didn't have an easy way of managing these letter templates or creating letters.
The core problems facing the team were:
• Most templates were managed in Google Drive, not the system. The templates that were in the system could only be edited and managed by engineers.
• Users had to find information from the claim and enter it into the templates manually, causing even simple letters to take up to an hour to complete, and some more complex letters taking up an entire day.
• Users often accidentally overwrote Google Doc templates with sensitive information or created copies of the templates to use and reuse, which could not be updated or managed by the compliance and legal teams.
• The lack of metadata from Google Docs meant the system had no way of tracking what kinds of letters were sent and when, making it hard to audit and prove compliance
Only two of the existing templates had minimal ability to autofill information in the claim and had to be managed by engineering. Most templates were managed outside of the system, and some were outside of the users flow entirely.
Defining the Solution
The claims group for the client decided to take on the large task of overhauling and updating all of their letter templates. At the same time, the product teams were looking for ways to give the system more information and ability to fuel their automation goals. I was pulled in to work as the senior product designer with a product manager, a team of engineers, and several legal and claims subject matter experts. I leveraged previous experience with document management clients to set the direction of our discovery, where we looked to learn a few key pieces of information:
• What were the types of templates adjusters needed to use and how were they organized? How did adjusters think about these templates when trying to find the right one to use?
• What pieces of information did the system need to auto-fill for the adjusters? What information was too complex for the system to handle? How were these placeholders related and was there any complex logic needed?
• How often were these templates updated? Who was responsible for updating them? Did we need specific features around version control?
• What tools and existing products or features could we leverage to help us? Did we have to build this from scratch or could we reuse previous work in the system or in Google Docs?
A white board example of working through the template types, naming conventions, relationships, and what metadata we may or may not need about them.
As we were working through some of these questions, the claims team began going through and taking stock of all of the templates they had and needed to update. This made it incredibly easy to observe and work very closely with them to get an understanding of exactly what was needed and how things were related.
We started creating placeholders based on what little things already existed, then we listed information the system had about the claim, vehicles, and people already involved and worked with the SMEs to narrow it down to what was most useful. We then started making "compound" placeholders for commonly used combinations and formatting.
Sketching
With a firm understanding of what these templates were and how they needed to work, we set out to visualize our understanding and begin exploring options for how to execute the work.
An early exploration allowed the SMEs to continue using Google Docs for management. Ultimately this was ruled out because we still couldn't control, fill, or find the templates or information from within the system.
Quickly we moved to sketches using the internal system and 3rd party rich text controls we had used elsewhere. Visualizing the information architecture and flow of finding and filling the templates let us test our understanding with adjusters and SMEs.
Final Product
Because the claims groups were actively working on overhauling their templates, and because we knew that in order for the solution to be useful, it needed to have all of the templates adjusters needed from the start, we decided to focus first on the template building and management portion of the system. Then we could reuse those pieces to build the adjuster facing screens.
Through discovery we learned that the Department, State, and template type were together enough information for adjusters and managers to find and use the correct templates. They also gave solid data points the system could leverage to classify both the templates and the documents created with them. Template types could be created by managers, and they were given a type-ahead box of all existing ones to limit accidental duplicates. Managers could then select from any of the available placeholders to bring into the template or could create their own by putting angle brackets around any phrase to give the adjuster direction on what they needed to manually insert in its place (for example, specific coverage language).
Once the templates were live, the adjuster interface reused much of the same design and components to streamline development.
For the adjusters, we leveraged the same organization that managers used to create and manage templates. We also leveraged a similar design for creating the document but replaced the template metadata area with controls for the adjuster to set the context of the letter by selecting the appropriate parties and vehicles for the system to use for the autofill. Instead of the placeholder selector, we showed a list of placeholders that were still in the document, including custom ones made by the template creator, and there was validation to ensure adjusters didn't send letters with missing information or embarrassing unfilled placeholders. Adjusters could then decide if they wanted to send the letter by email attachment or by mail. Quick follow enhancements were made to allow the user to simply generate the document and attach it to the claim file without sending it, as well as restricting certain letters to only be sent via mail for compliance reasons.
Results and Next Steps
For many of the common letters, adjusters time on task was cut by 75%, from an average of ~1 hour to an average of ~15 minutes. Even for the most complicated letters, averages went from being measured in days to being measured in hours. Finally, over the course of working together so closely, the claims compliance team and the product teams were able to deliver both the template overhaul and the template management and letter generation product a month ahead of schedule, accelerating the value of the project and making time for quick follows.
Some scope of the project was cut either because it was large enough to be considered a separate project entirely, or because the team wasn't certain until the product was released about what would be most valuable to pursue. Some of the following are items that were identified to be worked on next:
• Many letters for adverse actions (e.g. denying coverage or a claim) need to be reviewed and approved by a manager to make sure they are properly written. Ideally, users could send drafted letters through a manager approval flow, but this was enough work to be considered a separate project.
• Some of the more complex letters really take a lot of time and work that can get interrupted or require using multiple screens and windows. However, if the user closes or reloads the window with the letter generator in it, it will lose all of their work with no way to save a draft. Saving drafts was considered earlier, but the need wasn't clear until the product was rolled out.
• Giving the user more options for data to access from the system, or ways to access more complex data such as policy language to make transferring of that language into the letter easier. This was considered too large of a project to include at the start, and the value was unclear until the system was rolled out.
• The current document management scheme simply uses the file names to organize files. Bringing the tool into the system gave us more metadata about these letters and templates which could easily be used for a more robust system. However, metadata-based document management was decided to be enough work to explore as a separate project, however the metadata here is being recorded to be leveraged later.