I started a supper club for people working in AI

AI Supper Club is a dinner for people who want to talk about AI. I started it because I work in AI and want to meet other people who do. For each one I book a single table of about ten at a local restaurant and aim it at a particular group of people, so the guests have something in common before they sit down. I'll make the introductions, and each table has a question to get the conversation started. No dinner has run yet. I'm arranging the first in Colchester, and after that I'll host them across East Anglia and London.

The thing a dinner like this can't afford is a drop-out. I don't want one, the other guests don't want one and the restaurant doesn't want one, and at a table of ten a single empty seat is a tenth of the evening. So every dinner has a deadline, arranged in advance. A guest pays when they book and can cancel for a full refund up to that date. After it the payment is non-refundable, unless someone on the waiting list takes the seat, in which case the guest who gave it up gets their money back.

The deadline is also the day the restaurant gets its final numbers: how many are coming, how many of each dish to cook, and who can't eat what. Both the deadline and the menu change from one restaurant to the next. One wants a week's notice and serves a set menu, another wants three days and serves its own menu with a minimum spend.

Guests book and pay on aisupperclub.co.uk, and I built the booking system behind it around that deadline. It keeps the table full, and it tells the kitchen what to cook.

Each dinner is for a named audience

The group a dinner is aimed at is its audience, and every dinner has one. I'm starting with four: people building with AI, small business owners, people using AI at work, and people who are curious and haven't started. I'll add more as the dinners go on. Each audience has its own question for the table, because a table of builders and a table of business owners want to talk about different things. The builders get "What's working in production, and what did you rip out?" and the small business owners get "What do I automate first, and what do I leave alone?"

Most business networking over a meal is built on membership. BNI is the best known example: you join a chapter that meets every week, it takes one person per profession, and you're expected to be there. That works for people who want to know the same group well. AI Supper Club has no membership and no fixed group. You pick a dinner because its audience and its question are ones you care about, you come when one suits you, and you sit with different people each time.

The audience matters most when someone is choosing a dinner, so a dinner's page says who it's for under the heading "Who you'll sit with" and people can pick the night that suits them. It also decides who hears about a dinner. Someone signing up to the mailing list ticks the audiences they're interested in, and is added once they've confirmed their address from an emailed link.

The audience is one of several things I set for each dinner, because no two dinners are arranged the same way. The others are the price, the number of seats, the menu, the deadline, and the house rules for the evening, such as off the record and no selling.

Two ways to sell a seat

How a seat is priced depends on what the restaurant wants to serve.

The first is a set menu. I agree a menu and a price with the restaurant, guests pick one dish per course when they book, and everyone pays the same.

The second is pick-from-the-menu, for a restaurant that would sooner serve its own menu. Here the guest orders from that menu when they book and pays for what they ordered. Because there's no seat price, I can add an event fee per guest, a service charge as a percentage, and a minimum spend. The guest sees a running total with those charges included, so they know the full amount before they pay.

An order placed weeks ahead has to be one the kitchen can cook, so each section of the menu carries a rule about how much a guest can pick. A guest has to pick one main, can pick one dessert or none, and can have as many sides as they like. Options on a dish follow the same rules. A guest has to say how they want a steak cooked, and a sauce is optional and can cost extra.

Before any of that can happen, the restaurant's menu has to be in the system, and a full menu can be fifty dishes. Typing that in by hand would be slow, so I give an AI assistant a photo or a PDF of the menu, along with a page that describes the format the system expects, and paste in what it writes. That format page tells the assistant to copy names and prices as printed, and to ask when a price is missing. The system then checks the result. It lists every problem it finds, such as a missing price or two dishes with the same name, and it saves nothing until the whole menu is right.

Menus change, and a guest who has already paid shouldn't be affected when they do. So once a guest has paid, the system keeps their order at the names and prices they paid for. If the restaurant changes the menu later, new bookings see the new one and paid orders stay as they were.

What a guest sees

All of this reaches a guest through the dinner's page. It has the date, the venue with a map link, who the table is for, the menu and the house rules. Beside them is a booking box with the price, the seats left and the deadline for a refund. "What if I can't make it?" is the first thing I'd want answered before paying for a seat, so that date is stated in plain words.

What the booking box offers depends on where the dinner stands. While seats are on sale it takes a booking. Once the table is full it offers a place on the waiting list, and a dinner that has no date yet lets people register their interest. Neither of those costs anything.

Booking takes a few steps. A guest gives a name and an email, chooses their courses or their order, adds any dietary needs, and answers one question about what they do with AI. There's no account to create and no password. They then pay on a card payment page, and the system holds their seat while they do, so two people can't buy the last one.

Once they've paid, a confirmation email repeats the date, the venue, what they chose and the deadline. The email also has a private link to their booking, which is where they cancel if they need to, without writing to me. Up to the deadline, cancelling sends the money back to their card. After the deadline they can still give up the seat, and the page tells them before they confirm that the payment is no longer refundable. If someone on the waiting list then takes the seat, they get their money back.

