Privacy information

Andrej Fröhlich operates WaitBeam as a natural person: Friedrich-Engels-Platz 9/2, 1200 Vienna, Austria. Contact for this service and privacy requests: support@waitbeam.com. No data protection officer has been appointed.

Andrej Fröhlich is the controller for the WaitBeam website, business-account administration, existing pilot application records, service security and direct support. The fact that this is a privately organised pilot does not exclude the application of the GDPR and Austrian data-protection law.

For a business’s guest queue, the business decides why its guests are served, which services it offers and how requests are handled. The business is the controller for that processing; WaitBeam provides the technical service on its instructions as a processor. The business identified on the queue page must provide its own controller contact and guest privacy information. This notice explains WaitBeam’s part and does not replace that business’s notice.

WaitBeam is currently in private development and is being prepared for closed pilot testing with selected businesses. Public registration and commercial availability are not yet open. This notice applies in full nonetheless: invited pilot accounts exist, and account, queue and guest data is processed as described below whenever the service is used.

Opening a page transmits the IP address, requested address, time, browser/device information and technical connection data to Cloudflare so that the page can be delivered and attacks can be detected. A personal guest or legacy setup link may include a bearer token in its address. WaitBeam does not deliberately record these complete addresses in application logs; persisted Worker invocation logging is disabled. Cloudflare nevertheless processes network data and operational metrics to deliver and protect its infrastructure.

The legal basis for necessary website delivery and protection against misuse is Article 6(1)(f) GDPR. Our interests are providing a functioning service, protecting accounts and preventing automated attacks. The data is not used by WaitBeam for advertising or cross-site tracking.

The application derives SHA-256 rate-limit keys from request network signals and, for certain account actions, normalised account identifiers. It stores the key, counters and expiry rather than the raw IP in these limiter records. Hashing does not make this data anonymous. A shared D1 counter restricts guest joins to eight attempts per minute; account and pilot-request actions have separate temporary limits. Stale limit records older than 24 hours are removed by hourly cleanup once their cooldown has expired.

Public access requests are currently closed. The request form is not published and the endpoint rejects submissions, so no new access requests are being collected. Access requests stored from earlier submissions remain subject to the retention rules in section 7. Accounts for pilot businesses are prepared by the operator; the website offers no way to create one.

An access request contains the business name, email address, optional business type, processing status, and version/time of the privacy-notice acknowledgement. Business accounts also hold an optional personal display name, hashed password credential, account/session records, and business, location, service and queue settings. Passwords are not stored as plaintext.

Application assessment, account setup and service provision are based on Article 6(1)(b) GDPR where you apply for or use the service as an individual contracting party. For employees or representatives of a business, Article 6(1)(f) applies: our and the business’s interest in administering the business relationship and communicating with its authorised contacts. Optional display names support the personal interface you request under Article 6(1)(f). Security checks and administrator action records rely on Article 6(1)(f), to protect access and investigate misuse.

We receive these details from you or from the business/operator who arranges your pilot participation. Where an administrator prepares an account, the account details originate from that arrangement; this information must also be provided with the first setup communication. The application acknowledgement records that the notice was presented; it is not consent to advertising or a blanket consent to processing.

The business name and account email are needed to assess and provision access; a password is needed to activate and use an owner account. Without them, those functions cannot be provided. Optional fields may remain empty. There is no statutory obligation to apply for the pilot.

Owners may optionally publish a business logo on their public guest queue and ticket pages. The browser resizes and re-encodes the selected image; the server validates it and removes ancillary image metadata. WaitBeam stores the small public image and its technical dimensions/hash with the business in Cloudflare D1, until the owner replaces/removes it or the account is deleted. Turning off “Show logo on the customer queue screen” hides it publicly without deleting the stored copy; its preview remains accessible only to the signed-in owner. The original upload and its filename are not stored. This is part of the requested business presentation on the account-administration bases described above.

If you expressly accept a pilot agreement in account setup or Settings, WaitBeam stores the business ID and name, its legal name and postal address, the document type/version and SHA-256 hash, the acting owner’s user ID and email, the actual acceptance time and method. These records establish which agreement was accepted and by whom, on the contract-administration bases described above. Legal name, address and an express declaration of authority are required for this acceptance; a privacy-notice acknowledgement does not replace it. No IP address or user-agent evidence is collected for agreement acceptance.

A setup invitation uses a one-time link valid for 72 hours. The database stores its token hash. Reissue invalidates the earlier invitation. Administrator records document the actor, action, affected user/business identifiers and time, without passwords or recovery links.

