Skip to content
VELNIO

Draft — legal review required before launch

Not final, not legally reviewed and not presented for acceptance. No legal compliance or security guarantee is claimed. All bracketed placeholders must be resolved before launch.

Privacy Policy (draft)

For business owners, team members and visitors to customer-facing demos. This describes behavior visible in the current application code, not a complete audit of hosting or a policy for an active public booking service.

Unconfirmed operator details

Platform operator / legal entity
[TO COMPLETE — legal name and registration details]
Operator address
[TO COMPLETE — registered / correspondence address]
Privacy and service contact
[TO COMPLETE — monitored email / contact channel; none designated in this draft]
Privacy officer / DPO
[TO COMPLETE — determine whether appointment is required; name and contact if applicable]
Effective date and policy version
[NOT SET — draft has no effective date or final policy version]
Booking business identity (future real bookings)
[TO COMPLETE PER BUSINESS — name, address, contact and applicable business policy]

1. Current service and demo boundary

The signed-in business workspace uses Lovable Cloud for accounts and business records. The public booking, scripted assistant, waitlist, live queue and CRM previews are demos, not live booking or messaging services. A mock confirmation does not create an appointment in the internal calendar.

Use fictional details only in demos. This draft does not obtain consent or activate any future service.

2. Information handled by the business workspace

Account forms submit an email and password to the authentication service; signup also submits a display name and preferred language. Google sign-in is offered in the interface, but provider settings and the precise returned data have not been verified for this draft. Do not assume the sign-in option is configured for launch.

Workspace features handle business profile/contact details, services and prices, team membership and staff details, working hours and closures, customer names, optional phone/email and notes, reminder/marketing preference flags, and appointment details such as customer, service, provider, time, status and notes. Business users enter these records to manage their work. Do not enter unnecessary sensitive information in free-text notes.

The interface stores reminder and marketing preference flags on customer records. A flag alone is not proof of legally valid consent; no complete notice-version, source or withdrawal history has been verified. No automated reminder or marketing message is sent by these features today.

3. Demo input and photo previews

Booking demo forms and scripted chat hold entered text and synthetic booking/waitlist state in browser memory, without a production booking transport. The opt-in QA booking prototype keeps name/phone locally, excludes them from the mock protocol and clears them on reset or successful mock confirmation. Reloading discards this in-memory demo state; these are not real customer records.

Staff photo preview uses temporary in-memory object URLs. Previewing or applying a crop does not upload or save a staff photo. URLs are released on replacement, cancellation or leaving the preview. Demo provider portraits are fictional illustrations.

4. Browser storage, cookies and external requests

The code uses localStorage for language (abm.locale), the selected business and per-business tour completion. Authentication is configured to persist a session; outside the editor preview it uses browser localStorage, while the editor preview can use its session broker. Existing language controls can also save language to a signed-in profile; the language control on these legal drafts changes only the local preference.

A shared sidebar component contains code for a sidebar-state cookie; whether it is used on every deployed page is not established. Browser preferences have no application-defined automatic expiry in the reviewed code. Clearing site storage can remove preferences and the locally stored session and may require signing in again; it does not delete business records in Lovable Cloud.

Pages load Google Fonts from Google domains, which involves external browser requests and their normal connection metadata. Error-reporting code can forward an error message, stack and page path to available Lovable reporting hooks. Hosting logs, additional platform telemetry, cookie inventory, destinations, retention and data location have not been fully audited. No claim is made that visiting a demo produces no network traffic or that the site is cookie-free.

5. Access and service providers

Appointment access is designed so owners/managers see business appointments, staff see full details of their own appointments and other staff time appears as anonymous busy blocks. Customer-record permissions are a separate unresolved launch blocker: current staff access is broader than the intended restriction. Do not rely on a claim that every customer record is already restricted to its assigned staff member.

Lovable Cloud is used for authentication and business data; Google Fonts and the optional sign-in path are described above. Public demo features do not call a live AI, payment, WhatsApp, SMS or automated customer-notification service. Authentication emails are distinct from booking notifications: account code requests signup/reset emails, but delivery and hosted settings were not verified here.

6. Retention, requests and security — unresolved

Draft — legal review required before launch

[TO COMPLETE — retention periods for accounts, customers, appointments, notes, consent evidence, logs and backups; deletion exceptions and backup expiry.] No automated record-deletion schedule has been verified. Removing a record in the interface is not evidence of erasure from backups or all processors.

[TO COMPLETE — verified channel and identity checks for access, correction, deletion and consent withdrawal requests; response process and legally applicable timeframes.] This page does not submit a request. Applicable rights depend on law and circumstances; they are not promised by this draft.

Encryption controls, incident response, recovery and independent backup integrity have not been verified for this draft. It contains no security guarantee and no assertion of GDPR or Israeli-law compliance.

7. Before real public booking

Draft — legal review required before launch

[TO COMPLETE BEFORE ACTIVATION — operator/business responsibilities and legal basis, required vs optional fields, just-in-time notice, retention, secure appointment-scoped access, verified consent/withdrawal and notification providers.] Real booking is not active. Final notices must name the business receiving the booking and explain what is shared before any real details are submitted.

[LEGAL REVIEW REQUIRED — applicable jurisdictions, controller/processor allocation, provider agreements, cross-border transfers, sensitive data and minors, and notice updates.] Neither language version is a final policy or takes precedence yet.

Draft — legal review required before launch