Two reminders follow without my doing anything. The first arrives on the morning of the deadline, while there's still time to cancel. The second arrives the morning before the dinner, with the time, the address and what they ordered.

Keeping ten seats full

Even with a deadline, seats come free. Someone cancels, or someone starts to pay and walks away from the payment page. When that happens the waiting list fills the seat. Within the hour the system offers it to whoever has waited longest, in an email with a private link and 48 hours to claim the seat and pay. If they can't come, they can give the seat up from the same link and it goes to the next person. If they don't answer, the offer lapses after the 48 hours and moves on. While an offer is open the seat counts as gone, so nobody else can buy it in the meantime. If I'd like the offers made sooner, there's a button for that.

The seat held at the payment page has a time limit too. If a payment arrives after the hold has ended and the seat has gone to someone else, the system refunds the payment, puts the guest on the waiting list and emails them.

The same queue lets me test a dinner before I commit to it. I can publish a dinner with no date, and people register their interest. When I set the date, the system offers seats in the order people registered, everyone beyond the last seat joins the waiting list, and all of them get an email. That way I book the restaurant already knowing who wants to come.

The restaurant signs off the menu and gets one sheet

The restaurant is involved at two points, and the system has something for each.

The first is the menu. Before a dinner goes on sale I can send the restaurant a private link to the menu and the details of the evening, and they don't need an account to open it. They can comment on any dish, then sign the menu off or ask for changes, and I get an email when they answer. The system keeps each round of comments and sign-off, so I can see what they agreed to even if the dinner changes afterwards.

The second is a sheet for the kitchen to cook from. For a set menu the sheet has the number of guests, a count for every dish, dietary needs by guest name, and who ordered which dish, so each plate goes to the right guest. For a pick-from-the-menu dinner it has kitchen totals with the options broken out (three ribeyes: one rare, one medium rare, one medium), followed by each guest's order and any note they left for the kitchen. Either sheet prints, and the orders also download as a spreadsheet file for a restaurant that prefers one.

The sheet is only useful if the numbers on it hold, which is what the deadline is for. I set it for each dinner, anywhere from none to sixty days before, to match the day the restaurant wants final numbers. Payments are non-refundable after it, so the number I give the restaurant is the number I've been paid for.

Running a dinner from the host area

Everything above is run from a host area. Its first screen is a list of dinners, so I can see where each one stands. For each dinner it shows the status, the seats sold, seats held on the payment page, seats left, offers waiting to be claimed, the waiting list and the money received, which counts only guests who have paid.

Setting up a new dinner is quick because most of it is saved already. I save a venue once with its address, its map link, its usual menu and price, and my notes on who to ring, and a dinner starts from a saved venue and an audience. I can also duplicate any dinner, so a regular night at the same restaurant is a change of date. A new dinner stays a draft until I publish it.

On the night the same area becomes the guest list on my phone. It shows each guest's courses or order, their dietary needs and when they paid, and I can mark people as they arrive.

Refunds are handled here too. I can refund any guest at any time. The system records who made each refund and when. If I have to cancel a whole dinner, it shows me who will be refunded and how much, then refunds every paid guest and emails them. If a bank rejects a refund, the guest list flags that guest with the bank's reason and a retry button, and a double click or a retry still gives one refund and one email.

The last part is the mailing list. It filters by audience and exports, so news of a small business owners' dinner goes to the people who asked for those.

What does the job of a membership

A membership does a lot of an organiser's work. The members have paid for the year and agreed to turn up, so the organiser knows roughly who is coming before anyone books. Clubs without one tend to manage by hand. The organiser rings or emails the people they know and keeps the list themselves, and guests pay on the day if they turn up. There's usually no deadline and no waiting list, and nobody asks about allergies in advance.

With no members, nothing commits anyone to one of my dinners, and I can't know who's coming until they book. The booking system does that job. Paying at booking makes a yes mean something, and the deadline says when it becomes final. The waiting list fills a seat without a round of phone calls, the mailing list reaches people I've never met, and the restaurant gets its dish counts and dietary needs in writing.

After the supper club

AI Supper Club is the first use of this system. After it I plan to white label the system, so other businesses can run it under their own name and web address, with their own prices and rules. It would suit a breakfast for business owners, a drinks evening, a restaurant's private dining room, or a chamber of commerce's programme for its members, wherever a venue needs numbers in advance.

None of that exists yet. Today there's one site and it says AI Supper Club at the top. If you run a club or a venue and want to use it for your own events, get in touch.

Sources

• AI Supper Club, aisupperclub.co.uk, https://aisupperclub.co.uk

• BNI policies, BNI UK, https://bni.co.uk/en-GB/policies