Security and data
Your restaurant's guest list: where it lives and who can see it
Your bookings and your guests' details are stored in a database in London. Five named providers help us run the service, and your restaurant stays in charge of its guests' data from the first booking to the last.
Who is responsible for what
Data-protection law asks one question first: whose data is it? For your guests, the answer is yours.
Your restaurant: the controller
Guests book a table with you, so their names, contact details and booking history are your restaurant's. You decide what is kept and why, and you answer to your guests for it.
Slotora: the processor
Belavin Limitedstores and processes that data to run the service for you, on your behalf. Your guests are your restaurant's guests, not ours.
For your own account with us (your login, your subscription, your invoices) and for the early-access list, Belavin Limited is the controller; the privacy policy linked at the foot of this page covers that.
The providers that touch the data
The restaurant product uses these five. Text messages are not part of it.
- Neon hosts the database, in London (United Kingdom). It sees everything stored: bookings, guest cards, the floor plan, the settings.
- Netlify runs the application and serves the pages. It sees the data passing through as each page is built and sent.
- Resend sends e-mail. It sees the recipient's name and address and the message itself.
- Cloudflare checks that a form is filled in by a person and not a script (Turnstile). It sees the visitor's IP address and browser signals, never what is typed into the form.
- Stripe takes the restaurant's payment for its Slotora subscription. It sees the card details, entered on Stripe's own page; they never reach us.
How it is protected
- Every page and every connection is encrypted (HTTPS, with browsers told never to fall back to an unencrypted connection), and no other site can show Slotora inside its own frame.
- Passwords are stored only as one-way hashes; nobody at Slotora can read yours.
- Card numbers never reach our servers: they are typed into Stripe's page and stay with Stripe.
- Every change in the restaurant is recorded with who made it, and the record is kept for two years, so a moved booking or an edited guest card can always be traced.
- Each restaurant sees only its own bookings and guests. Several tablets and phones in one restaurant share one live floor.
- Every member of staff signs in with their own login, as host stand or manager, and the owner removes it the day they leave. Nobody needs the building's shared password, so access ends with the person.
- Allergy, diet and access notes on a guest card are written by your staff. The guest's table booking form has no field for them, only an optional note on that booking, so you hold what the guest chose to write and what your team chose to note.
When a guest asks what you hold about them
It is your guest and your answer to give, so the tools are on your side of the screen.
- Open the guest's card — from a name in the guest book or from one of their bookings — and export their record: their details and their bookings, ready to send.
- If they ask to be forgotten, erase them from the same card. The download and the erasure are there for the owner or a manager; a host-stand login does not even see the guest's e-mail and phone on the card.
- Guests can opt out of messages with one click.
- The whole guest book can be exported as a CSV file by the owner or a manager, and nobody else. Its mailing export holds only the guests who said yes to marketing; Slotora sends no marketing of its own.
The restaurant terms of service and the data processing agreement are being written now and will be published before any restaurant can sign up. Until then, questions about any of this go to hello@slotora.io.
More: the guest book and GDPR requests · guest data and consent when you change systems · the company behind Slotora · hear when it opens