The food industry runs on a strange piece of public infrastructure: every restaurant website is a complete product catalog with prices, hours, and contact info, sitting wide open for anyone to read. The big food-tech companies (DoorDash, Toast, OpenTable) employ teams to read these websites manually. Smaller companies tend to either pay a list-broker for stale data or skip prospecting entirely.
If you're in the second camp, this post is what I'd send you.
I'll use Italian restaurants in Boston as the example. Same approach works for any cuisine and any city — I just had to pick one.
Why restaurant websites are particularly easy
A few things make restaurants different from other small businesses:
Their websites exist almost universally. Even a tiny family-owned trattoria that opened in 1987 will have a website by now. Most are simple — homepage, menu, contact, sometimes a Yelp link. But they exist.
The menu is the website. Unlike most small businesses where the website is a brochure with vague service descriptions, restaurant sites typically have the actual menu with actual prices on a page called something obvious like /menu. This isn't true of dentists, lawyers, or contractors, where pricing is usually hidden.
Reservations and delivery platforms get embedded. A restaurant using OpenTable will have an OpenTable widget. One using Resy will have Resy. One using DoorDash for delivery will have a "Order on DoorDash" button. Looking at which widgets are embedded tells you which platforms they're already on, which is exactly the qualifying question if you're selling to them.
The owner is often named. Restaurants market through their chef-owners. About 70% of restaurant websites in my Boston sample named at least one owner or executive chef on the About page, and roughly 30% of those gave them a direct email.
Running a real scrape
I ran "italian restaurants" in Boston with a 200-lead target. The discovery took 28 seconds and returned 156 unique Boston Italian restaurant URLs (the realistic ceiling is around 200 — Boston isn't a huge Italian-restaurant city). The extraction ran across all 156 in 11 minutes.
Here's what came back per restaurant:
| Field | Found |
|---|---|
| Restaurant name | 100% |
| Address | 98% |
| Phone | 96% |
| Operating hours | 84% |
| Cuisine type explicitly named | 91% |
| Menu items with prices | 71% |
| Average price computed from menu | 71% |
| Reservation platform identified | 58% |
| Delivery partners listed | 41% |
| Owner or executive chef named | 68% |
| Owner email (specific) | 22% |
| Generic restaurant email (info@, etc.) | 79% |
| Instagram handle | 73% |
| Yelp/Google review link | 67% |
The menu-pricing field is the interesting one. For 110 of the 156 restaurants, the crawler found enough explicit menu prices to compute an average dish price. The distribution of those averages tells you something about Boston's Italian-restaurant market:
| Price band (avg main course) | Number of restaurants |
|---|---|
| Under $18 | 12 |
| $18-22 | 31 |
| $23-28 | 38 |
| $29-35 | 21 |
| Above $35 | 8 |
So Boston Italian splits roughly into casual under $20, neighborhood $22-28, and upscale $29+. Useful if you're prospecting at a specific price point.
What this is good for
Here's where the data turns into actual outreach value, broken down by what kind of company you'd be running.
If you sell POS systems (Toast, Square, TouchBistro), you can prioritize restaurants whose websites suggest legacy tech. A site with a downloadable PDF menu and no online ordering integration is probably running an older POS — fertile ground for a Toast sales conversation. A site with a slick Resy integration and online ordering already wired up is harder to switch.
If you sell delivery (DoorDash, Uber Eats), you can identify restaurants not currently on your competitor. The website tells you what delivery partner they're using, if any. About 22% of Boston Italians in my sample were on no delivery platform at all — a clean prospect list for whichever platform reaches them first.
If you sell wholesale food supplies (Sysco, US Foods), the menu tells you the cuisine, the price point, and the rough volume. A restaurant with 60 menu items at $30+ average is a different buyer than one with 12 items at $14. You can prioritize and route reps accordingly.
If you sell restaurant marketing (Popmenu, ChowNow, BentoBox), the question is whether their current site is any good. A site without a digital menu, without Instagram integration, without an ordering widget — that's a sales lead. A polished modern site is harder to displace.
If you're a restaurant operator yourself, you can pull every competitor's menu in your zip code and benchmark your prices. Most operators do this manually once a year. With this approach you can do it in a weekend, with citations.
A specific personalization example
The number that matters most for cold email is reply rate. A generic blast to 500 restaurants gets you maybe 2-4 replies. A blast with one specific menu detail per email gets you 15-30.
The specific-detail email looks like this:
"Marco — saw Trattoria Romana is running 38 menu items with an average of $26 and OpenTable for reservations. Most restaurants in that range that switch to Toast see a 30% reduction in reservation no-shows because of the SMS confirmation flow. Would 10 minutes next week make sense?"
That email pulls three specific facts from the website (menu count, price, reservation platform) and ties them to one specific outcome you're claiming. The recipient knows you've actually looked at their restaurant, not just bought their email from a database.
I won't pretend this works for everyone. Some chef-owners ignore cold email entirely. Some are sick of being pitched. But the per-email lift from specificity is real, and it's the kind of personalization you can't fake without actual menu data.
What you don't get
Menus inside images and PDFs are invisible to text extraction. A meaningful number of older family restaurants — maybe 15-20% in my Boston sample — have their menu as a JPG or scanned PDF. Our crawler reads the page but doesn't OCR the image. For most outbound work the existence of a menu page is enough signal; if you need every dish from every menu, you'll want to add an OCR step yourself.
Multi-location chains are weird. A site for a chain has one menu and one parent contact, but the real prospects are usually the individual general managers. Our crawler follows /locations/ pages and pulls individual store addresses, but the managers' names aren't usually published per-location. If your sales motion targets store-level GMs, this approach won't get you there alone.
Prices age. Restaurants update their printed menu once a year or so. Their online menu usually catches up within a couple months but not always. If your campaign depends on current pricing, re-scrape monthly. The cost is small.
Cuisine boundaries get fuzzy. A restaurant that calls itself "Modern American with Mediterranean influences" will sometimes show up under Italian searches and sometimes not. If your targeting needs precise cuisine matching, you'll want to post-process with your own classifier on top of the cuisine field. We extract what the restaurant calls itself; we don't second-guess.
The cost
I ran the 156-restaurant Boston Italian sweep on the Pro plan ($29/month). The full job used 156 credits. Pro covers 1,000 credits a month, so I could comfortably run the same scope across 6 cities a month.
For a full national US sweep — 20 major metros, 5 cuisines per metro, 200-lead cap — you're looking at about 15,000-20,000 credits, which fits inside the Growth plan at $79/month.
The equivalent dataset from a list broker would run $5,000-$15,000 for one delivery, and the data wouldn't be fresh.
How to try this on a vertical you care about
Pick a city and a cuisine — or a city and a sub-vertical (fast casual, fine dining, wine bars, sports bars, brunch spots, food trucks). Run a free discovery. The 50-lead free tier is enough to see what's there before you commit to a paid plan.
If you build something useful with this, I'd be curious to hear about it. Most of what we improve in the tool comes from real outbound use cases people share with us through the docs page.