Free tools · no sign-up

Free lead routing tools

Tools for the lead-routing workflow itself: simulating IF-THEN rules against a sample submission before going live, generating rules from workflow presets, planning multi-client setups, and quantifying the revenue impact of faster (or fewer-leaked) leads.

The three phases of routing

Build, test, debug, each with the right tool

Routing is one of those features that looks deceptively simple and has a long tail of failure modes. The three tools here line up with the three things you actually do with a routing setup: design and verify, audit the pipeline they live in, and troubleshoot when something silently breaks.

  • Build & test: the routing rule simulator. Paste a sample submission and an ordered list of IF-THEN rules; it tells you which fires and where the response would land. Catches operator mistakes (using equals on a field with trailing whitespace), value mistakes (forgetting that "Yes" isn't the same as "yes "), and ordering mistakes (more-specific rules below catch-alls).
  • Audit: the diagnostic checklist. Nine items covering the whole pipeline from “form is accepting responses” through “Slack channel still exists” to “no duplicate triggers”. Walk top to bottom, tick each, follow the fix for anything that's off. Saves locally; print for handoff.
  • Debug: the troubleshooter tree. Pick the symptom you're actually seeing (Slack stopped getting messages, the wrong content arrives, Apps Script shows an error, etc.); answer one or two follow-up questions; land on the targeted diagnosis.
Rule design patterns

A few that catch most failure modes

  • Specific first, catch-all last. Rules evaluate top to bottom; the first match wins. So IF Budget >= 100000 → #vip goes above IF Budget >= 50000 → #hot, and both above IF Source = Pricing → #pricing.
  • Default destination as a fallback, not the main case.Anything not matching any rule falls through to the default. Don't use the default as “everything else interesting”, write an explicit rule for that case so you can see in the log which rule fired.
  • One field per rule when you can.Two-field rules (“Budget >= 50000 AND City = Austin”) are tempting but harder to verify. Often you can decompose into “Budget >= 50000 → #hot, City = Austin → #austin-team” , first match wins, so the most specific lands first.
  • Test with a real submission, not a hand-crafted one.The simulator accepts both, but real submissions catch the trailing-whitespace and case-mismatch issues you didn't think to write into your test case.
FAQ

Frequently asked questions

What's 'lead routing' on this page?

Lead routing is the rule-based dispatch of an incoming form submission to the right destination based on its answers. A high-budget enquiry goes to #hot-leads, a low-budget one to #leads, a support question to #cs, an Austin lead to #austin-team. The tools here cover the three parts of the routing workflow: building the rules (simulator), auditing the pipeline they sit in (checklist), and diagnosing what broke when something silently stops (troubleshooter).

When do I reach for each tool?

(1) Routing rule simulator, when you're designing rules and want to verify they fire the way you expect against a real sample submission. Use it before going live; use it again when adding a new rule. (2) Diagnostic checklist, when you want a flat audit of the whole pipeline. Nine items, top-to-bottom, fix per item. Good for periodic health checks and for handing off a working setup. (3) Form-to-Slack troubleshooter, when one specific symptom appeared (Slack stopped getting messages, the wrong content arrives). It branches based on the symptom and gives you a targeted fix.

What's the difference between the checklist and the troubleshooter?

Same problem space, different UX. The checklist is linear, walk every item from 1 to 9, tick what's true, fix what's not. Best when you don't know which part is broken or want to confirm the whole pipeline is healthy. The troubleshooter is a decision tree, start with a symptom, answer one or two questions, land on one diagnosis. Best when you've already got a specific symptom and want the targeted fix without reading nine items first.

Do these tools require RouteForms?

No. All three run entirely in your browser. The simulator evaluates rules against any sample JSON or key/value text; the checklist is generic Apps Script / Slack pipeline knowledge with the RouteForms delivery-log item flagged as optional; the troubleshooter covers failure modes that apply to any Google-Forms-to-Slack setup, with RouteForms-specific guidance shown only where it's relevant.

What rule operators does the simulator support?

The full set RouteForms uses in production: equals, does not equal, contains, does not contain, greater than, greater than or equal, less than, less than or equal, is empty, is not empty. Numeric operators tolerate currency symbols and commas — '₹50,000', '50k USD', and '50000' all compare as 50000. Case-insensitive matching with leading/trailing whitespace trimmed on field names and values.

What's the right order of rules?

Top to bottom: most specific first, fallback last. The simulator walks the list top-to-bottom and the first matching rule wins. So 'IF Budget >= 100000 → #vip-leads' should sit above 'IF Budget >= 50000 → #hot-leads', and both should sit above 'IF Source = Pricing → #pricing-leads'. Anything that doesn't match any rule falls through to the default destination, usually the form's main Slack channel.

What's the most common reason routing silently breaks?

Field name drift. A teammate renames a Google Form question from 'Budget' to 'Budget (USD)'. The form still works, submissions still arrive, but every routing rule that says 'Budget' stops matching. The fix is in our /tools/google-forms-field-extractor, paste a real response, copy the verbatim field name, paste it back into the rule. The checklist's item 5 calls this out specifically.

Should I build routing in Apps Script or in RouteForms?

Pure Apps Script (via our /tools/routing-rules-to-apps-script translator) is the right answer if you want zero external dependencies and routing logic that lives entirely on Google's infrastructure. RouteForms is the right answer once you start needing operational visibility, a delivery log per form, one-click retries on failed posts, idempotency so retries don't double-post, and email alerts when delivery starts failing. The script gives you the rules; RouteForms adds the safety net.

Run real routing rules on real submissions

RouteForms runs the same rule model these tools simulate, only on actual Google Form responses, with retries, idempotency, and a per-form delivery log. Free for 30 responses a month.