A Guide to Insurance Policy Administration Systems in 2023: Build, Buy, or Integrate?

By The Boost Team on Aug 22, 2022

11 min read

For insurance carriers and agencies, a policy administration system is the most essential piece of their tech stack. Whether you’re an insurtech startup researching your first insurance policy admin system, or an established player looking to upgrade, this comprehensive guide will cover the most current options on the market.

What Is a Policy Administration System?

A policy administration system (PAS) is the system of record for every transaction related to an insurance policy. The insurance policy admin system supports all operations that can be taken on a policy or quote, such as rating, quoting, underwriting, document generation, document storage, billing, endorsements, cancellations, invoicing, and more.

Whenever anything happens with a policy, the PAS records the transaction and takes any necessary action. This includes things like generating a quote based on information provided in an online form, modifying the policy’s coverage endorsements, or generating the appropriate documents for a new policy and facilitating delivery to the policyholder.

Because the PAS is the technical underpinning for all-online insurance transactions, a robust PAS is essential to offering the convenient digital insurance experience that modern customers expect.

If your business needs a new PAS, you have a few different options: you could build one yourself, buy a third-party PAS and the custom development work needed to use it with your offerings, or partner with an insurance-as-a-service company and integrate with their PAS.

Building a Policy Administration System (PAS)

What is the benefit of building your own PAS?

The biggest selling point for building your own PAS is the control. When you build your own, you have complete control over every aspect of the system, and you can determine how it will run. You have the freedom to customize the system to best suit your products and customer needs, and you can avoid the compatibility issues that you might have with a pre-built product. But that freedom comes at a cost.

Building a PAS from scratch is a very difficult and time-consuming task, with costs that run in the millions. Additionally, there are many details to consider that require nuanced expertise and ongoing attention.

What do you have to consider in order to build a PAS?

The biggest challenge that developers face when building a PAS is state-by-state variances in insurance laws and regulations. When it comes to insurance, each state operates like a separate country. Insurance products must be approved in each state individually, and every state has its own requirements for how insurance products should be sold. This includes rates, underwriting guidelines, notifications, how policy documents have to be delivered to the insurer, and more.

In order for a PAS to function smoothly, it must be able to automatically identify and follow all applicable laws for the state a policy is sold in. Otherwise, your agents would need to manually check and set up each transaction in the system - which essentially defeats the purpose of having the PAS. This means that you'll have to build the legal requirements for each state you do business in into your PAS so that it can automatically enable compliant transactions.

Here are a few examples of areas with significant state-by-state variation, that your PAS will need to account for:

Document generation and delivery

For any policy life cycle event–like a quote, policy issuance, midterm endorsement, cancellation, or renewal– documents need to be generated and provided to the insured. For admitted-lines products, individual state requirements can get very granular on what information each document must contain, and even specify which fonts and font sizes can be used. Once the documents are generated, certain states may also mandate how they can (and can’t) be delivered to the policyholder. When building your own system, you would need to take those different requirements into consideration, and build them into your policy administration system.

Cancellation notices

If a customer doesn't pay their monthly premium, your PAS should give them a notice saying that their policy will be canceled. However, each state has a unique timeframe by which that notice has to be sent. In some states it’s as little as 10 days after an unpaid bill, in others it’s as much as 40 days, and there is a lot of variety in between. For your PAS to function legally, each state’s timeframe needs to be built into your system so that the proper notification is sent out at the right time required by each policyholder’s home state, and the policy cancellations are executed correctly.

Changing regulations

To top it all off, laws are constantly changing, and the requirements for documentation, cancellations, taxes, and billing–to name a few–are always evolving or being added. Keeping your PAS up-to-date, and legally compliant with each state you sell insurance in, means keeping up with contract and insurance laws in each individual state. This means building your own PAS requires more than just technical resourcing - you’ll also need ongoing input from insurance law and compliance experts in order to stay current.

Essentially, the work of building a policy administration system is never done. You have to keep checking for new state filings, rules, and laws so that you can build them into your system.

How much does it cost to build a PAS?

Simply put, building your own policy admin system will cost you a lot of time and money. Building a PAS that supports one insurance product can take two to three years to complete, and several million dollars in development costs.