For the first 1–5 accompanied free pilot businesses, email support is limited to administrative communication, scheduling, general usage questions and synthetic steps to reproduce an issue. Do not send real guest data, queue/guest screenshots containing personal data, personal status/setup/reset links, passwords, sessions or tokens. Confidential recovery, privacy and incident cases use a suitable private channel separately confirmed with each pilot business. An initial email can ask to arrange that channel without including confidential case details.

Owners of completed accounts contact support. After manually checking identity, an authorised SUPER_ADMIN generates a normal Better Auth reset link and privately delivers it to the owner. The owner alone chooses and submits the new password. Incomplete accounts use setup-link reissue instead. Password recovery does not reactivate a suspended business or extend pilot access.

The reset link is valid for 15 minutes and can be used once. WaitBeam persists a hashed verification identifier, not the raw reset URL. The URL is shown temporarily only in the authorised administrator response and is not placed in audit metadata or analytics. The reset page removes the fragment from its current address after reading it. A successful reset revokes existing sessions; the owner then signs in normally. Another already-issued link remains valid until it is used or expires.

Support processes the sender/contact details, message, time and information needed to resolve the request and verify account ownership. Never send a password, guest list, sensitive service details or unnecessary identity-document copies. Password recovery and contract-related support use Article 6(1)(b) for individual customers; contact-person administration, general enquiries and protection against account takeover use Article 6(1)(f). Requests to exercise statutory data rights are handled under Article 6(1)(c), in conjunction with Articles 12–22 GDPR.

Guests do not need accounts. The business and WaitBeam process an optional display name, service, party size, request/queue status, ticket number once admitted, estimated duration, operational timestamps and queue events. A random personal access token permits access to that entry; a separate random submission key prevents duplicate retries, with only its hash stored on the server. The service and party size are needed to submit the request; the display name may be omitted or be a pseudonym.

The personal status link should be kept private: a person possessing it may be able to view and operate that guest entry. Other guests do not receive the staff view or a list of guest names. Authorised staff handle the business’s requests and queue. Technical support access is limited to what is needed for an authorised support or security task.

For its guest service, the business determines and explains its legal basis, for example necessary steps towards providing a requested service under Article 6(1)(b), or a documented legitimate interest in organising walk-in service under Article 6(1)(f). WaitBeam processes these guest records on the business’s instructions; Article 28 is the basis for the processing arrangement, not a replacement for the business’s Article 6 legal basis.

WaitBeam does not ask guests for an email address, phone number, precise location, marketing profile or free-text note. Do not enter health information or other sensitive personal information in a display name or service label. WaitBeam is not designed to manage medical or similarly sensitive queues.

Cloudflare, Inc., USA, provides hosting, DNS/CDN, Workers, Durable Objects, D1 and incoming Email Routing. For customer content it acts as a processor or sub-processor under its data-processing terms. The D1 databases and Durable Object namespace are configured for EU jurisdiction. This does not mean that all network, security, support or email processing takes place exclusively in the EU.

Cloudflare’s Self-Serve Agreement incorporates its Data Processing Addendum. Its transfer terms refer to the EU–US Data Privacy Framework for covered transfers and to EU standard contractual clauses for restricted transfers (controller-to-processor or processor-to-processor as applicable). Availability of these terms is distinct from the operator’s duty to document the applicable contract, service scope and safeguards.

Messages to support@waitbeam.com are received through Cloudflare Email Routing and forwarded to an operator-controlled Gmail inbox. This temporary pilot channel is restricted to the administrative contents described above; it is not approved for guest-data support or delivery of personal links. Google receives the sender, recipient, subject and message body, which can contain personal contact data even in administrative correspondence. Google Ireland Limited generally provides consumer services for users in the EEA, with Google LLC and other recipients involved under Google’s privacy terms. Consumer Gmail is not represented here as an Article 28 processor: Google does not offer a data-processing agreement for that consumer service.

Google describes processing outside the EEA, including the USA, and transfer mechanisms such as the EU–US Data Privacy Framework and standard contractual clauses. Google’s own purposes and storage practices are described at policies.google.com/privacy and policies.google.com/privacy/frameworks. Cloudflare’s terms are available at cloudflare.com/cloudflare-customer-dpa and its current recipient list at cloudflare.com/gdpr/subprocessors. You may ask support@waitbeam.com for information about the safeguards applicable to WaitBeam.

The queue’s business receives its own guest and operational data. Authorities or legal advisers receive personal data only where a concrete legal duty or the necessary establishment, exercise or defence of claims requires it; the corresponding basis is Article 6(1)(c) or, for legitimate claims, Article 6(1)(f). WaitBeam does not sell personal data. Automatic Cloudflare Email Sending, advertising and payment processing are disabled in this manual pilot.

