phonon you are absolutely right. It's not possible to use A/B tests for admitted insurance use cases in the US, and we don't let our clients do so. This tool was designed with non-admitted use cases or non-insurance products, such as waivers, in mind.
Also, the names on the screenshot are illustrative as the client could vary other factors that are not price in the A/B test, like user verification workflows, deductibles offered, etc. The goal is to find the optimal solution that creates value for the company while matching the risk preferences of the users.
Thank you for relaying that so clearly. So here's the problem.
On Product Hunt[0], 2/8 screenshots clearly show that type of illegal use case ("+10% pricing"), and your own (US based) customer thanks you for "AB test pricing"[1]. You also can't get a product type that is more the personification of highly regulated filed personal lines as "auto insurance".
Literally in a comment from a few hours ago, you tout your ability in "running A/B tests with different pricing logics to optimize profitability."[2] and "your business users can launch and make changes (e.g., increase the price to certain categories of policies"[3].
If you thought what happened with Zenefits was bad, this type of thinking is 10x worse. As in, carrier/you gets fined and has to send rebates to all customers that might have been affected, program shuts down, and you lose your license.
If you're acting as the Broker (MGA?) you have to be extremely careful in whatever type of control you give to an unlicensed entity you are distributing through. What someone from outside of insurance thinks is a routine pricing optimization, "(What if we charge 5% more before a busy weekend?)", can cause untold compliance grief. Plus, if you give the unlicensed entity enough control in how the insurance is presented and sold, they themselves might now need to become licensed producers.
I'm also skeptical you are doing much in the non-admitted space, as marketing restrictions, three declinations, surplus lines stamping etc. is not something you can automate for a consumer (small personal lines) product.
I have no opinion on "non-insurance" products (whatever that is) except that must be a very small percentage of what you are trying to do, as you call yourself "An Insurance Platform".
Thanks for the follow-up message, phonon. You are absolutely right and we take these concerns very seriously. Insurance is one of most regulated industries for good reasons.
The A/B test can be used for non-insurance products, such as waivers, trip fees, etc. Definitely agree that this is a small niche and won't change anything in the insurance world, but can be valuable for a subset of the companies.
Our goal when designing the product is to make it modular so it empowers our clients with what they need. We have customers that don't use everything we offer, and that's totally cool!
Another issue is "AI based underwriting" which is not allowed in California and other states unless the Department of Insurance of that state has a chance to review your algorithms. (And even then, I wouldn't bet on it.)
California in particular requires full upfront public disclosure of all underwriting rules.[0] (What you can do, is gather data for risk optimization, and use that to inform your underwriting rules when they get periodically updated and filed, but insurance companies more or less do that now.)
That could definitely be explored. The key here, and to other new insurance products is: what unique data is Kickstarter generating about its campaigns that didn't exist before? I bet they have a lot of data on campaign types, product type, how much is being raised, etc, that could be used to assess the risk and eventually price insurance.
The explosion in the volume of data that companies generate will definitely help accelerate innovation in insurance.
The software part is available anywhere, and we have clients in the US, Canada, Europe and Australia.
We are only licensed as insurance brokers in the US, so we would have to work with partners in Canada and other countries to secure the insurance policy.
I wish I had a super interesting story, but here is the truth: we're building a product that covers many types of insurance, so we came up with "different tints of insurance". Like in the definition "any of various lighter or darker shades of a color".
We are a combination of software + marketplace (i.e. licensed insurance broker that provides full transparency to the clients).
Qover is cool, the overall concept is similar to ours. It looks like they don't allow the companies to customize the insurance products, our platform can provide more tailor-made products
Hi nikunjverma, it can definitely be done. For instance, a marketplace that connects software developers/designers with companies could offer professional liability as part of the offering.
Notch it up a step further and provide insurance for security mess ups like someone accidentally posting ftp credentials to github. Enterprises would love to have their risks hedged
Thanks! Our platform gives full control to the users, from setting up their product, to deciding which insurers to use, to running A/B tests with different pricing logics to optimize profitability. Think of us as the infrastructure/OS that helps the risk teams do their job better.
Boost/Sure are good services, but they don't provide the same level of transparency and control. They work more like agencies/outsourcing than insurance infrastructure
Can you elaborate a bit? Your website seems to make it more confusing for me. There are a lot of buzzwords like AI, No Code and Embedded Insurance but I’m having a hard time understanding from the site and your description above what the platform does.
Thanks for the feedback, we should definitely improve the website - and the product communication overall.
Say you want to embed insurance into your product - i.e., let your users purchase it or automatically get from your sale/membership, etc.
You have to do 3 things:
* Design: figure out what you want to protect, the options you offer, when in your user journey, if you charge for it, etc. And find an insurer to take the risk.
* Launch: you have to write code to plug the logic on your website, how to keep track, know who paid what, implement the logic that the insurer requires (e.g., don't insurer users younger than 25yo), etc
* Optimize: after launched, you need to figure out if it's working (conversion, profitability, etc), what do you need to improve, and actually make the changes. It's a ongoing optimization problem.
Our platform provides the tools to help your team do all of that, in different modules. We abstract all the complexity from your core product and give a GUI so your business users can launch and make changes (e.g., increase the price to certain categories of policies, remove age restrictions, etc) without asking you to change hard-coded rules in your product.
I hope this helps, we'd be happy to chat more with you or any others that have questions or suggestions!
Thanks and congrats on your launch. Another set of questions I had when looking at the website and your response
1. Are you targeting commercial insurance or personal lines?
2. Looking at US or international markets?
3. How are you reaching insurance carriers? e.g. referrals, direct connections for standard products, borrowing comparative rater APIs, agency or MGA or other capacity arrangements?
4. How are you dealing with producer licensing requirements? e.g. acting as the agency, getting your embedder partners licensed, some other referral scheme?
rubyfan thanks for the super insightful questions. here we go:
1. Today we work mostly with commercial lines and get master policies that cover our clients and their customers. From our experience the boundaries between commercial and personal are becoming increasingly blurry.
2. Most of our carrier partners are in the US today, so we have better coverage here.
3. We configure their rating logic on our platform or plug to their APIs if they prefer
4. We're licensed brokers and can play this role or can assist our clients get licensed when required. It depends on the program structure and how the insurance
I'd be happy to jump on a call and explain more if you'd like, please let me know.
Also, the names on the screenshot are illustrative as the client could vary other factors that are not price in the A/B test, like user verification workflows, deductibles offered, etc. The goal is to find the optimal solution that creates value for the company while matching the risk preferences of the users.