From a website enquiry to an owned follow-up

A website form is not a follow-up process. It is the moment an enquiry arrives. Everything that matters to the business happens after that: who sees it, whether it becomes a record someone owns, and what happens when a field is missing or a connection fails.

I see the same shape in established businesses. The site collects a name and a message. The message lands in a shared inbox. Someone copies the useful parts into a spreadsheet or a CRM when they have time. A second person replies from their own mailbox. A week later nobody can say whether the enquiry was answered.

The fix is not “add AI” and it is not “build a custom CRM”. The fix is a workflow with an owner, a record, and a defined failure path. A CRM you already pay for is usually the right place to start.

What “owned” actually means#

An enquiry is owned when four things are true:

1. It exists as a record, not only as an email.
2. A person or a queue is responsible for the next action.
3. The next action is visible, such as a task or a stage, rather than a memory.
4. Someone can tell whether that action happened.

If any of those are missing, the team is still running the process by hand, even if a form plugin says the submission was successful.

This is also why a redesign on its own rarely fixes follow-up. A clearer page can help someone enquire. It does not assign the enquiry, and it does not notice when the CRM rejected it.

An illustrative path, not a client dashboard#

This is a pattern, not a deployment I am claiming for a named customer. The steps are deliberately ordinary:

1. An enquiry arrives from the website.
2. The important fields are checked. A blank email address or a message that is only a URL should not be treated as a finished lead.
3. The CRM creates a record or updates the existing one.
4. The enquiry is assigned to a person or a queue using rules you already agree, such as service type, location, or who is on duty.
5. A follow-up task is recorded, with a due point the team actually uses.

Most mature CRMs can do the middle of this with their own forms, APIs, or a simple automation tool. Salesforce, HubSpot, and similar systems all document some version of “create or update a contact, then assign it”. The product names matter less than the fit: the API, the permissions, and the way your team already works.

The three failures that make the happy path useless#

The demo of this workflow is five boxes and a green tick. The real work is the cases that are not green.

Duplicates. The same person enquires twice, or already exists as a customer. Creating a new record every time splits the history and makes two people think they own the follow-up. The workflow needs a rule for matching, usually on email, and a decision for what “update” means when the new message disagrees with the old record.

Missing or messy information. Website forms attract half-finished submissions and messages that are not really enquiries. Validation should reject what you cannot act on, and it should tell the visitor what to correct. Silently dropping a submission is worse than a slightly longer form.

Failed connections. The CRM is down, a token has expired, or a required field on the CRM side was not on the form. If the only copy of the enquiry was the API call, it is gone. A durable approach keeps the submission, records that the handoff failed, and gives someone a way to retry or to see the original message. That is operational design, not an optional extra.

I would rather ship a boring, reliable handoff than a clever one that only works on the example we tested.

Where automation helps, and where AI does not#

Rules are enough for a large share of this work. If the form already has “service”, “location”, and “email”, you do not need a model to decide which queue receives it. An automation tool such as n8n, or the CRM’s own workflow, can route, notify, and open a task.

AI becomes useful when the message is unstructured and a person currently spends time interpreting it. Examples:

• pulling a company name, a product, or a deadline out of a free-text message
• suggesting a category so a person can confirm it
• drafting a first reply that a person sends

Those are assists. They are not a reason for the system to email a customer, change a deal, or delete a record on its own. The scope should say what the automation may do, what needs a person, and what happens when the output is wrong. A wrong category is cheap if a person checks it. A wrong email to a customer is not.

You can judge whether this helps without a vanity dashboard. Agree the measures before you build, and only where you can actually see the before-state. Useful ones include: enquiries that reach an owner, time from submission to first response, duplicate records created, and submissions that failed to reach the CRM. If you do not have the starting numbers, collect them during the first weeks and compare later. Do not invent a target increase to justify the project.

Use the CRM you have before you commission a new one#

A custom CRM is a product. It needs data entry, permissions, reporting, and someone to maintain it. It makes sense when you have a requirement that a suitable existing tool cannot meet, and you have already checked.

The assessment I start with is smaller:

• Which system should hold the customer record?
• What is allowed to create or change that record?
• Which fields are required for a person to act?
• What should happen when the connection fails?

If those answers are clear, connecting the website is an integration project. If they are not clear, software will not settle them. The process has to be agreed first. The GOV.UK Service Manual makes the same point in public-service language: understand the user need and the end-to-end journey before you build. For a business, the “user” includes the colleague who has to reply on Tuesday morning.

What I need from you to scope this#

A short description is enough to start. The useful version includes:

• the page or form the enquiry comes from
• where it goes today
• the CRM or inbox you want it to reach, if you already have one
• what “someone owns this” means on your team

Please do not send passwords, API keys, or private customer records in that first note.

If this is the process taking more effort than it should, describe the workflow. If the first problem is specifically the CRM you already use, start with that. The website itself may also need attention, but that is a separate decision, not a prerequisite.