Laravel and insurance broker
Blade layouts, a proposal form, and the line a broker cannot cross
A broking site in Laravel is usually three things at once: public pages, a proposal form that runs over several steps, and a client area holding documents. The assistant belongs on the first, gets asked about the second, and must stay off the third. The awkward part is that the second is where the questions come from and it is the part a crawl cannot see.
Why this pairing is its own job
The Laravel install guide covers the tag, and the insurance broker guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The proposal runs through Blade views rendered behind a POST with answers held in the session. The field labels, the help text and the declaration wording live in templates a crawl never requests, so the questions visitors are stuck on are precisely the ones missing from the material.
- The assistant can explain what a question asks for and must never answer it on somebody's behalf. Non disclosure is the customer's largest risk in this trade, and a helpful sentence about whether a detail probably matters is exactly the sentence that must not exist.
- Broker sites render printable summaries and certificates through their own stripped layout. That is the one layout where a launcher would be absurd and the easiest one to paste into by accident, because it has a body tag like all the others.
- The client area and the public site are one application with two layouts. Schedules, wordings and certificates sit behind the login, and none of it is readable by the assistant whichever layout ends up carrying the tag.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Laravel guide. Everything below is about where it goes on a insurance broker site specifically.
Publish the form's own wording as a page before you touch a layout
The highest value change on this pair is not the install. Take the questions the proposal asks, with the explanation each deserves, and publish them as an ordinary page: what we need in order to quote, and what each answer means. That page is crawlable, it answers most of the traffic the form generates, and on most broker sites it does not exist.
Write it as description rather than guidance. What turnover means for this class, what counts as a claim, which period the history covers, why the question is asked at all. Not whether a particular thing needs declaring, which goes to a broker every time without exception.
One layout is never all your layouts, and here it matters more
Search resources/views for the closing body tag and read the list. On a broker site you will typically find the public layout, a client area layout, and a print or document layout used for summaries and certificates.
The public one gets the tag. The client area one does not, because a customer looking at their own schedule is the person most likely to ask a coverage question of whatever is on screen. The print layout does not, because a launcher rendered into a certificate is a defect somebody will screenshot and send you.
Clear the compiled views after deploying, as with any Blade change, or the file on disk and the layout being rendered disagree and you spend the afternoon on the wrong problem entirely.
The claims route belongs in the refusal wording, not only on a page
Somebody who has just had an incident types before they read. Whatever the material holds, the first reply has to carry the claims line and its hours, which means it belongs in the refusal message itself rather than in a page the assistant may or may not reach for.
That is a setting rather than a template change, and it is the one part of this install worth completing before the tag goes live rather than after the first real message arrives.
Where the answerable material lives
| Product descriptions by class of business | What each cover is for, in the words customers use rather than the words insurers use. Matching a trade to a product class is the most useful thing the assistant does on a broking site. |
|---|---|
| What we need in order to quote | The page built out of the proposal questions. Crawlable, factual, and the single document that turns a stalled form into a submitted one. |
| Fees, cancellation and cooling off | Whether you charge a broker fee and on what, how a refund is calculated, what the cooling off period allows. Fixed answers to questions that consume real phone time. |
| Policy wordings | Deliberately absent. Index a wording and you have handed the assistant clause text to reason from, which is how a coverage answer gets composed. Keep wordings out and let coverage questions fall below the threshold and return the refusal. |
The first thing to get right
Publish the proposal questions as a page, index it, and link it from the first step of the form.
Abandoned proposals are the measurable loss on a broking site, and the cause is nearly always a question somebody could not answer confidently at nine in the evening. That page fixes the abandonment whether or not anybody opens the chat panel, which makes it the rare piece of setup work that pays for itself before the widget does.
The failure that belongs to this combination
It explained the form so well that somebody expected it to answer the question
The failure here is not a wrong answer, it is a helpful one. A visitor asks what claims history means, gets a clear explanation drawn from your own page, and asks the obvious next thing: does a windscreen claim from two years ago count. The material has an answer shaped hole exactly there and the conversation has momentum.
That is why the page must stay descriptive and the refusal must be specific. Whether something needs disclosing is a question about one person's circumstances with a policy consequence attached, and the only correct output is a name, an email and a broker calling back.
Set the caution level so a question of that shape falls below the match threshold rather than reaching for the nearest paragraph. On this trade a refusal is the product working rather than the product failing, and the team needs to hear that framing before they see the first transcript.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a insurance broker visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Can it prefill or submit the proposal for somebody?
- No. It has no connection to the form, the session or the application, and it never sees what has been typed into any step. It answers questions about the wording of the form from a page you published, and everything else is a handover.
- Our site is mostly about cover. Will it end up answering coverage questions?
- Only if you index the wordings. Keep the material to what each product is for, what you need in order to quote and how the process works, and there is no clause text for it to reason from. Then raise the caution level so a coverage question returns the refusal rather than the nearest marketing paragraph.
- Where does the client portal fit in?
- Outside all of this. It renders through its own layout, that layout does not get the tag, and nothing behind the login is readable by the assistant under any configuration. A customer who wants their own documents discussed needs a person, and the refusal should name which one.
Keep reading
- Installing on LaravelPaste the tag into resources/views/layouts/app.blade.php before the closing body tag, then clear the compiled view cache.
- Everything for a insurance brokerProduct information is safe ground. A personal recommendation is regulated, and no assistant may confirm whether a loss is covered.
- When installing the widget is a release, and rolling back is an uninstallThe template is packaged at build time, so the widget arrives with a release and a rollback removes it again with nothing to show that it did.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.