As we’ve seen, however, the initial build is only part of the PAS equation. After your system is launched, you’ll still need to budget for regular maintenance and update costs. These will vary based on the changes you make to your products; every time you refile your insurance product, you’ll need to update your PAS to support the changes. If you never update your products, then this cost will be minimal. However, if you want your products to stay competitive, you’ll probably do it regularly. Adding or updating PAS features is another frequent driver of maintenance costs.

If you have a multi-line business with more than one insurance product, the process becomes even more complex, expensive, and time-consuming. You would need to build a system that works for your most complex product and your simplest, taking all of their differences and intricacies into consideration.

For businesses that specialize in a single line of business and don’t intend to expand beyond it, building a PAS in-house can be a good option to create a system well-tailored to their specific needs. For businesses that don’t fit that scenario, it can quickly become a large ongoing expense. If you’re considering building your own PAS, it’s important to take these ongoing costs into account as you calculate the potential return on your investment.

Buying Third-Party Policy Administration Software

If building a PAS isn’t in scope, a second option is to buy an off-the-shelf software system from a company that specializes in building policy administration systems. There are several well-established companies that offer policy admin systems to insurance businesses of all shapes and sizes. However, the “off the shelf” label is a bit misleading. Deploying a third-party PAS isn’t as simple as adding to cart and installing software.

By definition, a third-party PAS is a generic piece of software, designed for use with any insurance company that buys it. What that means in practice, however, is that it’s not ready to use right out of the box. Before you can use a third-party PAS, it will need to be configured to support your business’s specific products and workflows.

How long does it take to implement an off-the-shelf PAS?

When you buy a third-party PAS, the amount of time required to get to market depends on the amount of customization you need and the kind of experience you want to offer your customers. In general, however, it’s a good idea to budget around a year.

You would likely kick off the process with a planning meeting to determine the scope of your needs. This includes issues like how many products your PAS will support (each product will need its own monthslong configuration), which specific products you offer and where you sell them, and whether you need any specific custom work from the vendor (for example, building a front-end to offer your products digitally). Once the contract is signed, the third-party company would adapt their baseline PAS to build a system to fit your specs, and integrate it into your existing systems and workflows.

If you have a single product line and are willing to accept a customer experience that may not fully incorporate your brand (for example, taking customers to a differently-branded portal), it can take around six months to a year. For multiple product lines, your vendor will need to do a separate configuration for each, which obviously would expand the timeline. Similarly, a highly customized front-end experience will require significantly more time and labor to bring to market.

If you have specific goals like a mobile-first experience or integrating your PAS into your website, that will require working with an API. This means you’ll need development resourcing on your side as well, to create the integration between your systems and your vendor’s API. How long this takes depends on several factors, but one of the biggest is the quality of your vendor’s API. If their API is low-tech or otherwise difficult to work with, it will negatively impact your developers’ timeline.

How much does it cost to buy a PAS off-the-shelf?

The total cost of buying an off-the-shelf PAS will depend on your vendor’s pricing model. The more traditional vendors tend to charge per-year service costs for building out and maintaining your PAS. These costs can be quite significant; some vendors’ prices start at $400,000 annually, with the potential to increase exponentially with any customization needs.

Rather than a large fixed yearly rate, newer vendors tend to charge a relatively low baseline platform fee, and then take a percentage of your gross written premium. Depending on your volume of business, this can be a more affordable option for companies that want to buy off-the-shelf. However, keep in mind that you’ll still need to pay a separate cost for the customization work to enable the PAS to support your products, and the managed services to build and implement. These indirect costs can sometimes be quite substantial, so be sure to ask questions about what you’ll need and get the full picture before making your decision.

Integrating with an Insurance as a Service Partner’s Policy Administration System

A third option is to partner with an insurance as a service company. This is a bit different from the other two options, as an IaaS partnership goes beyond just using your partner’s policy admin system.

What is insurance as a service (IaaS)?

Insurance as a service (IaaS) provides the whole solution necessary to support an insurance program. This includes a tech-forward PAS but also includes things like operational infrastructure, regulatory compliance, the insurance capacity needed to sell policies, and insurance products that can be white-labeled and sold under your brand.

