Watch our webinar that delves into the transformative power of no-code platforms and API integration in the insurance sector. As we explore the journey from early adoption to mainstream integration, this session will provide a comprehensive overview of technologies that have successfully crossed “The Chasm,” marking their transition into mainstream adoption. Discover how Managing General Agents (MGAs) and established carriers are utilizing these advancements to accelerate their pace, reduce costs, and innovate within the insurance market. What you’ll learn: Understand the Chasm Theory and its implications for technology adoption in the insurance industry. Discover how early adopters in insurance are using technology to gain a competitive edge. Who should watch: Insurance professionals seeking to innovate and streamline operations. MGAs looking for scalable growth strategies. Established carriers interested in integrating new lines with minimal disruption. Insurtech innovators and early adopters aiming to stay ahead of market trends. Good afternoon. This is Dan Reynolds, editor in chief of Risk and Insurance Magazine. I have the pleasure today to be introducing this webinar, which is titled why some MGAs thrive, lessons from the front lines of innovation. Please join us for this enlightening webinar, which is sponsored by Origami Risk, and it delves into the transformative power of no code platforms and API integration in the insurance sector. As we explore the journey from early adoption to mainstream integration, this session will provide a comprehensive overview of technologies that successfully crossed the chasm, marking their transition to mainstream adoption. Discover how managing general agents, which we refer to as MGAs, and established carriers are utilizing these advancements to accelerate their pace, reduce costs, and innovate within the insurance market. We think insurance professionals seeking to innovate and streamline operations. MGA is looking for scalable growth strategies, established carriers interested in integrating new lines with minimal disruption, and InsurTech innovators and early adopters aiming to stay ahead of market trends would be very interested in this content. We hope to help you understand the Chasm theory and its implications for technology adoption in the insurance industry and discover how early adopters in insurance are using technology to gain competitive edge. We have two speakers today. Our first is Jason Cole, a seasoned entrepreneur, author, and technologist with a lifelong passion for leveraging technology to solve real world problems. Since writing his first lines of code at age twelve, Jason has founded and led multiple successful technology companies in industries ranging from contact centers to insurance. As the former CEO and current president of Dais, cloud native insurance platform acquired by Origami Risk in twenty twenty three, Jason spearheaded the revolutionizing of the insurance value chain by seamlessly integrating cutting edge AI and machine learning technologies. His vision and leadership modernized critical aspects of the industry, paving the way for a more efficient and customer centric future. Aaron Larson is the CRO of Dais and an accomplished actuary with a standout record in operational roles across commercial and personal insurance lines known for his innovative use of analytics to revolutionize MGAs and carriers. With a keen analytical mind and a passion for technology, Aaron has led the charge in integrating sophisticated data analysis and machine learning to optimize insurance operations, enhancing efficiency growth and customer satisfaction. His work in the industry characterized by a forward thinking approach to solving traditional challenges has set new benchmarks for operational excellence and risk management. Aaron’s dedication to transform the insurance landscape through digital innovation has made significant impact, streamlining processes, and improving profitability. And with that, I’m gonna turn it over to Jason, Aaron, and wish you good luck in your presentation. Thanks, Dan. It’s exciting to be here with you today. We’re, we’re really looking forward to this presentation, and I think you’re gonna find some very useful, and new new ideas and hopefully some actionable insights that you can take away because this is an exciting thing to be looking at. Just a little preview of what we’re gonna be talking about. We’re gonna be talking about the Chasm Theory and where it comes from. We’re gonna take a look at three trends that are becoming mainstream right now. We’re gonna talk about who the early adopters are, and we’re privileged to be able to work with a number of those, in our work, especially with MGAs. We’re gonna talk about how early adopters are finding success using these tools and technologies and trends, briefly cover some lessons learned from the front lines. Hopefully, we can save everybody some some, headaches by showing you what works and what doesn’t. And then if we have time, we’re gonna talk about some other, emerging trends as well. First, a little bit about Deus. Deus has been around for seven years. We were acquired by Origami Risk last year, which has been fantastic for us, really helping us scale the the amazing technology that we’ve built. Our keys to success are really fast implementation. We routinely see customers go live in days and weeks versus months. We make it very easy for customers to get distribution for their products. Importantly, we also make it easy for customers to set up and configure the systems themselves and make their products available for sale either through independent agents or direct to consumer. We we have a number of innovative products that we host in the platform as well, such as on demand and usage based coverages. And then it’s fully automated, which really is important because it allows us to take the products to market much more cost effectively. So things like underwriting and data integration are built right into the system. So we’ll show you some demos here in a moment of how folks are actually using these technologies within the platform so it becomes more tangible and concrete for you. Let’s dive in and take a look at, you know, what is the the chasm theory? This is really a it’s a famous book, if you’re not familiar with it, by Jeffrey Moore, where he set out a framework for how technology becomes mainstream and eventually becomes obsolete. He listed a number of categories of, adoption that most companies fall into one of these categories, which starts with innovators. This is really the the bleeding edge. So things like AI would would fall into that at this at this point, Early adopters and this is really what our focus is today. And in the early adopter category is the chasm, and this is really the jump that a technology or a tool takes to become mainstream. The early majority then is when the technology or the tool is actually, mainstream and and commonly used. So we’re gonna look at some examples in each of these here in a second, followed by late majority and laggards. So most companies fall somewhere in the spectrum. The companies that we work with tend to be early adopters, innovators, and the early majority. This is an interesting construct to look at technology that’s moving through this cycle. So, specifically, just to give you a little bit more context around this, GenAI, again, as I mentioned, is kind of on the leading edge of this curve. We’re gonna be talking about some of the technologies that are sitting in the early adopter category, ones that are becoming mainstream that people are finding success with. Early majority and, again, we are talking insurance here. So this this is inclusive of, carriers, but we’ve got predictive analytics, SaaS. Those are obviously becoming mainstream, every day. And then, you know, as you get into the late majority of laggards, things like managed cloud and on prem, the more legacy type of construct. And different companies that you’re familiar with are gonna fall in different places on this on this scale. We’re gonna be focusing on early adopters, specifically what’s been working for them and what’s crossing the chasm right now. So who are these early adopters, and why are they important? Well, they tend to care about speed of value. They wanna get products out to market quickly. So an MGA, for example, often wants to start writing policies as quickly as possible to recoup their investment. They wanted to get products out the door, as quickly as possible so they get so so that they can get premium on the books. They’re scrappier. We have a lot of MGAs that set it up and configure the products themselves, or they work with an implementation partner depending on the size of the company. In either case, they can go much faster with less than traditionally you’ve been able to. Often, in our world, these are MGAs. We work a lot with MGAs, startup carriers, carriers that are starting new experimental lines of business. But our sweet spot is really MGAs, and that’s who we’re gonna be talking about today. Jason, I’d maybe make one quick comment, you know, just to kinda round out that slide that on the innovator and the early adopter phases, that’s when you see a disproportionate share of value created from those companies. So the folks that can get there first either as an innovator or the early adopter are the most likely to have a differentiated outcome in terms of the upside and the value for the business that they’re building. Absolutely right. So what are we gonna be looking at here today? We’ve got three different emerging trends that we wanna take a deep dive into, and we’re actually gonna show you this in the platform itself so that that you can get a concrete understanding of what these mean. So in q one, q two of twenty twenty four, we are seeing massive adoption of no code customization. This is for a number of reasons. Number one, smaller scrappier companies wanna do self-service. They wanna be able to make product changes themselves. They also wanna take their destiny into their own hands and control their speed to market. So if they’ve got a a motivated team and they wanna get their product configured and out to market very quickly, no code is the way to do that. It it’s it allows for a different approach to product deployment than the traditional SI led implementation project where customers can actually get in there. And without having to put code into the system, they can configure the products and make changes increasingly in our in our world. We’re gonna talk about rating as a service in ERC two point o. We’re increasingly seeing this go down market. So rating as a service, if you’re not familiar with it, is the idea that you can host a rating service in the cloud and use it in addition to your your policy admin system, rating as a service really being the cloud implementation of that. And that’s really becoming more prevalent, especially with the maturation of ERC two point o from Verisk. So we’ll show you what that means and and how folks are using that. Thirdly, API use is exploding, really across the board. We’ve got customers who are building their own front ends using APIs. They’re integrating with partners using their APIs, integrating with custom data sources and even outside services for things like usage based insurance. And API use is really starting to cover the entire policy life cycle. So this is exciting, and it’s opening the door for lots of new possibilities that really weren’t practical before. And then, again, if we have if we have time, we’ve got a bonus round here where plug and play portals are becoming, much more popular specifically for customers and agents. The ability to stand up a a customer portal without having to code it have it track along with the underlying insurance products is, a meaningful and important feature that we see more and more MGAs taking advantage of. And then the data ecosystems, which is somewhat related to API usage, but it’s really the idea that we can take data that lives within the within the company’s walls and use that to enhance things like underwriting automation or rating, really taking the the data advantage, taking full advantage of the data, especially proprietary data that might give these companies a competitive edge. So with that, let’s dive in here. We’re gonna take a look at each of these trends, in turn, and then we’re gonna, Erin’s gonna open up a demo here, you’ll actually get to see them. So no code custom products and self-service. What you’re looking at here is a screenshot from our platform, which you’ll notice does not look like code. This is actually an end user tool for modifying insurance products. Erin will demo it in just a moment. But what we’re seeing is that the the ability to self-service across the entire economy is leading to incredible growth rates because it allows companies to move much faster. And it reduces the the cost of lost time, which increasingly with inflation matters a ton to our customers. Specifically, the the ability to iterate on products quickly, implement new underwriting rules, adapt rates, take rates as quickly as possible. This is really having positive impacts on the bottom line to our customers and really across the industry. Jason, I would mention that from an industry standpoint, especially kind of on the actuarial and underwriting side that, you know, every month that you’re delayed for an implementation of a rate change, especially in a fluctuating market, will impact either your profitability if it’s a hard market or your growth prospects if it’s a softer market. And every single month that’s involved in implementing a new change or dependencies that require, you know, iteration are substantially improved with having that kind of control of the business and the outcomes in the business user’s hands. Absolutely right. Trend number two is, again, rating as a service and ERC two point o. And this is becoming increasingly important. In fact, data was just announced that forty four percent of midsize p and c insurers are planning major improvements to their rating systems in twenty twenty four. And the reason for this, I think, is because people are seeing the constraints of the traditional rating approach, and they’re looking for faster ways to take rate. So what this means in practice is insurance products are now available in a digitized format. It doesn’t require people reading through circulars and filings and manuals to set up a product any longer. ERC two point o is a is a great example of that. So for systems like ours that can integrate directly with ERC two point o, you can stand up products incredibly fast. ERC two point o, if you’re not familiar with it, is the digital representation of the ISO product set. So one example of a digitized product that we can then instantly convert into a rating as a service implementation. This has a number of advantages. For example, the the data is coming directly from the bureaus from the source of truth itself. So there’s no no fear that it’s being misinterpreted, that there’s any errors in the implementation. It’s really truly the implementation from the source of truth. The other big benefit to this is you can take updates incredibly fast. You can adopt new versions as quickly as they can come out. Deus has a unique partnership with Verisk, around, reading as a service, and we offer some really cool add ons as well such as book ratings and friendly APIs for the service. Aaron, do you have any comments on this? Yeah. When I think about the industry, this is a trend that giving a, you know, kind of a technical, analytical background, I have troubles on seeing. So the idea that you have to build a rating plan from ground up, including the questions, the algorithms, the order of operations, the rounding procedures, the conditionality of question logic, and then the interjection of underwriting rules is no longer required. The analogy that I would use is a simple one. If I wanna go send an email, in the old world, I used to have to build an entire email system to be able to go do that. I just wanna configure my email preferences and get ready to go. So from a rating as a service perspective, Verisk and ISO have created an option where you can just turn rating on. It includes all the content via API for the questions, the rating, and the conditionality. And then as a company, you set up what’s the equivalent of your email preferences in terms of deviations both in questions or forms logic or, rating kind of algorithm changes, and you’re able to deploy that rapidly without having to recreate recreate it from the ground up, which is saving probably eighty to ninety percent of the configuration time. That’s really challenged carriers in the past as they’ve looked at building these algorithms. So as an analytical, member of the industry, this is a trend that, frankly, I can’t unsee and that I view as permanent, and it will eventually deploy throughout the rest of the industry. Amen. Trend number three, API use is exploding. I don’t think this is going to be a surprise to anybody. What has been surprising, though, has been to see the proliferation of API usage across the entire policy life cycle from quoting to binding to servicing and renewal. Every single step of the policy life cycle is being instrumented with APIs, and there are now emerging conversational API integrations. And, again, this is done in our platform, for example, in a no code manner, and you’re looking at a screenshot to the right of what it looks like in our platform. But what this allows the the technology folks within our customers to do is really kind of take the governor off and integrate our system as one example with other systems in the ecosystem. You what we’re seeing is an ecosystem of solutions emerging that work together, and they talk together through APIs. So the ability to for example, when a quote is requested, call out to another system, whether that’s a rating system, a document generation tool, a marketing system like a a Marketo or a HubSpot. All these things become possible once the APIs are unlocked. And, in our case, you know, it’s it’s a no code tool enabling people to build their own integrations, which is extremely powerful. And if if you’re not familiar with what APIs are, it stands for application programming interface. It’s been around for many, many years, not so much in the court system space, especially on the carrier side, although that’s starting to change, which is why this is an emerging trend. APIs are going to be incredibly important for the foreseeable future, especially with the the emergence of AI because AI can kind of natively use these tools. But what we’re what our customers are using these for today are, for example, building their own customer experiences and custom user interfaces on top of our APIs. So many MGAs that we work with wanna add value in their customer experience, so they’ll offer value added tools in their user interface. They wanna pull the the insurance data and the insurance capabilities into that customer experience. The APIs allow them to do that. They can also integrate APIs with their underwriting and rating processes. So for example, if you’re calculating a custom, risk score by customer, you can take all of the data that you have for them, feed it out to a a model or a system that’s calculating a score, get that back, and then use that in the underwriting process to to determine if they’re eligible for straight through processing. Jason Oh, sorry. Go ahead. Yeah. Go ahead. I was just gonna say one historical data point. You know, a decade two decades ago, everybody thought about the core carrier stack or the core MGA stack as billing, claims, and policy administration. And as that happened, people built solutions that formally integrated those three different systems, and that was a core system stack that lasted for decades. And as time went on, agencies, for example, had a difficult time corresponding with those. So they had processes through companies that did upload or download. And then you had the advent of CRM systems, which is still not really part of the stack, though in reality, it’s actually a part of most MGAs or carriers’ tech stacks, but there’s a customer relationship management element now that needs to be one of the legs of the milking stool. That’s normally, introduced through an API as well as the ability to bring in, you know, connectivity with things like agency management systems or comparative raters. And all of this connectivity is really formulating a new ecosystem or a new system stack, which will include CRMs. It is likely to include rating elements either to companies like an ISO and a Verisk or other ones sometimes when the business doesn’t fit. But the landscape and the definition of what’s in that tech stack is quickly, migrating to a different solution than we’ve seen over the last two decades. Well said. Alright. So those are our three trends that we’re gonna take a look at in a demo here. So just before we do that, we’re gonna take one look at who these early adopters are, then we’re gonna show the demo and talk about some lessons learned. So this will go fast. Our early adopters I mentioned MGAs. We work a lot with MGAs from inception to scaling and growth. We also work with a lot of ISO based insurers and increasingly in the early adopter side with with tools like RAS and rating as a service, New York City two point o. You’re seeing these ISO and various based insurers being much more innovative and looking at some of these new tools to speed their time to market especially. High-tech insurers have deeper technology needs than the traditional insurers. So for example, they’ll often roll their own models. They’ll have API needs for things like for unique coverages, like on demand coverage based insurance. All of these demand connectivity with other systems, which requires API connectivity. Increasingly, we’re seeing brokerages also get into the game. They’re increasingly taking their workflows, automating those, and often growing into MGAs themselves, which is an exciting trend that we we expect to see a lot more of. And custom product insurers. This is kind of on the opposite end of the spectrum from the ISO based insurers, but custom product insurers who are kind of working, building products from whole cloth often need additional capabilities, whether that is because of custom proprietary coverages or, again, because they’ve got technology partners who are giving them proprietary data that they’re building products on. So these are really the users of these tools that we see. And, with that, let’s go ahead and dive into a demo so we can see what it is we’re talking about here. Sure. I’m gonna show a couple of things today. I’m gonna show an example of a policyholder getting a quote from a custom we call it a storefront, but the persona is a policyholder getting a quote. Then I’ll show you what it looks like for an underwriter on the back end. And then finally, I’ll show you what it looks like as a product builder to actually build a product. And kind of the magical thing about all of this is that you can configure it through a no code interface, and the end of it is a generated quote and experience, but also an API that accompanies it that comes out of the box. So people that have historically been very good at, like, understanding the business, the requirements, the definition are now able to contribute to the IT velocity of an organization, whether it’s an MGA or a carrier. And as Jason mentioned, a lot of the newer ones are scrappier trying to have all hands on deck making solutions work. This is some of the ways that we found the most successful ones doing it. So let’s say I’m a policyholder, and I wanna get a quote quick. I’ll click to get started. I just made up a hypothetical, solution. Let’s say I want a quote in GL. Notice things like status tracking going down the side. Those are all generated through us hitting our own API on the product side from the storefront. What this next part is gonna do is actually prefill data based on looking up solutions and things like Google’s API or classification services for that matter. So in this case, just to show what’s happening here, we’ve actually showed all the questions, which can be configured individually by Carrier MGA. And based on that phone number, I’m able to get the business name, the city, the state, and the ZIP code as well as the industry. And now this industry actually looked up the answer based on an output from the Google algorithm. So from Google, it got the name and address. It needed that to pull the NAICS code, and it was able to pull that in. But even simple things like getting the classification right from a loss ratio standpoint, that’s critical because every every year companies, you know, burn one to probably two points of combined ratio on misclassification, and this helps to automate Now I’m gonna answer a few extra questions. Putting in some exposure data. We have conditionality of questions. So let’s say you had claims. You could put in a narrative. Let’s assume we don’t. But you can also do things like capture a signature. And let’s actually finish that quote. That quote just generated a proposal with a limit of a million dollars. Now I’m gonna purchase that account. And from there, I’m going to pay for it. It’ll run like an OFAC check. It’ll make sure funds are available through Stripe. I’m gonna purchase that coverage then. And this is all happening with zero touch from an underwriter or an agency, which is an extraordinary time say savings from an expense standpoint. And this did actually deliver a policy, So I can see that that policy was just delivered here, a very simple one. And then I’m gonna go back to the view of an underwriter. So I’m going to our Deus platform. I’m bringing up a customer that we just quoted. I have the profile of that customer here. I can see that we quoted it a minute ago for the line of business and general liability. And for each of the different questions here, there’s a workflow that’s more optimized for, like, an underwriter, but you can see all the data. If you choose to change questions, you’d have authorship and lineage updated. But in this simple quote, you can see that the policy was issued, and you can see as well that we have, things like a rating worksheet that can be attached. You can actually document the entire algorithm and the rate order of calculations, including things like rounding procedures, variables, and administration of the algorithm. And then you can also see that there were documents that were delivered, and those are automatically downloaded and auto tagged. Documentation is a huge hassle for any MGA or carrier, and it also allows you to automate that, which is really good from, like, an e and o perspective. And I can actually see policies. So one of the things that Deus does is have a no code interface. I’ll show you that in just a moment. But the true power of the platform is that there is orchestrated life cycle events. Every step of the insurance life cycle is decomposed and can be automated. So what I’ll show you here are a couple day two transactions really quickly so that you can see this isn’t just a a quick quoting environment. It actually allows you to quote bind issue and service policy. So let’s endorse this policy quickly. I’m gonna take a endorsement here at the end of June. I’m gonna take my exposure up a little bit. And what it’s doing is it’s calculating the rate impact of that endorsement so you can actually see what’s happening there. And notice that the premium goes up. I can issue that endorsement. I can do things like I can see my financial overviews, that sort of thing. I can also do things like out of sequence endorsements, but I’m gonna cancel the policy now. So let’s just say that I changed my mind. I’m continuing that. Say I change it in here. I can see that there’s a refund that’s coming back from it. I can submit that cancellation. And then notice that we have the entire life cycle getting updated here, so I can also do things like reinstate that policy. And we even go to stages like filing a first notice of loss. So let’s say that we have a claim. Let’s say that we have a date, a Joe claimant, and a hypothetical phone number. And I can submit the FNOL. And through that, I can go and finally see my API log, which is the digital representation of all those events that we just took. And notice there was a lot going on here. So this particular process is taking carriers sometimes years to set up, but we started with the concept of having a client. We had client data, and this is called a JSON object off to the right. This middle column here called events is our policyholder life cycle. And notice that for every event, I’ve got the concepts of the intake that happened on the account, the location, the question answers. I was able to get a quote that came back. I’m then generating payments, and I’m doing things like creating a policy. And I’m also doing things like creating an FNOL in some cases. And each of these life cycle events can be shared through an API key facility that we have, and then there’s developer documentation that we have available as well in terms of authentication. And so each of this is sorry for jumping in, but what so what you’re showing here is a product that was built using the no code tools and now exposing that product through the APIs. Right? And I think this is, like, example of a custom product in this case that was built from scratch in the platform. Yep. So what we’ve done is we’ve shown a policyholder getting a quote, an underwriter servicing a quote, doing things like canceling, reinstating, doing FNOL, and then seeing the API exhaust, so to speak, and a key facility where you could expose that and share that with agency management systems, competitor raters, that sort of thing. The last step I’m gonna walk through is building a product. So in this case, I’m going to build a product that we just look at the GL product that we just built, and we’ve got six steps every time that we build a product. This is the no code interface. So now I’m in my third persona. I’m not a underwriter or a policyholder. I’m now the product builder or the product manager at a MGA or a carrier. So you can do things like set up market visibility of a product. The second step is to have the builder, which is, like, the questions and the underwriting rules. So notice that we’ve got all the different questions that you saw in intake here. We had a couple of hidden questions as well that could emerge conditionally. We’ve got a question editor where if you go in and you can see a state, for example, I have different controls for text, yes, no drop downs, or a number of other things here, including, like, file attachment for a schedule. I can do things like To jump in here for one second, Aaron, this is really where the power of no code shines because if you’re familiar with the more traditional core systems, in order to add a question to a product, whether it’s an underwriting question, something you need for rating, you’re looking at weeks of time and IT resources to put that in. In this case, and this is why this is so powerful, a product manager, the the person that actually manages the insurance product can go in here and make these changes in a new version of the product and deploy them within a matter of minutes or start testing them. Yeah. And changes can happen on the fly and a lot of flexibility in terms of, like, conditions that you can have built in here, required answers, hidden questions, default answers, immutable answers. A lot of flexibility, including things like qualifying rules up front. So for example, you may want to exclude garbage haulers from eligibility. You can do that here in this step. The third thing that we do is we turn on prefill. And a lot of times, this may be a proprietary data source. In these cases, these are options that are off the shelf. So what we saw in our example was Google prefill where if you put in phone number, you’re able to actually get from that key name, website, street, city, place. It’s from Google Places, including, like, latitude and longitude as well as the Google Places ID that allows you to bring in things like the images, and the location geographically. And for us, we can simply turn those on or off, and we’ve got a robust pipeline to bring in new sources of data and things like conversational APIs to interact between different systems. And that means that even nontechnical users can then set up very powerful data integration capabilities for prefill in this case, all by themselves without having to go to a developer to turn this on. And it even goes so far as to do things like daisy chaining different prefill sources together, again, all without a line of code. Yeah. So in the example that we saw, we saw Relativity, Google detailed data working together with Relativity six. Relativity six needed the business name, street, and state that came from Google from the phone number, and that was able to yield the NAICS code. So some pretty powerful capabilities and being able to, like, determine the order of daisy chain and things like that can all happen out of the box, which is a very elegant kind of solution for business users. The fourth example is the combination of a forms library as well as, like, policy life cycle event automation as well as things like authentication. But in this example, I’m setting up a policy deck page in this example, and I’m able to map my questions to this, literally just drag and drop a box. We also work with, like, JavaScript. This is uploading a PDF, but we’re able to handle the questions that come through with simple kind of UI to map those as well as complicated things like the policy number generation or the premium that’s generated as well. And we also have things like JavaScript plugins available for really complex rules and very specific forms requirements. And you’re able to create a composition of multiple types of forms. You can create a bundle of forms that generates with different rules at different times. And we’re also able to configure things like endorsements, cancellations, or FNOL from here. And from there, you set up the policy. You allow it to be issued with a certain deck page. You can have it auto renew, generate renewal ninety days prior to expiration or whatever your time sequence is. You’re doing things like setting up the financial kind of requirements. So I’m gonna use a monthly pay. I don’t have to collect escrow funds. You may or may not use different, payment processing, and then you may have settlement refund processing differences as well. A lot of flexibility, but you set up the billing configuration, in the system as well. The next example the next step is to go through policy management, and you’re actually setting up the actions on day two transactions. For things like endorsements, I can go in here and figure out if they happen in the past. Is it premium bearing? Do I need to add a deck? And a lot of flexibility. And from there, you’re able to create things like border row reports or really intense automation. So you can run a report every week, and I can map to that very easily from almost an Excel like interface. The fourth step then in our process is to set up events. And in this case, I’m focusing on quoting just so you can see that. But we actually took a general liability rating worksheet, and what we’ve done is we’ve uploaded an Excel sheet, simple rating plan based on number of employees and sales. This handles to the most complex. We’ve actually been able to load very complex ISO, algorithms across, like, property as well as, like, a bot, which are heavily complicated. But what we’re able to do is map the input data. So I’m mapping my number of employees to, like, cell c four, and you’re creating the fields that you need to get the rating plan. And then you’re presenting the outputs at the end. So in this case, I’m creating a premium that links from the file as well as, like, an occurrence limit, which you saw on the quote. And that all happens effortlessly. But once that’s created, that literally and then we have things like versioning so that you can have different versions of products. You can deploy them to different orgs. Think about it like kind of a GitHub repo in the tech space for insurance. But I can do things like analyze changes of versions, fork my versions. I can have multiple heads on a version. So a complex organization can have four different divisions, use a common product, and it gives you a lot of flexibility. But all of that activity in the building is all that it took to build a product. And from there, you have those APIs that you saw at both the policy level or the underwriting level. That that’s fantastic. Thanks, Aaron. Maybe, finally, I think the one trend that we didn’t actually show yet, so maybe we could sneak that in, is building a product from scratch using, rating as a service and ERC two point o. Yeah. Again, this, to me, historically, had taken nine to twelve months for somebody setting it up for their first time. And let’s see if we can do one in the time of this demo. So I’m gonna set up a BOP product, for example. Just pick a BOP here, a bureau product. And, again, this is fully from scratch. I’m gonna pick some additional coverages that I wanna add. Let’s say I’m focused on barbershops and beauty salons. And what it’s doing is it’s importing the electronic rating content from Verisk. It’s creating the product structure, applying the forms and coverage recommendations that populates the questions. It builds the conditions on the schedules. It provisions the RAS quotes. And in seconds, instead of months or years, you have a product that’s configured. What this actually did is it brought in every single question that exists on the ISO side for BOP, including the metadata. Like, is it blanket rated or policy type? Those might be hidden. Here’s your limit per occurrence. Here’s an aggregate limit. And the questions bring in the rich detail around this. So let’s say I’m looking at an aggregate limit. I have drop down options that actually vary based on the occurrence limit that was underlying it, and all of that data comes in automatically. That’s usually five to ten pages of business requirements just for that one question. And in this case, we have, you know, hundreds of questions that kind of have gone down this entire, question set, including things like forms attachment and that sort of thing. So you have a real product that came in, and a very simple platform can actually handle that complexity. And then what I’m gonna do is I’m gonna set up a rating of that from scratch. So I’m going to my my rating event. I’m gonna do a quote. I’m going to go to the policy life cycle event of quoting. This is that architecture that we talked about. Might be issuing a policy, getting a quote. This case, I’m gonna stand up various RAS with deviations. And what this has allowed us to do is bring in every single table from ISO. Let’s just say I’m looking at, you know, different loss costs that might be available. You might have loss assessment deductible, just different sorts of factors here. In this case, you know, your housing countrywide layers as well as state layers. But in in this case, I can go in. I can override a value and make that be one point eight. I can apply that and close it. Next time I go in there, I can see my deviations are highlighted. I can look at my changes only, and I can undo them, but I can also import and export entire tables out of here. But this actually gives you the full ISO algorithm. So from that simple example, I can go in then and get a quote on a Verisk account, and I’ll show you some deviations that we did. But in this example, I have a quote that that line of business just generated. I’m just bringing one in here. This is a customer that we had prefilled for this purpose. And I can go in, and I can actually see the algorithm that was applied here. So this is one of the more powerful tools of the system. But in terms of a bop rate, you have the high level detail, but you’re actually able to see all of the rounding procedures as well as the lookup tables with the factors and the algorithmic approach and structure to fully document from a, like, an audit perspective what was included in the rate, and that metadata comes out of the box with rating as a service. This is months of work for carriers to test and implement, and it comes out of the box. Probably the neatest thing that we do is we have the ability to deviate, like we talked about, and create deviations before the fact or after the fact, all in a very light low code interface. Excellent. Thanks for the demo, Aaron. Yeah. Sure. I’m gonna share my screen again. Back to the slide deck to wrap things up here. I wanted to go through a couple lessons learned. This these are, again, based on our experience with these early adopters who’ve been using these tools and what they’ve found worked or didn’t work. So we’re hoping that this adds a lot of value to folks as they think about these these tools and and trends. One of the things that has become apparent is the product architecture, insurance product architecture, and design are really kind of a new muscle that that these companies are exercising. In these cases, when you’re using no code tools, you’re not really outsourcing the product design to an SI partner, for example. So you need to think through, and there and there are a lot of options as to the way the way that you can deploy these products. So, for example, from the personal lines world, folks may be familiar with things called rate call one and rate call two, where you’ve got product structures that start with a limited set of questions, order some data, make an initial underwriting determination, and then go to a rate call to a second product to order more expensive reports, and do another round of underwriting even before you get a quote. Sometimes there’s a quote indication upfront. Often, companies will wanna bundle things together in a package. And in our world, for example, where you’ve got complete freedom as to how you wanna develop your product, you can even use packages to put very friendly user interfaces in front of a a full blown ISO product so that you don’t have to expose the entire product. It’s a great user experience improvement. But what we’re finding is that team members need to have these abilities, and MGAs in particular often have the product builders on the team with them, and so that’s why they’re able to be so successful. They’re they can go in and set up the product. They’ve got the requirements, within the team itself. And I think what you’re gonna see emerging here is a new skill set of product architecture, folks that can go in using no code tools like this instead of products from soup to nuts. Aaron, I I’m curious to hear where where you think about the the profile of these folks and who’s been successful. Yeah. Years ago, some of the leading personal lines carriers set up a process called product management. And in that step, what they did is they had, like, an underwriting and an actuarial team that were often kinda linked together. But then they also and oftentimes things like marketing. But then they had the the foresight to bring in an IT team and start working with that group of people. And in that process, there was a lot of people having to figure out, you know, how to speak IT and speak business and try to make those pieces work together. And today, what needs to happen is that folks that may have done underwriting rules in the past can actually think through how to be setting up product structures in, almost like an IT setup to save costs. Like, one of the most expensive costs are, like, reports or buying external data or applying AI at the at the right times. And what our platform allows companies to do that we’ve learned as we’ve implemented this is you can get a quick quote. Is the customer interested? Great. Move on. Now we’re gonna order a few reports. Those reports maybe cost nickels and dimes. That looks good so far. They’ve cleared. Well, now I have a chance to go order some of the expensive reports. Maybe you’re ordering MVRs or really complicated kind of, like, property surveys or inspections, things like that. And we’ve got the orchestration and the automation of the flow in the quoting and the issuing process to enable differences along each of those different decision points. And the business side isn’t totally comfortable with setting those up out of the box. On the IT side, it thinks about automation regularly, but maybe doesn’t have the business applications. So the teams collectively have to figure out how to make this work in a very orchestrated way. And that really leads us kinda to the next bullet, which is the user journey and thinking about, like, the user experience of the customer, what you wanna build, how to delight that customer, and how your orchestration of all these different steps in the policy life cycle can either help or hurt it. What we saw over the years is just there was a lot of friction. We were probably one of the least efficient industries out there in terms of, like, automation and delighting customers. And with a platform that allows you to have that life cycle architecture, we can finally change that and address some of those gaps and make insurance, you know, just as delightful as the apps that you see on your cell phone. Yeah. It it’s a new way of thinking about products where you’re really thinking about the reducing the friction between the user, whoever that is, an agent or a policyholder or prospect, then putting the data in and and getting the quote back as one example, not even talking about day two transactions. But it’s it is a powerful way to increase customer satisfaction and and really get more customers in the door. And I think what we’re also seeing is, again, increased use of APIs even in the customer experience because often, if you can bring data in that prevents people from having to key in additional data, that moves the needle significantly in conversion rates. So it’s it’s been exciting to watch that. Yeah. I would say on that second bullet, just to elaborate a little bit more, you know, for about ten years, companies were really working with, like, agency portals or policy holder portals. And, you know, they would be able to define the algorithm. They’d be able to get the the rate calculated. But, you know, the simple little things like, when do you get a signature? When do you have the producer sign off if that’s a requirement? Where do your ENS workflows go in terms of declination management or things like tax licenses and fees calculations? A lot of business users hadn’t had to get to that level of detail. And how you want it to feel to a customer that a prospect that’s going through a quote is different from an algorithm perspective than it is from an overall kind of process flow. And that’s where we’ve really seen people make the most progress is understanding what does it feel like for a prospect with your new experience, and can you improve and delight them in that process? I agree. Which really leads us to our last and and final lesson learned here, which is, it’s important to think bigger. The constraints that used to be there with some of the the systems and tools that folks used in the past are no longer there. And so we’ve seen a lot of MGAs in particular kind of go through this process of having an initial set of requirements based on what they think is possible. And when they can start doing things like API integrations on their own or product tweaks or, you know, promoting new versions up through the different environments, it really allows folks to do to go much, much faster and ultimately bring a much better product to market. So, things like adopting an agile framework or even mindset where you can quickly iterate on products because you don’t have to wait for months to get a production release out the door. You can schedule it and forget it and then look at the results. New users and experiences are now pass new user experiences and workflows rather are now possible. So I anticipate you’re gonna see a lot different form factors going forward, things like AI driven chatbots, customer service. Apps are gonna continue to proliferate, different types of embedded opportunities where folks are using data from partners to provide initial or bindable quotes. We’re seeing more and more of these every single day, and I think this is one of the most exciting things that we get to witness firsthand is really the the ambition that a lot of these smaller scrappier companies have. And they end up with some really phenomenal customer experiences and products that really wouldn’t have been possible before, but it requires them to have a mindset where they’re unconstrained. And they’re willing to think without the the traditional carrier enterprise constraints in mind because in many cases, they don’t exist anymore, which is an interesting place to be. Yeah. Jason, just a simple one on that last item. Like, growth is a profitable growth is, like, the key consideration for an MGA or a carrier. In the past, we used to wait for severity results to come out, and then we’d look at, like, frequency. And as this new data is available, you can figure out quickly where your hit ratios are the highest, like, within weeks or days. You can figure out when you’re declining too much or too little upfront. You can figure out when you’re writing an issuing business, and is there a break between your bind and your issuance process? All of that data has really never been at the fingertips of the businesses to optimize, and now they can actually implement changes in real time to react to that. And even leading indicators like frequency that you might see sooner than a full severity trend allow you to adapt to the market and the profitability as it’s changing in front of your eyes and the skill set to be able to handle that and make decisions based on that is really liberating, I think, to a lot of the MGAs that we’ve seen be the most successful. Couldn’t agree more. Alright. I don’t think we have time for the bonus round, but, we would love to talk to you about these if they’re of interest. Plug and play portals are amazing. We consider portals in minutes. Again, going back to these customer experiences and data ecosystems, we’ve touched on that. Both of these are also strong trends that are emerging, right now. So, again, we’d love to talk more with you about that. I hope this has been informative. It’s an exciting time to be in the industry. We can’t wait to see what you build, and I hope this has been motivating to build some of the products of your dreams. Aaron, any parting words? No. Just thank you for your time, and we’re so excited about what’s about to happen to the industry and what’s making it change, and it’s exciting to see insurance become on par with the rest of digital experiences that exist. Absolutely. Thanks, and please get in touch.