Your Restaurant's SMS Waitlist Is Broken (Here's What a Good One Looks Like)

Walk into a busy restaurant on a Friday night in Orlando. The host asks for your name and number, mumbles "about 45 minutes," and hands you a buzzer or tells you they'll text. So you wander down the block. Forty minutes in you've heard nothing. Fifty. You call — voicemail. You check the app — it's not connected to anything. At an hour you give up and go somewhere else.

That restaurant just lost a $120 table. And the ironic part is they probably did send a text at some point. They just had no waitlist system worth the name.

After wiring one of these up for a restaurant client recently, I've looked at dozens of the "off the shelf" options, and almost all of them treat SMS as a one-way megaphone. A good waitlist is a conversation.

What the flow should actually look like

When a guest joins the list, they should get an instant confirmation with three things: they're on the list, their position, and how to leave gracefully.

Hi Sarah — you're #7 on the list at Asian Gourmet. Estimated wait 25-35 min. We'll text updates. Reply PASS to drop off, STOP to opt out.

Then, as positions move, they get updates at meaningful thresholds — not every time somebody seats. A text when they hit #3 ("you're next up in ~10 min — start heading back") is far more useful than seven "you moved up" pings.

The ready text is the big one, and it's where most systems fail. It shouldn't just say "table's ready." It should say:

Your table's ready at Asian Gourmet. We'll hold it 10 minutes — reply HERE when you're on your way or NEED MORE TIME if you're still 15 min out.

Now the host isn't guessing. If the guest replies HERE, the host seats the next party knowing #1 is inbound. If they reply NEED MORE TIME, the host slides the next party into that table and bumps Sarah down one spot — automatically, with another position text to her so she's not blindsided.

That's a waitlist. Not "we sent a text, they didn't show up, oh well."

The compliance stuff that gets numbers flagged

If you're spinning this up yourself on Twilio, three things will sink you if you skip them:

10DLC registration. Any number sending application-to-person SMS to US recipients needs a registered campaign (called TCR). Without it, carriers throttle or block you, and customers just stop getting texts. Registration takes 1-3 weeks and costs ~$15/mo in fees.

STOP keyword handling. Every text you send has to honor STOP, UNSUBSCRIBE, CANCEL, QUIT, END as opt-out keywords. If you don't, you're violating the TCPA and carrier rules will bounce you before any regulator does.

Quiet hours. TCR best practice — and common sense — is no SMS between 9pm and 8am recipient local. Your waitlist system should geofence this around the venue's timezone, not the server's.

Most restaurant owners never hear about any of this until their number gets flagged and deliverability drops to 40%. Then they wonder why customers aren't getting the ready text. The same compliance logic applies if you ever expand into an SMS loyalty program — opt-out handling and quiet hours aren't optional there either.

What it actually costs

This is the part that surprises people. SMS on Twilio is about $0.0083 per message in the US. A busy restaurant sending 4-5 texts per waitlisted party, maybe 100 parties on a Friday, is looking at under $5 for the night. Add the TCR fees and the number rental and you're at roughly $25/month all-in for a single-location restaurant.

Compare that to one no-show table on a Friday night — let alone a walk-out — and the math gets ridiculous fast.

Why your current system probably isn't doing this

The built-in waitlist feature in most restaurant platforms (Toast, Resy, OpenTable, Owner.com) does exist, but it's designed to be vendor-neutral and conservative. They can't customize per-restaurant flows without engineering, so you get generic templates, rigid timing, and no way to extend with things like rewards hooks or follow-up "thanks for dining" SMS. Before you sign with any of those platforms, it's worth understanding what leaving one of them actually costs — the contract terms matter as much as the feature list.

When I build these for clients, I wire them directly into their site and their POS if there is one — it's a Twilio number, a Laravel or webhook listener, and a handful of message templates the client can tune themselves. Total build is usually a couple days for a single-concept restaurant.

If you're evaluating this

A few questions to ask any waitlist tool (yours or a vendor's):

• How many position updates does a guest get on average?
• Does the "ready" text accept replies, or is it one-way?
• Does the system handle STOP, is it TCR-registered, and does it enforce quiet hours by venue timezone?
• Can I add new keyword responses without waiting on a vendor release?
• What happens when a guest replies with something unexpected — does a human see it?

If the answer to most of those is "no" or "I'm not sure," your waitlist is costing you tables. That's fixable — and it's usually a lot cheaper to fix than to keep losing covers every busy night. And if you want the rest of your restaurant's local presence working as hard as your waitlist should be, ten minutes a week on your Google Business Profile will do more than most paid tools.

If you're running a restaurant and any of this sounds like your current setup, drop me a line. I'd rather build it right the first time than help you migrate off something generic later.