A default notice nobody saw for a week
A client pays their commercial van policy monthly through a premium finance provider. One direct debit fails. The provider sends a default notice, perhaps by email to a shared address, perhaps as an entry on its broker portal. It sits there. The provider's process moves on: a second attempt, a letter, and eventually a notice that the agreement will be terminated and the insurer asked to cancel.
By the time a handler notices, the client has a letter saying their cover is about to end. They ring, upset, and ask why nobody told them sooner. Often it was a changed bank account or an expired card, something that could have been sorted in a two-minute call.
Why default notices get lost
Premium finance providers each have their own way of telling brokers about missed payments. Some email, some post to a portal, some send a daily file. None of them lands in the broking system as a task. Someone has to look, find the policy and decide what to do.
The notices are also easy to deprioritise. They look like admin, arrive among many other emails, and do not have the urgency of a new enquiry, until the deadline is close.
The cost of reaching the client late
- Clients lose cover or come close to it over something easily fixed.
- Cancellations mean reissuing, reinstating or rebroking, all extra work.
- Clients blame the broker, whatever the cause, and some leave at renewal.
- There is no clear record of when the client was contacted and how.
What you say to a client about their finance agreement and cover is governed by your own procedures and the provider's terms. The build is about making sure the conversation happens early and is recorded.
An alert, a contact sequence and a board
- Default notices are collected from wherever each provider sends them: email, portal export or data file.
- Each notice is read and matched to the client and policy in your broking system.
- A contact sequence starts straight away: a text message and email to the client in your wording, with a way to call back or update their payment details through the provider's own route.
- If the client does not respond, the account handler gets a task to call, with the provider's next deadline shown.
- Every contact attempt and outcome is logged to the client file.
- A board shows all open defaults by provider, date and next deadline, so a manager can see what is at risk.
- When the provider confirms the arrears are cleared, the case closes automatically.
The difference in the first week
| Day | Without the workflow | With it |
|---|---|---|
| Notice issued | Sits in an inbox or portal | Matched to the client the same day |
| First few days | No contact | Text and email to the client |
| No response | Nothing happens | Handler task to call |
| Later notices | Client calls, upset | Most cases already resolved |
The last line is what the workflow is designed for, not a promise of outcome. Some clients will not respond whatever you do. The point is that every one of them is contacted and recorded.
It also changes who does the work. Nobody has to remember to log into four provider portals each morning. The notices come to the team as tasks, already matched to the client, with the provider's deadline on the screen. Handlers spend their time on the calls that need a person, such as the client whose business is struggling and wants to talk about their options with the provider, rather than on finding out who is in arrears.
Is this a problem in your office?
- Default notices from finance providers sit unread for days.
- Clients have been surprised by cancellation letters.
- Nobody owns the job of checking the provider portals.
- You could not quickly list every client currently in arrears.