Business sessions expire after seven days and can be renewed during use; signing out ends the current session. Active account and business records remain for the service relationship until the account/business is deleted. Suspension or pilot expiry alone does not delete an active account. The account-deletion function requires a recent sign-in and removes the owner account and associated business data from the active database.

Pending and rejected access requests are deleted once they are 90 days old. Abandoned setup is removed 90 days after the latest unused invitation expires, including the inactive owner/business preparation. After completed setup, access-request/invitation metadata is removed after 30 days. These rules run hourly.

After an entry becomes done, no-show, left, removed, business-cancelled, declined or withdrawn, the hourly job removes its name, personal access token and submission-key hash once that status is more than 24 hours old. With successful scheduled runs, this occurs after 24–25 hours. Unanswered walk-in requests and their linked events are deleted after 24 hours by the hourly job. Active waiting/called entries remain until their operational status ends; closing a browser does not end them.

Service, party-size, timing, ticket and status records and related events remain for the business’s operational history and summaries until its data is deleted. Removing a name/token is not a guarantee of irreversible anonymisation: a small business may still associate times or services with a person. These residual records therefore remain subject to data-protection requirements; there is currently no separate automatic age-based deletion for them.

Consumed password-reset verification records are removed. Unused expired records await later Better Auth cleanup; the 15-minute validity is not a promise of physical removal at that time. The administrator view clears the link on close, page departure or expiry. Clipboard, browser history and correspondence copies are separate and may remain longer.

Support correspondence currently remains in the mailbox until manually deleted; administrator audit records have no automatic deletion period. The relevant retention criteria are completion of the specific enquiry, continued need to establish the handling of an account/security incident, and any identified legal claim or binding preservation duty. These are separate from the hourly queue cleanup; this notice does not claim that it deletes mail or audit records.

Agreement records remain in the account while the business exists and are removed from the active database when it is deleted. Both parties can download the fixed agreement and acceptance record before deletion. Separately retained operator copies are reviewed at contract end and held only for a documented contractual/legal evidence purpose, until that purpose or a specific applicable preservation obligation ends. They are not part of the guest history or hourly cleanup.

Deletion from an active database does not instantly erase earlier backups. Cloudflare documents a seven-day D1 Time Travel window on Workers Free; a restored backup can contain earlier data and requires reapplying intervening deletions. Google’s retention rules distinguish deletion from the product and subsequent removal from its systems/backups. We cannot delete a recipient’s mailbox or browser history. Where a specific law or live claim requires a limited record to be preserved, only the necessary record is retained for that purpose, not the whole account or guest history.

Under the conditions of the GDPR you may request access, correction, erasure or restriction. Where automated processing is based on your consent or a contract, you may request the data you provided in a structured, commonly used machine-readable format and, where feasible, its transfer to another controller. If processing is based on consent, you may withdraw it for the future without affecting the lawfulness of earlier processing.

Right to object: where we rely on Article 6(1)(f), you may object at any time for reasons relating to your particular situation. We will stop that processing unless compelling overriding grounds or the establishment, exercise or defence of legal claims justify continuing it. WaitBeam does not use your data for direct marketing.

Send a request to support@waitbeam.com or the postal address above. We normally answer without undue delay and within one month. Where the GDPR permits an extension because of complexity or number of requests, we will explain it within that month; the extension is at most two further months. Reasonable identity doubts may require proportionate additional information; a passport copy is not routinely required. Requests are normally free of charge.

For records processed on a business’s instructions, contact that business or ask us to help direct your request. The business is responsible for deciding it; we assist it. We do not collect extra identifying data merely to reidentify records we can no longer associate with you.

You can complain to a supervisory authority, in particular in your place of habitual residence, work or the alleged infringement. In Austria: Österreichische Datenschutzbehörde, Barichgasse 40–42, 1030 Wien, Austria; dsb@dsb.gv.at; dsb.gv.at. You do not have to contact us first.

WaitBeam does not perform profiling or solely automated decisions producing legal or similarly significant effects within Article 22 GDPR. Staff decide whether to accept a guest request and may change its estimated duration. Queue positions and ETAs are operational calculations and estimates; they do not guarantee when service will begin. Automated security limits may temporarily prevent further requests.

The cookie and browser-storage mechanisms below support the functions you request. WaitBeam relies on the exemption for strictly necessary storage under section 165(3) Austrian TKG 2021, not advertising consent. Language/theme preferences are stored only after your selection. You can remove them through browser settings; doing so may end your session or remove same-device recovery. No advertising, cross-site tracking or behavioural-analytics consent is collected.

This notice describes the current manual pilot. We will update it before materially changing purposes, recipients or optional tracking and provide any required further information or consent choice. Last updated: 7 September 2026.