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: Server-side spam scoring (no CAPTCHA to solve)

We do not put a CAPTCHA in front of your customers. A puzzle costs you real leads from real people, and the bots worth worrying about get past them anyway. Filtering happens on our side, after the form is submitted, where the customer never sees it.

Every inbound lead is scored 0-100 on arrival against the things that actually separate a bot from a customer: disposable email domains, placeholder and repeated-digit phone numbers, names that are URLs or symbol soup, and message text matching known solicitation patterns. A lead scoring 50 or above is marked spam and held out of the pipeline. It is never dialled, never texted, never counted toward "leads delivered" and never billed. Between 25 and 49 it is flagged and shown to you anyway, because a borderline lead is your call, not ours.

Public lead forms also carry a hidden honeypot field. A person cannot fill a field they cannot see; a bot fills everything. Those submissions are dropped and the bot is told it succeeded, so it does not come back with a different shape.

Implementation reference: lib/leadSpamCheck.js in our worker scores every lead before it reaches your dashboard. The counts on this page come from that scorer.

Layer 2: Behavioral and origin checks

Every state-changing API call goes through CSRF protection (Origin header + Content-Type assertion + per-session token) and rate limits that are enforced per IP and per client, so a botnet rotating addresses still cannot grind a single form. Lead forms are additionally capped per submission on file count and size.

Each rejection is logged with the reason code (RATE_LIMITED, CONTENT_TYPE_REJECTED, ORIGIN_REJECTED) so we can audit and tune, and every spam-scored lead keeps the reasons it was scored on.

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 info@elmob.ai 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-08-10.