Building the GTM Engine for Ask Arthur
An AI voice agent for restaurants needed to know exactly who to sell to and how, not just that everyone with a phone was a prospect.
situation
Ask Arthur builds an AI voice agent that answers restaurant phones, takes orders, and books reservations. They wanted help with GTM and outbound infrastructure. Every restaurant with a phone is technically addressable, which makes the TAM enormous and useless. The real task: find exactly which restaurants Arthur wins fastest and keeps longest.
result
The insight was structural, not demographic. Arthur wins where peak call volume and peak service intensity collide, the Friday dinner rush when nobody can pick up the phone, and where the person who feels that pain also approves the spend. That points at independent, phone order heavy, casual restaurants. Not fine dining, not chains, not reservation first concepts.
Disqualified ghost kitchens, high price tiers, reservation primary spots, and multi location chains before scoring anything. Scored the rest on weighted signals: ordering channel, takeout, price level, independence, and foot traffic popularity.
Then the founder challenged the thesis and asked for two additions: front of house hiring signals and reservation platform detection. I rebuilt the scoring and layered segment logic on top, producing three named segments instead of one flat tier list. Urgent, Plugged In, Empire, each with its own opener, objection handling, and channel. That turned into a short term contract, built in the founder's own Clay instance so he owns the data.
I designed, built, and tested the full outbound motion against the Urgent segment, personalized with 3x3 research, then replicated it at scale through Clay's sequencer without losing the specificity of a hand written email. Handed the system off for the team to run.
impact / results
Replaces one generic pitch sent to every restaurant with three distinct conversations built around how each type of restaurant actually decides to buy, cutting the back and forth it normally takes to figure out if a prospect is even a fit. The Urgent segment turns a public job posting into a same week opener grounded in a real, current fact about the business, the kind of relevance that gets a reply instead of a delete. The whole system was handed off turnkey so the team runs it without needing me in the room.
tech stack
Clay (Google Maps enrichment, scoring and segment logic, native sequencer), Claygent (chain and channel classification), Foursquare Places API (foot traffic signal), Find Jobs (front of house hiring signal).
Web scraping to backfill reservation platform and menu data, a paid firmographic source for faster disqualification, Slack alerts on entry to Urgent, CRM sync so segment and score travel with the account, geographic territory logic for field reps.
process map
reflections
The failure taught me more than the build. I needed a real time busyness signal, not a historical popularity number, so I reached for the Foursquare Places API and paid for access before confirming it worked. The first endpoint returned a 410. Foursquare had migrated and deprecated the old path, the auth format had changed, and Clay's AI URL builder silently generated a broken request I only caught by reading the raw response. Then the field I needed sat behind a paid tier I had not budgeted for. That gap, between clicking a native enrichment and actually solving the problem, is where Clay stops and GTM engineering starts.
The bigger lesson came from the client. My thesis assumed Arthur needed a fast single threaded sale: one owner, one decision, days not quarters. The founder pushed back. He is fine with a longer cycle if it means onboarding several locations at once. That one comment turned a binary filter into three distinct buying motions, a better model than my first draft. Being wrong in a way the client could correct beat getting it right alone.