Online bookings with deposit and no-show protection.

No, and we would be wary of any supplier who told you otherwise. Vertex applies the policy you configure. You set whether a deposit applies and to which bookings, whether it is charged per person or as a fixed amount for an event, how much notice a guest must give to cancel, and what happens when they give less; the software then presents those terms to the guest at the point of booking, records what they agreed to, and processes cancellations against the rule you wrote. That is the whole of the mechanism. Whether the terms you write are lawful and enforceable where you trade is a different question, and it is yours to settle with a legal adviser rather than with us. Deposits, no-show charges and cancellation fees sit in consumer-contract territory: rules on unfair contract terms, on what counts as a genuine pre-estimate of loss rather than a penalty, on how prominently a term must be disclosed before it binds anyone, and on refunds and chargebacks all vary by jurisdiction and change over time. You will not find a lawful deposit amount, a safe cancellation window or a defensible fee stated anywhere on this page or in this product, because those are not ours to state. The specific figures the design prints — the 24, 48 and 72-hour options in the cancellation panel, the fifteen-minute late-arrival example, the per-person and fixed-event amounts on the deposit screen — are illustrative configuration values, chosen to show that the fields exist. Read none of them as a recommendation. The same caution applies to the payment side. This page shows a setting labelled "Vaulted Cards — capture details without charging immediately", and the phrases "all deposits are processed securely" and "no hidden platform fees for guests". Those describe the intent of the design. They do not say who holds the card details, which payment provider sits behind the capture, what is stored rather than referenced, or what certifications apply, and we are not going to fill that gap from a marketing page. Take it to sales as a procurement question and get it in writing — which provider processes your deposits, who is the merchant of record, what happens to card details when a booking is cancelled or a card expires — and have it reviewed before you go live rather than after. Nothing here should be read as a claim about card storage, tokenisation or payment-card compliance, or as a statement that using Vertex makes you compliant with consumer-protection, unfair-terms or payment law.

That is not a promise we will make, and it is not one the software could keep. A no-show is a decision a guest makes; a table turn is the product of your menu, your kitchen, your service style and how long people want to sit. Vertex does not seat a party, cook a course, clear a table or persuade anyone to arrive. What it can do is narrower and still worth having. It puts your terms in front of a guest before they confirm, so the commitment is explicit rather than assumed. It sends the reminder and the late-arrival message you have written, so a booking is less likely to be simply forgotten. It records who arrived, who arrived late and who did not come, so you have a factual history instead of an impression — and that history is what lets you decide whether a deposit policy is worth introducing, or whether the one you have is doing anything. And it keeps the host stand, the floor and the kitchen looking at the same picture of the room, so a table that has come free is visible to the person who can fill it. Whether any of that moves your numbers depends on your guests, your neighbourhood, your prices and how the policy is actually enforced by the person on the door on a busy Friday. We publish no no-show rate, no turn-time improvement, no cover uplift and no recovered-revenue figure on this page, and you should treat any such number from any supplier as a claim to be tested against your own data rather than a result you have bought. The right way to judge this is the way you would judge a well-kept reservation book: it makes the information available and it keeps a record. It does not run the door for you.

A walk-in party goes on the list with a name and a party size, and the host attaches a quote — the two examples on this page are a party of four quoted twelve minutes and a party of two quoted twenty-five. The list is visible at the host stand for the rest of service, and the page shows automated SMS notifications used to tell a party their table is coming up. The quote is the part to be careful about. It is an estimate, and the host owns it. The page says the feature quotes "accurate wait times based on historical turnover data" — that is the design's phrasing, it describes turnover figures the system has recorded from your own past services, and we would rather you read it as a starting suggestion than as an arrival time. Past turnover cannot see tonight: a four-top lingering over coffee, a large party running long, a station backed up, one server short, or a table that was quoted before the kitchen took six tickets at once. A quote is a considered guess made from an average, and the host adjusting it against what they can see in the room will usually beat the number on the screen. So use it as a baseline, let the host override it freely, and quote guests a range rather than a figure if your room is unpredictable — an under-quote that runs over annoys people more than an honest wider estimate. The second limitation is reachability. A waitlist only works if the party can be contacted and chooses to come back. If the phone number was mistyped, if the message does not arrive, if they have gone to a bar out of range or simply decided to eat elsewhere, the list will show a party waiting who is not going to appear, and the table sits while someone works that out. Keep the habit of confirming the number when the party joins the list, and give the host a clear rule for how long a called party is held before the table goes to the next name.

Taking the second half first: this page names no third-party booking platform, no directory listing and no reservation marketplace, so we are not going to imply a connection to one. If you take bookings today through an outside platform and need those covers to appear in the same book, that is a real integration question with a real answer, and it belongs with sales before you sign rather than in a paragraph here — ask what is supported, in your market, in writing. On notifications, the page describes three things and only three: a booking confirmation and reminder to the guest, an "Are you coming?" check-in message sent by SMS once a party is past the grace period you set, and SMS notifications to a waiting party on the list. It names no SMS gateway, no email provider and no messaging app, and it says nothing about which countries can be reached, what a message costs, who pays for it, or how sender identity and opt-out are handled — all of which are ordinary questions with setup-specific answers. Ask them, and test the flow on a real handset on your own network before you build a door routine around it. Whatever the plumbing turns out to be, plan for messages that do not land. Numbers get mistyped at the point of booking, handsets get switched off, messages get filtered, and a guest who is dining with you for the first time has no reason to recognise the sender. The message is a prompt that reduces how often someone has to pick up the phone; it is not proof that the guest was told. For anything that costs you a table — a large party, an event booking, a slot you are holding against a deposit — keep a human call in the process and treat the automated message as the thing that makes the call less often necessary.

Yours, and it is worth being plain about it. A reservation book is a customer database. The guest profile on this page carries a name and photo, contact details, a member-since date, a record of past visits with dates, party sizes and spend, dietary and allergy notes, seating preferences and free-text notes from staff. That is personal data by any reasonable reading, some of it — allergy and dietary information — the kind that attracts extra care in most privacy regimes. Vertex holds it on your behalf. You are the one who collected it, you decide what gets recorded, how long it is kept, who on your team can see it and what it is used for beyond running the booking. The page's line about personalised service at scale describes the upside honestly enough, and the upside is real: knowing a regular's usual table, or that a guest has a nut allergy, is good hospitality. But the same record can go wrong in ordinary ways. A free-text note written for a colleague's eyes can be read as a judgement about a guest, and a guest may have the right to ask what you hold about them and see exactly that note. Dining history accumulates whether or not anyone still needs it. Staff who have left should not still have access. So set the ground rules yourself: tell guests what you keep and why at the point you collect it, restrict profile access to the roles that need it, keep staff notes factual and service-related, decide a retention period and apply it, and remove access when someone leaves. On allergy notes specifically, treat the profile as a prompt rather than a confirmation — a preference recorded eighteen months ago is not a substitute for asking at the table, and Vertex does not verify anything a guest or a member of staff typed in. What your privacy obligations actually are, and what your notices need to say, depends on where you trade and is a question for your own adviser, not for a software page.