Herald Changelog

Six GL Products

Sorry this is a bit late. Last week, over three thousand leaders gathered in New York City at an Insurtech Insights event and Yours Truly was one of them. Still, we’re happy to announce that Herald now supports six General Liability products. This newest integration brings our total number of supported products up to fifteen and marks the sixth new product we’ve launched in the last eight weeks.

Updates to our dynamic application

Developers can send in an array of products to our dynamic application endpoint (/applications) and receive a list of questions required to get quotes. Over the last two weeks we updated this endpoint to make it easier to use in three main ways:

• We now set the “value” property of unanswered questions to “null” instead of omitting that property entirely. This helps developers identify unanswered questions both visually (e.g., in Postman) and programmatically.
• Certain questions ask you to submit an array of equivalent values. For example, imagine a question that asks for a list of one or more addresses defining all locations relevant to a business. Previously, we returned two unanswered instances of the location value: one marked required and one marked optional. This behavior confused developers who did not understand why the second optional location was included. Now, we start with one required location, and only return an optional location once the first location is given an address.
• Finally, we updated the order in which properties are returned from the /applications endpoint to ensure consistency. This consistency makes it easier for developers to read and understand /applications responses.

Fixes and improvements

We also made the following improvements and fixes to Herald:

• We updated the error message returned when a customer sends in an expired JSON Web Token (JWT) to more accurately describe the issue.
• We added the ability for distributors, at the quote stage, to submit risk parameters that are optional to quote but are ultimately required to bind.
• We expanded our taxonomy of accepted legal entity types to include “Trustee.”

‍

Another one

This week, we launched another Workers’ Compensation integration. This addition brings our number of Workers’ Compensation products up to three and our total number of supported products up to fourteen. This product launch marks the fifth new product we’ve launched in the last six weeks!

Updates to our dynamic application feature

Our dynamic application feature allows developers to easily get and render the correct underwriting and coverage questions on screen for their users. To create a dynamic application, developers make a POST request to our /applications endpoint.

For this initial request, we only require the array of products for which the user wants to get a quote. The response to a successful POST /applications request includes all the known underwriting and coverage questions needed to successfully submit that quote. We also tag each question with metadata that helps developers render those questions correctly.

One request we heard from developers was to include additional information to help them organize these questions in various ways depending on the user experience they were building. During this sprint, we updated the /applications response to clearly tag each answer with the set of products for which that answer is relevant. We also added additional attributes to indicate whether each parameter was required to get a quote or to ultimately bind coverage.

Fixes and Improvements

We also made the following fixes and improvements this release:

• We added support for over 100 new industry codes across our BOP and Cyber products.
• We fixed a bug in our /submissions endpoint where, despite sending the correct producer information to the carrier, we occasionally returned the wrong producer information to the distributor.
• We fixed a bug where, for certain fields in the /applications endpoint, entering zero (0), false, or NULL blocked the application from reaching a “complete” status. Now we allow these values in all applicable fields.
• We added “early decline logic” for a Workers’ Compensation product that doesn’t have appetite for certain legal entities.
• We updated our Sentry alerting system to capture the HTTP method (POST, PUT, GET, etc.) of the triggering request to help our customer support team more quickly troubleshoot issues for our developers and their users.

‍

Our third BOP product

This week we launched another Business Owners Policy (BOP) product. This integration brings our number of supported BOP products up to three. In the process of adding this BOP product we added support for over 470 classes of business including electricians, plumbers, painters, and many others.

Expanded BOP coverage values

This week we expanded the acceptable range of inputs for certain BOP coverage parameters. In particular, we now allow distributors to request zero ($0) for both the building limit and the business personal property limit when making BOP requests.

(Even more) granular industry mapping

Herald uses a very granular set of industry descriptions in order to map our standard industry taxonomy to the variety of taxonomies that our carrier partners use. In particular we use the “Index Entries” from the NAICS classification system, which offer industry descriptions at one level deeper than the 6-digit NAICS code.

Until recently, every Herald industry description in our taxonomy mapped cleanly to no more than one code for each of our carrier partners. In other words, every input had only one output.

This release we encountered our first scenario where our industry descriptions mapped to more than one industry code in a carrier partner’s taxonomy. As a result, we built conditional questions that helped refine our industry selection to accommodate the needs of this carrier partner.

Increased visibility of user behavior

Every quote from Herald includes a link to the broker portal of the carrier who provided that quote. Until recently we shared that link as it was sent to us by each carrier partner. This approach was quick and easy to launch, but limited our ability to understand when broker users visit the carrier’s portal.

This release we replaced these links with new links that allow Herald to track when users visit quotes on the carrier’s portal. This allows us to enhance the analytics we return to distributors and carriers partners to find insights about their users’ behavior.

‍