My website form leads get lost in email. How do I fix that?
Short answer: A lead landing in a shared inbox is already halfway to being forgotten, since nobody owns an inbox the way they own a task list. If your form runs on Netlify, the fix isn't a better inbox, it's a webhook notification that pushes every submission straight into Slack, a spreadsheet or your CRM the moment it arrives, so follow-up doesn't depend on someone remembering to check email.
You know the leads are coming in. The problem is what happens, or doesn't happen, after they land.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
This is one of the most common, and most fixable, leaks in a small business's pipeline. The website is doing its job, people are filling out the form, but the lead arrives in an email inbox that three people have access to and nobody fully owns. It sits unread for a day, then two, and by the time someone replies the prospect has already called a competitor or forgotten they asked.
The root cause isn't the form. It's that email is a terrible task-management tool, and using it as your lead-routing system means every lead's fate depends on someone noticing it in a crowded inbox.
If your site runs on Netlify, there's a decent chance the form itself is already using Netlify Forms, one of several ways a small business site collects a submission without a separate form tool bolted on. That part is usually fine as is. The weak link in this story isn't the form or the platform collecting it, it's everything, or nothing, that happens after the submission lands.
Why email notifications alone fail
An email notification tells you a lead arrived. It doesn't tell anyone it's their job to follow up, it doesn't track whether anyone did, and it competes for attention with every other email in the same inbox. If your form currently only emails a submission to a shared address, you already have the data, you just don't have a system turning that data into action.
The options, from least to most effort
- Keep using email, but assign ownership. Free, but relies entirely on discipline, which is exactly what's already failing.
- Zapier, connected via webhook: genuinely low effort once set up, and the most flexible option for routing a Netlify form submission into dozens of other tools.
- A CRM's own built-in form (like HubSpot's): works well if you're willing to rebuild your form inside the CRM itself, but you lose the form you already built and styled on your own site.
- A custom build: the right call once you need logic a no-code tool can't express cleanly, like routing by job type to different team members.
How to actually route a Netlify form submission
Netlify Forms supports two notification types: email, and an HTTP POST webhook. The webhook is the one that actually solves this problem, because it fires the instant a submission comes in and can target any URL that's listening for it, not just an inbox.
- In your site's dashboard, go to Forms, then Settings and usage, then Form notifications. Add an "Outgoing webhook" notification.
- Point the webhook at a Zapier "Catch Hook" trigger (or Make's equivalent), which gives you a URL to paste into Netlify's webhook field.
- Build the Zap: from that trigger, add a step to post the submission into Slack, append it as a new row in a Google Sheet, or create a record in your CRM. Most CRMs with an API have a pre-built Zapier action for "create a contact" or "create a lead."
- Test with a real submission before relying on it, and check the data actually lands with the right fields in the right place, not just that something arrived.
- Keep the email notification running alongside the webhook for the first few weeks as a safety net, until you trust the automated route completely.
I couldn't confirm a dedicated, one-click Zapier connector built specifically for Netlify Forms on Netlify's own documentation, so treat this as a two-step connection (Netlify's generic webhook into Zapier's generic webhook trigger) rather than a native integration. It works exactly the same either way, it just means the setup takes slightly more care the first time.
What I'd actually tell you
Most businesses I talk to think the fix is "check email more often." It isn't. The fix is removing the step where a human has to notice and act, because that's precisely the step that keeps failing. A webhook into Slack means the whole team sees a new lead the moment it lands, in a channel people already check, rather than an inbox that's really one person's responsibility disguised as a shared one. A webhook into a CRM goes one step further: the lead becomes a tracked record with a status, not just a message that can be marked read and forgotten.
The honest tradeoff: Slack notifications are the fastest to set up and the easiest for a small team to actually see, but they don't track follow-up status over time the way a CRM record does. If you're a two or three person operation, Slack (or even a dedicated phone notification) might be the better first move. Once you're big enough that "who's following up on this" is itself a question that needs an answer, the CRM route earns its extra setup time.
When this still isn't enough
A webhook gets the data somewhere useful, but it doesn't add logic. If you want different job types routed to different people, or a lead scored by value before it's assigned, that's beyond what Zapier's simple trigger-action model comfortably handles without starting to feel fragile. At that point you're better served by a small custom piece built on the form's actual webhook payload, with the routing rules written explicitly rather than chained through several no-code steps that are each individually simple but collectively hard to debug when something breaks.
A worked example: a home renovation company switching from email
Say a home renovation company's quote-request form has been emailing a shared inbox for two years, and a review of that inbox turns up a handful of quote requests sitting unread for over a week, including one from a genuinely high-value kitchen renovation lead that nobody noticed until the prospect called to ask why nobody had followed up. Setting up a webhook that posts every new submission into a dedicated Slack channel, checked by the office manager and the two estimators every morning, means a new lead is now visible to three people the moment it arrives, not buried in an inbox where it's technically "someone's" responsibility but not clearly anyone's in practice. Within the first month, the average time between a lead arriving and someone making first contact drops from over a day to under two hours, not because anyone got better at checking email, but because the lead stopped depending on a human noticing it in a crowded inbox at all.
Common mistakes when setting up lead routing
- Turning off the old email notification immediately. Running both in parallel for a few weeks catches any gap in the new automated path before you're relying on it exclusively, rather than discovering a missed field or a broken webhook only after a lead has actually been lost.
- Building the automation and never testing with messy, real-world input. A form submission with an unusual character, a blank optional field, or a very long message can sometimes break a simple no-code automation in ways a clean test submission never reveals.
- Routing leads somewhere visible but still not assigning ownership. A Slack channel everyone can see but nobody's specifically responsible for checking recreates the same diffusion-of-responsibility problem as the original shared inbox, just in a different tool.
How I'd approach this
The most common fix I actually build for this exact problem isn't a new form, it's exactly this: taking a form that already works and making its output land somewhere a human is actually paying attention, with the right person notified and nothing silently dropped. If you've already got a Netlify-hosted form and just need the routing done properly, that's usually a small, well-scoped job, not a rebuild. If your actual need is scoring, assignment logic, or joining form data with other systems, that's where a proper custom build earns its cost over stacking more no-code tools on top of each other.
Questions people ask
Why do website leads keep getting lost even though the form works fine?
Because an email notification tells someone a lead arrived, but doesn't assign ownership or track whether anyone followed up. The form isn't the problem; routing the output to a place with actual accountability is.
Does Netlify Forms support Slack notifications directly?
Not as a built-in option. Use Netlify's outgoing webhook notification pointed at a Zapier or Make trigger, then have that automation post into Slack. It takes one extra step but works just as reliably.
Is there a native Zapier integration for Netlify Forms?
A dedicated one-click Zapier connector for Netlify Forms specifically isn't confirmed on Netlify's own documentation. The reliable path is connecting Netlify's generic webhook notification to Zapier's generic "Catch Hook" trigger, which works the same way in practice.
Should I route leads to Slack or straight into my CRM?
Slack is faster to set up and easiest for a small team to see immediately, but doesn't track follow-up status. A CRM record is more setup but gives you an actual trackable status over time. For a very small team, start with Slack; once "who's following up" becomes its own question, move to the CRM.
Can I keep both email and webhook notifications running?
Yes, and it's worth doing for the first few weeks after setting up automated routing, as a safety net while you confirm the new system is actually catching everything.
What if I need different leads routed to different people?
That's routing logic beyond what a simple webhook-to-Zapier chain handles cleanly. At that point a small custom build reading the form's webhook payload directly, with explicit rules, is usually more reliable than stacking several conditional steps in a no-code tool.