How to Configure a New Insurance Product With Openkoda AI Product Builder

What Does It Mean to Configure an Insurance Product?

A new product always starts the same way: somebody in product and pricing writes a document. It says what is being launched, what is insured, what is covered, what it costs, who gets turned away and what should happen when an application arrives. It is written in business language, because the people who write it think in business language.

Then it is configured, which means the same six things are said again in a system’s terms:

What you insure - a risk item with attributes: species, age, whether it is microchipped. Each one typed, each one marked required or not, each one marked whether pricing depends on it.
What it covers - coverages with limits, mandatory or optional.
What it costs - rating tables, a formula that combines them, and the charges that sit on top.
What you ask - the quote form, one question per thing you need.
What you refuse - automated underwriting rules that decline or refer.
What happens next - the workflow that rates the application, applies those rules, and quotes, refers or declines it.

Nothing in that list is derived from the document. It is all already in there. The gap between a requirements document and a configured product is mostly transcription, and transcription is where products lose their first month.

This article walks through closing that gap in one pass, and then, the longer half, through checking what came out. The checking is the point. A builder that proposes configuration is only useful if a person can read what it proposes before it is real, and verify it component by component afterwards.

The whole thing is on video as well, if you would rather watch someone do it than read the steps. It covers the same fourteen steps in one pass; the written version below is the one to keep open in another window while you configure your own.

How to Turn a Requirements Document Into a Configured Product

Before you start, you will need: a requirements document, an empty product to configure, and an account that can reach the Product Builder.

Step 1 - Write the Requirements the Way You Already Write Them

No special format, no field codes, no template. An ordinary document with headings and a few tables.

Page one of a pet insurance requirements document: what we are launching, a settings table, and the start of the insured animal section — An ordinary requirements document, written in business language - product name, term, how it is sold, the smallest premium, the currency.

One habit is worth adopting, and it is not a technical one: put the facts in tables. Prose that says “we price dogs at 240 and cats at 160, with a discount for young animals” is harder to read correctly, for a person and for a model, than two columns with a row each.

Step 2 - Say What You Insure, as a Plain Table

The example product insures an animal, so the document has a table of what it records about one: what we record, how it should be captured, and whether it is mandatory.

The requirements table listing what is recorded about the animal: species, breed, age, weight, neutered, microchipped and existing conditions, each with how it should be captured and whether it is mandatory — What we record, how it should be captured, and whether we insist on it - three columns a product manager can fill in without knowing a single field name.

“A choice between dog and cat” is enough to produce a dropdown. “A number, this one is used in pricing” is enough to produce a numeric attribute flagged as a rating input. You are not writing a specification in disguise; you are being specific in English.

Step 3 - Say What the Policy Covers, and What It Costs

Section three is the covers, with a limit each and a note on whether they are optional.

The cover table from the requirements: vet fees with a limit per cover level, third-party liability for dogs only, and loss or theft of the animal — Section three: one mandatory cover with a limit at each level, and two optional ones.

Section four is the price. A starting figure per species; an adjustment for age as a table of bands; an adjustment for the level of cover; then the loading, the fee, the tax and the floor, in the order they apply.

The pricing section: a starting premium per species and a table of age bands, each with a lower age, an upper age and a multiplier — And section four: a starting figure per species, then a band table - a lower age, an upper age and what to multiply by. Ordinary tables, not a rating language.

Give each band an explicit from and to. It is the one place where a loose phrase (“a discount under three, a loading over eight”) turns into a pricing defect that is invisible until someone audits a quote.

Step 4 - Say What Should Happen When an Application Arrives

Two more sections, and the second is the one most requirements documents never have: the rules, and the journey.

The referral and decline rules, and beneath them a bulleted description of the journey an application should take — The two rules, and the part most requirements documents leave out: what should actually happen when an application arrives, as five bullets of prose.

Five bullets - price it, apply the rules, quote and email it, raise a task, or decline it politely - is a workflow. It is worth writing even if nobody has ever asked you for one, because it is the section that decides whether the product is straight-through or a queue of manual work.

