Privacy Policy

In short: ResoFlow is a trading name of Caleonix LTD, a UK company. We are the data controller for the businesses that use ResoFlow (our tenants), and we process their guests’ data on their behalf, as a data processor.

Caleonix LTD (company number 17162652) is a company registered in England and Wales with its registered office at 71-75 Shelton Street, London, England, WC2H 9JQ. We trade as ResoFlow and operate the website at https://resoflow.co.uk.

For data protection matters, contact us at [email protected].

We are registered with the UK Information Commissioner’s Office (ICO), the UK’s independent data-protection regulator, under registration number ZC127147. We are not required to appoint a statutory Data Protection Officer; data-protection queries go to [email protected].

Controller and processor roles

ResoFlow is a B2B platform. Our relationship with you depends on who you are. Throughout this policy, “guests” means the people a venue serves through ResoFlow — the venue’s own customers (which is what a venue’s dashboard calls them): anyone who books or joins a waitlist, asks to be told when a table frees up, orders, buys a ticket, buys or receives a gift card, or joins a loyalty scheme.

We are a data controller for:

• Tenant accounts (the business that signs up for a subscription or product).
• Caleonix's own billing and payment records.
• Site-visitor analytics, cookies, ad measurement on our own website, and marketing communications we send to tenants.
• Support conversations and chat transcripts directed to ResoFlow.

We are a data processor for:

• All guest data — bookings, orders, tickets, gift cards, loyalty, customer profiles and history — whether the guest gives it or the venue adds it.
• Tenant-side staff data (members the owner adds to their dashboard and PIN portal).
• Messages a venue sends its guests through our email and text providers. Resend sends our emails. divergent (PureSMS) is our main text provider, and we use Twilio alongside it at any time: for a venue that set up its texts before we moved to PureSMS (until we move it across), to keep texts going if PureSMS is unavailable, and for phone numbers and calls if we offer them. When a guest replies to an email a venue sends through ResoFlow, the reply comes to a ResoFlow reply address. On the venue’s Pro and Complete plans it is kept in the venue’s Messages: on the booking, or, for an email that isn’t about one booking (a birthday email, for example), in the guest’s own conversation with the venue. On the Free and Plus plans — and, on every plan, for a reply to a marketing email the venue sends to many guests at once (a campaign, or a message it writes itself to its loyalty members) or to the email confirming a sign-up to its news — we pass the reply straight on to the venue’s own email address and keep nothing of its words: once the forwarding email is sent its words are removed from our sending records, and only its subject, addresses and dates are kept, for up to 90 days, so we can show the venue it was delivered (a forwarding email that can’t be delivered is kept, words included, for up to 12 months so it can be sent again). Automatic replies, such as out-of-office messages, are recognised and not passed on.

The Data Processing Agreement governs the processor relationship between Caleonix and each tenant.

In short: We collect information directly from tenants, on behalf of tenants from their guests, and automatically when you use our Services.

Information from tenants (we are controller)

• Owner name, email address and mobile phone number. A UK mobile is required when you sign up: we confirm it’s yours with a code we text to it, to keep your account secure and so we can reach you about it — and when our team reviews a business check, they can see whether the owner’s mobile was confirmed.
• Business name, address, and basic operating details.
• Authentication credentials. Your password is stored only as a one-way hash, by Firebase Authentication. When you reset your password or sign in with a recovery code, our servers pass it straight on to Firebase — it is never stored or logged.
• Payment method. Card details are handled directly by Stripe; we receive only non-sensitive references (such as the card brand, last four digits, and Stripe token references) — never the full card number.
• Your plan, any standalone products you subscribe to, your business type, usage counters and a log of administrative actions. If you tell us when you sign up which booking system you’re moving from and how you heard about us, we keep those answers and count them to see where our customers come from. We also note, for each person who signs in, when they were last shown the welcome tour at each venue and how it went (for example, whether they skipped it), so it isn’t shown to them again by itself.
• The server’s sign-in record for each sign-in (when you signed in, whether you chose ‘keep me signed in’, when it was last used) — kept 31 days after it was last used, and deleted at once when your account is closed.
• For each device signed in to your account we keep a rough town, looked up on our own servers from the address it signed in from (no outside company is involved), so you can spot a device that isn’t yours. It’s kept while the device is signed in, and for 31 days on the record of that sign-in. Separately, so we can warn you about a sign-in from somewhere new, we keep the last 10 internet addresses your account signed in from (for a newer IPv6 address, only its network part).
• After you sign in, your browser keeps a sign-in proof so the security check isn’t repeated while you stay signed in. We keep a one-way scrambled copy of it, with your account’s ID, the sign-in it belongs to and when it was last used; it is deleted when that sign-in ends, or otherwise 31 days after it was last used.
• If you tell us a computer is yours (“Yes, it’s mine”), we remember your account on that browser, so you aren’t asked “Keep me signed in on this device?” again when you sign in there with the same account — it never signs anyone in, and it works for your account only. We keep a one-way scrambled copy of the proof your browser holds, with your account’s ID, a one-way scrambled form of the browser’s device ID and when it was last used. It stops working when you use Sign out everywhere, change your password or two-step sign-in, remove that computer from your devices list, choose Sign out and forget this device or later tell us other people use it, or once it hasn’t been used for 30 days — then it is deleted automatically.
• Passkeys. If you add a passkey to sign in with Face ID, a fingerprint or your device’s screen lock, we keep the passkey’s public key and its technical details (an identifier, a counter, and whether it syncs between your devices), the name you give it, and when it was added and last used. The private key, and your face, fingerprint or device PIN, never leave your device — we never see or receive them. When you sign in with a passkey, we also give your browser a one-time pass for the security check, so none is shown; we keep a one-way scrambled copy of it, with your account’s ID and the passkey it was for, for at most two minutes, and delete it as soon as it is used.

Where a venue has not opted out, the public details it already publishes (its name, town, cover image or logo, strapline and a link to its booking page) may also appear in our venue directory at resoflow.co.uk/venues — with a card while the venue is actively used, and otherwise by its name and town in the A to Z list. The directory never shows information about guests.

When you create an account we record which version of the Terms, the Privacy Policy and the Data Processing Agreement you accepted, when you accepted them, and your confirmation that your business operates in the UK. We keep this record with your account as evidence of the agreement, for as long as the account exists and for 30 days afterwards.

When you first switch on marketing emails or texts, or choose your own text sender name, we check that your business is real using public records: Companies House (for a company) and the Food Standards Agency’s food hygiene register, and whether your Stripe account is set up to take payments. We keep what we find — your company’s number, registered name, status and registered office, and the food hygiene listing we matched — with your declaration that the business is yours (who made it, when, and the words), and use it only to confirm your business, to register your text sender name with our text provider, and to re-check it from time to time. We never look up or keep details of your company’s directors, and we never ask for documents.

Venue setup codes (prospective customers)

Where we visit or speak with a prospective venue, we may prepare its account setup in advance. For this we store the venue’s own details (its name, address, telephone number, contact email address and website), the proposed configuration (such as opening hours, table layout and operating preferences), and the name and email address of the owner we are dealing with. Where the venue gives us a logo or cover image for their public pages, we hold those too.

Access to the prepared setup is given by a one-time setup code, which we share with the owner privately ourselves — we never send one automatically. The code works once, and only for the email address we recorded. While we prepare a venue’s setup we keep those details — and any files and answers sent through a setup upload link — for 30 days after we last worked on the setup, and never more than 90 days from the day we started it. They are deleted then, or as soon as the setup is cancelled, and once a venue has used it what was prepared becomes part of that venue’s account. Any files a venue emails to us for its setup, instead of sending them through the link, are deleted within 30 days after the setup is used or cancelled.

Where we are setting a venue up remotely, we may also send the owner a private upload link so they can send us what we need to prepare the account: a logo and photos, a menu, photos of the rooms, and typed details such as opening hours, cancellation wording, the first names and roles of their team and their Google review link. The owner can also choose to send a list of their customers or the bookings they already hold, so that we can move them across; the venue remains responsible for making sure it is entitled to share those details with its booking system. The link can only be used to send us files and answers — it cannot open an account — and it stops working when the setup code does.

