The enquiry checklist for handing a website over to a client

Why do enquiries break at handover?

Because handover is when the things a form depends on change hands. The domain moves from staging to live, DNS records change, mail accounts move from the agency to the client, and the person who tested the forms moves on to the next project.

The usual result is a form that looks fine to visitors and sends nothing useful. Notifications still go to a developer's test address, email goes out through an SMTP account the agency later closes, or a spam check rejects every visitor because its key was registered for the staging domain. The client rarely notices straight away, and only wonders a few weeks later why the website has gone quiet. Handover is often the last time anyone technical looks closely at the forms, so an hour spent on them now pays for itself.

How should you test every form before handover?

Test each form on the live domain, after the DNS change, exactly as a visitor would. A test on staging proves very little about the live site's mail, keys and caching.

List every form first, including the ones people forget: the footer newsletter sign-up, a pop-up, a quote form on one service page, a careers form. Then run each one through the same steps.

1. 1

   Submit it as a visitor

   Use a private browser window on the live domain, logged out, and fill in every required field with recognisable test details.

2. 2

   Check what the visitor sees

   Confirm the success message or thank-you page appears, and that a validation error shows clearly when a required field is left empty.

3. 3

   Check the notification

   Confirm it reached the client's inbox or phone, not spam, with every field present and the visitor's address set as the reply-to.

4. 4

   Check the auto-reply

   If the form sends the visitor a confirmation, make sure it arrives, comes from the client's domain and has no placeholder text.

5. 5

   Repeat on a phone

   Submit once from a mobile, and once with a file attached if the form accepts uploads.

Warn the client before you start, so nobody tries to ring your test details back at nine in the evening, and delete the test entries afterwards so their records start clean. If a form fails, fix it and run every step again, because one change to the mail settings can affect all the forms.

Is the email set up properly on the client's domain?

Form email should come from an address on the client's own domain and go out through a mail service the client owns. If it's sent through your agency's SMTP account or API key, it stops the day that account is cancelled or its password changes.

Move the sending account into the client's name, or set up a new one in their name, before you hand over. Then check that the domain's SPF, DKIM and DMARC records cover the service you've chosen, so receiving servers trust the mail. For the sending side, see how to set up SMTP for WordPress contact forms; SPF, DKIM and DMARC in plain English covers the DNS records.

Set the reply-to on each notification to the visitor's own email address. The client can then press Reply and answer the enquiry directly, instead of sending their reply to the website's own sending address, where nobody reads it.

Who should receive the notifications?

The client, at an address the business owns. A role address such as enquiries@ survives staff changes better than one person's mailbox, and a second recipient means a holiday or a full inbox doesn't block anything.

Ask the client who actually answers enquiries and where they look during the day. A tradesperson on site may never open email before the evening, so a text or WhatsApp alert may suit them better than another inbox. Where different forms go to different people, such as sales and support, test each route separately.

If the client wants alerts on a phone, connect their phone rather than yours, and send a test while you're with them, so they know what a real enquiry looks like when it arrives and where to tap to see the full details.

What else belongs on the handover checklist?

Five more items: spam protection, a stored copy, the privacy notice, account ownership and a written note. Each is quick to fix before you leave and awkward to fix afterwards.

Spam protection on the live domain

reCAPTCHA keys and Cloudflare Turnstile widgets only work on the domains registered for them, so a key set up for staging can block every real visitor on the live site. Add the live domain, and create the keys in the client's own Google or Cloudflare account. Check the filter's strictness too, because an over-strict filter loses real enquiries as surely as a broken form. How to stop contact form spam without losing real enquiries covers the trade-offs.

A copy of every submission

If the notification email is the only record, one mail fault loses enquiries for good, and Contact Form 7 keeps no copy of its own. Turn on stored entries or another copy before handover, and show the client where to find it. How to keep a copy of every form submission compares the options.

A privacy notice by the form

The ICO says you must give people privacy information at the time you collect their details. In practice that means a link to the privacy notice next to the submit button, and a notice that names any service receiving submissions, such as a mail provider, a CRM or an alert service. The client is responsible for the notice, but you're best placed to tell them what the site sends where.

Accounts in the client's name

The mail service, the spam protection keys, any alert service and the form plugin's licence should belong to the client, or be handed over with a clear note of who pays for what. Anything left in your agency's accounts becomes a single point of failure the day you part ways.

A one-page handover note

List every form, where its notifications go, how mail is sent, where copies are stored, which accounts are involved and who to call if enquiries stop. Keep it short enough that the client will actually read it, and save a copy yourself.

What should happen after handover?

Test again a week after go-live, then on a schedule. Plugin updates, hosting changes and expiring keys break forms long after launch, and an uptime monitor won't notice, because the page still loads.

When a client does report that enquiries have stopped, these are the usual causes:

Nothing arrives at all

Submit the form yourself. If the visitor sees an error, check the spam protection keys and recent plugin updates. If it succeeds, check the mail service account and its logs.

Notifications land in spam

Check the SPF, DKIM and DMARC records still cover the mail service, especially after a DNS or hosting move.

Emails go to someone who has left

Update each form's recipient to a role address the business controls.

Some forms work and others don't

Look for forms with their own settings, such as a separate recipient, a different form plugin or a pop-up added later.

If you run a care plan, add a monthly test submission to it and ask the client to confirm it arrived. If you don't, show the client how to send one themselves, and tell them plainly that a website going quiet is a reason to check the forms before putting it down to a slow month. Write the date of each test in the handover note so the next person knows when it last worked.

Where does Formcrier fit?

Formcrier sends each submission straight to the client's phone on WhatsApp, a text, Telegram, Slack or Microsoft Teams, and its dashboard shows whether every alert was delivered, with the reason if it wasn't. With Contact Form 7 it still alerts when the site's own email fails. See Formcrier for agencies.