Dev.to WebDev 🛠 Dev 👁 0 📖 13 min read

One n8n Workflow That Follows Up New Website Enquiries — Built for a Small Business, Step by Step

A small business gets an enquiry through its website. Someone fills in the contact form, the business gets an email, and then nothing happens for a day — or two. Not because the owner does not care, but because the owner

A small business gets an enquiry through its website. Someone fills in the contact form, the business gets an email, and then nothing happens for a day — or two. Not because the owner does not care, but because the owner is busy doing the actual work: serving customers, answering the phone, keeping the day running. By the time they reply, the person who enquired has already asked someone else.

This is the most common automation problem I see in small service businesses. It is not a complicated problem. It is a repetitive one, and repetitive problems are exactly what a workflow is for.

In this article I will walk through one n8n workflow I built for this exact task: taking a new website enquiry from the moment it arrives, following it up automatically, and handing it to a human at the right moment. I will show the trigger, each step, the edge cases that broke the first version, and what to check before you rely on it. This is not a generic explainer. It is the workflow as I built it, with the decisions I had to make along the way.

The manual process, as it is today

Before building anything, I mapped the manual process as it actually happens — not as it should happen in theory, but as the owner described it to me.

A visitor fills in the contact form on the WordPress site. The form sends an email to the business. The owner reads the email when they get a chance. If the enquiry looks serious, they reply by email or by phone. If they are busy, they mean to reply later, and later sometimes never comes. There is no list of open enquiries, no reminder, and no record of who was already answered. An enquiry that arrives on a busy day can sit unread while the owner serves walk-in customers.

There are two problems here, and they are different problems. The first is speed: the first reply takes too long. The second is memory: there is no system that remembers an enquiry until it is answered. A workflow can fix both, but only if it is built around the real process instead of an ideal one. That is why the first step is always to write down the manual steps before opening n8n.

What the workflow does

The workflow does one job: every new website enquiry gets a prompt first follow-up, and a second follow-up if there is no reply, and then the enquiry is handed to the owner with everything in one place.

It does not close sales. It does not answer questions about prices, availability, or specific services. It does not pretend to be a person. Its job is narrower than that: make sure no enquiry is forgotten, and make sure the first contact happens quickly, every time, even on a busy day.

That narrow scope matters. A workflow that tries to do everything ends up doing nothing reliably. The checks and the handover to a human are part of the design, not an afterthought.

The trigger: a form submission

Every workflow needs a trigger — the event that starts it. Here the trigger is a new submission on the website's contact form.

In n8n, I used a Webhook node as the trigger. The WordPress form sends its data to the webhook URL when a visitor submits it. The data that arrives is simple: the visitor's name, their phone number or email, the service they asked about, and their message. Nothing else is needed to start a follow-up, and nothing else is collected.

There is a decision hidden in this step that is worth stating plainly. The trigger should fire only on a real form submission, not on a page visit or a test. The webhook URL is not published anywhere on the site, and the form is the only thing that calls it. That keeps the workflow from starting on noise.

The first version of this workflow had a weakness here: the form had no validation worth the name, so junk submissions started the workflow as happily as real ones. I will come back to that in the edge cases, because it changed how the workflow is built.

Step 1: Check the enquiry before doing anything with it

The first node after the trigger does not send a message. It checks the enquiry.

It checks that the required fields are present: a name, and at least one way to reach the person — a phone number or an email address. It checks that the message is not empty. If any of those are missing, the workflow stops and logs the submission for the owner to look at. It does not send a follow-up to an enquiry it cannot answer, and it does not send a message to a blank address.

This step exists because a workflow that acts on bad data creates a new problem while solving the old one. A follow-up sent to a wrong number, or a half-empty message sent to a real customer, is worse than no follow-up at all. Checking first is cheap. Fixing a bad message after it has been sent is not.

Step 2: Store the enquiry in one place

Next, the workflow saves the enquiry in a single list — a simple table with one row per enquiry, the date and time it arrived, the visitor's details, and a status field that starts as "new".