If the code is used, what was prepared becomes part of the venue’s account records and is kept under the tenant retention periods in section 8.

Launch and industry-interest waitlist (prospective customers)

If you ask us to keep you posted — for example by registering interest in ResoFlow for your type of venue on our website, or during sign-up when we are not yet ready for your industry — we store your email address, the industry you told us about (where you chose one, or the short description of your business you typed if you chose “Something else”), the exact consent wording you agreed to and when, and basic anti-abuse details (a one-way-hashed network identifier and your browser’s user-agent string). We use this only to confirm your sign-up and to email you when ResoFlow is ready for you — it is never used for general marketing without a fresh choice from you.

You can remove yourself from the list at any time using the link in your confirmation email, or by contacting us (section 14) — either way we delete your entry.

Booking a call with us (prospective customers)

If you book a call with us on our website, we collect your first name (and last name if you give it), email address, phone number, the topic you choose, any notes you add, and your chosen time slot, together with a one-way-hashed network identifier used only to prevent abuse of the booking form. We use these details only to arrange and hold the call — including sending you a confirmation email with a calendar invite, and a cancellation email if we have to cancel — never for general marketing without a fresh choice from you.

Information from venue staff (we process it for the venue)

When a venue owner adds staff members to their dashboard, we process the following personal data on the venue's behalf as a data processor. The venue is the data controller; we hold this data under its documented instructions. See our Data Processing Agreement for full details.

• Identity — name, username (chosen by the venue), assigned role, and any per-staff permission overrides set by the owner or admin.
• Contact (optional) — work email address, work phone number, and job title, only if the owner chooses to record them.
• Security — the staff PIN, stored only as a one-way cryptographic hash (a PIN we create while setting up a new venue is held for up to an hour, readable only by our servers, so the owner can see it once; then it is deleted), a device token bound to a specific browser or tablet the owner has enrolled, and the IP addresses the staff member signs in from. Sign-in IPs are kept only as needed for security alerts and the venue's audit log. While a member of staff is signed in, their browser keeps a sign-in proof so the security check isn’t repeated; we keep only a one-way scrambled copy of it, deleted when they sign out, and automatically once that sign-in’s 12 hours are up.
• Preferences — the staff member's chosen theme (light, dark, or system), and which alerts and sounds they choose to see and hear in the app.
• Push alerts (optional) — if the venue turns on alerts for a paired staff device (the ResoFlow Staff app, or ResoFlow in a browser, on a tablet or phone), we store a push token for that device (an identifier issued by the device’s browser or operating system), the device type and browser, and when it was last used, so we can send the alerts the venue asked for. The alert itself carries a short line — about a person, at most a first name and initial; for a booking, a party size and a time; for an order, its items and total — never a phone number, email address, allergies or notes. It is deleted when alerts are turned off, when the device is removed, or after 60 days of not being used.
• Rota (optional) — if the venue uses rotas, the shifts it gives each member of staff: the days and times, their position (for example Bar or Kitchen), planned breaks, any note a manager adds to a shift, whether they are under 18 and whether they have opted out of the 48-hour working week (both only so the rota can warn about working-time rules — never a date of birth), the hours and days a week in their contract if the venue adds them, and when each shift was published or changed. The venue can ask ResoFlow to draft a week from the cover it needs, each person’s contracted hours, the times they’ve said they can’t work, their time off and the working-time rules; a draft is only a suggestion that the venue checks and changes before anyone sees it, so a person at the venue decides every shift. When the venue publishes the rota we email each member of staff their own shifts (and again if the venue tells them a published week has changed), with two private links: one that adds their shifts to their phone’s calendar and one that opens their own rota page. The calendar link shows that person’s shifts. The rota-page link shows their shifts, the open shifts they could take, their own time off, their holiday balance, the times they can’t work and their swaps, and lets whoever has it ask for or cancel time off, change the times they can’t work and ask for, answer or cancel swaps in their name. Because it opens without signing in, it never says that a day off was for sickness: sick days, can’t-work days and other time off all show there as “Off”, no request shows its note, and an “Off” day shows no record of when it was asked for or who answered it; holidays show as holidays. It does show whether each request is still waiting for an answer, so a day off that is still waiting could hint that it is a sick day the venue hasn’t answered yet. Anyone with these links — including anyone the member of staff forwards them to — can see and do the same; the venue can renew them at any time, which stops the old ones working.
• Rota requests (optional) — if the venue uses rotas, what each member of staff tells it about their shifts: the times they can’t work, their requests for time off (the type — holiday, sick, can’t work or other — the dates, and any note added to a request that isn’t for sickness), and their requests to swap, cover or take a shift, with a colleague’s and a manager’s answers. The people who approve the venue’s rota can also record time off for a member of staff, sickness included — for example when someone phones in sick. Sickness is recorded as the dates only — never a reason, a note or anything about health; only the member of staff (when signed in), the venue’s owners and admins and the people who approve its rota are shown that it was sickness, and everyone else — on the rota, on the venue’s devices and on the member of staff’s own private rota-page link — sees “Off”. We email a member of staff when a colleague asks them to swap or cover a shift and when a request of theirs is answered; their private rota page lets them make these requests without signing in. A member of staff can tell the venue they’re off sick themselves (on their private rota page or the venue’s devices) only if the venue switches that on; otherwise they phone the venue and someone who approves its rota records it.
• Clocking in (optional) — if the venue uses clocking in, when each member of staff clocks in and out and takes breaks, timed by our own server (not the device’s clock), and which of the venue’s paired devices they used — clocking in only works on those devices. If a manager corrects a time, we keep what changed, who changed it and the reason they gave, and the member of staff can see the reason. A shift nobody clocked out of is closed at its planned end and the manager is told.
• Holiday and pay (optional) — a holiday allowance in days or hours, or holiday that builds up from the hours clocked (12.07% of them), with what has been taken, booked and carried over; and, if the venue records it, an hourly pay rate, whether the person is in the venue’s workplace pension and their National Insurance band (standard, under 21 or apprentice under 25 — never a date of birth). Only the venue’s owners and admins can see pay; it is used to estimate what a week of the rota costs the venue, including its own National Insurance and pension contributions, worked out when the page opens and never stored, and is never shown on the rota, to other staff or in the hours file the venue downloads for payroll. We don’t work out anyone’s pay, tax or own National Insurance, and nothing is sent to HMRC.
• Tipping policy (optional) — if the venue keeps its tipping policy in ResoFlow, we keep each published version (with the text its staff were asked about), the draft it shared with its staff, each member of staff’s comment on that draft (with their name, so the venue can follow up) and the written summary the venue publishes. We also keep a member of staff’s request for their tips record (the dates asked for, when they asked and when it was sent). When the venue shares a draft, each member of staff with an email address on its staff list gets an email with their own private link to read and comment on it; the venue’s owner gets an email when a member of staff asks for their tips record, and a reminder when the policy is due for its review.
• Activity metadata — last sign-in time and active session records (device, last-seen time) so the owner can review and revoke sessions.

Staff personal data is displayed only to authorised accounts at the venue. Staff can view and edit their own optional contact details, theme and alert choices from the staff portal Profile page.

Information from guests (we process it for the venue)