When you partner with an IaaS provider, you’ll select which of their products you want to offer your customers, then integrate your website or app with your partner’s system via API. This offers insurtechs a significantly faster and lower-cost path to expanding their insurance product offerings than building a new insurance program themselves.

From a technology perspective, the PAS is provided as part of the IaaS provider’s standard solution. An IaaS provider’s PAS will only work with that partner’s products.

How long does it take to integrate with an IaaS partner’s PAS?

An insurance as a service PAS offers some considerable speed advantages vs. building a PAS yourself or buying a third-party system. Since the system will already be configured to support your partner’s white-label insurance products, there will be no need for the time-consuming development work required to build product workflows or customize an off-the-shelf PAS.

This is particularly beneficial when expanding your product offerings. If you wanted to add another insurance product to your lineup, you could simply select the product you wanted from your partner’s available portfolio, make a few modifications to your existing API connection, and begin selling a new insurance line within a few weeks.

However, there is still some initial development work required. You’ll need to build the connection between your digital front-end and your partner’s PAS, using their APIs. The good news is that insurance-as-a-service systems are designed for this, and so their APIs tend to be well-documented and easy to use. With a small development team and a high-quality partner API, you should plan for this step to take 3-6 months. The actual API integration itself usually accounts for about a month of development, with the rest of the time spent building the front-end to transact with the consumer.

It’s worth noting that some IaaS partners also offer solutions to help businesses get started faster, which include simple front-end experiences as part of the service (Boost’s QuickStart is one example). If your top priority is speed, it’s worth asking a potential partner about this kind of offering.

What does it cost to integrate with an IaaS partner’s PAS?

Because the PAS is included as part of an insurance-as-a-service offering, the cost structure differs from build or buy. When you work with an IaaS partner, you will pay them a commission for sales of their product, and usually also a platform fee for using their service. The PAS will be included in these standard costs, with no special purchase or subscription required.

Another major savings point with IaaS is maintenance. As we saw earlier, a PAS is never really “finished” - in order to stay fully functional, it needs to be continually updated with the latest state regulations. A major selling point for IaaS, however, is that the insurance backend is essentially taken care of.

This includes keeping the policy admin system up to date - your IaaS partner is responsible for staying on top of compliance developments and ensuring the PAS continues to meet all regulatory requirements. With a good IaaS partner, these changes should happen in the background without any need for your involvement. New state requirements or product updates should simply be there when you use the PAS.

The most significant cost of integrating with an IaaS partner’s policy administration system will likely be paying your development team to build the API integration and front end. The cost for this can vary depending on if you plan to use in-house resources or an outside development firm. As we saw previously, the majority of the time (and thus expense) necessary for this step is related to building the front end, so your costs will also vary based on the scope and complexity of what you intend to build.

The policy administration system is a complex but critical system for any insurance company, and acquiring a new one can be a major project. Consider your budget and timing needs, as well as how to manage ongoing requirements, when deciding whether to build a system in-house, buy from a third party or integrate with a partner who’s already done the heavy lifting.

If you want to learn more about insurance-as-a-service through Boost, contact us, or dive into building your insurance program with Boost Launchpad.

Explore Popular Categories

Boost News Embedded Insurance Employee Spotlight Fintech Industry Insurance 101 Insurtech Partner Stories Pet Insurance SMB Insurance

Explore Popular Tags

Affinity Insurance Beginner's Guide to Insurance Best Places to Work Boost Growth Boost News Boost Platform Boost Quickstart Built In Business Insurance Crypto Insurance Crypto Wallet Insurance D&O Insurance Digital Insurance Embedded Insurance Embedded Insurance Partner Employee Spotlight Emy Donavan Event Recap Events Fintech Fintech Industry HR HR Hiring Human Resources ITC InsurTech NY Insurance 101 Insurance 101 Insurance API Insurance Capacity Insurance Coverages Insurance Licensing Insurance Program Insurance Technology Insurance as a Service Insurtech Insurtech Connect Insurtech Events Insurtech Recruiting Management Liability Marketing Modern Customer Experience Money 20/20 Offering Insurance PAS Partner Stories Partner Success Personal Lines Insurance Pet Insurance Policy Admin System Recruiting Revenue Growth Startup Management Liability White-label Insurance crypto insurance crypto wallet insurance personal lines insurance security