This step is the memory the manual process was missing. Without it, there is no way to know which enquiries have been followed up and which are still waiting. With it, the owner can open one list and see every open enquiry, instead of searching through an inbox.

The workflow updates this row as it goes: "first follow-up sent", "waiting for reply", "replied", "handed to owner". The status is not decoration. The later steps read it to decide what to do next, and that is how the workflow avoids sending a second follow-up to someone who has already replied.

Step 3: Decide what the first follow-up says — and when to send it

The first follow-up is short, and it is written in advance, not generated on the fly. It says who the business is, confirms the service the visitor asked about, and asks one simple question that moves the conversation forward — usually when would be a good time to talk, or which day suits them.

There are two rules behind this message. The first is that it never promises anything the business has not agreed to: no prices, no availability, no guarantees. It only confirms the enquiry was received and asks the next question. The second is that it reads like it was written by the business, because it was — the owner approves the wording before the workflow goes live, and the wording does not change without the owner's say-so.

The timing matters too. The first follow-up goes out promptly after the enquiry arrives, while the visitor still remembers filling in the form. The workflow does not wait for the owner to be free. That is the whole point: the first contact happens even on the busiest day.

Step 4: Send the first follow-up

The workflow sends the first follow-up through the channel the visitor gave: a messaging app message if they gave a phone number, an email if they gave only an email address. It uses the details from the stored enquiry, so the message refers to the right service and the right person.

After sending, the workflow updates the stored row — "first follow-up sent" — and records when it was sent. That record is what makes the next step possible. Without it, the workflow would have no way of knowing how long it has been waiting for a reply.

One detail here took a second attempt to get right. The first version sent the follow-up and immediately moved on, without confirming the send had actually worked. When a send failed, the workflow still marked the enquiry as followed up, and the enquiry quietly died. The fixed version checks the result of the send step: if it fails, the enquiry stays marked as needing attention, and the owner sees it in the list. A workflow should never report success it did not achieve.

Step 5: Wait, check for a reply, and send the second follow-up

After the first follow-up, the workflow waits. Waiting is a real step in n8n, not an absence of one: a Wait node pauses the workflow for a set period, then wakes it up to check whether the visitor has replied.

When it wakes up, it checks the stored enquiry and the inbox. If the visitor has replied, the workflow stops — the enquiry is now a conversation, and a human takes it from there. If there has been no reply, the workflow sends a second, shorter follow-up: a gentle reminder that the enquiry is still open, and the same single question, asked once more.

The second follow-up is the last automatic message. There is no third, fourth, or endless sequence. Two messages are enough to catch someone who missed the first one. More than that stops being a reminder and starts being a nuisance, and a business that annoys people on first contact has made things worse, not better.

Step 6: Hand the enquiry to the owner

Whether the visitor replies or not, the workflow ends by handing the enquiry to the owner with everything in one place: the original enquiry, what was sent, when it was sent, and whether the visitor replied.

If the visitor replied, the handover says so, and the owner picks up the conversation. If the visitor did not reply after the second follow-up, the handover says that too, and the owner decides whether to call personally or let it go. The workflow does not decide that. It gives the owner the facts and gets out of the way.

This handover is the part of the workflow that owners notice most, because it is the part that changes their day. Instead of discovering enquiries by accident in an inbox, they get a short, complete summary of each one. The automation does the remembering and the first contact; the human does the talking and the deciding.

Edge cases: what broke the first version

A workflow that only works on a perfect day is not a workflow. These are the cases that broke the first version, and how each one is handled now.

Duplicate enquiries. The same person sometimes submits the form twice, or submits it once and then messages the business directly. The workflow checks the stored list for an enquiry with the same contact details that is still open. If it finds one, it does not start a second follow-up sequence — it adds the new message to the existing enquiry and lets the first sequence continue. One person, one sequence.

Junk and spam submissions. A form on the open internet gets junk. The first version followed up on everything, which meant the business was messaging nonsense addresses. The check in Step 1 now stops submissions with missing or obviously invalid contact details, and the form itself has basic validation — a required phone or email field, and a check that the message is not empty. Validation belongs on the form as well as in the workflow, because the workflow should never be the only defence.

