Privacy Policy
Last updated: July 2026
This is a draft pending legal review and may change before launch.
This policy explains what data Almenu collects, why, and how we protect it. It is written to align with Saudi Arabia's Personal Data Protection Law (PDPL), and it describes the product as it works today — including the plans on which we collect no diner data at all.
1. Who we collect data from
From restaurant owners and staff who sign in: your name, email address, a password we store only as a salted hash, your restaurant and branch details, and the menu content you create. From diners: nothing that identifies a person unless they place an order at a restaurant whose plan includes ordering (section 2). Diners never create an account with us and are never asked to sign in to view a menu.
2. Order data — and the plans that collect none
Ordering is a paid capability, available on Pro and Enterprise. On Free and Starter there is no cart, no checkout and no order endpoint at all — the menu is read-only — so no diner name, phone number, table number, order note or order history is collected on those plans. Not less of it: none of it. Where ordering is available, an order carries the name the diner types, an optional phone number they may leave blank, the table number encoded in the table QR code if one was scanned, and any note they add. We keep no separate customer database: a regular customer is derived on the fly from the orders that share the same phone number, so a phone number exists in exactly one place — the order it was given on.
3. What we count when nobody orders
On every plan we keep aggregate counters per restaurant — video plays served and AI requests made on a given day, menu photos imported in a given month — used to enforce plan limits and to size our own costs. Each is keyed to a restaurant and a date, never to a person, and holds no content. A diner's cart, liked dishes and chosen branch are stored by their own browser on their own device and are never sent to us. We set no cookie on a menu page and run no advertising or third-party analytics trackers; the only cookie we set is the signed session cookie for a merchant who signs in.
4. The AI assistant
The assistant is available on Pro and Enterprise, and on any account we have granted a trial of one of them. Where it runs, the message a diner types is sent, together with that restaurant's own menu, to Cloudflare Workers AI — a third-party model provider — which runs the model and returns a reply. The conversation is not stored: no message, no reply and no recommendation is written to our database. What we store is a counter: one row per restaurant per day holding a number of requests, which is how the plan allowance is enforced. Our operational logs record the restaurant, the feature used and how long the model took; they never record the message.
5. Voice
Voice is off by default for every restaurant on every plan, and no plan includes it: it is a single per-restaurant switch that only an Almenu operator turns on, for a pilot. Where it is on, the short audio clip is sent to Cloudflare Workers AI for transcription — it is not processed on the diner's device — and the resulting text is answered exactly like a typed message. We store neither the audio nor the transcript: the clip is held in memory for the length of the request and then discarded, and the reply is text. Where a restaurant has not been switched on, the microphone button is simply absent and no audio ever leaves the device. The optional spoken reply uses the device's own built-in speech; when a diner turns it on we record only that the option was enabled at that restaurant, with no identifier and no content.
6. Processors we rely on
Cloudflare — hosting, database, media storage, and AI inference for both the assistant and transcription. A payment gateway (such as Moyasar or Tap) — only for a restaurant on a plan that includes online payments, and only once that merchant enables and configures it. An email provider — transactional email such as address verification and account notices. Google Fonts — when a restaurant chooses a font it serves. Each handles data only to provide its service to us, under its own terms.
7. Trials and internal records
When we grant a restaurant a trial of a paid plan, we record which plan was granted, when it ends, when it was granted, and which of our operators granted it — or that it was granted automatically — together with an audit entry carrying that operator's email address at the time. This is an internal accountability record about our own staff and the account, processed on the basis of our legitimate interest in knowing who granted what. It contains no diner data.
8. How long we keep data
While an account is live we keep its data so the service works. When an account is deleted, deletion is retention-aware rather than absolute: menu content, media, settings, staff logins, usage counters and export bundles are destroyed; past orders are kept for their financial fields but stripped of personal data — the customer name is replaced, and the phone number, table number and notes are removed; subscription invoices and the audit trail are retained for the period tax and accountability law requires; and the restaurant record survives only as an unpublished archive that can no longer be signed into. A data-portability export is available on request, and its download link expires after seven days.
9. Your rights
Under PDPL you may request access to, correction of, or deletion of your personal data, and you may object to certain processing. For data a restaurant collects through its own menu, that restaurant decides what is collected and why and we process it on their behalf — contact the restaurant first and we will help them act on your request. A diner who asks a restaurant to erase their phone number has it cleared from that restaurant's orders: the revenue history survives, the identifier does not. Contact us to exercise these rights and we will respond within the period the law requires.
10. Data security
Passwords are hashed, sessions are signed, and data is transmitted over encrypted connections. No system is perfectly secure, but we design tenancy so one restaurant can never read another's data.
11. Changes to this policy
We may update this policy as the product evolves or the law changes. We'll update the date above and, for material changes, notify account owners.
Questions about this policy? Contact us at hello@almenu.ai.