Step 5 - Start From an Empty Product

On the other side is the product, created and named and nothing else. Its overview is a row of zeros: no risk types, no coverages, no plans, no forms, no rating, no rules, no workflows.

The product overview for Pet Vet Cover showing zeros across structure, plans, forms, rating, underwriting and workflows — The product before anything is configured: zero risk types, zero coverages, zero forms, no rating, no rules, no workflows.

The tabs behind it are empty in the same way. Worth a look before you start, because it is what makes the after picture meaningful.

The Structure tab of the empty product, reporting no risk item types yet — And nothing behind the tabs either - with no risk item there is nothing to hang a cover or a price on.

Step 6 - Hand the Document Over

Open the AI Product Builder on that product, attach the document, and say in one line what you want done with it.

The AI Product Builder tab with the requirements file attached and a one-line instruction, above the panel listing what the product is still missing — The document, attached, with one line of instruction - and a standing reminder of what the product is still missing.

The instruction here is worth copying in shape: configure this product from the attached requirements, set it up as a new kind of insured item with its own details, and make sure the quote form asks for each thing only once. It says what to do with the document and names the one judgement call the document itself left open.

Step 7 - Read the Proposal Before Anything Changes

Nothing has been applied yet. What comes back is a proposal: a paragraph saying what it intends, then one row per change - what the product says today, what it would say instead, and a tick box.

The top of the builder's proposal: a paragraph summarising what it would configure, then rows with apply checkboxes, the current value and the new value — What comes back is a proposal, not a change: a summary, then one row per edit - what the product says today, what it would say instead, and a tick box.

Read the summary first and check it against your own document, section by section. It is the cheapest review you will get: a paragraph against six, before anything exists.

Further down the proposal: rating table and charge rows ticked to be added, above them greyed-out rows refused with a can't-apply reason — Further down: the rating tables and the charges. Note the greyed rows - the builder refuses what it cannot yet apply and says why, rather than failing quietly.

Two things to look at closely here. The greyed rows: those are changes the builder could not apply against the product as it stands, each with its reason. They are not silent failures, and a handful of them is normal, because some things cannot exist until the things they hang off do. And the codes: SPECIES_BASE, INSURED_ANIMAL, pet_age. Your document named none of those. They are the builder’s invention, they differ between runs, and they are worth reading now because they are what every later screen will show you.

Step 8 - Apply What You Agree With

Untick anything you disagree with; the button applies the rest.

The last proposal rows including a whole workflow to author, the Apply selected changes button, and a line confirming 36 changes were applied — One button applies everything still ticked - here thirty-six changes, including an eleven-node workflow written in one go.

Thirty-six is this run’s number, not a specification. Give the same document to the same builder twice and you will get two proposals that differ in their counts, their codes and sometimes how they band a table, which is exactly why the rest of this article is six steps of checking rather than a victory lap.

Step 9 - Check the Structure It Built

Start with what the product insures. Every attribute from the document’s table is there, typed, and marked for whether it is required and whether rating depends on it.

The Insured Animal risk item with eleven attributes: species as a dropdown of dog and cat, breed, age, weight, neutered, microchipped, existing conditions, vet practice, pet name, cover level and dental cover — The insured animal, with every attribute the document asked for - each typed, each marked required or not, each marked whether it is used in rating.

Check three columns, in this order: type (is species a dropdown with the right options?), required (does it match your “do we insist on it?” column?), and used in rating (every field your pricing section mentions, and nothing else). The third is the one that bites - a rating input nobody collects is a quote that cannot be priced. The same description step carries a stranger risk just as well, as in the tutorial on creating an AI insurance agent product.

The coverages underneath: vet fees mandatory with a 3,000 to 12,000 limit range, third-party liability at 1,000,000 and loss or theft at 1,500 — And underneath, the three covers from section three, each carrying the limits the document gave it.

Step 10 - Check the Rating Tables

The document’s two pricing tables are now two rating tables, and the age table is banded the way the document banded it: a from, a to and a factor per row.

