Privacy Policy

In short: ResoFlow is a trading name of Caleonix LTD, a UK company. We act as the data controller for our own tenants and as a data processor for the diners that tenants serve.

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.

We are a data controller for:

• Tenant accounts (the restaurant business that signs up for a subscription).
• Caleonix's own billing and payment records.
• Site-visitor analytics, cookies, and marketing communications we send to tenants.
• Support tickets and chat transcripts directed to ResoFlow.

We are a data processor for:

• All diner data uploaded by tenants (bookings, customer profiles, history).
• Tenant-side staff data (members the owner adds to their dashboard and PIN portal).
• Outbound communications a tenant sends to its diners through our Resend and Twilio infrastructure.

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

In short: This summary highlights the most important points. Each point links to the relevant section below for the full detail.

• What we collect: account information, contact information, payment information (held by Stripe, not us), booking and dining history, allergies and dietary preferences, and automatic data such as IP addresses.
• How we use it: to provide and improve our Services, process payments, prevent fraud, comply with the law, and (with consent) send you relevant updates.
• Who we share it with: a small set of vetted subprocessors listed at /policies/subprocessors. We do not sell personal data.
• Your rights: you can access, correct, export, restrict, or delete your personal data. See section 12.
• How to contact us: [email protected].

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

Information from tenants (we are controller)

• Owner name, email address, mobile phone number.
• Business name, address, and basic operating details.
• Authentication credentials. Passwords are hashed by Firebase Authentication; we never see your password in plain text.
• 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.
• Plan, usage counters, and audit log of administrative actions.

Information from tenant staff (we are processor for the tenant)

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

• Identity — name, username (chosen by the tenant), 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 — a one-way cryptographic hash of the staff PIN (we never see or store the plaintext PIN), 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 tenant's audit log.
• Preferences — the staff member's chosen theme (light, dark, or system).
• 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 tenant accounts. Staff can view and edit their own optional contact details and theme preference from the staff portal Profile page.

Information from diners (we are processor for the tenant)

• 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. Date of birth is optional and used only for birthday messages where the restaurant enables them.
• Allergies and dietary preferences — see section 4.
• Profile the restaurant 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). This is entered and controlled by the restaurant.
• Activity the platform derives for the restaurant — attendance history (no-shows, cancellations, abandoned waitlist places), lifetime spend on deposits and tickets, average party size, and previous names or phone numbers seen on your profile.
• Event tickets — where a restaurant 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, a device identifier and push token, stored only so we can send updates if the event details change.
• Payments (deposits / no-show protection) — where the restaurant switches these on. Your card is handled directly by Stripe on the restaurant’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).

We do not sell or otherwise disclose diner data outside the strict bounds of delivering the Services to the tenant restaurant. Diners should direct questions to the restaurant in the first instance.

Information from other sources. A restaurant may also give us diner data it already holds, rather than you entering it directly — for example by importing its existing customer or guest list into its account. We process any data imported this way on the restaurant’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.
• Cookies and similar technologies (see our Cookie Policy).
• Camera (event-ticket scanning) — where a restaurant scans event tickets at the door, a staff device may request permission to use its camera to read the ticket’s QR code. No photo or video is captured or stored — only the ticket code is decoded to check the ticket in.
• Cookieless page-performance measurements via Cloudflare — load timings, browser type and country-level location, with no cookies or cross-site tracking.
• Sentry error reports, which may contain user IDs and technical context necessary to debug a fault, plus — on signed-in screens only — a short, fully masked session replay around an error. See our Cookie Policy for the full detail.
• Email engagement — marketing emails sent through the platform contain a small tracking pixel and tagged links that record whether the email was opened and which links were clicked, so the sender can measure how it performed. For marketing a restaurant sends, the restaurant is the sender and we act on its behalf; for the occasional service or product email we send you about your own ResoFlow account, we are the sender. See our Cookie Policy.

Support correspondence

When you contact us via the in-app chat or by emailing support@, billing@ 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.
• Interaction logs from our AI first-line responder (an EU-hosted Google large-language model). Internal model diagnostics are stripped from any data export.

