The problem with agency form embeds
A nanny agency runs on two forms: the family enquiry and the candidate registration. Both need to end up in the CRM, whether that is a recruitment platform, a general sales CRM or a childcare-agency-specific system. So the CRM offers an embed snippet, someone pastes it in, and the site gets slower.
The damage is rarely on the form page itself. It is that the snippet ends up in a global template, so every page, including the vetting page and the fees page that do the persuading, loads a third-party script and often an iframe it never uses.
There are three ways to connect a form to a CRM. They perform very differently.
Option one: link out to a hosted form
The CRM hosts the form on its own domain and you link to it. Nothing loads on your site, the integration cannot break, and it takes ten minutes.
The cost is that the family leaves your site mid-decision and lands on a page that looks like someone else's. For a candidate registration that is usually acceptable. For a family enquiry, at the moment they have just read your vetting page, it is not.
Option two: embed the vendor's form
An iframe or a script that renders the vendor's form inside your page. Fields map themselves, and the form works without a developer.
The costs are real: extra requests, often a third-party stylesheet and script, layout shift while it loads, a form that cannot be styled to match, and third-party cookies that may need to sit behind your consent banner. Iframes also break autofill and can be awkward with screen readers and keyboard focus.
Use it where the CRM's form does something you do not want to rebuild, such as CV parsing on upload.
Option three: your own form, posting server side
Build the form in your own site, in your own markup, and post it from your server to the CRM's API. Nothing third-party runs in the visitor's browser at all.
This is what we build for agency sites. The form is fast, it is styled like the rest of the site, it works on a phone with autofill, the three-step branching flow is yours to design, and the CRM never sees the visitor's browser. The trade is that someone has to build and maintain the field mapping.
The rules if you do embed
Load it on one page only. The enquiry embed on the enquiry page, the registration embed on the registration page. Every other page links to them. No form scripts in the footer template.
Reserve the height. Give the container a minimum height matching the rendered form so the page does not jump while it loads. Layout shift on a form is the most irritating kind, because it moves the field someone is typing in.
Preconnect, do not preload. One line in the head of the page that carries the embed:
<link rel="preconnect" href="https://forms.your-crm.com" crossorigin />Load on interaction where you can. If the form sits below a page of content, render a placeholder and load the widget when the visitor scrolls to it or taps into it.
Do not put an embed behind a consent banner it needs to work. If the vendor sets cookies, either configure the cookieless option where one exists or make sure the form is reachable another way for someone who declines.
Never lose an enquiry
Whichever option you choose, add a fallback. Post to the CRM, and if the API call fails, queue it and email the enquiry to the office. An agency that loses a family enquiry to an expired API token loses a placement fee and never finds out why.
Log submissions on your own side too, with a timestamp and the CRM record id, so a "we filled in your form last week" call can be answered.
Uploads deserve their own thinking
Candidate registration means CV upload, and uploads through a third-party iframe on a phone are the most common silent failure on an agency site. If you build the form yourself, upload directly to your own storage, show real progress, state the size limit before the file is chosen, and keep the rest of the form filled in when an upload errors.
Keep sensitive documents out of web forms entirely. Certificates and identity documents belong in your verification process, not in a public upload field.
Spam without the weight
Agency forms attract bots. A honeypot field plus a lightweight challenge is enough for most, and it costs a fraction of a heavy verification script running on every page. Add a rate limit on the server. Do not put a challenge in front of a family enquiry unless you have a real problem, because it costs you genuine enquiries.
What to test before launch
Submit both forms on a phone and a laptop. Confirm each record lands in the CRM with every field mapped, not merged into a notes blob. Confirm the confirmation email arrives and is not in spam. Confirm the fallback email fires when the integration is switched off. Then run a page speed test on the vetting and fees pages and check that no form script loads there at all.
Where this sits
Own forms, server-side posting into your CRM, embeds isolated to a single page and a fallback that never drops an enquiry are how we build a nanny agency website, and the same integration pattern runs through our childcare websites. The packages are on pricing. Keep the third-party code on the one page that needs it.