Privacy Policy

Last updated Jul 29, 2026

In short

The hotel decides what guest data it records; we store and protect it on the hotel's behalf. We do not sell it, do not use it for advertising, and erase it 30 days after an approved deletion request. Guests can ask the hotel about their data, and the hotel can act on that request inside the app.

1. Roles

For guest and staff data entered into the Service, the hotel is the data controller and Anyname Hotel is the data processor acting on its instructions (KVKK: veri sorumlusu / veri işleyen; GDPR: controller / processor).

For the hotel's own account and billing records, for support messages sent to us, and for enquiries submitted through the public website, Anyname Hotel is the controller.

As a processor we act only on the hotel's instructions, given through the Service or in writing. We do not use guest data for our own purposes, do not sell or rent it, do not use it for advertising or profiling, and do not use it to train machine-learning models.

2. What is stored

Held for the hotel, as its processor:

Guest records: name, email, nationality, identity or passport number, date of birth, phone, notes the desk adds, and any VIP or blacklist flag the hotel sets.

Stay records: room, dates and times, number of people, rate, folio charges, payments and their method.

Company and agency records (Cari): company name, tax number, the name, phone and email of the contact person, and notes.

Staff records: name, username, role, and an action log of what each account did (check-in, payment, correction, room status), with the account name and time.

Property records: hotel name, legal name, address, contact details, currency, check-in/out times, and the hotel's own KBS credentials where the integration is used.

Where the hotel switches on the Telegram check-in bot: the Telegram chat identifier, user identifier and username of the people linked to it, and whatever a guest types into the bot while a check-in is in progress.

Staff invitations, where used: the email address invited and whether the invitation was taken up.

Held by us, as controller:

Enquiries sent from the public website: name, hotel name, phone, city and the message written, so we can answer and follow up.

Support messages sent from inside the app: sender name, the reply address given, the topic, the message, and which property it came from.

Account-closure requests: who asked, when, any reason given, and our decision.

Data-export requests: who asked, when, the reason given, our decision and any note, and whether the approved download was used.

Licence and billing references for the property. If card payment is ever enabled, cards are handled by the payment provider and we keep only its reference, never the card.

No card numbers, CVVs or bank credentials are stored anywhere in the Service: payments are recorded as an amount and a method (cash, card, transfer, mobile), not as card data.

3. Why it is stored

To run the property: assigning rooms, billing stays, reconciling the till, and showing management what happened.

To meet the hotel's legal duties, including identity reporting to the Turkish authorities (KBS) and keeping accounting records for the statutory period.

To keep the Service secure and to investigate misuse, using the action log.

To answer enquiries and support messages, and to keep a record of what was asked and what we did about it.

Nothing in the Service makes an automated decision that produces a legal effect for a guest or a member of staff. Flags such as VIP or blacklist are set by the hotel's own people, not by us and not automatically.

4. Who it is shared with

Supabase (hosting, database and authentication) and Vercel (application hosting) as our infrastructure providers, under their own data-processing terms.

The Turkish authorities, through the hotel's own KBS account, where the hotel enables identity reporting.

Telegram, only where the hotel switches on the optional check-in bot, and only for the messages that flow through it.

An email delivery provider, only for support messages sent to us from inside the app, and only for the contents of that message. Guest records are never sent by email.

Nothing is sold, rented, or used for advertising or profiling. Nobody outside these providers receives guest data unless the hotel instructs it or the law compels it.

If we add or change a provider that handles hotel data, we tell the owner account before it starts, so the hotel can object or leave before it takes effect.

5. Who at Anyname Hotel can see it

Our platform console can list properties, their licence state and their usage totals. A small number of our staff can also reach a property's records where it is genuinely necessary — to investigate a fault the hotel has reported, to restore data, or where the law requires it.

That access is limited to the people who need it, is used only for those reasons, and is not used to read guest records out of curiosity or for any commercial purpose. We do not sign in to a hotel's own account without asking the hotel first, except where we must to stop a live security incident.

6. If something goes wrong

If we discover a breach that affects a hotel's data, we tell the owner account without undue delay once we have enough to describe it — what happened, which data is involved as far as we know, what we are doing about it, and what the hotel should do.

As the data controller, the hotel is the one that reports to the Personal Data Protection Authority (KVKK) and, where required, to the people affected. We give the hotel the information and help it reasonably needs to do that inside the deadlines that apply to it. Where we are the controller — enquiries, support messages, account records — we report it ourselves.

7. Where it lives

Data is hosted in Supabase and Vercel data centres, which may sit outside Türkiye. Under KVKK art. 9 a transfer abroad needs its own lawful ground; we rely on the written undertakings and standard contractual terms in place with those providers, and a hotel may ask us which ones apply to it.

A hotel that needs its data to stay in a particular region should raise it before onboarding, so we can tell it whether we can meet that.

8. How long it is kept

Guest and stay records stay until the hotel deletes them or closes its account. Accounting-relevant records are kept for as long as the hotel's own retention duty requires.

Closing an account happens in stages. The hotel sends a deletion request; we review it; if we approve it a 30-day waiting period begins from the moment of approval, during which nothing is deleted and the hotel can still cancel. When those 30 days end, the hotel's rooms, guests, reservations, folios, payments, tasks, action log and staff logins are erased from the live database, and roll out of encrypted infrastructure backups within a further 30 days.

If a licence expires or is suspended for non-payment, the data is kept for 90 days from expiry so that renewing restores it, and may be deleted after that.

Website enquiries are kept for 24 months from the last contact, unless the sender asks us to delete them sooner. Support messages are kept for 24 months so we can see the history of a problem. Account-closure and data-export requests, with our decision on them, are kept for 5 years as proof of what was asked and what we did.

Identity reports already transmitted to the authorities live in their systems, not ours, and cannot be recalled by closing an account here.

9. Security

Access is authenticated per staff account and separated by role. Every property's rows are isolated at the database level (row-level security), so one property cannot read another's. Traffic is encrypted in transit and data is encrypted at rest by our infrastructure providers. Operational actions are written to an append-only log.

10. Guest and staff rights

Under KVKK art. 11 and the GDPR, a person can ask whether their data is held, ask for a copy, ask for corrections, ask for deletion, and object to processing.

Guests should address the hotel that recorded their stay: it holds the relationship and can view, correct or delete the record itself in the app. If a request reaches us first, we pass it to the hotel and help them act on it.

Staff of a property, and hotels asking about their own account, can write to support@anynamehotel.com.

11. Cookies and tracking

The Service sets only what it needs to work: a session cookie for staying signed in, plus browser storage for the chosen language and light/dark theme. There are no advertising or cross-site tracking cookies.

12. Children

The Service is a staff tool and is not offered to children. A guest record may include a minor travelling with their family, because accommodation law requires it; the hotel is responsible for that data like any other guest record.

13. Changes

Updates appear at this address with a new date. Material changes are announced to the owner account of each property before they take effect.

Questions

Write to us at support@anynamehotel.com and we will answer within 30 days.

support@anynamehotel.com