01
ask arthur
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.
clayclaygentfoursquare places apifind jobsclay sequencer
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.
the build
- Found the real buyer, not the whole market. Arthur wins where the phone never stops ringing and the person who feels that pain also controls the budget: independent, phone-order-heavy, casual restaurants. I ruled out fine dining, chains, and reservation-first spots before scoring anyone.
- Scored every prospect on signals that predict a fast win — how they take orders, takeout volume, price level, whether they're independent, and foot traffic — so the list ranks itself instead of sitting flat.
- Split one flat list into three buyer groups, each sold to differently. A "segment" is just a named group of similar restaurants: Urgent (feeling the pain right now), Plugged In, and Empire (multi-location). Each gets its own opening line, objection handling, and channel.
- Built it inside the founder's own Clay workspace so he owns the data and the system keeps running after I'm gone.
- Ran the whole outbound motion end to end on the Urgent group: every email personalized with current, specific facts about that business, then scaled through Clay's email sequencer without losing the hand-written feel. Handed off turnkey for the team to run.
process map
1Pull the restaurant list
2Drop the ones Arthur won't win
3Score the rest on buying signals
4Sort into the three buyer groups
5Find the right contacts
6Personalize with live facts
7Send the sequenced outreach
8Replies route back by group
impact
- Three tailored conversations instead of one generic pitch — each built around how that type of restaurant actually decides to buy, so the team wastes less time figuring out who's even a fit.
- Timely openers that earn replies — a public job posting becomes a same-week email grounded in something real and current about the business, not another cold template that gets deleted.
- Turnkey handoff — the team runs the whole system without me in the room, and with no ongoing cost.
tech stack
currently using
- ClayGoogle Maps enrichment, scoring and segment logic, native sequencer
- Claygentchain and channel classification
- Foursquare Places APIfoot traffic signal
- Find Jobsfront of house hiring signal
phase 2
- 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
reflections
- The tooling fights back, and handling that is the job. I paid for a data source (Foursquare) before confirming it worked; it broke because the endpoint had moved and Clay's AI request builder silently generated a bad call I only caught by reading the raw response. The gap between clicking a "native" integration and actually solving the problem is exactly where GTM engineering starts.
- The client made the model better. My first thesis assumed a fast, one-decision sale. The founder pushed back — he'll take a longer cycle if it means onboarding several locations at once. That one comment turned a yes/no filter into three distinct buyer groups. Being wrong in a way the client can correct beats being right alone.