We rebuilt your pet quote journey on InsuredHQ in a few hours.
Not a mockup. A live, working POC - quote, client, policy, a separate line of business per pet, and invoice all created through our Core API in a single call chain. And it works.
A live POC on your own journey, stood up in less than a day.
Insurance technology should accelerate you, not gate you. To prove that point in the most direct way possible, we took your existing online quote journey, mapped the steps, and rebuilt a parallel version of it on InsuredHQ - connected to a sandbox provisioned just for you.
It took less than a day. One person. No bespoke build. No "discovery phase." The same framework we use to stand up new products on the platform was pointed at your journey, and the result is what you see in this paper.
Why we did it this way
The fastest argument for speed is to demonstrate it. Rather than ask you to imagine how quickly we could replicate your product, we did it - and provisioned a sandbox so you can poke at it. Your specific journey is incidental. The point is that any product, in any line of business, can be stood up on InsuredHQ at this pace. Pet was just convenient and visual.
Seven screens. Every one is calling IHQ Core through our API.
What follows is the front-end journey we wired up. Every screen below is calling our Core API in the background. By the time the customer gets to the quote screen, a client record, a quotation and a tracked quick-quote already exist inside InsuredHQ. On bind, the policy, a separate line of business per pet - cats and dogs treated independently - and the invoices are all created in the same call chain.
The customer picks a species. Behind the scenes, the framework opens a Quick Quote against an anonymous quote client. Nothing is lost between this screen and the next - every keystroke onwards is appended to the same record.
Name, gender, date of birth, desexed status. Each of these maps directly to attributes against the line of business that will eventually sit under the policy. We are already shaping the LOB at this point, not just collecting form data.
Breed selection is backed by a rating table held inside InsuredHQ. The exact same interface that drives the picker here is what your team would use to add new breeds, retire old ones, or change the risk loading on any of them - across an effective date range, with no code change.
The two underwriting questions below sit entirely inside the front-end journey. That is by design - underwriting questions, eligibility logic and customer wording are where insurers differentiate, and they change often. Your application owns these. InsuredHQ records the answers against the LOB and exposes them to your rating call.
Each pet on the policy becomes its own Line of Business inside InsuredHQ. That means each one carries its own premium, its own taxes and levies, its own broker or sales commission, and its own underwriter and reinsurer seeding rules - differentiated by species. A multi-pet household is a single policy with multiple LOBs, each financially distinct.
The customer details screen turns the anonymous quick-quote into a named client. At this point the quick quote (tracked under a holding client) is upgraded to a full client record with its own ID, and the quotation is re-attributed to it. Nothing is duplicated and nothing is lost.
The customer sees three covers, three excess options, three payment frequencies (fortnightly, monthly, yearly), and an optional Routine Care add-on. Selecting Bind is the moment the platform earns its keep: a client, a policy, a line of business and an invoice (annual or instalment, with the full schedule) are all created from a single API call. The green banner at the top of the screen is the live confirmation from InsuredHQ.
A thin orchestration layer. A full insurance core.
The POC looks like a quote journey. What it really is, is a thin orchestration layer sitting on top of a full insurance core. Here is what was kicked off by the few API calls behind those seven screens.
Quote-to-policy lifecycle, captured end-to-end
- Quick quote tracked from the first click. The opening species selection opens a record. Every subsequent step writes back to it, so abandoned journeys are still measurable and recoverable.
- Client created on details capture. When the customer enters their name and contact details, the quick quote is upgraded to a real client record - not a duplicate, not a copy. The quote moves with it.
- Policy and LOBs created on bind. Selecting a cover triggers policy creation, with one LOB per pet. Each LOB carries its own rate, tax and levy treatment, commission profile and reinsurance seeding.
- Invoices generated automatically. Annual and instalment invoices are produced from the chosen payment frequency. The full schedule (fortnightly, monthly, annual) is materialised, not implied.
- Notifications and attachments dispatched. Policy schedule, certificate of insurance and invoice are produced and emailed to the client. The POC stops short of plugging into a live mail relay, but the documents and payloads are real.
Financial postings, generated for you
Every transaction above produces the full set of insurance-grade GL postings automatically. Every line carries its DR and CR counterpart. There is nothing for the integrating application to compute or post.
Per-species financial differentiation, out of the box
Because each pet is its own LOB, you can configure dogs and cats with different rate tables, different broker commission structures, different sales-staff incentive splits, different reinsurance treaties, even different tax treatment if jurisdiction demands it. A single policy with a dog and a cat will produce two financially distinct sets of postings, correctly apportioned, from one transaction. This same pattern scales to genuinely complex risks - the platform regularly handles aviation policies with hundreds of LOBs across panel underwriters and varying reinsurance splits, off the same engine.
Payment integration - deliberately stubbed in the POC
We have not wired this POC to any of our existing gateway integrations - Stripe, GoCardless and WorldPay are already live on InsuredHQ and production-tested elsewhere - so no card is taken and no money moves here. Picking one for a production build is a configuration decision, not a build. The hooks are in place. In production, the same flow processes the card through your chosen gateway and reconciles the resulting receipt against the invoice automatically. Customers can manage their stored card details through a self-service portal, and instalment failures are picked up by built-in credit control without manual chasing.
Rating tables - yours to control
The POC already uses a full rating-table system inside InsuredHQ with a single interface for managing rate values across effective date ranges. You add new rates or breeds, retire old ones or stand up a new calculation method without touching code. If you would rather keep rating in your own engine, InsuredHQ accepts the calculated values you pass in and proceeds with the postings either way.
Eligibility, underwriting questions, endorsement triggers, renewal invitations, cancellation reasons, refund treatment, cooling-off periods, branding and customer communications all sit in your journey, where they belong - because that is where you differentiate, and that is what changes most often. When the journey reaches a point where a financial transaction needs to be recorded, it calls InsuredHQ. From that single call, the platform takes over: premium, taxes, levies, fees, broker commissions, underwriter and reinsurer postings, instalment schedules - all driven by configuration, not by code in your application.
- Onboarding flow and questions
- Eligibility and underwriting rules
- Endorsement triggers and conditions
- Renewal invitations and re-rate logic
- Cancellation paths, refund treatment
- Lapse, reinstatement and grace periods
- Branding, copy and customer comms
- Premium, taxes, levies and fees
- Broker, sales and intermediary commissions
- Underwriter and reinsurer panel postings
- Instalment schedules and reconciliation
- Insurance-grade GL journals
- Trust-account banking and credit control
- Bordereau and regulatory reporting
Configuration, not code.
The POC took a few hours because the platform is built to be configured, not coded against. The same is true once you are live. Specifically:
-
Rate changesUpdate a row in the rating table. Effective from a date you choose. No deploy.
-
New product, same line of businessConfiguration. Days, not months.
-
New line of business entirelyA few configuration steps and a journey wrapper. Weeks, not quarters.
-
New jurisdiction or tax treatmentAdd the tax or levy rules and attach them to the carrier or LOB. No core change.
-
New broker, panel underwriter or reinsurerConfigure once. The chain rebalances automatically on the next transaction.
-
New commission structureFlat or percentage, with broker-level overrides. Configuration.
This POC was built by a talented team sitting on top of an insurance-specific OpenAPI architecture and a comprehensive platform of record. The speed you see is the compound of both - capable people, enabled by the right tools.
Your team, with full access and our framework, will move faster again.
The other half of the platform.
The POC deliberately stays inside the quote-to-bind window. There is a substantial amount of platform sitting behind that window that we have not touched in this demonstration. In rough order of how often it comes up in conversations with insurers:
Your sandbox is already running.
A dedicated environment for your team. The URL and password below get you in. Everything inside is real - real policies, real LOBs, real invoices, real GL postings.
Four things you can do inside
- Search and manage the test clients created from the POC, including the one you just walked through.
- Inspect the policy structure, the LOBs, the invoices and the underlying GL postings.
- Hit the Core API directly with the credentials we will share separately, and see exactly what your team would be integrating against.
- Take the POC code itself - the HTML/JS journey, the PHP CORS proxy, and the API call sequence - and stand up your own variant.
Two conversations we'd like to have.
Once you have had a look around the sandbox, there are two follow-ups worth booking.
First, a 30-minute walkthrough - ideally with whoever owns the product roadmap on your side - where we walk through claims, claims accounting and reinsurance recoveries on a real policy in your sandbox. That is the day-two conversation, and it is the half of the platform we have not shown you yet. Second, API credentials and sandbox login details for whoever on your team wants to poke under the hood on their own time.
The short version: you can build your next product on InsuredHQ in the time it currently takes you to scope one. We will give you the code, the sandbox and the access to prove that to yourselves before any commercial conversation.