How to Create Well-Designed Insurance Email Templates in Openkoda PAS

Why Insurance Email Templates Are Worth Doing Properly

Most of what a customer knows about their insurer arrives by email. The quote, the welcome, the renewal reminder, the receipt, the request for a missing document. The policy is a database row, but the relationship is a sequence of messages.

Those messages are usually the last thing anybody configures. They end up hard-coded in a developer’s file, or pasted by hand from somebody’s drafts folder, which is why so many of them look like a form letter from 2009.

A template system worth having answers four questions:

Who writes it? Ideally the person who owns the customer relationship, not a developer with a ticket.
How does it get the data? Placeholders bound to fields on a record, so “your policy expires on…” is filled from the policy rather than typed.
Who sends it, and when? A workflow step, so nobody has to remember.
Where does the copy go afterwards? Onto the record, so a year later you can see what the customer was actually told.

This walkthrough builds one renewal reminder from nothing and follows it all the way to the sent log. The first draft is written by AI, which turns out to matter less for the prose than for the placeholders, as Step 4 explains.

Before you start, you will need: an account that can reach the template library and the product builder, and a product with at least one workflow on it.

The whole thing is on video too, if you would rather watch it than read it. It runs three and a half minutes; the written version below has the detail worth having open in another window while you work.

How to Build an Email Template in Openkoda PAS

Step 1 - Start From the Template Library

Every message the system sends starts as a template, and they live together in one place: quote letters, welcome emails, renewal notices, payment reminders, decline letters.

The email templates list showing templates for claims, declines, receipts, welcomes and quotes, each tied to a product with a placeholder count and a status — Every message the system sends starts here - each template tied to a kind of record, optionally to one product, with a count of the placeholders in it.

