Why intake gets messy in the first place
The problem with most small-business intake processes is not that they are broken — it is that they require someone to be paying attention. A form submission arrives in an inbox. Someone notices it eventually, copies the details into a spreadsheet or CRM, sends a reply, and maybe creates a follow-up task. This works until it does not, and it tends to stop working around the point where the person responsible has four other things open.
What we were asked to build in three recent projects was roughly the same thing each time: take the manual steps out of the intake loop. What we found is that the same goal — routing a form submission to the right place without human intervention — produces very different implementations depending on what tools the client is already using and what "the right place" actually means for their process.
Implementation one: the webhook-to-CRM pattern
The first client was using HubSpot with a custom-built intake form on their WordPress site. The brief was simple: form submissions should go directly into HubSpot as contacts and deals, with a notification to the sales lead in Slack.
We hooked the form submission to a webhook, sent it to a Make scenario, and from there to HubSpot's API and to Slack via their incoming webhook. Two hours of setup, two days of testing edge cases. The main unexpected cost was handling duplicate submissions — the same person submitting twice with slightly different email formatting, for instance. HubSpot handles deduplication on email, but only if the email is parsed consistently before it arrives. We spent more time on input normalisation than on the actual routing.
The most interesting finding: after the automation went live, the team started receiving Slack notifications for leads they had previously never seen, because those had been lost in inbox noise. The automation did not create more leads — it made visible the ones that had been quietly dropping.
Implementation two: when the CRM is a spreadsheet
The second project was harder. The client was a twelve-person firm using a Google Sheet as their CRM — intentionally, because they had tried Pipedrive and hated it. The brief was the same: automate intake so it does not need human triage. But the destination was a spreadsheet with a structure that had evolved organically over three years and had a lot of logic embedded in conditional formatting and manual conventions that nobody had fully documented.
We used n8n here instead of Make, partly because the client's IT policy made Make's cloud service awkward, and partly because the volume of data warranted something they could run on their own infrastructure. The integration took four weeks instead of two, mostly because we had to reverse-engineer the sheet's implicit structure and because the handoff between a form field named "company" and a column named "Client Organisation" is the kind of thing that is obvious to a human and invisible to a script.
This one worked in the end, but we would probably recommend against doing it this way for a new client. If your CRM is a spreadsheet, the automation is building on an uncertain foundation.
Implementation three: routing with conditional logic
The third was the cleanest. A consultancy with two service lines that needed different follow-up sequences depending on what the prospect selected in the form. Web project enquiries went to one team member; strategy enquiries went to another, with a different email template and different CRM pipeline stage.
Typeform handled the form, Make handled the routing, Pipedrive received the contact. The conditional logic was about six nodes in the Make scenario — not complex, but it required the client to be precise about the conditions before we started building. The briefing session took longer than the build.
What actually changes
In all three cases, the practical change was not speed — it was reliability. Responses to leads went out within minutes instead of hours or days, not because the team had more capacity but because a consistent trigger replaced an inconsistent human memory.
What did not change: the quality of the response. Automation handles routing and notification. The actual reply — the one that decides whether the prospect becomes a client — is still written by a person. We have seen clients try to automate that too. It is possible. It is also usually obvious to the recipient that it happened, and that is a harder problem to fix than slow response time.
Email updates
New dispatches by email when they go up. Subscribe via the contact form.