• Contact details — name, email address, and phone number.
• Booking details — date, time, party size, table assignment, any special-occasion or other notes you add, and your booking history. Your birthday (day and month) is optional. It is used for birthday messages where the venue enables them, to let the venue choose who gets a campaign or offer in their birthday month (only customers who can receive its marketing), and, if you are a loyalty member of a scheme with a birthday gift, for an automatic once-a-year birthday bonus on your loyalty card. If you save a booking to a device wallet, we also keep a device identifier and push token, only so we can update the pass if your booking changes. If the venue checks guests in with a QR code, your booking confirmation, reminder and change emails, your wallet pass and your manage-booking page show a check-in code for that booking. On its own the code shows nothing about you: it only lets the venue’s own team find your booking and mark you as arrived.
• Answers to a venue’s own booking questions — if a venue asks its own questions when you book, your answers are kept and deleted with the booking, like its notes, and are never shown publicly. We stop a venue’s questions asking about health, religion or other sensitive subjects, apart from allergies and diet (see section 3).
• Messages with a venue — messages you send a venue (a reply to its email, its message box, the chat page a venue’s text or email links to, or My account’s Messages) and its replies. Your account at a venue shows your messages with it.
• “Notify me” requests — If a date is fully booked, a guest can leave their name and their email address or mobile number, with the date, the times and the party size they wanted, to be told if a table frees up. When a booking on that date is cancelled (or a no-show frees its table), we send one email or text to each person on the list whose times and party size it suits, in the order they asked; the first to book gets the table.
• Allergies and dietary preferences — see section 3.
• Pre-orders — where a venue offers pre-ordering for larger bookings and your party chooses its food in advance: the dishes selected (with any choices and quantities), any first names added against a dish so the kitchen knows who it’s for, any short note added to a dish for the kitchen (often about an allergy — special category data, see section 3), and the order’s total. You may make these choices while placing your booking, or afterwards from your booking’s manage page. This is stored on the booking and visible to the venue. If the venue takes payment for pre-orders online, your card is handled directly by Stripe on the venue’s own Stripe account (never by ResoFlow) and we hold only Stripe payment references.
• Party food by link — where a venue lets each guest in a party choose and pay for their own food on their own link: each guest’s name, an email address if they give one, any dietary needs or allergies they choose to tell the venue (special category data — see section 3), a short note on any dish they choose for the kitchen, the dishes they choose and what they paid or were refunded, and — if they joined from the party’s shared link — a one-way fingerprint of their device, so the same browser is welcomed back to the same place. These guests may not be the person who booked. A guest’s dietary note and dish notes are shown to the venue, never to the rest of the party. We email each guest who gives an email address their own link, a reminder on the last day choices are open (or when the venue sends one) and a receipt for what they pay, and we email the organiser who has chosen and who hasn’t, by first name only.
• Order & Pay orders (at the table, collection and delivery) — where a venue offers ordering from your table by QR code, or ordering ahead for collection or delivery: the dishes you order (with any choices, quantities and notes you add for the kitchen), your table (for at-table orders), any tip, your email address (so we can send your receipt and any service emails about your order — for example when it’s ready, or if the venue has to reject and refund it) and, optionally, your name. For collection and delivery orders we also collect your name and phone number (required, so the venue can reach you about your order) and the time you asked for. For delivery orders we collect your delivery address and any door notes you add for the driver — the address is used to check it falls inside the venue’s delivery area and to work out the delivery charge (see the Google Maps entry on our Sub-processors page), and it is shown to the venue and its driver to deliver your order. When you search for your address, your browser sends what you type to Google Maps to suggest matching addresses, so Google also sees your IP address (never your name or contact details). If the venue accepts cash, we record whether you chose to pay in cash at hand-over. If a card refund fails and the venue repays you by bank transfer or in cash, we keep a record of that repayment — the amount, how and when it was paid, the transaction or receipt reference, the reason and who approved it — linked to the failed refund and marked as recorded by the venue, not confirmed by Stripe. The venue’s team is told never to type bank or card details into it. If gift card value on the order is returned to you on a new gift card instead, we keep its amount, expiry, the reason, who approved it and a link to the original card and order; the new card’s full code isn’t kept on that record. If you have a customer account and are signed in, you can save delivery addresses to your account for next time — you can edit or delete saved addresses at any time from your customer portal, and they are removed if you ask to be erased. If you’re a member of that venue’s loyalty scheme, your email address is also used to add the visit to your loyalty balance — exactly as a booking visit would be. Paying for an order (at the table, for collection or for delivery) creates or updates the guest profile the venue keeps about you, exactly as making a booking does, and the checkout offers the same choice about the venue’s marketing: we record whether you left the marketing box as it was or ticked it to opt out, together with evidence of that choice — when it was made, which page it was made on, the exact wording you were shown, and the choice itself — so the venue can demonstrate the basis for any marketing it later sends. If your order contains alcohol we also record your confirmation that you’re 18 or over. Your card is handled directly by Stripe on the venue’s own Stripe account (never by ResoFlow) and we hold only Stripe payment references. Every order asks ‘Does anyone in your party have a food allergy or intolerance?’ and we record your answer on the order. Where the venue has chosen to let you tell it about an allergy with your order and you answer Yes, we also collect the short note you write about it (special category data — see section 3), which the venue’s staff see on its Orders screen and kitchen ticket and which is shown on your receipt; it is removed with your other details.
• Reviews you leave — where a venue switches customer reviews on: your star rating, the words you write and the display name you choose to show publicly, held with a pseudonymous link to the completed order, booking or event ticket the review came from — never your email address on the review itself. You can edit your review for 30 days. The venue can reply publicly and can report an abusive review to ResoFlow; the venue cannot delete your review, though ResoFlow can remove one the venue has reported. If you ask to be erased, your reviews are deleted outright.
• Profile the venue keeps about you — a VIP flag, tags (e.g. “regular”), free-text notes, a seating preference, and family details for your party (number of children, whether a highchair or children’s menu is needed). The venue’s team enters most of this; you can add your own family details, and an “About me” note for the venue’s staff, in your account at the venue.
• Your account at a venue — if you sign in to a venue’s “My account” page (with a code we email you), you can add details yourself for the venue’s team: your name, phone number, birthday (day and month), your own allergies and dietary needs (see section 3 — the venue sees them on every booking you make there), family details and an “About me” note. The venue’s staff can see what you add. If you stay signed in, a token kept on your device signs you in at that venue for up to 30 days (see our Cookie Policy). When you ask to sign in, we email a 6-digit code to the address you enter, whether or not you have been to the venue before. The code lasts 10 minutes and works once. To stop misuse we keep a scrambled record of each request (made one-way from the email address and from your device or internet connection, never the email address itself) for a few days — at most four — and the venue’s activity log notes that a code was sent, with the email address scrambled the same way. Like every email we send, the code email’s delivery record (which holds the address) is kept for 90 days (see “Email delivery logs” below). Signing in doesn’t create a customer record for you: the venue has one only once you book, join its loyalty scheme, buy something or save your details. A sign-in lasts up to 12 hours, or up to 30 days on a device where you stay signed in.
• Activity the platform derives for the venue — attendance history (no-shows, cancellations, abandoned waitlist places), how many orders you have placed, lifetime spend (on deposits, orders, event tickets and gift cards), average party size, and previous names or phone numbers seen on your profile. If you give a venue a UK mobile number but no email address, the venue keeps a customer record for you under that number, with your visits and the details from your bookings. If you later book with an email address, the same mobile number and the same first and last name, the two records are joined into one; if the name is different (or only a first name was given), the venue’s team decide whether it’s you. A landline or the venue’s own number never makes a record. At venues that record arrivals, the venue’s team can see how many of its own bookings a guest didn’t turn up for, when they book again; this is never shown to the guest.
• Event tickets — where a venue runs ticketed events: the buyer’s name, email and phone, and any additional attendee names the buyer provides. If you save a ticket to a device wallet, we also keep a device identifier and push token, only so we can send updates if the event details change. If the venue switches on event reminder texts, we also text the buyer’s mobile a reminder before the event, with its date, time and a link to the tickets — a service text about their own tickets, never marketing.
• Event waitlists — if an event has sold out and you join its waitlist: your name, your email address and how many tickets you want. When tickets come back they are offered in the order people joined: we email you when it’s your turn, with the tickets held for you for a short time and links to buy them or pass them on to the next person; and if the venue takes you off the list, we email to tell you. These are service emails, never marketing. Your place is deleted the day after the event, or straight away if you ask to be erased.
• Payments (deposits / no-show protection) — where the venue switches these on. Your card is handled directly by Stripe on the venue’s own Stripe account and is never seen, stored, or processed by ResoFlow; we hold only Stripe references (such as a token, a saved-card mandate for no-show protection, and any charge or refund reference). If the venue chooses, it can skip asking a regular guest for a deposit or a card. To decide, we check — only for a guest who has confirmed their email address in that browser — how many times they have visited the venue, whether they have missed a booking there in the last 12 months and, where the venue has chosen to count them, whether it has marked them as a VIP or they belong to its loyalty scheme. It only ever means being asked for less, and the booking records what wasn’t asked for and why. If the venue has chosen to turn a deposit it keeps (after a late cancellation or a missed booking) into credit, we create a gift card in your name for the amount kept and email it to you.
• Loyalty scheme membership — where a venue runs a loyalty scheme and you choose to join it: your membership status and join details (including a random member code used for scanning your card), your stamp or points balance and lifetime totals, and a history of each earn, redemption, and any staff adjustment. On schemes that award points by the amount you spend, this includes what you pay through ResoFlow (an order, event tickets or a booking paid in full) and any bill amount a staff member types in for a visit — there is no link to the venue’s own card machine or other payment systems. Because a loyalty scheme is, by nature, a record of your visits (and, on spend-based schemes, your spend) at that venue, this recording only happens for the scheme you actively joined, so the venue can run it — you are never enrolled automatically, and if you join while making a booking, an order or a ticket without signing in, we keep a note of which one it was so that it can earn for you once you confirm your email address. If you don’t confirm, the note is deleted 12 days after the last confirmation email we sent you; once you confirm, it is kept until that visit earns (a few days after its date at most). It is also deleted if the booking is cancelled. If you are already a member and book without signing in, your booking confirmation email carries a link to collect what that booking earns; until you use it or it expires (a week after the booking’s date), we keep a note of which booking it is for. You can end your membership yourself at any time from your customer portal (your remaining balance and rewards progress are permanently cleared when you leave). If you save your loyalty card to a device wallet, we also keep a device identifier and push token, only so your card can update when your balance changes. If a venue runs member groups (for example a student discount) and you join one, we keep which group, when and how it was confirmed (by the venue’s staff, or with a code sent to your university or work email) and when it ends. We never keep that university or work address — only its ending (for example st-andrews.ac.uk) and a one-way fingerprint, so the same address can’t confirm another member at that venue; they’re deleted if you leave the scheme or ask us to erase your data. A code we send lasts 30 minutes. If the venue runs a Regulars group, your membership can be placed in it automatically once the venue has recorded a set number of visits for you; your place lasts 12 months from your latest visit and then ends by itself. The groups you’re in can show on your wallet loyalty card (for example “Student · until Jun 2027”, and as the heading of a message the venue sends to a group) and under the QR code in your account, and the venue’s staff see them when they scan that code, so they can give you the group’s discount. A venue can use a member group you’re in to choose who gets its marketing (emails, texts and loyalty card messages) — still only members who said yes to its marketing.
• Loyalty invitations — If you join a venue’s loyalty scheme through another member’s invitation, the venue’s records note which member invited you (their internal customer reference and the date) so the venue can pay the rewards it promised. The inviting member is never shown your details, and you are never shown theirs; ResoFlow does not contact a person who has been invited but has not joined.
• Promotions and offer codes — where a venue runs its own promotions: which offer codes you have used, when, and on what, so the venue can honour per-person limits and see how an offer performed; and, if you save an offer to your loyalty account, that saved coupon and whether it has been redeemed.
• Gift cards — where a venue sells gift cards, a gift card record involves up to two people: the buyer (for online purchases, their name and email; for purchases at the venue these are optional) and, where the card is a gift, the recipient (their name and email, plus the buyer’s personal message, so the card can be delivered and its balance updates and expiry reminder sent). On the card’s record, the spendable code is stored only in a protected one-way form (a gift scheduled for a later date keeps its code until the gift email is sent — see section 8); each card also carries its value, balance, movement history, expiry, and — for online purchases — Stripe payment references only (your card is handled by Stripe on the venue’s own account, never by ResoFlow). Buying a gift card also creates or updates the guest profile the venue keeps about you (the buyer) with the purchase details, as making a booking does — for venue purchases only where you gave an email address. The gift page offers the same choice about the venue’s marketing as a booking (the soft opt-in in section 5): we record whether you, the buyer, left the “No thanks to offers” box as it was or ticked it to say no, together with evidence of that choice (when it was made, which page it was made on, the exact wording you were shown); a purchase at the venue records no marketing choice. Recipients never receive marketing from us or the venue on the basis of receiving a gift card, and no customer profile is created for a recipient. If the venue switches on its ‘Gift card sold’ staff email, a copy of each sale goes to the venue’s own notification address with the buyer’s and recipient’s names, the amount and only the last four characters of the card’s code. If you save a gift card to a device wallet, we also keep a device identifier and push token, only so the pass can update when the balance changes.
• Signing up for a venue’s news on its website or venue page — if a venue’s ResoFlow website or venue page shows a ‘Get our news’ box and you type your email address into it, we send you one email asking you to confirm. Nothing else happens unless you open its link and press ‘Yes, send me news’ on the venue’s website or venue page: until then we keep only the address you typed and when, for 7 days, so the link can work, and then delete it. When you confirm, the guest profile the venue keeps about you is created or updated with your email address and your yes to its news and offers by email, together with evidence of that choice (when it was made, where, and the exact wording you were shown). Every marketing email from the venue has a link to stop.
• Your choices about a venue’s marketing — offers by text go only to a UK mobile, to customers who have visited, ordered or bought a ticket in the last 24 months or who said yes, at most one campaign text a week — and never between 9pm and 9am. A venue that imports customers records a yes to offers only for the customers its file marks as having said yes, and confirms it has permission to upload them. If you tell a member of the venue’s team, in person or by phone, that you would like its offers by email or text, they can record that choice for you; we keep the same evidence, together with the name of the staff member who recorded it. If you tell a venue’s team yes to offers by text, that covers texts only: the venue won’t send you marketing emails because of it, even if your records are later joined or you give them your email address. Saying no to offers by text stops marketing texts; it doesn’t change what you’ve told the venue about emails. If you had already said no to the venue’s marketing emails, only a deliberate yes to emails given after that ends it: you turning emails back on (the link in the venue’s emails, your preferences page or your account page), you signing up for the venue’s news and confirming it from the email it sends you, or the venue’s team recording that you’ve told them you want their emails, with a separate confirmation on your record. A yes to texts doesn’t end it, a yes when the team asks you about offers as they take your booking turns on texts only, and joining two of your records never ends it either. If your record is deleted after you said no, the venue remembers that no (see the “No marketing” marker in section 8), so a record made for you later — under your email address or, unless you had said yes to its texts, your UK mobile number — starts as a no too. If you had said no only to its texts — by answering no when asked, or by switching its texts off — the venue remembers that too, as a no to texts: a record made for you later under your UK mobile number starts with its marketing texts off, unless you say yes to them then. A venue can choose who gets an email campaign from what it holds about its customers — for example when they last visited, where a visit is a booking or a paid order — and only among customers who can receive its marketing. A venue may also switch on automatic emails linked to what it sells: an “order again” reminder after a quiet spell and a thank-you after a first order (Order & Pay), news of a new event to people who have bought its tickets before (Tickets), and a “we miss you” to loyalty members who haven’t visited for a while (Loyalty). Each is off until the venue turns it on, goes only to customers who can receive the venue’s marketing and haven’t switched that kind of email off, and a customer gets at most one of these a week from a venue. They are chosen from the dates of a customer’s orders, visits, tickets and loyalty activity.