Share this Article

The Boost Policy Admin System: How We’re Different

Sep 16, 2022

As an insurance infrastructure-as-a-service partner, Boost provides more than just white-label insurance products: we also provide the technical infrastructure necessary to digitally offer those products on your website. The most important part of any insurance tech stack is the policy administration system (PAS), which is the system of record for every transaction related to an insurance policy. As part of Boost’s API platform, we deliver a state-of-the-art policy admin system (PAS) to support our products at every stage of their policies’ lifecycle. What makes Boost’s policy admin system so special? Here are seven factors that set us apart. One of the most complex parts of building a PAS is accounting for the differences between state insurance regulations. Insurance products must be approved by each individual state that you want to sell in, and each state has its own laws, regulations, and requirements regarding the sale of insurance. Depending on the state, you may need to account for changes in areas like: These parameters are built into Boost’s policy admin system. When a transaction takes place, our PAS will automatically apply the necessary rules for the customer’s specific state. This ensures that every transaction is compliant with relevant state regulations. State regulations change, however, and today’s "fully-compliant" is tomorrow’s "out-of-date." To make sure Boost's policy administration system keeps up, we have a team of in-house insurance law experts who carefully follow insurance regulatory developments in all fifty states, and provide guidance to the Boost technical team to ensure our PAS stays current. With Boost, you never have to worry about staying on top of state regulatory changes - we do it for you. A seamless transaction experience is important for converting customers, but a seamless claims experience is important for keeping them. When your customers suffer a covered loss, a fast, easy claims process helps deepen their relationship and engagement with your brand. With Boost’s PAS, the potentially complex claims management process is made simple. Rather than having to manually contact carriers and manage the process yourself, our first notice of loss (FNOL) API acts as a unified point of entry to all the services you need. Our FNOL API is connected to all appropriate claims administrators. When a customer submits a claim for their policy, we automatically route that claim to the right administrator, along with all available supporting documentation. The administrator gets everything they need to start working on the claim, in real-time. This helps reduce the overall time needed to process a claim, which then means faster resolution for your customers. User experience is a vital component of any digital service, but we’re equally concerned with developer experience. Our insurance API was built from the ground up to leverage modern RESTful patterns, and to be easy for developers to build to and implement. The API is also designed for consistency, so that once developers understand a given resource, they understand how to use it across our platform. From issuing a policy to executing a renewal, midterm endorsement, or cancellation, once your engineers understand how to do it once, they can do it anywhere. An essential piece of a developer-friendly API is good documentation, and so we make sure that our documentation is exceptional. Boost’s API documentation is intuitively organized, personalized to your business, and updated in real-time - so you’ll never need to worry about working with outdated docs. You’ll also get permanent access to a dedicated testing environment, so you can build out integrations and test new platform features with no surprises when you go live. All this makes it easier than ever to get your developers up to speed, which means you can get to market or make updates to your integration that much faster. One reason why building a PAS is a complex and expensive process is that the system must be separately configured for each insurance product it supports, and each additional product adds to the cost and timeline. This can be a roadblock for insurtechs looking to expand their offerings with new lines of business. At Boost, our partners can choose from seven white-label insurance products (with more to come). Our PAS is fully configured to support each product at their launch, so our partner can easily add new LOBs by simply updating their existing API connections to include additional Boost products. Rather than needing to work with multiple insurance providers to get the breadth of products that you want to sell, and having to integrate multiple other systems and products into a PAS, you can integrate one time with Boost and still benefit from multiple lines. Growing your business by expanding your LOBs has never been simpler. It may feel like the entire world has gone all-digital, but a surprising amount of insurance isn’t quite there yet. Many traditional carriers provide partners with the ability to rate and quote customers digitally…but then switch to manual processes to complete the transaction. Critical insurance functions like issuing policies, creating endorsements, filing claims, or processing renewals regularly require you to contact the carrier, then wait for a response. Boost’s policy admin system supports an entirely digital workflow end–to-end, allowing you to offer your customers a truly seamless digital insurance experience. From underwriting to policy modification to renewal, any function necessary for an insurance transaction can be performed through the PAS, with an instant automated response. There’s no need for either you or your customers to ever pick up the phone. The Boost PAS is built on an enterprise-grade platform, leveraging modern industry tools like Kubernetes and Terraform. With 99.99%+ uptime, multi-region support, and the ability to handle multiple releases per day, you can count on the Boost insurance platform to be available when you need it. We understand that stability is vital, and that’s why we’re also careful to ensure that the Boost insurance platform is versioned so that it stays backwards-compatible. If you build an integration based on a current feature set, and we make changes in a future release, your integration won’t break. You’ll be able to keep using it the way you always have - which translates to lower development costs over time since you aren’t forced to redo your work every time we make a big update. Modern customers expect their digital experiences to be speedy, and Boost delivers. The response time of our API is up to 10x faster than other insurance carriers. That means when we get a request through the API, we can process data and get a response back to the user with unmatched speed. No waiting around for a loading bar to tick through - the customer gets what they need immediately, and gets on with their transaction. Working with Boost helps you launch new or expanded insurance offerings at a fraction of the time and cost required to DIY, and a significant part of that savings is driven by our PAS. We built it from the ground up to deliver a fast, reliable, developer-friendly platform, so you can get what you need, when you need it, and get back to growing your business. To learn more about insurance infrastructure-as-a-service through Boost, contact us, or dive into building your insurance program with Boost Launchpad.

