Applications

In order to quote or bind an insurance product, the carrier offering the policy must first receive an application. The application is the carrier’s way of gathering information on a business to determine eligibility and calculate pricing. An application can collect information related to the business’s operations, exposure to risks, and claim history; the list of questions asked will vary by carrier and by product.

Applications at Herald

At Herald, an application is comprised of a product (or multiple products), and the set of information a carrier requires to get a quote for that product. We break out the questions of an application into two major categories: [.h-code-link]risk_values[.h-code-link] and [.h-code-link]coverage_values[.h-code-link].

‍

Risk values

Risk values are the values needed to describe a business and its operations, which will vary depending on the product(s) you are using. Each question that falls under the risk value umbrella is a [.h-code]risk_parameter[.h-code]. A risk parameter could be anything from the applicant’s name to an industry-specific underwriting question, which can affect the applicant's eligibility or quoted price. Here are some examples:

‍

Coverage Values

Coverage values describe the nature of coverage for an insurance policy, and vary by line of business and carrier product. Each question that falls under the coverage value umbrella is a [.h-code]coverage_parameter[.h-code], and each one is specific to a certain line of business. Coverage parameters encompass everything from the policy effective date to the individual coverage limits. Here are some examples:

The are hundreds of risk and coverage parameters, but only certain parameters are relevant for each product.

• Some parameters have conditional relationships, meaning they only become relevant under certain conditions. For example, a carrier may need to ask if an applicant serves alcohol, but only if the applicant has provided a certain class code for an industry such as catering.
• Parameters can also have parent/child relationships, where a parameter is a subset of a parent parameter. For example, if an applicant performs work in multiple industries, they may need to submit revenue for each industry. In this case, the risk parameter for industry (class code) would be a parent of the risk parameter for revenue.

Creating Applications

In order to submit an application to a carrier, an answer to every relevant question must be included. All applications are submitted using [.h-endpoint-link]/submissions[.h-endpoint-link] but Herald offers two ways to fill out an application. You can either create your own static application, or use the Dynamic Application product.

‍

Dynamic Applications

Trust us when we say that applications have a ton of complexity and conditionality. To simplify the process of creating applications, Herald developed the Dynamic Application. Our Dynamic Application removes the burden of managing questions, conditionality, maintenance, and so much more.

From a high-level, the Dynamic Application works by sending you every question required for a certain set of products. As those questions are answered, Herald sends back any conditional questions that may now be necessary. Each risk and coverage parameter includes metadata to help you render this on screen with validation. For more information on Dynamic Applications, read our deep-dive on Dynamic Applications with Herald.

‍

Static Applications

[.icon-alert][.icon-alert] Herald strongly recommends using the dynamic application for all the reasons mentioned above.

To create a static application, you can gather all of the relevant questions for your products from our appendix. The appendix outlines the relevant products, question type, acceptable values and more for each risk and coverage parameter. In this case, you will need to build logic to support any necessary conditionality for your application.