Cut Lead Response Failures 90 Percent With Proof Routing

Leads don’t die because you “responded in five minutes.” They die because the answer lives in someone’s head, the routing rules live in a spreadsheet, and the follow-up lives in a tab that gets closed the moment Slack pings. Fast response just exposes the rot. This playbook builds a working lead-to-meeting system where every inbound request gets classified, enriched, routed, and followed up with proof, not vibes. No heroics. Tool stack (and why): n8n for orchestration (you own the logic, not a brittle zap). Supabase as the system record for lead state, routing decisions, and audit trails. Gemini for structured classification and reply drafting with constraints (not “write a nice email”). Airtable as the operator console for exceptions, triage, and manual overrides. Workflow: 1) Capture: Web form, email parser, or webhook lands in n8n. Generate a lead_id immediately. If you can’t identify it, you can’t fix it later. 2) Normalize + store: n8n writes the raw payload to Supabase (leads_raw) and a cleaned row to leads (company, role, intent, source, urgency). Keep both. Raw is your courtroom transcript. 3) Classify: n8n sends the cleaned lead to Gemini with a tight schema: intent category, estimated ACV tier, region, product fit score, “must-ask” questions, and risk flags (competitor, student, vague procurement). Reject unparseable outputs. 4) Route: n8n applies explicit policy (Supabase table routing_rules). Example: Enterprise + EU routes to AE_2, but only if open_leads < 15; otherwise to SDR_queue with a “delay_reason.” 5) Respond: Gemini drafts a short reply that asks only the missing qualifiers and proposes two meeting windows. n8n sends it and logs the exact content + model inputs to Supabase. 6) Operate: Airtable pulls “stuck” leads (no reply in 15 minutes, no owner in 30, bounced email, low confidence classification). Humans fix edge cases. The system learns by updating routing_rules, not by “trying harder.”

Mara runs growth at a mid-market B2B SaaS. Mondays are a trap. Paid search spikes, partners send “warm intros,” the demo form fills, and Sales swears nothing good ever makes it to their calendar. At 9:12 a.m., an inbound hits the web form: “Need pricing for 2,000 seats. EU rollout. ASAP.” n8n grabs it, generates lead_id, dumps the raw JSON into leads_raw in Supabase, then normalizes into leads: company, role, source=paid_search, urgency=high. The raw stays. Because later someone will argue about what was “really” said. Gemini classifies it. Enterprise tier. Region=EU. Fit score 0.82. Must-ask: security requirements, timeline, procurement contact. Risk flag: “vague procurement” because the email is a generic alias. Routing runs next. Supabase routing_rules says Enterprise+EU goes to AE_2 unless AE_2 has open_leads >= 15, then SDR_queue. Today AE_2 is at 14. Lucky. Except here’s the friction. The open_leads count is wrong. AE_2 closed three leads last week but nobody marked them closed in Supabase because they “just used Salesforce.” So the system thinks AE_2 is overloaded by noon and starts shunting good EU leads into SDR_queue with delay_reason=capacity. SDRs chase whales with the wrong script. AEs get mad. Mara gets screenshots in Slack. How do you measure capacity when the truth is split across tools and moods? By 9:15, the response goes out anyway. Gemini drafts a tight email: two meeting windows in CET, three qualifier questions, no fluff. n8n logs the exact prompt and reply content to Supabase. Proof. At 9:30, Airtable lights up: “stuck leads: owner assigned but no calendar link sent.” Turns out an incorrect implementation: someone changed the email node and stopped writing message_id back to Supabase. Now you can’t correlate sends to leads, so the “no reply in 15 minutes” check is lying. Mara assigns a human to patch it. Then updates routing_rules and the schema. Not vibes. Just repairs.

If you’re going to implement this inside a real company, treat it less like “automation” and more like a production system with owners, SLAs, and change control. Otherwise you’ll just build a prettier way to be wrong. Start with one uncomfortable rule: Supabase is the source of truth for lead state, even if Salesforce is where reps live. That means every state transition has to be written back: assigned, contacted, meeting scheduled, disqualified, closed-lost, closed-won. If Sales refuses, fine—then build the sync and make it invisible to them. But don’t pretend you can do capacity routing off a database that never gets updated. Next: define capacity in a way that can’t be gamed. “Open leads < 15” sounds clean until you realize “open” is a human opinion. Use timestamps. A lead counts against capacity until it has either a meeting booked or a terminal state, and it ages out if untouched for X hours and gets escalated. Capacity becomes math, not vibes. Then lock down your interfaces. Any node that sends an email must return a message_id, and the workflow should hard-fail if it doesn’t get one. Same with calendar links. No “best effort” sends. If correlation breaks, every SLA check turns into fiction and you won’t notice until Slack starts screaming. On the Gemini side, keep it on a leash. Have it output confidence and require deterministic fallbacks. Low-confidence classification should route to Airtable triage, and you should log every “human override” as training data for routing rules, not just as a one-off fix. Finally, install a weekly ops ritual: 30 minutes reviewing stuck-lead reasons, bounce reasons, misroutes, and overrides. Update routing_rules and schemas like you’d update product code. If you can’t point to the exact change that fixed last week’s leakage, you’re not operating a system—you’re hoping at scale.