Your website form feeds other tools: who else receives that data?

Submit a test enquiry with a made-up name and a mailbox you control. Then watch where it lands. Check the CRM, the inbox, the sheet, the chat history and the ad dashboard. Open the CRM, the mailbox, the chat widget history, the ad account and the automation tool one by one, and look for that test name in each of them.

Most owners expect two destinations and find five. A plugin posts to the mailer. An automation copies the row to a sheet. The pixel reports a conversion with a hashed email.

Draw the path as boxes and arrows on one page. Every box is a vendor that now holds someone’s name and phone number. Add the date each connection was made and who set it up, because the person who wired the Zapier zap three years ago may have left long ago.

A processor handles data on your instructions, such as a CRM or a mail platform. You choose why the data is used. The vendor only stores and sends it. Typical processors are the CRM, the mail platform and the form plugin, since each stores or forwards contact details only for the task you gave it.

Some ad and analytics tools use data for their own purposes as well. Read the vendor’s data terms. Where they use it for their own ends, your lawyer needs to look at the arrangement. Where a vendor uses submissions to build audiences or improve its own products, ask your lawyer whether your notice and your consent wording actually cover that use.

Keep a register with one row per vendor. It lists what they receive, where they are based and whether you hold a signed data processing agreement.

A booking tool needs a name, a date and a way to reply. It does not need the date of birth or the home address that the form also collects. Go field by field through the form. Compare the form with the CRM record afterwards, and you will often find a date of birth, a postal address and a free-text field nobody opens.

An ad pixel needs an event, not a person. Send the conversion without the email where you can. A chat widget needs a name and a message, not the full enquiry body. If the chat widget only has to say hello by name, there is no reason for it to carry the phone number and the budget field as well.

Mark each field as needed, useful or unused for each destination. Unused fields come out of the payload this week.

Edit the form’s webhook or plugin settings so each tool gets its own short field list. Many form builders send the whole submission by default. Switch that off. Use a named mapping in each tool: the mailer gets first name and email, the CRM gets name, phone and enquiry type, and the sheet gets a reference number.

Remove copies nobody reads. The spreadsheet from a campaign two years ago may still be collecting rows. Archive it, delete it or end the automation.

Check consent too. If the form feeds a mailing list, the tick box must be separate and unticked, and the record should store when it was given. Store the consent time, the wording shown and the page address with the record, so you can answer a withdrawal request without hunting through old screenshots.

Forms change when a marketer adds a plugin. Put a line in the launch checklist: any new tool that touches a form updates the register first. Ask whoever runs the website to tell you before installing a new plugin, pixel or booking widget that touches the form, and add that rule to the handover notes.

Review the register every quarter alongside the retention schedule. Cancel tools you no longer use and delete the data inside them.

Start today by running one test submission and comparing it with last year’s notes.