Enquiries outside working hours. An enquiry that arrives late at night still gets its first follow-up promptly, because the follow-up is automatic and does not depend on the owner being awake. But the follow-up does not promise a reply at that hour. It says the business will be in touch, and the handover to the owner waits until working hours. Automation can be instant; a human reply cannot, and the message should not pretend otherwise.

A reply that is not interested. Sometimes the visitor replies to say they no longer need the service, or they found someone else. The workflow treats any reply as a stop signal: it stops the sequence, marks the enquiry as closed, and hands it to the owner with the reply attached. There is no second follow-up after a person has answered.

A visitor who replies to the first follow-up with a question. The workflow does not try to answer it. It stops the sequence and hands the enquiry to the owner, with the question included. An automated system that guesses at answers to real questions is a risk the business does not need. The workflow's job is to make sure the question reaches a human quickly, not to answer it itself.

A send that fails. As I described in Step 4, a failed send used to be marked as a success. Now the workflow checks the result of each send, and a failure leaves the enquiry marked as needing attention. The owner sees it in the list instead of assuming it was handled.

What to check before you rely on it

A workflow that nobody has tested is a hope, not a system. Before this one went live, I ran through a checklist, and I run through the same checklist every time I change it.

First, submit the form yourself, with your own details, and watch the whole sequence. Does the first follow-up arrive? Does it mention the right service? Does the stored row update? If you cannot see each step happen, you do not know it works.

Second, submit the form with something missing — no phone number, no message — and confirm that the workflow stops and logs it instead of sending a broken message. The failure path matters as much as the success path, because real enquiries will take it.

Third, submit the same enquiry twice and confirm that only one follow-up sequence starts. Duplicates are not a rare event; they are a normal one.

Fourth, reply to the first follow-up and confirm that the second follow-up never sends. A workflow that messages someone who has already answered is a workflow that will embarrass the business.

Fifth, check the handover. Open the list the owner will see and ask whether it tells them everything they need to pick up the conversation: who, what they asked about, what was sent, and whether they replied. If the owner has to go hunting through an inbox to understand an enquiry, the handover is not finished.

Sixth, confirm the owner has approved the message wording, and that nobody else can change it without the owner knowing. The words the workflow sends are the business speaking. They should not drift.

Finally, check it again a week after it goes live. Workflows rot quietly: a form changes, a credential expires, a channel changes its rules. A weekly look at the stored list — are enquiries moving through the steps, or are they piling up in one status? — catches that early.

What this workflow does not do

It is worth stating the limits plainly, because an automation that is oversold is an automation that gets switched off.

It does not answer questions. It does not quote prices or confirm availability. It does not decide whether an enquiry is worth pursuing. It does not replace the owner's judgement, and it does not work if the owner never looks at the handover list — in that case, the enquiries are still being followed up, but the conversations are still waiting for a human who is not there.

What it does is narrower and, in my experience, more useful: it makes sure the first contact happens every time, it remembers every enquiry until it is answered, and it gives the owner a complete picture instead of a scattered inbox. For a small business, that is usually the difference between an enquiry that turns into a customer and one that quietly disappears.

A short summary

The manual process fails in two ways: the first reply is slow, and nobody remembers the enquiries that are still waiting. The workflow fixes both by doing one job well: trigger on a real form submission, check the enquiry, store it, send a short first follow-up, wait, send one reminder if there is no reply, and hand everything to the owner.

Build it around the real process, not the ideal one. Test the failure paths, not just the happy path. Keep the automatic messages short, few, and approved by the owner. And check it a week after it goes live, because that is when the problems you did not expect will show up.

Asad Bukhari is a freelance WordPress developer based in Lahore, Pakistan. He builds WordPress websites for small and service businesses, including websites for salons and spas, and sets up AI automation with n8n workflows. He also works on SEO for WordPress sites.

Portfolio: https://asadbukhari.site

Live tools: TikSave AI — https://tiksafe-ai.streamlit.app/ · ResearchFlow AI — https://researchflow-ai01.streamlit.app/

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.