Two rating tables: species base premium with dog at 240 and cat at 160, and an age band multiplier with four bands from 0-2 to 9-12 — The document's two tables, as rating tables the engine can read: the species base premium, and the age bands as bands - a from, a to and a factor.

Check the numbers against the document cell by cell. This is the one place to be pedantic, because these are your figures, not the builder’s, and an ordinary-looking table that is wrong prices every policy you write. Check the bands too: four rows covering 0-2, 3-5, 6-8 and 9-12 with no gap and no overlap. Two open-ended rows instead of four bands is a real failure mode, and it looks fine until you rate an eight-year-old.

Step 11 - Check the Formula, Then Rate an Animal With It

The paragraph of prose about pricing has become one line the rating engine executes.

The generated premium formula multiplying the species base by the age factor and the cover level factor, adding the dental loading, with a minimum of 120 — A paragraph of prose about pricing, as one line the rating engine executes - base × age band × cover level, the dental loading, and the document's 120 floor.

Read it against section four in order: base, age, cover level, dental loading, and the 120 floor from section one. The fee and the tax should not be in it. They are charges applied after the premium, and a formula that has swallowed them charges them twice.

Then stop reading and price something. The test panel rates a sample against the configuration on screen.

The test calculation panel with a five-year-old dog on Essential cover with dental, returning a premium of 268.80, a 25.00 fee, 35.26 of tax and a total of 329.06 — A five-year-old dog, Essential cover, dental included - priced against the configuration on screen and itemised charge by charge.

Do the arithmetic yourself once: a dog starts at 240, a five-year-old sits in the 3-5 band at 1.00, Essential is 1.00, and dental adds 12%, which gives 268.80. The fee is 25.00, so tax at 12% of 293.80 is 35.26, and the total is 329.06. Every number on that screen traces back to a cell in the document. If one does not, you have found the defect now rather than in your first month of live quotes.

Step 12 - Check the Quote Form

The form asks the animal’s questions, each one once, which is what the document asked for in a sentence and what a duplicated question does to a conversion rate.

The generated quote form showing the animal's questions - species, breed, age, weight, neutered, microchipped, existing conditions, vet practice, pet name, cover level and dental - and the coverage checkboxes — The quote form, built from the same attributes: each question asked once, which is what the document asked for in a sentence.

Check it as an applicant would, not as a configurer: are the required markers on the things you actually need, and is anything being asked that the customer cannot reasonably know?

Step 13 - Check the Underwriting Rules

Both rules from section five are typed and live: one declines, one refers.

The underwriting rules: a decline rule when the animal's age is over 12, and a referral rule when the animal has existing conditions, each with the message the applicant sees — Both rules from section five, typed and live: one declines, one refers, and each carries the wording that goes back to the applicant.

Check the boundary rather than the rule: the document says decline anything older than twelve, so a twelve-year-old must still be quotable. Greater-than versus greater-or-equal is the classic one-character difference between what a document says and what a system does.

Step 14 - Check the Workflow

And the five bullets of prose are a workflow: the trigger, the rating, the decision that reads those same two rules, and three branches.

The generated new-business workflow: application received, rate quote, apply appetite rules, then a decision branching to quote and email, raise an underwriter task, or decline — And the five bullets of prose, as a workflow: rate it, apply the rules, then branch - quote and email, raise a task, or decline.

Follow each branch to an end. Three outcomes were described, so there should be three ends - quoted, referred and declined - and no path that stops in the middle. Nobody drew this; it was a paragraph.

The interesting claim here is not that a model can read a Word file. It is that a requirements document already contains a configured product, and that the distance between the two is transcription: slow, unreviewable, and done by whoever is free rather than by whoever wrote the requirements.

Handing the document over closes that distance in one pass, but it moves the work rather than removing it. What was a week of typing becomes an hour of checking, and the checking is real. The proposal is reviewable before anything changes, the codes are the builder’s own invention, the numbers have to be reconciled against the document’s tables, and the boundary on a decline rule still deserves a person’s eye. That is a good trade, but only if you actually do the six checks.