Methodology

Bot leads don't count. Here is exactly how we filter them.

Industry research puts bot and invalid traffic at 10 to 30 percent of inbound leads for most local businesses. Most agencies count those leads in their reports anyway. We don't. They never appear in your dashboard. They never count toward "leads delivered" billing tied to volume. This page documents the receipts.

Layer 1: Cloudflare Turnstile (CAPTCHA without the puzzle)

Every public-facing form on the platform (booking widget, lead-capture forms, contact forms, hosted landing pages, signup, password reset) is protected by Cloudflare Turnstile. The widget is invisible to humans most of the time and silently challenges traffic that scores low on browser fingerprint, IP reputation, and behavioral signals.

When a form is submitted, our worker re-verifies the Turnstile token server-side against Cloudflare's siteverify API before accepting the lead. A submission with no token, an expired token, or a token that fails siteverify is rejected at the API boundary, never written to your database, never counted, never billed.

Implementation reference: verifyTurnstile() in our worker rejects requests without a valid token. Audited in the security panel.

Layer 2: Behavioral and origin checks

Beyond Turnstile, every state-changing API call goes through CSRF protection (Origin header + Content-Type assertion + per-session token), per-IP and per-email rate limits, and a pattern-detection layer that flags submissions matching common bot signatures (impossible time-on-page, copy-paste-only field entry, known-spam email domains, addresses harvested from data breaches).

Each rejection is logged with the reason code (CAPTCHA_FAILED, RATE_LIMITED, CONTENT_TYPE_REJECTED, ORIGIN_REJECTED) so we can audit and tune.

Layer 3: Post-capture grading

Even after a lead is captured, the AI lead-scoring agent runs a final grade pass: implausible names (asdf asdf), syntactically valid but disposable email domains, mismatched area-code geography, and identical-fingerprint resubmits all flag the lead as invalid rather than countable. Invalid leads sit in a separate bucket your operator can review, but never inflate "leads delivered" counts.

What this means for your invoice

Bot rejections at Layer 1 and Layer 2 never reach your database. They are not counted, not billed, not graphed.
Invalid grades at Layer 3 are visible to your operator (so you can audit Layer 3's accuracy) but excluded from any billing tied to lead volume.
If you ever subscribe to a tier or add-on that bills per-lead-volume, the methodology above is enforced in the same code path that produces the invoice.

What we do not do (and why)

We do not make per-lead "credit dispute" billing the customer's job. Some platforms let you flag bot leads after the fact for credit. That puts the labor of cleanup on the customer and biases the count toward "billed unless you complain." Our model is the opposite: filter before billing. If anything slips through Layer 3 and you spot it, email [email protected] and we will investigate, refund any associated charge, and tune the filter so it does not happen again.

Want to see it?

Logged-in operators see a "Bot leads filtered" counter on the System Health panel inside the platform. Submission-level reasons are visible in the security event feed. We are working on publishing aggregate quarterly stats here on this page.

See every commitment Elmob makes

Last updated 2026-05-03.