We do not sell or otherwise disclose guest data outside the strict bounds of delivering the Services to the venue you booked with. Guests should direct questions to the venue in the first instance.

Information from other sources. A venue may also give us guest data it already holds, rather than you entering it directly — for example by importing its existing customer list into its account. We process any data imported this way on the venue’s behalf in exactly the same way as data entered directly through the platform.

Information collected automatically

• IP address, browser type, operating system, and device information.
• If you turn on push alerts on one of your own devices (the ResoFlow app on your phone, tablet or computer), a push token for that device (an identifier issued by its browser or operating system), the device type and browser, when it was last used, and your alert choices (which alerts, and any quiet hours). The token is deleted when you turn alerts off, sign out or remove the device, when you lose access to the venue the alerts are for, or after 60 days of not being used. These alerts include a reply from our support team to a conversation you started: the alert says who from ResoFlow replied — never what the conversation is about — and follows your “Money and security alerts on my devices” switch.
• Cookies and similar technologies (see our Cookie Policy).
• Ad measurement on our own website — only if you tick “Ad measurement” in our cookie banner (as well as analytics cookies), and only on ResoFlow’s own website and sign-up pages: the click reference Google adds to our adverts’ links, kept in a Google cookie for 90 days, and, if you then sign up a new venue, the fact that it signed up and the type of business it chose. Google Analytics passes this to Google Ads so we can see which of our adverts lead to sign-ups. It is never collected on the dashboard, the staff portal, a venue’s booking or other guest pages, or a venue’s own website, it never includes a name, an email address, a phone number or anything about a venue’s guests, and it is never used to show you personalised adverts. See our Cookie Policy.
• Camera (the Scanner) — where a venue uses the Scanner to check event tickets, loyalty cards or gift cards, a staff device may ask permission to use its camera to read the QR code. No photo or video is captured or stored — only the code is read.
• Map images on venue pages — where a venue’s public page shows a map of its location, your browser fetches that map image directly from Google Maps, so Google receives your IP address and browser details alongside the venue’s address. It is a plain image — no cookies are set and none of your personal details are sent. See our Sub-processors page.
• Sentry error reports, which may contain user IDs and technical context necessary to debug a fault, plus a short, fully masked session replay around an error on signed-in screens only (the dashboard, staff portal and our own admin panel — never on a venue’s booking or other guest pages). Replay stores nothing on your device. See our Cookie Policy for the full detail.
• Email and text engagement — marketing emails sent through the platform from ResoFlow’s marketing address (a venue’s campaigns, its other marketing emails such as birthday, thank-you and review-request emails, and the product news we send venue owners) contain tagged links that record which links were clicked, so the sender can see how the email performed. No email contains a tracking pixel, so opening an email is never recorded. Emails a venue sends from its own connected domain carry no tagged links, and neither do service emails such as booking confirmations, reminders, receipts or password resets. Where a venue’s campaign text includes a link, each guest’s text carries their own short link: when you tap it, we record the tap against a one-way reference to you (never your name or number), once per campaign however often you tap, so the venue sees how many guests tapped — not who. A link preview drawn by a chat app or a search robot isn’t counted, and the link works for 90 days from the send. For a venue’s marketing, the venue is the sender and we act on its behalf; for our product news to venue owners, we are the sender. See our Cookie Policy.

