AI chatbot for a mortgage broker website

A chat widget on a broker website is a small thing with a disproportionate ability to cause problems, because it is the one part of your marketing that improvises. Everything else on the site was written once and approved. The chat window makes up new sentences about regulated products, in public, unsupervised, at three in the morning.

That is manageable. It just needs to be treated as a publishing decision rather than a plugin installation.

Be honest about what you want from it

Most brokers who install one want more enquiries. Very few want a support channel, and almost none want an explainer service for people who will never become clients.

If the goal is enquiries, the widget's job is short: work out roughly what the visitor needs, capture a way of contacting them, and get a slot in a diary. Measured against that goal, a long informative conversation that ends without contact details is a failure, not a success, however impressive the transcript reads.

Deciding this first changes the design. An enquiry-focused widget asks questions. An explainer-focused one answers them, and it tends to satisfy curiosity without ever creating a lead.

The scope problem

The hard part is not making the thing talk. It is stopping it.

A visitor will ask whether they can borrow five times income on a fixed-term contract. A general-purpose model will answer, because answering is what it does. That answer is a communication from your firm about a regulated product, made to a specific person's circumstances, without a fact find and without an adviser.

Even where it does not amount to regulated advice, it is a client communication and it sits under the FCA's requirement that communications are fair, clear and not misleading. If it is wrong, it is your firm that was wrong.

So define the boundary explicitly and test it hard. A reasonable position is that the widget may describe your services, your process, your fees, your opening hours and general uncontested facts about how mortgages work in the UK, and that anything touching the visitor's own eligibility, affordability, likely rate or product choice routes to an adviser without an opinion attached.

Then try to break it. Ask leading questions. Ask it to speculate. Ask it as though you were an anxious first-time buyer who wants reassurance. The interesting failures are not the rude prompts; they are the sympathetic ones, where the model wants to be helpful and drifts across the line to do it.

Restricting what it knows

A widget answering from your own approved content is a very different risk from one answering from general knowledge.

The safer pattern is to give it a defined body of material, drawn from pages your firm has written and checked, and to instruct it to answer only from that material and to say so when it cannot. This does not eliminate invention, but it narrows it substantially, and it means most answers are things you already stand behind.

It also means your website content becomes the product. Vague pages produce vague answers. Firms often find that building this forces them to write down things they have never written down, such as what their fee actually is and when it is charged, which is useful independent of the chatbot.

Disclosure, data and the boring paperwork

Say it is automated, in the widget, before the conversation starts. People work it out anyway and the ones who work it out late feel misled.

Treat every transcript as personal data. Visitors type things into chat boxes that they would never put in a form, including health details and financial distress, so your retention period should be short and deliberate rather than indefinite. Your privacy notice needs to cover the widget, and if the vendor processes conversations outside the UK that needs to be documented.

Cookie and consent rules apply to the widget like anything else that stores information on a visitor's device. Check what the vendor drops before the visitor has agreed to anything.

Keep the transcript with the enquiry when one is created. An enquiry that arrives in your CRM without the conversation that produced it forces the adviser to start from nothing, which annoys the client who has just explained their situation at length.

Escalation, and being available

The route to a person is the most important feature and the one most implementations get wrong.

There should be an obvious way to ask for a human at any point, it should be offered proactively when the conversation stalls, and it should trigger automatically on anything resembling a complaint, distress, or a mention of difficulty paying. Do not let a widget try to help someone who says they are worried about losing their home.

During working hours, escalation should mean a live handover if you can staff it. Outside them, it should mean a captured contact and an honest promise about when someone will call, kept.

What to check once a month

Read conversations, not dashboards. Twenty transcripts, chosen at random, read end to end.

You are looking for three things. Answers that went beyond scope, which tells you the boundary needs tightening. Conversations that ended without contact details, which tells you the flow is not doing its job. And questions asked repeatedly that your website does not answer well, which is a free content plan.

That last one is often the widget's biggest return. Firms install a chatbot expecting leads and end up with an unusually honest list of what their prospective clients are confused about.

Whether it is worth it at all

For a firm with meaningful website traffic and a habit of responding fast, a tightly scoped widget is a reasonable addition. For a firm with forty visitors a month, it is decoration, and the effort would be better spent making the phone number obvious and answering it.