A lead-sourcing pipeline for a voice-AI-for-restaurants GTM team

Overpass query over OpenStreetMap · amenity=restaurant, website + phone tags present · one Manhattan bounding box

80 restaurants harvested, 65 homepages successfully fetched in stage 2, 15 fetch-failed and excluded from scoring rather than dropped silently — reported in data/leads_scored.json under excluded.

Raw-HTML domain-fragment matching — every hit stores the literal fragment, but a hit can also come from comments or inactive references and requires review

22 of the 65 fetched sites had zero detections at all — no ordering, no reservation platform, nothing but a phone number. Those are the highest-priority accounts in stage 3, and the pipeline says so because the join says so, not because I asserted it.

A bare-word grep for "tock" during early manual scoping produced two real false positives on this exact dataset:

• Tick Tock Diner matched because the restaurant's own name contains "tock" — it actually runs OpenTable, not Tock.
• samsunnynyc.com also matched "tock" — from a JS config string, "stores.EnableOutOfStockAlignment", nothing to do with reservations at all.

fingerprint.py requires the real domain fragment (exploretock.com, not the word "tock") specifically because of these two catches — both verified clean in the current output. Small example, but it's the actual argument for evidence-based detection over keyword matching.

+40 phone-only/no ordering · +25 OpenTable (live Maple integration) · +15 delivery marketplace w/ no direct ordering · −50 voice-AI-adjacent already detected

The two accounts with a detected voice-AI-adjacent platform (Zoob Zib Thai, Chote Nawab) score −10 net — still phone-dependent, but flagged as a likely displacement conversation rather than a greenfield one. Scored down, not hidden.

No Claude/OpenAI API call — no key available in this environment. Template-composed from real detected facts, disclosed here exactly as it is in the code, not presented as a live model call.

Pre-call brief — Hard Rock Cafe
Website: hardrockcafe.com/location/new-york/
Phone: +1 212-343-3355
Maple-fit score: 80

Why: +40 phone-only, no online ordering · +25 OpenTable detected
     (live Maple integration) · +15 Grubhub, no direct ordering

Detected stack:
- online ordering: no online ordering detected on the site
- reservations: opentable (evidence: opentable.com)
- delivery marketplace: grubhub (evidence: grubhub.com)
- voice-AI product: none detected

Talking point: High call-dependency, no direct ordering channel
of their own — the exact profile of a restaurant losing orders
to missed calls during peak hours.

A separate, wider citywide Overpass query (400 restaurants) — the 80-restaurant demo sample was too small to reliably surface chains, so this stage documents and runs a bigger one on purpose

Without this stage, a sales team sourcing from raw map data would call two separate "leads" that are actually one HQ decision-maker — a real, disclosed data-hygiene problem, not a hypothetical one, found by widening the query and checking rather than assumed. The matching heuristic (normalized base-name collision) is disclosed as imprecise in dedupe_chains.py: it will both over-merge coincidental name collisions and under-merge chains with inconsistent naming — the actual tradeoff real GTM data hygiene runs into, not hidden behind a clean demo number.

build_dashboard.py generates rep_dashboard.html — one self-contained file, sortable by score, searchable by name, click a row to expand its full brief

Every earlier stage in this pipeline produces a file a GTM engineer can read — JSON, markdown. None of them are something an AE would actually open between calls. This closes that gap directly: no server, no build step, no framework — an AE double-clicks one HTML file and gets a working, sortable lead list with pre-call context inline. That's the literal ask in a GTM Engineer job description that names "a rep tooling layer that makes an AE genuinely faster" as a first-class responsibility, not an afterthought.

Open the live rep dashboard →

Hypothesis: delivery-marketplace-only accounts deserve a stronger fit bonus (+30 instead of the shipped +15) because 15–30% commission pressure is as real a pain point as call-dependency

The decision, written from the numbers rather than a feeling: keep Model A as-is. Six leads' scores moved, but the shift was uniform within that group and never crossed another lead's score band, so who-gets-called-first remained unchanged. The delivery-commission hypothesis might still be true, but this offline comparison cannot establish conversion lift. A real A/B test would require prospective randomized assignment and observed commercial outcomes.