Support correspondence

When you contact us via the in-app chat or by emailing support@, billing@, security@ or [email protected], we collect:

• The messages you send and any file attachments you choose to include.
• Your IP address and browser user-agent at the time you send the message.
• When you read a reply from us in the in-app chat: when you read it, and whether you were active in the conversation at that moment (the chat on screen and used in the last minute), so that we don’t also email you a reply you have already seen. It is kept with the conversation, and removed if your staff login is deleted.
• Interaction logs from Rezo, our AI support assistant (an EU-hosted Google large-language model). Internal model diagnostics are stripped from any data export.
• Pictures you attach in a support conversation are read by Rezo (the same EU-hosted model) so it can help with what you have shown it — a screenshot of a settings page, for example. They are never used to train any AI model.
• When you ask Rezo whether a booking email or text message was sent, it can look up recent delivery records for your own venue — the recipient (shown partly masked), the message type, whether it was sent and when. It never sees the message contents and never another venue’s records.
• When you ask Rezo about a booking, it can look up that one booking at your own venue — its status, date and time, table, party size and, for staff allowed to see payments, its deposit, payment or refund — with the guest shown only by their initials. It never sees the guest’s contact details, notes or allergy information, and every look-up is recorded in your venue’s Activity log.
• Recent support conversations are summarised to help with your next one: when a conversation with Rezo closes, a short summary (who asked, the topic, the outcome, the date — never the transcript) is kept for 30 days so Rezo can pick up where you left off. You can switch this off at any time in Account → Preferences.
• Reports of a Rezo result. When someone at a venue reports a Rezo result as wrong, we keep what they reported — the job, what Rezo read and what it produced (which can quote a guest’s review or message), their note and our answer — for 90 days, then delete it. It is used only to put the result right and to improve Rezo.

For external (non-tenant) senders who email support@, billing@, policies@ or security@, or use the chat on our website: we also retain the sender email, the name you give us (first name and surname, where you provide them so a reply can reach you), IP and user-agent on the conversation record so we can reply and identify duplicate or abusive senders.

Our sending addresses (for example [email protected] and [email protected]) don’t take replies. If you write to one, we send you one automatic answer explaining how to reach the venue — at most once a day — and we don’t keep your message.

You can sign in with Google, with an email address and password, or with a passkey; a venue’s staff sign in with a PIN on a device the venue has paired, and guests sign in to their account at a venue with a code we email them. We do not use Apple, Microsoft, Facebook or X as login providers, and we do not buy intent data or social-network friend lists from third parties.

In short: Allergies and dietary information are special category data under UK GDPR. The venue is the controller and relies on your explicit consent (Article 9(2)(a)); ResoFlow processes it only on the venue's behalf.

Allergy and dietary information is treated as special category data under Article 9 of the UK GDPR. The venue is the controller for this data and relies on your explicit consent (Article 9(2)(a)) when you choose to tell it about an allergy or dietary need so it can be catered for. You provide it voluntarily and can ask the venue to remove it at any time.

An allergy or dietary need you type when you book (the box asks about your whole party) is kept with that booking only. It is saved to your customer profile at the venue — so the venue sees it on your future bookings — only when you choose that: by ticking “This is my own allergy — remember it” (or “These are my own dietary needs — remember them”) as you book, by adding it in your account at the venue, or when you ask the venue’s team to save it. When you’re signed in, the booking page shows what’s saved and you can remove it there.

ResoFlow processes this information only on the venue's instructions, as its processor — showing it to the venue’s staff (on screen, on kitchen tickets and printed kitchen dockets, and in the venue’s new-booking emails) and, for an order or a pre-order, on your receipt. The venue is responsible for ensuring its kitchen and front-of-house teams act on it.

In short: We process personal data only for the specific purposes set out below.

