An app for buying, an inbox for everything after
Your digital-first insurance product lets customers buy in minutes. After that, things slow down. A customer moves house, adds a named driver, buys a new laptop to add to their gadget cover, or changes their business turnover. The app lets them update their email address and phone number. For anything else, it says contact us.
Support takes the request, types it into the policy administration system as a mid-term adjustment, gets a price, emails the customer, waits for them to accept, takes payment and sends the new documents. For a simple change this can take days. For the customer, it feels like the product they bought is not the product they have.
Why changes were left out of the app
Launch focused on new business. Changes are harder because they touch the existing policy, the price, the payment and the documents at once.
- The rating was built for new quotes, not for re-rating part way through a policy.
- Additional or return premium calculations sit inside the policy administration system and are not exposed.
- Some changes need an underwriter, and there was no way to route them from the app.
- Taking or refunding a premium difference needs payment handling the app did not have.
- Updated documents have to be generated and issued.
A support team doing data entry
Support spends much of its time typing changes into the system rather than helping customers. Changes wait, and while they wait the customer's cover may not match their situation, which matters at claim time. Errors creep in through rekeying. Customers compare your post-sale experience with the buying journey and are disappointed.
Which changes can be made automatically and which need an underwriter is for your underwriting team to decide within your authority. The build applies those rules.
Self-serve changes we build
What we build extends the app to handle the changes customers ask for most.
- We list the change requests support handles and pick the common ones to build first, such as change of address, adding a driver or an item, or changing a sum insured.
- Each change is a short flow in the app that asks only what that change needs.
- The change is re-rated through your rating service or the policy administration system's quote API, and the customer sees the difference in premium before confirming.
- Any additional premium is taken through your payment provider, and any return is refunded or credited according to your rules.
- The change is written to the policy administration system as a mid-term adjustment through its API, and updated documents are generated and sent.
- Changes outside your automatic rules go to the underwriting queue with the details attached, and the customer sees that it is being reviewed.
| Change type | Typical route | Customer sees |
|---|---|---|
| Change of address within rules | Automatic re-rate and issue | New price, confirm, new documents |
| Add an item under the single-item limit | Automatic | New price, confirm, new documents |
| Add a named driver with claims or convictions | Underwriting referral | Under review, with an update when decided |
| Increase sum insured above auto limit | Underwriting referral | Under review |
| Contact details | Automatic, no re-rate | Updated immediately |
Changes on an ordinary day
We usually start with the two or three changes that make up most of the support requests, get those working end to end, then add more. Each new change type reuses the same re-rating, payment and document steps.
A customer who moves house updates their address in the app, sees a small change in premium, confirms, pays and downloads new documents. Support never sees it. A change that needs an underwriter reaches them with everything attached. Support deals with the customers who genuinely need help.
Signs your change process needs this
- Most support contacts after purchase are change requests.
- The app cannot re-rate a live policy.
- Support types changes into the policy system.
- Customers wait days for simple changes.
- Documents are resent manually after changes.