The placeholders column is the one to read when you inherit somebody else’s library. 6 · 6 mapped means six tokens in the template and all six bound to a field. A template showing 7 · 6 mapped has one token that will not resolve, which is how “Dear {##insured_party.first_name##},” reaches a real customer.

Step 2 - Name It and Bind It to a Record Type

A new template needs a name and the kind of record it belongs to. Everything else follows from that second choice.

The new template form with a name typed, entity type set to Policy, an optional document type and a product scope of all products — Two fields decide everything downstream: the name, and the kind of record it belongs to. Choose Policy and every field on a policy becomes available to it.

Choosing Policy does two things at once: it decides which fields the template can reach, and it decides where the template is offered, on policies and nowhere else. The product scope is the narrower cut. Leave it generic and every product can use this wording, or pin it to one product when the tone or the legal wording differs.

Step 3 - Describe the Email You Want

Rather than starting from an empty box, describe the job in a sentence or two.

The Draft with AI panel with a two-sentence description of a renewal reminder typed into it — Describe the job, not the layout: what the email is for, what it must say, and what you want the reader to do.

Describe the job, not the layout. What the email is, when it goes out, the facts it must carry, and the one thing you want the reader to do. Layout is what the draft is good at; intent is what only you know.

One practical warning: the draft writes the subject line as well as the body, so anything you type into the subject beforehand is overwritten. Draft first, edit second.

Step 4 - Read What Came Back

What arrives is a whole email rather than a blob of text: a branded header, a headline, a greeting, body copy, a call-to-action button, a sign-off.

The drafted email in the editor: a branded header bar, a headline, a greeting, body copy with placeholders, a call-to-action button and a sign-off — A first draft with the shape of a real email - branded header, headline, body, a call-to-action button, a sign-off - and the record's fields already written in as placeholders.

The prose is the least interesting part of this. What matters is that the fields are written as real placeholders, {##current_period.policy_expiry_date##} and {##current_period.gross_written_premium##}, rather than plausible guesses at what your data might be called. A draft that invents field names costs more to fix than writing the email by hand; one that uses your actual schema is genuinely a first draft.

Read it as an editor, not as a proofreader. Is the one action you want the reader to take obvious? Does it say when, and how much? Is anything promised that your team cannot deliver?

Step 5 - Check the Subject Line

The subject line field, written by the draft, containing two placeholders — The subject was written for you too - and placeholders work there, so the customer sees their own product and date before they open anything.

Placeholders work in the subject, which is worth exploiting: a subject carrying the product name and the expiry date is a reminder even when it is never opened. Keep the tokens near the front, because mail clients truncate, and a personalized detail after the cut is a detail nobody sees.

Step 6 - Edit It Like a Document, Not Like Code

The draft is a draft. Everything in it is editable in a visual editor: headings, bold, lists, alignment, links, color.

The editor toolbar with headings, bold, lists, alignment, links and color, above the email body with one line emphasised — Everything is editable on a toolbar - headings, bold, lists, alignment, links, color. Select a line, emphasize it, move on.

This is the step that decides who owns your customer wording. If changing “at your earliest convenience” to “within 14 days” takes a selection and a click, the person who cares about the sentence can make it. If it takes a pull request, they will not, and the sentence will stay wrong for a year.

Step 7 - Insert a Field Rather Than Type a Value

When the message needs to say something about the record, pick the field.

The insert-placeholder menu listing fields from a linked record, each with its human label and the token it inserts — Pick the field instead of typing the value. The list follows the record's links outward, and each row shows the label and the token it will insert.

Two things make this list usable rather than a lucky dip. It follows the record’s links outward, from the policy to the product, the insured, the broker, the agency, the current period, so a template can reach the whole of a policy’s world without anybody writing a query. And every row shows both the human label and the token it inserts, so you choose by meaning and the system writes the syntax.

There is a keyboard route too: typing an opening brace in the body searches the same list without leaving the keyboard.

Step 8 - Save, and Check What It Detected

On save the template is read back, and the placeholders in it are listed and bound.

The saved template page listing the placeholders it detected and a mapping table binding each one to a field on the record — On save the template is read back: every placeholder found, and every one bound to a field on the record it belongs to.

Do the arithmetic here, the same as in Step 1: detected should equal mapped. If the page finds nine placeholders and maps eight, one of them is misspelled or points at a field that does not exist on this record type, and fixing it now costs nothing.

Step 9 - Preview It as the Recipient Will See It

The email preview showing the rendered message with its tokens still visible because no record is attached — Preview renders it as the recipient will see it. The tokens are still showing because no policy is attached yet - this is the template, not a sent message.

The tokens still showing is correct, not a bug: no policy is attached, so there is nothing to substitute. This is the template. Attach a record, which is what happens when a workflow sends it, and each token becomes that policy’s own detail.

What preview is for is the layout: does the header survive, does the button sit where you meant, does a long product name wrap into something ugly.

Step 10 - Let a Workflow Send It

Then nobody has to remember. A Send message step in any workflow picks the template and the recipient.

A three-step workflow - a schedule, a send-message step and an end - with the send step's properties showing the channel, the template and the recipient — A Send message step picks the template and who it goes to. Because it points at the template, editing the wording changes what goes out - with no workflow to touch.

The recipient is a role rather than an address, the customer, their broker, the agency, the carrier, which is what makes one step correct for every policy the workflow runs on. The same step can attach a document generated from a Word template, add accept and decline links or a pay-now link, and drop a copy into the client portal.

And because the step points at the template, not at a copy of its text, editing the wording changes what every workflow using it sends. No workflow to edit, nothing to redeploy.

Step 11 - Everything Sent Is Kept

The email log listing every message the system has sent with its recipient, the record it is about, its status and the time — Every message the system sends is kept against the record it belongs to - so a policy's history includes what the customer was actually told.

Each row records what was sent, to whom, about which record, whether it left, and when, with attachments counted. This is the part that is missing when transactional mail is sent from outside the system: the history of a policy should include what the customer was told, not just what was done to their record.

Step 12 - Decide Who May Change the Wording

Two separate privileges in the role builder: viewing document and email templates, and managing them — Viewing templates and changing them are separate privileges - so the people who write the wording need not be the people who can see it.

Viewing templates and managing them are separate privileges, which is the right granularity: an underwriter can see what a customer was sent without being able to rewrite next month’s renewal notice.

The template list with the newly created renewal reminder at the top, active, with all its placeholders mapped — And the finished template joins the library: active, every placeholder mapped, available to any workflow on the records it belongs to.

The useful idea here is not that a model can write an email. It is that the email lives in the product: bound to a record type, its placeholders checked against real fields, sent by a workflow that points at it rather than copying it, and logged against the policy afterwards.

That is what turns “we should soften the renewal reminder” from a ticket into an afternoon. The draft saves you the blank page and, more usefully, gets the field names right the first time. The visual editor means the person who owns the sentence can change the sentence. Everything after that, the mapping check, the preview, the sent log, exists so you can be confident about what your customers actually received.