• To create and maintain tenant accounts.
• To enable tenants to manage bookings, communicate with guests, and run their venue.
• To process subscription payments and send invoices.
• To email you about your account credit: Account credit added — sent when we add credit to your account; Account credit returned — sent when a refund puts money back onto your account credit; Account credit expiring — sent 30 days before some of your account credit expires.
• To email a venue’s owner a short Your month summary on the 1st of each month — the venue’s bookings and covers for the month just ended. It follows the owner’s Product updates choice (Your details, or the unsubscribe link in each one); a suggestion about the venue’s plan and one line of ResoFlow news are included only for owners who have agreed to product updates.
• When you join, we may send up to three service emails about finishing your set-up in your first two weeks, and one about each product you add if it isn’t live three days later (each with a note in your notifications); the set-up ones stop at your first online booking, and you can turn them all off on Your set-up.
• Where a venue enables deposits or no-show protection: to provide the technical means, through Stripe Connect, for the venue to collect a deposit, save a guest's card — when you book, or afterwards through a secure “save a card” link the venue sends you — or charge a no-show fee on its own Stripe account. Saving a card never charges it: the link shows the no-show fee (and any late-cancellation fee) you are agreeing to before you save the card. If you organise a party whose guests each choose and pay for their own food, the venue may also ask you to save a card through a card link for any guest’s share still unpaid when choices close. The link shows you those words before you save the card, and that card is never used for a no-show fee. A no-show fee is charged when the venue deliberately marks a booking as a no-show, or — where the venue enables it — automatically when you cancel after the free-cancellation deadline you agreed to at booking; either way the fee and that deadline are shown to you before you confirm. ResoFlow facilitates the payment on the venue's behalf and does not handle the guest's card details; the deposit or no-show fee is paid to the venue, although ResoFlow may deduct a platform fee.
• A venue can also send you a payment link for your booking — a deposit, a payment in full, an extra, a no-show payment or another amount — with a short line the venue writes saying what the payment is for (about the payment, never about you), which you see on the payment page, in the email or text and on your receipt; the link’s record is kept as the retention table in section 8 says. Whenever you pay a payment link (including a paid change to an order or a tip added afterwards), or pay online while booking at a venue that has switched its booking confirmation email off, we email you a payment receipt; and if a no-show fee you paid is refunded, we email you to confirm it. Where a venue lets you pay at the venue, or asks for the rest of a booking’s price by a date, we email you one reminder about three days before each payment is due (only if it’s still unpaid), and a receipt when the venue records money you paid there; if a payment link is no longer needed because you paid at the venue, or the venue gives you back money you paid there, we email you to say so. These money emails can’t be switched off, and are never marketing.
• If a venue charges a party’s organiser for unpaid shares, we use the card saved with the booking to take that one payment, and the organiser’s receipt names each guest whose share it paid (first name and initial) and the amount — never what they chose. The charge is kept with the booking’s payment records.
• Where a venue runs a loyalty scheme or promotions and you take part: to record your membership and keep your balance and earning history accurate, to validate offer codes and apply per-person limits, to update a loyalty card you have saved to a device wallet, and to send the scheme’s emails on the venue’s behalf. Those emails are: a membership confirmation or welcome when you join; a reward unlocked notice when you earn a reward (you can switch this off in the customer portal); an optional round-up of your points (monthly or weekly), which we treat as a marketing email — only sent where the venue switches it on, to members who joined the scheme themselves (the join page says so) or said yes to the venue’s marketing; your “no” to the venue’s marketing stops it, you can switch it off any time, and every round-up carries an unsubscribe link (joining doesn’t otherwise sign you up to the venue’s marketing emails); and a scheme closure notice if the venue closes its scheme. A venue’s messages to your saved loyalty card stop if you tell it you don’t want its marketing, or switch off Loyalty card messages on your preferences page; the card itself keeps working. If you’ve said yes to a venue’s marketing, its messages to members also come to you by email, with an unsubscribe link — switch them off with Offers and news on your preferences page. Separately, two data-protection service messages are sent to scheme members even if you have opted out of marketing, because they are administration of the scheme and record you hold: a warning before your customer record is deleted at the end of the venue’s retention period, and a warning before an unused loyalty balance expires through inactivity (where the scheme sets an expiry).
• Where a venue sells gift cards and you buy or receive one: to process the purchase and deliver the card (including on a future date the buyer chooses), to keep its balance and movement history accurate, to update a gift card you have saved to a device wallet, and to send the card’s transactional emails on the venue’s behalf — the buyer’s receipt, the gift email carrying the card, a short note to the buyer when a gift they scheduled has been delivered, a balance update after each redemption (where the venue has these on), and one expiry reminder about 30 days before the card expires. If a venue switches it on, the person holding a gift card that still has money on it and hasn’t been used for a few months may also get a balance reminder: one short email with the card’s balance and expiry date, in fixed wording the venue can’t change and with no offers. It goes to the person the gift was sent to, or to the buyer if they bought the card for themselves — never to the buyer of a gift given in person — and is sent at most once until the card is used again. These are service messages about value you hold — never marketing — and receiving a gift card never adds you to any marketing list.
• Where a venue messages you through ResoFlow: to send a one-to-one message about your visit (never marketing); a text or an email telling you a venue has messaged you about your booking, with a link to read and reply (never marketing); and a new link for your email and text choices, when you ask for one on an unsubscribe page (it goes only to an address the venue already holds).
• To respond to support requests via the in-app chat and email channels.
• To provide AI-assisted first-line support replies from Rezo, our support assistant, through an EU-hosted Google large-language model (see Sub-processors). We do not use support correspondence to train any AI model: the model is off-the-shelf, with no fine-tuning, and Google does not use what we send it to train its models. Rezo answers from the ResoFlow help guides and your own set-up. When you ask, it can make a change for you — you check it and press Save; it never changes anything by itself. Jobs like reading your menu use Rezo credits and say their price first; asking is always free. Rezo is never handed card details, passwords, PINs or your customers’ full contact details.
• So that Rezo can answer questions about your own setup, each reply includes a short summary of your venue’s current settings (for example your booking window, deposit rules and which features are switched on), your plan and your current usage figures, and the page of the dashboard you are on. It never receives your customers’ personal data, and nothing in that summary is used to train any AI model.
• If you leave your email address with Rezo on our public contact page so that a member of our team can follow up (for example after a pricing question), we store that address (and your first name, if you give it) together with the exact consent wording you agreed to and use it only for that follow-up. This is a sales and marketing purpose based on your consent; you can withdraw it by replying to the follow-up or emailing [email protected].
• To show a signed-in account owner their own billing summary (current plan, next billing date and amount, and the last four digits of the card on file) inside the support chat, on request and only after they re-confirm their identity. The figures are assembled on our servers from Stripe and shown only to the verified owner; our AI assistant never receives them.
• To read a menu a venue chooses to import (a photo, PDF or menu web page) using the same EU-hosted Google large-language model, so the venue’s dishes can be set up automatically. The uploaded file is deleted as soon as it has been read and is never used to train any AI model. The same read happens when we import a menu for you from a file you sent us through a setup upload link: the copy we read is deleted as soon as it has been read, and the file you sent stays with your other setup uploads until those are deleted.
• Floor-plan import. If you choose to import a floor plan from a picture, the picture you upload (a photograph, drawing, printout or screenshot) is sent to the same EU-hosted Google model to read the table numbers, seat counts, shapes and positions. Photographs are stripped of camera and location metadata in your browser before upload. The picture is deleted the moment it has been read, whether or not the read succeeded, and is never used to train any model. Only the table list you review and save is kept, as part of your floor plan. The same applies when we read a floor plan for you during an in-person setup visit, or from a picture you sent us through a setup upload link: the copy we read is deleted in the same way, and only the table list you checked with us is kept, on your setup code until you apply it. A picture sent through an upload link reaches us exactly as you sent it — it is not stripped of camera or location details first — and the original stays with your other setup uploads until those are deleted.
• Reading an event poster. If a venue asks Rezo to fill in a new event from a picture of its own poster or flyer, the picture is sent once to the same EU-hosted Google model to read the event’s name, date, times and ticket prices. The picture is redrawn first — in the venue’s browser, or on our server for an iPhone photo the browser can’t open — which removes a photograph’s camera and location details. The picture is never stored and never used to train any model; what Rezo read is kept for 7 days only so a repeated request isn’t charged twice, and only the details the venue checks and saves become part of the event.
• Where a venue uses the optional AI marketing assistant in the campaign composer: to draft the venue’s campaign text, design a whole email (and, where enabled, a picture) from the brief the venue types, using the same EU-hosted Google large-language model. The model receives only the venue’s own facts — its name, the brief, the design’s fields, anything the venue has already typed, the short descriptions the venue has saved on its own image-library photos and, when it designs a whole email, small copies of up to 12 of those photos (so it can choose the best ones — a photo that shows people shows them in its copy too), the venue’s own logo when it makes a picture (as a guide to the venue’s colours only), and the details of a promotion the venue attaches. It never receives customer personal data — no names, email addresses, booking history, customer lists or guest reviews — and nothing sent to it is used to train any AI model. An email it designs can show one of the venue’s own published reviews, exactly as the venue’s page shows it; the review is added after the AI has replied.
• Where a venue asks the AI to draft a promotion: to suggest the shape of one offer from the goal the venue types, using the same EU-hosted Google large-language model. The model receives only the venue’s own facts — its name, the goal it has typed, the promo codes it already uses (so the same code is not suggested twice), and whether Order & Pay and events are switched on. It never receives customer personal data — no names, email addresses, booking history, customer lists or spend figures — and nothing sent to it is used to train any AI model.
• Where someone at a venue asks Rezo to explain a month on its Reports page: to write a few plain sentences about that month’s figures, using the same EU-hosted Google large-language model. The model receives only the venue’s name and its own totals — the money taken through ResoFlow, refunds, tips and gift cards sold, from the month’s accounts pack, and its daily booking counts (bookings, covers, walk-ins, cancellations and no-shows) — with the same figures for earlier months to compare. It never receives customer personal data — no names, contact details or notes — it never changes a figure, and nothing sent to it is used to train any AI model. Its words are kept for 7 days only, so that asking again isn’t charged twice.
• Where a venue asks Rezo to write for its website or an event: to draft the About text or the frequently asked questions on the venue’s ResoFlow website, or an event’s description, using the same EU-hosted Google large-language model. For the website the model receives only the venue’s own facts — its name and profile, its own opening line, the names of its menu sections and dishes, its opening hours, booking rules and public phone number, and whether it sells gift cards; for an event, the event’s own details and anything the venue types for Rezo to mention. It never receives reviews, bookings, orders or customer lists; the venue checks and saves the words itself; the words are kept for 7 days only, so that asking again isn’t charged twice; and nothing sent is used to train any AI model.
• If a venue asks Rezo to draft a reply to a review, the review’s star rating and words are sent to our AI provider (Google Vertex AI, in the EU) to write the draft — never the reviewer’s name, email address, phone number or booking. The draft is shown only to the venue, and kept for 7 days so a repeated request isn’t charged twice.
• Search requests worked out by Rezo. When someone at a venue types a request into the search, nothing in the search offers to do it, and they press “Work it out with Rezo”, we send the words they typed to our AI provider (Google Vertex AI, in the EU) to work out which screen they mean and what to fill in. Phone numbers and email addresses are removed before it is sent, but the words may include a guest’s name (for example “book Sarah Jones for 4”). The model also receives the venue’s dates for the next two weeks, its clock setting and the names of the screens that person may open — never customer records, bookings, the menu, settings or payments. Nothing changes until the person presses that screen’s own button. We don’t keep or log the words, and nothing sent is used to train any AI model; what we keep is a count of how many times each venue used it in a month (deleted after about 13 months), a short-lived count of how often each person used it in the last hour (to stop misuse) and what each use cost us — none of them holds the words.
• To find the right help guide when you search our Help Centre or ask Rezo a question. The words you search for, or your question to Rezo, are sent to an EU-hosted Google text-embedding model, which turns them into a list of numbers so we can match them by meaning against our own help guides rather than only by exact wording. This model does not write text and does not answer your question — it only compares meaning. Your wording is never used to train any AI model.
• Where a venue uses the optional “Check my wording” tool in their policy settings: to give that venue an advisory read of the policy wording they have written, using the same EU-hosted Google large-language model, so we can point out anything that appears to contradict the fixed clauses we provide. It runs only when the venue clicks the button, it is advice only — it can never block or change what they save — and the wording is never used to train any AI model. The text checked is the venue’s own policy copy, not your personal data.
• To help our own team support you: when a member of our team asks, the same EU-hosted Google model summarises a venue’s account, drafts a support reply for our team to check before anything is sent, or explains an error or a failed order. Email addresses, phone numbers, postcodes, card-like numbers and guests’ names are removed first; a failed order is looked at only during a support session the venue has started; and nothing sent is used to train any AI model.
• To forward support messages to Slack so we can monitor them and, where needed, respond (see Sub-processors).
• To monitor performance, detect bugs, and improve the platform.
• To detect and prevent fraud, abuse, or unauthorised access.
• To comply with our legal obligations (tax records, ICO orders, court orders).
• With your consent, to send marketing or product-update emails.

