A new insurance product rarely fails because of a bad idea. It fails because it arrives too late.
Underwriters know what they want to sell. The requirements are written down, the pricing is agreed and a distribution partner is waiting. Then the product sits in a queue while someone translates that document into coverages, rating tables, rules, forms and workflows, tests it, finds mistakes and translates again. Weeks turn into months.
That translation step is where AI can make the biggest practical difference, not as a chatbot on top of the system, but as a tool that does the configuration work and leaves the decisions to people.
This guide shows how that works in Openkoda, a highly customizable, AI-enabled policy administration system, using its AI Product Builder and a complete example: a pet insurance product configured from an ordinary Word document.
Where Product Launches Lose Time
In most insurers and MGAs, a product launch goes through the same loop:
- Business writes the requirements. Covers, limits, pricing tables, eligibility rules and the customer journey end up in a document or a spreadsheet.
- IT or a vendor transcribes them. Someone rebuilds every table, rule and form field in the core system, often in a proprietary tool only a few specialists know.
- Testing finds gaps. An age band overlaps, a referral rule is missing, a question appears twice on the form. The document goes back for clarification.
- Every change repeats the loop. After launch, a new exclusion or a pricing tweak goes into the same queue.
None of this work is what makes the product different, but it decides how long the launch takes.
How the AI Product Builder Works
The AI Product Builder lets business users describe a new product or a change in plain English, or upload a requirements document, and get a configuration proposal back in seconds.
Three design choices make it safe to use on a system of record:
- It proposes, people approve. The AI drafts a change-set with one row per change, each showing the current and proposed value. You untick what you disagree with, edit a line or ask for a revision. Nothing changes until a person approves it.
- Every change is a typed operation. The builder works from a fixed catalogue of operations, such as adding a coverage, a rating factor row or an underwriting rule. It never writes free-form code.
- Every change is versioned and logged. Approved change-sets are applied in one transaction and logged with who approved them and when. Product configurations move from Draft to Current to Superseded, and structural changes to a product with issued policies create a new version automatically, so policies already sold keep their original terms.
It can work on coverages, deductibles, limits and charges, rating tables and formulas, underwriting rules that auto-approve, refer or decline, forms, workflows, extensions, exclusions and endorsement templates. A readiness checklist flags anything still missing before a product goes live.
In-Depth Example: Launching Pet Insurance From a Word Document
Let's walk through a real configuration run. The product is Pet Vet Cover, a pet insurance policy for dogs and cats.
Step 1: Write the Requirements as You Normally Would
The starting point is an ordinary Word document, written in business language with headings and tables:
- What is insured: a table of the details recorded about each animal, including species, breed, age, weight, neutering, microchip and existing conditions, with how each is captured and whether it's mandatory.
- Covers and limits: mandatory vet fees cover, plus optional third-party liability (dogs only) and loss or theft cover.
- Pricing: a starting premium per species (dog 240, cat 160) and an age band table with explicit from and to values and multipliers.
- Rules and journey: when to refer or decline, and what should happen to an application, from pricing and quoting to raising an underwriter task.
One practical tip: put facts such as prices and bands in tables, not prose. Loose wording like "young dogs" produces ambiguous pricing, for people and AI alike.
Step 2: Hand the Document to the AI Product Builder
The product is created empty, with no structure, plans, forms, rating or workflows. In the AI Product Builder tab, you attach the document and add a one-line instruction, for example to configure the product with each question asked only once on the quote form.
Step 3: Review the Proposal
The builder returns a short summary and a change-set. In this run, it proposed the full product, and 36 changes were applied, including an eleven-step new-business workflow. Rows the builder can't apply are greyed out with a reason, so nothing fails silently.
Step 4: Check the Structure and Rating Tables
An Insured Animal risk item now holds eleven attributes, each with its type, whether it's required and whether it's used in rating. The coverages carry the document's limits: vet fees from 3,000 to 12,000, liability of 1,000,000, and loss or theft of 1,500.
Both pricing tables became rating tables. This is where a reviewer checks the figures cell by cell and makes sure the age bands (0-2, 3-5, 6-8 and 9-12) have no gaps or overlaps.
Step 5: Test the Price
The pricing description became one formula: base premium times an age factor times a cover level factor, plus a dental loading, with a minimum premium of 120. The policy fee and tax sit outside it.
The test calculation panel prices a sample risk straight away. A five-year-old dog on Essential cover with dental comes out at a premium of 268.80, a fee of 25.00 and 12% tax of 35.26, for a total of 329.06. That's easy to verify by hand before anyone outside the team sees a quote.
Step 6: Check the Form, Rules and Workflow
The generated quote form asks each question about the animal once, with required fields marked.
Two underwriting rules came from the document: decline animals over 12, and refer animals with existing conditions to an underwriter, each with applicant-facing wording. It's worth testing the edges here, for example that a 12-year-old dog can still get a quote.
The workflow runs from application received to rating, appetite rules and a decision that branches to quote and email, raise an underwriter task or decline.
Step 7: Publish and Keep Iterating
Once the review is done, the product is published as the Current version and new business is rated on it. Changes after launch follow the same path. A request like "add an optional dental cover for cats" or "raise the loading for the 9-12 age band by 10%" becomes a new change-set, reviewed and published as a new version, while existing policies keep their terms. If something goes wrong, you can roll back to the previous version.
Here's the whole flow, from requirements document to configured product:
The full walkthrough, with screenshots of each step, is in the AI Product Builder guide.
Why It's Faster, and Still Under Control
The time saving comes from removing transcription, not from removing judgement.
The AI does the work nobody wants to do by hand: rebuilding tables, wiring rules and laying out forms and workflows. Underwriters and product managers keep the decisions, and review becomes the main task. That review still matters. The same document can produce slightly different internal codes or banding on different runs, which is exactly why every change is shown before it's applied.
Because the product is configuration on a complete PAS, there's nothing else to build before launch. Policy administration, rating, underwriting, claims, billing, documents and bordereaux are already running on the same data model. Branded quote forms can be embedded on a partner's site, and every form has a submission API.
AI Across the Rest of the Lifecycle
Product setup is the most visible use of AI in Openkoda, but not the only one:
- Reporting AI answers plain-English questions about the book, such as loss ratio by product or policies due for renewal.
- The underwriting copilot flags the risk and pricing factors that matter on each referred case, while the underwriter decides.
- AI document reading pulls data from submitted documents into the record.
- An MCP server lets AI assistants work with live policy data, within the same permissions as your users.
The pattern is the same everywhere: AI drafts, people approve, and every step is audited.
Getting Started
Openkoda runs on managed cloud or on-premise, with configuration and data you can export at any time, and flat, published pricing with unlimited users. The AI Product Builder is available on the Business, Enterprise and On-Premise plans with an Openkoda AI subscription.
Want to see it configure one of your own products?
Top comments (0)