For external (non-tenant) senders who email support@: we also retain the sender email, IP and user-agent on the conversation record so we can reply and identify duplicate or abusive senders.

We use Google sign-in and email/password authentication only. 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 restaurant is the controller and relies on your explicit consent (Article 9(2)(a)); ResoFlow processes it only on the restaurant's behalf.

Allergy and dietary information is treated as special category data under Article 9 of the UK GDPR. The restaurant 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 restaurant to remove it at any time.

ResoFlow processes this information only on the restaurant's instructions, as its processor — displaying it accurately to authorised staff. The restaurant 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 diners, and run their venue.
• To process subscription payments and send invoices.
• Where a restaurant enables deposits or no-show protection: to provide the technical means, through Stripe Connect, for the restaurant to collect a deposit, save a diner's card, or charge a no-show fee on its own Stripe account. A no-show fee is only charged when the restaurant deliberately marks a booking as a no-show (or, where enabled, a late cancellation), never automatically. ResoFlow facilitates the payment on the restaurant's behalf and does not handle the diner's card details; the deposit or no-show fee is paid to the restaurant, although ResoFlow may deduct a platform fee.
• To respond to support requests via the in-app chat and email channels.
• To provide AI-assisted first-line support replies 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 there is no per-tenant or per-conversation persistence at Google.
• 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 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 paying tenant or to handle a booking on behalf of a diner.
• Legitimate interests — cookieless performance monitoring, fraud prevention, error and security monitoring, sending service and booking-related emails (necessary to deliver the Services), the PECR soft opt-in for marketing to a restaurant's existing customers, and (where a restaurant 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, and the special category data covering allergies and dietary needs that a diner chooses to provide (explicit consent under Article 9(2)(a); see section 4). 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 subprocessors that help us deliver the Services. Each is bound by a Data Processing Agreement.

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

• Payment processing.
• Transactional and marketing email delivery.
• SMS delivery (with per-tenant subaccounts).
• 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 our AI support model.
• CDN, DDoS protection, web application firewall, bot management, and cookieless performance analytics.
• Website analytics, error tracking, and uptime monitoring.
• Event-ticket wallet passes (Apple and Google Wallet) — carry the ticket-holder name and event details.
• Address geocoding and autocomplete — business address data only, no customer personal data.

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.

Restaurant-configured integrations (Zapier / webhooks)

Where a restaurant chooses to switch on the Zapier or webhook integration, booking data — including a diner’s name, email address, phone number and any booking notes — is sent to the third-party URL the restaurant configures. The restaurant 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 destination the restaurant 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). Sentry hosts our error data in the EU. Other subprocessors are listed at /policies/subprocessors 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.

Each subprocessor’s data-processing terms incorporate one of these mechanisms.

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.
• Multi-factor authentication available on every account.
• Audit logging of administrative actions.
• Role-based access controls following least-privilege defaults.
• 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. Diners booking a table should be 16 or over. We do not knowingly collect data directly from younger children.

Account holders and their staff must be aged 18 or over. Diners booking a table or buying a ticket should be aged 16 or over; the restaurant is the controller of diner data and is responsible for handling any younger diner’s data appropriately. A diner 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 diner 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 diner, the restaurant you booked with 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 that have a legal or similarly significant effect using solely automated means. A no-show fee is only ever charged when a restaurant’s staff deliberately mark a booking, never automatically; and our AI support assistant only drafts replies for human handling — it does not make decisions about your account.

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

• Tenants: email [email protected] from your account email to request a copy of your data (we produce the export and send a secure download link) or to delete your account.
• Diners: contact the restaurant first. If they cannot help, email [email protected] and we will forward the request.
• External (non-tenant) senders who have emailed support@, billing@ or policies@ 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: We honour browser Do-Not-Track signals where it is technically feasible to do so. We do not use your data for advertising.

ResoFlow does not run advertising campaigns or build profiles for ad targeting. Where your browser sends a Do-Not-Track signal we honour it for the analytics and optional tracking cookies described in 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].

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