RESERVATION SYSTEM
A reservation system that answers the guest.
Fork Time is an AI restaurant reservation system that takes bookings across phone, email, SMS, WhatsApp, web chat and compatible AI assistants, and holds them all in one live book. A reservation is not only a time and a headcount. Fork Time captures dietary requirements, allergies, the occasion and each guest's name as the booking is made, and lets the person booking invite the rest of the party to RSVP individually. Table allocation, waitlists, deposits and guest history sit in the same system, so the host sees who is arriving, what they need and what they are celebrating before the party reaches the stand. There is nothing to run underneath it. Bookings, guest profiles and visit history belong to the restaurant and leave with it. Pricing starts at $99 per location per month with no per-cover fees.
THE BOOKING MOMENT IS THE ONLY ONE YOU GET
Restaurant booking flows inherited their design from online checkout: strip the fields, remove the friction, get the guest through. That logic is sound when the transaction is the end of the relationship. In a restaurant the booking is the beginning of it, and it is the only structured moment before the guest walks in when anything can be learned about them.
The tension is real. 44% of diners stop trying when booking becomes difficult, so every field added to a form costs bookings. But every field skipped costs the welcome, because the host greets a name and a party size and nothing else.
A form cannot escape that tradeoff. A conversation can. Eight fields on a screen is friction. A question asked in a conversation, on the phone or in a message, is service: "any dietary requirements I should note for the kitchen?" collects the same information and feels like care rather than paperwork. That is why Fork Time takes bookings through conversation on every channel, and why the reservation arrives with more in it than a time and a number.
ONE BOOKING, SIX GUESTS
A table for six usually produces one guest record and five strangers.
The person who booked is known. The other five arrive with no name, no history, no dietary record and no preferences, on their tenth visit as surely as their first. Five-sixths of the people in the room are invisible to the system that is supposed to remember guests.
Fork Time lets the booker send an invitation to the rest of the party. It arrives branded to your restaurant rather than looking like a software notification, which matters because the guest receiving it has a relationship with your restaurant and none at all with us.
Each guest confirms in their own name and adds what they need: dietary requirements, allergies, anything the kitchen should know. That information attaches to the guest rather than to the booking, so it is still there on their next visit whoever makes that reservation.
The restaurant sees the party as people rather than a headcount. Six names, six sets of requirements, and a kitchen that knows the real allergy count before service rather than at the table.
Compounded across a year of service, this is the difference between a booking list and a guest base.
OCCASIONS ARE DISCOVERED TOO LATE
An anniversary is the most valuable thing a restaurant can know about a table, and it is usually discovered at the table, when the only response left is a candle in a dessert.
Captured at booking, the same information gives the kitchen and the floor time to do something with it. Fork Time asks about the occasion during the booking conversation and flags it on the reservation, so the team decides what to do with a week's notice instead of ten minutes.
THE CHANNELS STOP BEING SEPARATE
A guest who calls on Tuesday, changes the booking by WhatsApp on Thursday and asks about parking by email on Friday has had one conversation with your restaurant. Most systems record three unconnected events, and often three different guest entries.
In Fork Time every channel writes to the same book and the same guest record. The booking that started as a web enquiry and finished on the phone is one reservation with one history. Availability is read from the same floor no matter where the request arrives, so two guests booking at once cannot be given the same table.
WHAT THE HOST SEES
Before the party arrives, the host sees who is coming by name, how many times each guest has visited, what they cannot eat, what they are celebrating, where they prefer to sit and what was noted last time.
None of that requires anyone to remember anything. Front of house tenure is short in most venues, and a restaurant that relies on memory for recognition loses that capability every time someone leaves. A guest record is the version of that memory that does not resign.
WHAT ELSE RUNS IN THE SAME BOOK
Table allocation for reservations and walk-ins. A live waitlist that feeds cancellation recovery when a table opens. Deposits requested per booking when demand and risk are high, rather than a blanket policy applied to everyone. Guest records that carry across every visit. All of it reads and writes the same live availability, because they are one system rather than several connected ones.
WHAT FORK TIME IS NOT
Fork Time does not run a diner marketplace. It brings no discovery traffic. A restaurant that needs to be found should keep a marketplace listing, and OpenTable is the stronger choice for that job. Fork Time works on the demand a restaurant already has, and it does not charge per cover for guests who already chose you.
AFTER THEY SIT DOWN
A guest who has just been seated is in the least comfortable moment of the meal. They have not read the menu, they do not know what they want, and there is a person standing there waiting to find out.
Most restaurants solve this with timing and instinct. A good host reads the table and comes back. A busy one hovers, or disappears for twelve minutes, and the guest gets the version of service the room could spare that night.
Fork Time gives the table another option. Once seated, guests can browse the menu at their own pace and raise their hand in the system when they are ready. The request appears on the floor view, so the team goes to the table that wants them rather than circling to check.
The ordering research supports this, and it is not obvious. Ariely and Levav (Journal of Consumer Research, 2000) tracked real diners ordering in groups and found that when people order aloud in sequence they choose differently to be distinctive, and they enjoy what they ordered less. When choices were made privately, people were more likely to order what they actually wanted and were more satisfied with the meal. Ordering out loud around a table is a social performance, and the performance costs the guest something.
A menu the guest reads at their own pace, without a server waiting and without hearing what everyone else picked first, removes that pressure.
It matters most where distance is the problem. A large dining room, a terrace, a beachfront venue, a room split across levels: these are the places where a server covers ground rather than tables, and where a guest with a question waits longest. Raising a hand in the system covers that distance instantly and saves the walking that produced nothing.
Your team still runs the room. This does not replace the check-back or the recommendation. It removes the guesswork about when they are wanted.
EVERY CALL ANSWERED
See it working on your own service.
The demonstration uses examples based on your restaurant and service style.