Learn how APIs work, and the attributes of a high-quality API

What Makes a Good API?

Jan 13, 2023

APIs have become ubiquitous in modern technology - and in modern tech marketing. If you’ve ever looked into buying a software service or platform in the last ten years, the odds are that a good API was listed as one of the selling points. But what exactly makes an API “good?” Before we dive into that question, let’s take a minute to recap what APIs are, and why they’ve become so central to business and technology. Application Programming Interfaces (APIs) are the mechanisms that allow computer software to communicate with each other. APIs ensure that when one software system makes a request, another system can understand the request and respond correctly. When discussing the relationship between two software systems, the application sending the request for action is called the client, and the application sending the response is called the server. For example, your bank’s software system houses all of your banking data–that software system is the server. The banking app on your phone is the client. When you initiate actions in your banking app, like making transactions, checking your account balance, or even chatting with a representative, the app communicates with the bank’s software via its API and tells it which action to perform. The server provides an API for the client to use to perform actions. Let’s say that you want to make a transfer of funds from your checking account to your savings account. You open your banking app and navigate to the transfer tab where you are asked which account you are transferring from, which account you are transferring to, the amount you want to transfer, and any additional notes before you can submit the request. Within seconds of submitting your request, the number on your checking account decreases and the number on your savings account increases, and the physical amount of money you can withdraw from the bank for both accounts has changed. For this to happen and money to actually be moved, the app needs a way to tell the bank’s system what to do. That is where the API comes in. The APIs are the rules and protocols that are coded into both systems as a set of predetermined requests and responses. When you enter how much money you want to move and where you want to move it to, the client communicates with the API on the server. When the server receives that request, it reads the information and executes a predetermined set of actions to move exactly the amount of money that you requested into the correct account. From a technical standpoint, APIs consist of two main components: an address and a body. The address, also known as an endpoint, tells the data where it's supposed to go (in our example, the bank’s system). The body is the data that will be delivered to that address. APIs allow developers to automate functions and create a very clear, easy-to-understand relationship between what the user needs to do and what the computer systems will do in response to their requests. Without APIs, the modern conveniences of apps, digital transactions, and the like couldn't exist. Everything would require human, manual interference. Instead of quickly logging into an app on your phone to make a transfer of funds, you would have to physically go into your bank or talk to a teller over the phone, and your request would take much longer to process. But because of the code and predetermined actions built into digital systems through APIs, users can interact with services much faster. You can transfer your money in seconds, and the bank can gather your information, automate manual processes, and make their work more efficient. Now that we’ve established what an API is and why they are important, let’s talk about what makes a good API. While all APIs follow the same principle of allowing systems to communicate, not all APIs function equally well. The quality at which an API is developed impacts how effective any system will be at actually doing what the user is asking for. So what makes a good, well-constructed API? Here are 5 aspects of a good API. First and foremost, APIs should be simple. This means having clear addresses, endpoints, and easy-to-understand request body structures. In our banking example, the bank’s software and the app’s software are presumably owned and operated by the same company–the bank. Oftentimes, however, the client and the server belong to different companies. Developers at both companies will need to build their systems to be able to understand the API and react accordingly. A simple, straightforward API structure makes it easier to correctly implement. Let's take a look at an insurance API example. Say that you own a pet store and you have partnered with an insurance carrier to offer embedded pet insurance to your customers. In order for your customers to purchase insurance from you, they have to enter their information in a form on your website. Then the insurance company receives that information, makes an underwriting decision, and issues the policy. In order for the insurance company to receive your customers’ information and take action on it, your front-end systems need to communicate with your insurance partner’s system. The set of requests and responses between these separate systems should be simple and clear. The simpler the API, the faster and more seamless the integration between these two systems will be, and the fewer opportunities for mistakes. A good API should be able to execute all (or at least most) of the functions a user would need. Going back to our bank example, an app that allowed the user to check their balance but not to transfer funds wouldn’t be very useful to the customer. To be effective, the bank’s API needs to be able to handle most of the things a customer might want to use their bank app for. For more complex functions, it’s important that an API be able to collect and process all of the information needed to return a response. For our pet insurance example, let’s say that in order to decide to issue a policy, the insurance company needs ten pieces of information from the customer. If the API could only handle five of those pieces of information, the rest would need to be submitted separately (likely over email or a phone call with an insurance agent). It would be an inconvenient experience for both the customer and the insurance company, and increase the likelihood of manual errors. A good insurance API would be able to collect and process all information needed to issue a policy, right from the app or website. Errors are inevitable with any piece of software. What sets a good API apart from a bad one is how it handles errors when they arise. Good error handling can make the difference between getting back on track quickly, or getting bogged down in bug reports. Broadly speaking, there are two kinds of software errors: 400 errors and 500 errors. The difference between the two is how much information they can give about what’s gone wrong. 400-type errors are specific errors with an identified problem. One of the most familiar is a “404 not found” error, which occurs on the web when a user tries to navigate to a web page that doesn’t exist. If you’ve ever mistyped a URL or clicked on an old link to an inactive page, you’ve seen a 404 error. Because 400-type errors give a specific reason for why the request failed, they also give direction on how to go about fixing the problem. 500-type errors, on the other hand, are much less clear. 500 errors indicate general server failures, crashes, or bugs. These tend to be more frustrating for users and developers alike, since they don’t contain much to go on for how to fix it. A good API should be able to produce mostly 400-type errors that identify the problem so that it can be easily tracked and fixed. When an API produces a lot of unidentifiable 500 errors, it indicates a poor-quality API. While not technically part of the API itself, good documentation is essential to a successful API. As developers integrate systems or build the API rules into an app, documentation has a direct impact on how quickly they can work, and how well they can avoid errors. Good documentation should specifically describe each of the endpoints, what the requests should contain, and what the responses will contain. In many applications, an API will touch various parts of an overall system. This is especially true for more complex operations like our pet insurance example. On the user’s side, applying for insurance might seem like a straightforward software operation - they fill out the form, and the software sends it. On the insurance company’s side, however, it’s much more complex. When the user submits their application, numerous parts of the insurance company’s system will be involved with the process. One part of the system will document the personal information they provided in the application. Another part will use that information to make calculations around premium costs, and still another part will generate the policy itself. In order to make sure this all happens seamlessly, developers need access to comprehensive, up-to-date documentation for how all these components interact and are executed via the API. Finally, a key benefit of APIs in general is speed. Rather than trudging through manual processes, APIs are meant to automate functions that would take much longer if human interactions were required. A good API should allow information to be passed between servers quickly and efficiently. Going back to our earlier examples, no one wants to sit and wait to see if their bank transfer request or their insurance application was successfully received. For the best user experience, APIs should process requests in less than a second. If an API is slow to respond, it may indicate inefficient architecture, or that the servers are housed on insufficiently powerful hardware. APIs allow businesses to function in a modern, technologically savvy way. By continuously improving the communication between client and server systems, consumers have access to a wider variety of digital transactions and services than ever before. If you want to learn more about Boost’s API and how we can help your business stand out through insurance-as-a-service, contact us, or dive into building your insurance program with Boost Launchpad.

