Launching a website with CRM automation: who does what?

A new website is often only one part of a larger system. When someone completes a form, the website may store the entry, send a notification, pass details to a CRM and trigger an automation that creates a task, a document or a message.

Each of those steps can be built by a different person or company. The web developer builds the form. A marketing agency or specialist builds the workflow. Your team owns the process and the data. When something goes wrong on launch day, the question “whose job is this?” costs time you may not have.

This article proposes a way to answer that question before launch. It includes a runbook table that assigns owners to each task.

The usual cast

Every project is different, but three roles appear almost everywhere.

Sometimes one organisation covers two roles, and sometimes there are extra parties, such as a hosting provider, an email administrator or an analytics agency. What matters is that every task has a named owner, not that there are exactly three.

Credit the right people

It helps to be clear about which part each party built. In a recent example of this arrangement, our Total Health Choice project included a conditional referral form built with Gravity Forms on the website, while a separate specialist built the automation behind it. Our part was the website side: the form and its handoff. The automation belongs to the specialist.

Being exact about this is good practice, not modesty. It tells everyone whom to call about what.

Why launch day needs a plan

Websites often launch with a final switch: pointing the domain at the new hosting, publishing the new forms or turning on integrations. At that moment, several things change at once. Forms may connect to a live CRM instead of a test account. Real people start submitting real details.

A runbook turns launch from a hopeful moment into a series of checked steps.

Before launch: agree these

Before you assemble the runbook, answer these questions in writing.

1. What is the intended journey? Describe it in plain words, from visitor submission to staff action.
2. What data moves, and where? List fields and destinations.
3. Where is testing done? Which environments or accounts are test and which are live?
4. Who can say “go”? Name the person with authority to approve launch.
5. Who can say “stop”? Define what failures mean a rollback or pause.
6. How will the team know it works? Choose the checks you will accept as evidence.
7. Who is available on launch day? Include contact methods for each party.

The launch runbook

Copy this table into a shared document. Replace the example owners with names. Add rows for anything specific to your project. Mark each task when done and note who confirmed it.

Test with the right data

Use obviously fake records for launch testing. A fake name, a number and email address you control, and a phrase such as “TEST – please ignore”.

Do not use real people’s details. Do not use realistic sensitive information, such as health details. If your workflow produces documents or messages, find out in advance who will see the test output and whether it could reach a real person by mistake.

Whatever your sector, speak to your adviser about any privacy or regulatory requirements. This article cannot cover them.

Define rollback before you need it

Decide ahead of time what you will do if launch checks fail. Options include:

• Pause the connection so the form still stores entries but nothing passes to the automation. Staff then act on the entries manually.
• Switch the form to a simple notification while the workflow is repaired.
• Revert the website to the previous version, if that is possible and sensible.
• Proceed with a known limitation, with the client team’s explicit agreement, if the issue is minor and well understood.

For each option, record who decides, how quickly it can be done and what the team does meanwhile. A decision made calmly beforehand beats one improvised under pressure.

Prepare for the first real enquiries

The first few submissions deserve attention. After launch:

• Someone checks the entries list and the CRM against each other.
• Someone confirms the first notifications arrived.
• The client team confirms that the downstream result, such as a task or a message, is what they expected.

Our guide to testing a website form properly provides the checklist behind these steps.

Common ways launches go wrong

• No named owner for the join. The website passes data to the automation, and each side believes the other is checking.
• Test and live settings mixed up. The form still points at a test account, or a test workflow sends real messages.
• Permissions assumed. The person who needs to approve or fix something lacks access.
• Field names changed late. A form is edited after the automation is built, and the data stops arriving.
• No agreed contact on launch day. Messages go to someone who is away.
• No rollback plan. Everyone waits for someone else to make the call.

Most of these are prevented by the runbook above and one shared conversation.

Keep the runbook alive

After launch, keep the document. It becomes the reference for later changes, such as new form fields, a changed workflow or a new team member. Update it when responsibilities shift, and retest when anything changes.

A sensible next step

Take the runbook table to your next project meeting and ask each party to correct their column. The corrections show where assumptions differ.

If you are planning a launch that involves forms and automation, talk to us about the website side. We will be clear about what we handle and what belongs with your other partners.