Builder's Risk

Builder's Risk - Best Practices

This page covers where to place Builder's Risk in your platform, how the integration works, and what your builders will experience. The technical reference and code samples follow below.

Terms used on this page

Builder's Risk: property coverage for a structure while it is being built. For policy details, talk to our insurance team.
Quote: the price and coverage offered for a specific project, based on the details you and the builder provide.
Bind / purchase: the moment the builder accepts the quote and pays. Coverage is in force from here.
Underwriting: our team's review of a project that can't be priced automatically.
Additional interest: a party other than the builder, usually the lender, that is listed on the policy because it has a financial stake in the property.
Change request (endorsement): any change to a policy after purchase, such as extending the end date.

Why Builder's Risk belongs in your platform

Your customers need Builder's Risk coverage for every financed project, and lenders require it before a loan closes. Today they buy it off your platform through a broker. Your users leave, you have no view into the transaction, and you capture none of the revenue.

Built in, it becomes a revenue stream, a coverage status your customers can act on, and one less reason for them to leave your product.

Coverage needs to be in force before construction begins, and the lender needs proof of coverage before the loan closes. That timing is why the purchase belongs inside your platform, where the project and loan details already live.

Placement

Placement of the Builder's Risk offer differs based on the type of platform. At minimum, every integration needs a project-level offer the builder can reach on their own.

Construction management platforms

The drop-in component sits on the project page, so a builder or project manager can buy a policy without leaving your platform. Prompt the builder with a notification tied to the construction start date.

How to implement: render the drop-in component on the project page and populate it from your project record.

Pass the data you already hold and let the component collect the rest. The more fields you pre-populate, the smoother the experience and the higher your conversion rates.

Likely supplied by your platform: property address, project dates and type, construction cost, builder name and contact details.
Likely supplied by the builder inside the flow: federal employer identification number, loss history, years building.

Lender management platforms

The lender sets the coverage amount and the additional interest on the policy, then triggers the builder to complete the purchase in their portal before the loan closes.

This is the better pattern for lending platforms for two reasons:

More accurate policies. The lender sets the policy's specific requirements up front.
Your platform becomes the place requirements are satisfied. You can require the builder either to purchase through you or to upload an existing policy.

What the lender provides: that a policy is required, their entity name and address, and the additional interest type. Everything else comes from your project record or from the builder in the flow.

Additional interest types: MORTGAGEE, LENDER_LOSS_PAYEE, LOSS_PAYEE, ADDITIONAL_INSURED

How to implement:

Set the additional interest type as an organization-level default, starting with MORTGAGEE. Allow it, along with the entity name and address, to be adjusted per project. It rarely changes between projects, but the flexibility helps.
Your platform owns the lender workflow and interface. We'll partner with you on design and can be as involved as you'd like. The drop-in component accepts the lender details above.
When the lender triggers a request, notify the builder and place the drop-in component within your builder portal to complete the purchase.
Make policy documents available in your platform so the lender can review them.
If you support uploading an existing policy, that upload flow lives in your platform. Talk to us if you'd like guidance on this step.

Insurance overview (both platform types)

Give your customers one place to see every project alongside its coverage status: covered, not covered, or expiring. Purchase can happen on the same screen with the same component, so no project goes uninsured because someone missed it.

How to implement: Create a list or dashboard view.

Within this view show policy status based on project, consider status options: Active, Expired, Cancelled. Look to flag items that do not have an active policy, especially those where the loan closure date is imminent or those that are in progress (set to expire soon). Policy metadata your platform should collect and events such as purchase, cancellation, and changes are available through Webhooks & Metadata.
Allows a user to purchase a policy from this view as well. When a project is selected, render the drop-in component on this screen so purchase happens inline.

Implementation details

Why use the drop-in component

We continue to optimize our offer, and the form can change over time based on our carrier relationships and requirements. With the drop-in component, you get all the value of these improved offers with no development work on your side. It keeps insurance off your roadmap so your team can focus on your product. We'll always contact you ahead of any major change.

The component owns the whole quote and purchase flow. Our recommendation is to use this component, do not rebuild any part of it in your own UI, or use the quote or purchase endpoints directly. There are API calls outside the component required in some situations.

Payments

In most cases the drop-in component collects payment for this product. If you already have a payment processor, we support card-on-file and split payments. See Payments for supported processors and setup, and Drop-in component payments for component options.

Conversion tracking

Call VerticalInsure.trackOffer(client_id) when the Builder's Risk option is displayed, not when it's clicked, and pass the returned ID into the component as tracking_offer_id. That gives us the top of the funnel. The component tracks everything from the click onward. Conversion stats are in the Partner Portal. See Conversion tracking.

Saving a quote for later

Pass a unique project ID in the unique_offer_id field and we'll store the quote so the builder can return and purchase later. If any project details on the quote change, we'll request a new quote for the builder.

Branding

The component can be themed to match your platform, including layout, colors, and fonts. See Usage.

Policy documents

Policy documents are stored in our customer portal and emailed to the builder after purchase. Providing access to these documents in your platform is optional. In the lender workflows this is highly encouraged as the lender requires them for review. A link for a customer to view a policy document can be obtained using the Retrieve Policy Document API. To download policy documents server-side, please reach out to our implementation team for guidance.

Quoting experience

One offer per project

The builder sees one offer, priced for their project. There are no plans or tiers to choose between, which keeps the purchase to a few steps.

When we can't quote instantly

Instant quotes cover new construction in most states. Some projects need a closer look from our team before we can offer coverage, including renovations, commercial projects, projects in Alaska, Florida, and Hawaii, and projects with elevated fire risk.

When that happens, the builder sees a message that our team will be in touch. These are often unique builds, so we follow up by email and shop the project with other carriers. Any policy purchased this way is attributed to your partner account. It appears as an external_policy in the Partner Portal.

Change requests

Changes after purchase, including policy extensions, go directly to our support team at support@vicoverage.com. Your platform doesn't need to handle them.

Example

<html>
  <head>
    <script src="https://cdn.jsdelivr.net/npm/@vertical-insure/embedded-offer"></script>
  </head>
  <body>
    <div id="offer"></div>

    <script>
      new VerticalInsure("#offer", {
        client_id: "test_********************************",
        partner_client_secret: "your_partner_client_secret_here", // Obtain from backend using /v1/auth/partner/secret
        component_type: "construction.builders_risk",
        product_config: {
          "builders-risk": [{
            "customer": {
              "email_address": "test01@verticalinsure.com",
              "first_name": "John",
              "last_name": "Doe",
              "state": "MN",
              "postal_code": "55414"
            },
            "policy_attributes": {
              "property": {
                "street": "789 Property St",
                "city": "Minneapolis",
                "state": "MN",
                "postal_code": "55432",
                "county": "Anoka County"
              },
              "project_details": {
                "category": "NEW",
                "type": "FRAME",
                "start_date": "YYYY-MM-DD",
                "end_date": "YYYY-MM-DD",
                "construction_cost": 500000
              },
              "builder": {
                "name": "Vertical Insure, Inc.",
                "street": "10 2nd Street NE",
                "suiteOrUnit": "#103",
                "state": "MN",
                "postal_code": "55413",
                "city": "Minneapolis",
                "phone_number": "2222222222",
                "email_address": "hello@verticalinsure.com",
                "fein": "12-3456789"
              },
              "loss_history": false,
              "years_building": 2,
              "insured_type": "CONTRACTOR"
            }
          }],
        }
      }, function(offerState) {
         console.log(offerState)
      });
    </script>
  </body>
</html>

Builder's Risk

On this page