What is Parental Leave Insurance?

May 10, 2022

If you’ve never heard of parental leave insurance, you’re not alone. Parental leave insurance is a relatively new product on the market but an increasingly necessary one. Let’s explore a few of the reasons why parental leave is important and what solutions insurance can offer. Becoming a new parent is a major life event that can be happy and exciting, but it can also present challenges in the workplace for both employees and employers. Over 60 million Americans are parents, but the U.S. is one of the few countries worldwide with no universal parental leave requirements. As such, nearly 30% of working women quit their jobs after giving birth. In states that do require paid parental leave, however, the rate of mothers leaving the workforce dropped 20-50%. It’s no surprise that according to recent studies, “When deciding to accept a job offer, 66% of employees said the employer’s paid parental leave policy is important.” Parental leave is a significant DEI issue for retaining female employees who become mothers. Social and cultural shifts over the past few decades have made this issue more important than ever. “With the increase in female employment rates, coupled with the decline of the male breadwinner family model…entitlements to job-protected leave after childbirth has become important policy measures to support parents” (EIGE). Employees ranked parental leave as the third most desired benefit, outranked only by flexible work and paid insurance premiums, but many small and medium enterprises (SMEs) don’t offer it. In fact, only 23% of private employers in the U.S. offer paid parental leave in their benefits package, which puts SMEs at high risk of losing their employees when parenthood arises. Though paid parental leave is a highly requested benefit, it can be expensive for businesses to cover. For SMEs, this often prohibits them from offering any benefit at all. Adding to the difficulty, paid parental leave is also an unknown liability on the balance sheet. Employers can't predict if or when their employees will use it, which translates to a potentially large expense that they can’t accurately plan and budget for. The Facebooks and Googles of the world can afford to be generous and pay that out of pocket, but many smaller companies can't. This puts those smaller companies at a disadvantage for both acquiring and retaining talent. In the absence of a national parental leave solution, it’s up to the private sector to find ways to support new parents in the workforce. Parental leave insurance is a business insurance innovation designed to make parental leave affordable for small and medium enterprises. This is how it works: an insurance provider offers the parental leave insurance product, sometimes as part of a larger business insurance suite. The SME chooses a package that covers the kind of leave they want to offer their employees. This includes factors like what percentage of the employee’s salary will be covered and the length of leave the SME will offer. The SME then buys the policy, and pays the insurance provider a recurring premium based on their selected benefits and employee demographics. When a covered employee takes parental leave, the small or medium enterprise will file a claim through their insurance provider’s claims process. The SME will then be reimbursed for the cost of paying the employee during the covered leave period, as spelled out in the parental leave insurance policy. It’s a solution for providing this benefit that mitigates large, unexpected leave costs. Instead, the employer pays a regular, planned amount in premiums, and can rest easy knowing their insurance policy will protect them. No more unknown liabilities on their balance sheet. Meanwhile, the SME can reap the benefits of attracting and retaining top talent by offering parental leave. With over 30 million small and medium enterprises in the U.S., there is a significant opportunity for insurtechs and embedded insurance providers to help businesses affordably provide this valuable benefit to their employees. Offering a first-of-its-kind, highly desirable insurance product is a forward-thinking way to set yourself and your clients apart in the market. By offering parental leave insurance, you can help your clients attract and retain top talent. Employees are far more likely to work for a company where they feel supported, and this product is an effective way to establish your brand as focused on employees’ well-being while helping your clients to do the same. More than ever, employees want competitive, comprehensive, and inclusive insurance packages, and offering parental leave is an opportunity to positively impact employee experience and perception of their employer. Additionally, adding parental leave insurance to your product lineup creates new cross-sell opportunities to boost revenue and LTV with your existing customers, and deepens their business relationship with you. Parental leave insurance provides an opportunity to stand out from the competition. This is a first-of-its-kind product that is not being offered by many insurtechs, but benefits employers and employees alike. You have the opportunity to get ahead of the curve with this innovative white label insurance product. If you want to learn more about growing your customer LTV with Boost’s Parental Leave Insurance, contact us.