Aggregated and anonymised information

We may also create and use aggregated or anonymised information — statistics and insights that do not identify, and cannot reasonably be used to identify, any individual (for example, total bookings processed, or trends in platform usage). Because this information is not personal data, we may use and share it freely, for purposes such as understanding how the Services are used, producing reports, and improving the platform.

In short: We rely on contract, legitimate interests, consent, and legal obligation as our lawful bases under Article 6 of the UK GDPR.

• Performance of contract — the majority of processing necessary to deliver the Services to a tenant (on a free or paid plan) or to handle a booking on behalf of a guest. This includes running a venue’s loyalty scheme for a guest who actively joins it: recording qualifying visits (and, on spend-based schemes, the bill amount entered by staff), holding the balance, and honouring rewards are all performance of the scheme agreement the member chose to enter.
• Legitimate interests — we rely on these for:
  • cookieless performance monitoring;
  • fraud prevention (including the anti-abuse counters that stop an offer code or join bonus being claimed more times than allowed, which use one-way hashed identifiers);
  • error and security monitoring;
  • sending service and booking-related emails (necessary to deliver the Services);
  • the loyalty data-protection service messages described in section 4 (warnings before a record is deleted or an unused balance expires);
  • the PECR soft opt-in for marketing to a venue’s existing customers — when you book, join its waitlist (online or at its door kiosk), take event tickets, buy one of its gift cards or order from it (at the table, or for collection or delivery) and don’t tick “No thanks to offers”; you can say no then, or any time after with the link in any marketing email or text;
  • checking that a venue is a real business before it can send marketing, or texts under its own name, to prevent fraud and to protect guests and other venues; and
  • (where a venue chooses to enable it) a single recovery reminder if you begin buying event tickets but do not complete the purchase.
• Consent — marketing communications, non-essential cookies (including analytics and ad measurement on our own website), and the special category data covering allergies and dietary needs that a guest chooses to provide (explicit consent under Article 9(2)(a); see section 3). You may withdraw consent at any time.
• Legal obligation — tax records, accounting records, regulatory requests, and court orders.

In short: We share data only with carefully selected providers that help us deliver the Services. Those that process data for us are bound by a data processing agreement; the wallet and push services and the public registers on the Sub-processors page work under their own terms, linked there.

The full list of current subprocessors lives at /policies/sub-processors. Categories include:

• Payment processing.
• Transactional and marketing email delivery.
• Text message (SMS) delivery.
• An internal support-messaging bridge — support correspondence (name, email, message text and any image attachments) is forwarded so we can monitor it and respond where needed.
• Cloud hosting, database, authentication, and the AI model behind Rezo, our support assistant.
• CDN, DDoS protection, web application firewall, bot management, and cookieless performance analytics.
• Website analytics, error tracking, and uptime monitoring.
• Wallet passes (Apple Wallet and Google Wallet) for table bookings, event tickets, loyalty cards and gift cards. A pass exists only where you choose to save it to your wallet. A ticket pass carries the ticket-holder name and event details; a loyalty-card pass carries the member’s name, balance and member code, and the member groups they are in; a gift-card pass carries the card's balance, code and expiry, and the buyer's own message if they wrote one (with the buyer's first name when the card was sent to someone else). A table-booking pass carries the venue's name and address, the booking's date and time, the party size, the booking reference, the name the booking is under and, if the venue checks guests in with a QR code, a check-in code; it changes with the booking, shows as no longer valid if the booking is cancelled, and leaves your wallet after the visit. A venue offers table-booking passes only if it has switched them on; if it later switches them off, a pass you have already saved keeps updating until your visit. Some passes also carry the venue's own address location so your phone can show the pass when you are nearby: a table-booking pass while the booking stands, an event-ticket pass if the venue has saved its address, and a loyalty-card or gift-card pass if the venue switches this on. Your phone decides this by itself; your location is never sent to the venue or to ResoFlow.
• Maps, address look-ups and delivery distances — a venue’s own address and, for a delivery order, the delivery address a guest enters (sent with no name or contact details), to check it is inside the delivery area and work out the charge.
• Push alerts to the staff phones, tablets and computers that have turned them on — a device token and the alert’s words (about a person, at most a first name and initial; for a booking, a party size and a time; for an order, its items and total — never a phone number, email address, allergies or notes).
• Public registers we look things up in — Companies House and the food hygiene register when a venue confirms its business, and domain registries to check when a venue’s own connected domain is due to expire.

The named providers behind each category, where they process data, and a link to each one’s data-processing terms are on the Sub-processors page.

We do not sell personal data.

Google Ads (ad measurement on our own website)

If you tick “Ad measurement” in our cookie banner on ResoFlow’s own website, Google Analytics (which works for us) tells Google Ads when someone who arrived from one of our adverts signs up a new venue, with the type of business chosen and Google’s click reference. For this, Google is an independent controller under its own terms (the Google Ads Controller-Controller Data Protection Terms) and its own privacy policy. We never send Google Ads a name, an email address, a phone number or anything about a venue or its guests, and we don’t use Google’s remarketing or personalised adverts. Untick the choice (Cookie preferences in our footer) and it stops at once.

Venue-configured integrations (Zapier / webhooks)

Where a venue chooses to set up a webhook (for example to Zapier or Make), ResoFlow sends the events the venue picks — bookings, waitlist entries, ticket orders, new customer records, a guest’s marketing choices, and loyalty scheme joins and leaves — to the web addresses the venue sets up (up to five). Each message carries the details of that event and a code for the guest made with that venue’s own secret key, so the same guest has a different code at every venue and the code can’t be worked out from their email address. A guest’s name, email address and phone number are included unless the venue switches them off, and booking notes only if the venue switches them on. Allergy and dietary details, ticket, gift card and loyalty card codes, and booking and payment links are never sent. If a destination is unavailable, a message waits in Google Cloud (europe-west1) for up to 24 hours while delivery is retried; a message already waiting when a guest’s details are deleted can still be delivered in that time. The venue is the controller of that onward transfer and is responsible for the receiving tool and for any further processing it performs. ResoFlow only delivers the data to the destinations the venue has set up; these destinations are not ResoFlow sub-processors.

Business transfers

If we are involved in a merger, acquisition, or sale of assets, we will provide notice before personal data is transferred and becomes subject to a different privacy policy.

In short: Some of our subprocessors are based outside the UK. We use the UK International Data Transfer Agreement (IDTA) or the EU Standard Contractual Clauses (with the UK Addendum where applicable) to safeguard those transfers.

Our Firestore database and Cloud Functions are hosted in Google Cloud's europe-west1 region (Belgium). So are the logs our servers write, which are deleted after 30 days. Sign-in accounts (Firebase Authentication — your sign-in email address, your password, stored only as a one-way hash, and any second sign-in step) are processed in the United States, where Google runs that service; guests don’t have one. Sentry hosts our error data in the EU. Cloudflare sits in front of our public websites (and, where a venue enables the optional Your domain product, in front of that venue's own connected domain) as a global edge network: request metadata such as your IP address and browser details transits the nearest Cloudflare data centre — including UK and EU locations — for security filtering and certificate handling. Cloudflare Turnstile also runs a bot check on our public forms. It usually works without showing anything, and asks you to tick a box only when it needs to; Cloudflare’s Turnstile Privacy Addendum explains what that check collects. Other subprocessors are listed at /policies/sub-processors along with their primary processing location.

Where data leaves the UK, we rely on:

• The UK International Data Transfer Agreement (IDTA) for UK to US transfers.
• The EU Standard Contractual Clauses (SCCs) for EU to US transfers.
• The UK Addendum to the EU SCCs where the underlying agreement uses EU SCCs.
• Where a US subprocessor is certified under the EU-US Data Privacy Framework and its UK Extension, that framework may additionally apply alongside the mechanisms above.

Where a provider processes data for us outside the UK, its data-processing terms incorporate one of these mechanisms; the wallet and push services on the Sub-processors page work under their own terms, linked there. If you choose ad measurement on our own website, Google Ads receives it as an independent controller under Google’s own terms, which carry Google’s own transfer safeguards (section 6).

This description of our transfer mechanisms is provided on a best-effort basis and is not legal advice.

In short: We keep personal data only for as long as we need it for the purposes we collected it, plus any period required by law.

In short: We use industry-standard technical and organisational measures, but no system is 100% secure. We acknowledge that risk transparently.

• Encryption in transit and at rest.
• Two-step sign-in available to every venue owner and admin.
• Audit logging of administrative actions.
• Role-based access controls following least-privilege defaults.
• Support access: ResoFlow staff may view a venue’s account data to provide support, investigate a fault or resolve a billing query. Viewing is read-only; changes to the venue’s own data are only made during a time-limited session the venue owner starts or approves, with three exceptions: a change of its name or web address when the venue asks us in writing, applying a setup prepared with the owner while they’re with us, and returning a guest’s payment our systems couldn’t complete. Every session, and each change made outside one, is recorded in the venue’s Activity log, and the owner is emailed when a session ends or the web address changes (both owners, for a venue that has joined another person’s account). ResoFlow staff never see card numbers — those stay with Stripe.
• Continuous Sentry monitoring and BetterStack uptime checks.

Despite these measures, no system can be guaranteed 100% secure. If you suspect unauthorised access to your account, contact [email protected] immediately.

In short: Account holders must be 18 or over and staff 16 or over. Guests booking a table should be 16 or over. We do not knowingly collect data directly from younger children.

Account holders must be aged 18 or over, and their staff aged 16 or over. Guests booking a table or buying a ticket should be aged 16 or over; the venue is the controller of guest data and is responsible for handling any younger guest’s data appropriately. A guest may also record family details about their party — for example, the number of children dining, whether a highchair is needed, or whether a children’s menu was requested. Where this information relates to a child, it is provided by the adult guest on behalf of their party; we do not collect information directly from young children or invite them to use the Services themselves.

If you believe we have inadvertently collected information directly from a minor, contact [email protected] and we will delete it promptly.

In short: Under the UK GDPR you have the right to access, correct, erase, restrict, port, and object to processing of your personal data. You can also lodge a complaint with the ICO.

If you are a guest, the venue you booked with — or bought from, ordered from, or whose scheme you joined — is the controller of your information — exercise your rights with them in the first instance (we assist them as their processor). The rights below describe how we handle requests where we are the controller (tenant account holders and people who contact us directly).

Under Articles 15 to 22 of the UK GDPR, you have the right to:

• Access the personal data we hold about you.
• Have inaccurate data corrected.
• Have your data erased ("right to be forgotten").
• Restrict our processing of your data.
• Receive your data in a portable format.
• Object to processing based on legitimate interests.
• Withdraw consent at any time.
• Not be subject to fully automated decisions that have a legal or similarly significant effect.

Automated decisions. We do not make decisions about you using solely automated means that produce legal or similarly significant effects, such as profiling. A no-show fee is charged when a venue’s staff mark a booking as a no-show, or — where the venue enables it — automatically when you cancel after the free-cancellation deadline you agreed to at booking; either way the fee and that window are set by the venue and shown to you before you confirm. Loyalty earning and redemption are mechanical consequences of your own actions (a qualifying visit earns; a redemption you or staff trigger redeems) — any manual balance adjustment is made by a named member of the venue’s staff with a recorded reason, never automatically. Rezo, our AI support assistant, answers support questions directly, but it takes no actions on your account and makes no decisions about it — every change stays a click a person makes.

We respond to verified requests within 7 working days. To exercise your rights:

• Tenants: the account owner can download a copy of your data, or close your venue, at any time from Account → Your data, or email [email protected] from your account email to ask us for one (we produce the export and send a secure download link) or to delete your account.
• Guests: contact the venue first. If they cannot help, email [email protected] and we will forward the request. A venue can download or delete a record kept under your mobile number in the same way as one kept under your email address; deleting it removes your name, number and notes from the bookings made with that number (payment records are kept without your details).
• External (non-tenant) senders who have emailed support@, billing@, policies@ or security@ can request access or deletion of their support correspondence by emailing [email protected] from the same address.

You also have the right to complain to the Information Commissioner's Office at https://ico.org.uk/make-a-complaint/.

In short: Analytics and ad measurement cookies are only set with your explicit consent, so a Do-Not-Track browser is covered by default. We do not use your data to show you adverts.

ResoFlow does not use your data to show you adverts or build profiles for ad targeting. Analytics cookies, ad measurement cookies and other optional tracking cookies are never set without your explicit consent through our cookie banner, so a Do-Not-Track browser is covered by default — none of them is set unless you opt in. Ad measurement, if you choose it, only tells Google Ads that a new venue signed up after clicking one of our adverts (see section 6). Our two cookieless monitoring tools, described in the Cookie Policy, set no cookies and don’t follow you across sites. See our Cookie Policy.

In short: We will give 14 days advance notice in-app and by email before any material change takes effect.

For non-material changes (typo fixes, formatting, clarifications) we will update the "Last updated" date at the top of this page without separate notice.

For privacy and data protection matters, email [email protected].

Report a security problem: [email protected]

By post:
Caleonix LTD (Company No. 17162652)
71-75 Shelton Street
London
England, WC2H 9JQ
United Kingdom

Related documents

Please also refer to our main Terms of Service and our Cookie Policy.