Privacy Policy for RefineRack

1. Who we are

RefineRack is software for restaurants in India. It covers digital menus, table and session tools for hosts, waiters, and cooks, bill summaries in Indian rupees (₹), an AI waiter ("Raju"), and a web and WhatsApp concierge used to set up a restaurant. RefineRack is not a restaurant and not a payment provider.

[Counsel: name the contracting party and the data fiduciary. The grievance contact is RefineRack at connect@refinerack.com. If a company will go live, name that company, its GSTIN, and its registered office.]

This policy sits beside the Digital Personal Data Protection Act, 2023. It is not a finished legal opinion on that Act. The restaurant decides why guest and staff data are needed for its service. We process guest data on the restaurant's instructions so the product can run the visit. We decide how we secure the platform, how sign-in works, and how we keep our own account and billing records.

This policy covers the website, the signed-in workspace, the table page opened from a QR code, and WhatsApp messages handled by our concierge.

2. Who this policy covers

• Restaurant operators. A person who signs in with an Indian mobile number and a one-time password, accepts the terms once for a business, and connects a Google account. The phone is the account.
• Staff. Waiters, cooks, and hosts the operator adds. They sign in with an Indian mobile number and a one-time password. They do not accept the commercial terms and they do not connect Google. The operator is responsible for what they do on that workspace.
• Diners. A guest who scans a table QR, gives a name, and uses the one-time code the waiter gives that party. A diner has no RefineRack account. The table flow does not collect a phone number. A person who messages the restaurant on WhatsApp is also covered, because WhatsApp supplies the sender's phone number.
• People who write to us. Anyone who emails connect@refinerack.com or uses the public concierge before a workspace exists.

Staff accounts are for adults. A diner at a table may be a child. We do not knowingly build a marketing profile of a child. The table flow does not ask anyone, adult or child, for a phone number.

3. Data we collect

Operators and staff

• The Indian mobile number used to sign in. That number is the account, for the operator and for staff.
• For an operator who connects Google: the Google account email, name, and profile photo. We open Google's own account picker. We do not read other Google accounts in the browser. The operator tells us whether that Google account is a business account or a personal account.
• The fact and time that the operator accepted a named version of the terms for that business. Staff do not accept the commercial terms, so we do not store a staff acceptance.
• The role the operator assigns (waiter, cook, or host) and the actions that person takes on orders, tables, and bills, so the restaurant has an audit trail.
• Restaurant details the operator enters or that we read from the Google listing the operator picks and confirms as their restaurant: name, address, public phone, website, hours, and photos.
• Menus and files the operator uploads, and the menu draft produced from them.

Diners at the table

• The name the diner gives after scanning the table QR. We do not ask for a mobile number. There is no optional guest-phone field. A waitlist, if used, is name only.
• The one-time code the waiter gives the party. That code locks the table session to that party. It is not a phone login, and it does not create an account.
• Orders, notes, and the bill summary for that visit. The bill is a summary. The restaurant decides what is payable. We do not take card or UPI details and we do not collect payment.
• What the diner tells Raju, including a food preference or allergy they choose to mention. We do not ask for medical records.
• A technical session identifier for the browser that opened the table page. That identifier is not an account.

WhatsApp

If a person messages the restaurant on WhatsApp, WhatsApp itself supplies the sender's phone number, and we receive the message content. The QR table flow still does not collect a phone number. Meta's terms and privacy policy also apply to that channel.

Automatic and support data

• IP address, browser type, device type, and rough time of access, in server and security logs.
• Product usage events. [Counsel: confirm whether Firebase Analytics is enabled in production at launch. If it is, name it here and say what it records. If it is not, delete this bullet before publication. Do not assume any other analytics tool.]
• Messages sent to connect@refinerack.com.

4. Why we use it

• To sign operators and staff in with a one-time password to an Indian mobile number, and to record the operator's acceptance of the terms for that business.
• To open Google's account picker, store the operator's Google email, name, and profile photo, and attach the Google listing the operator confirms.
• To run the workspace: menus, tables, the one-time table code, name-only waitlist, kitchen tickets, and bill summaries in INR.
• To extract menu text from files the operator uploads, and to answer questions through Raju and the concierge. The operator must review AI menu output before guests see it.
• To show the diner's name, orders, table chat, and bill summary to staff of that restaurant. Not to other restaurants. A diner's phone number is not part of the table visit. A WhatsApp sender's number is visible to that restaurant because WhatsApp supplied it.
• To keep an audit trail of staff actions on orders. The operator is responsible for those actions.
• To reply on WhatsApp when someone messages the restaurant there. We do not send marketing messages to diners.
• To detect abuse, debug failures, and protect the service.
• To meet tax, accounting, and legal duties for our own fees. Guest bills are the restaurant's.

We do not sell personal data. We do not use diner chats to train a general-purpose model that we offer to other companies. We send menu text and chat text to Google Cloud, Firebase, and Google Gemini so they can return an answer for that request, and to WhatsApp when that channel is used.

5. Who we share it with

We share personal data only as follows.

• That restaurant's staff. For a table visit they can see the diner's name, orders, table chat, and bill summary. They cannot see a diner phone number from the QR flow, because we do not collect one. They can see a WhatsApp sender's number when the conversation is on WhatsApp. None of this is shown to other restaurants.
• Google Cloud and Firebase. Hosting, database, file storage, and phone authentication for operator and staff sign-in.
• Google account sign-in. When the operator connects Google, we use Google's own account picker. We receive the email, name, and profile photo of the account the operator selects.
• Google Gemini. Menu text and the text of a conversation, so we can extract a menu or draft a reply. Raju can be wrong. Allergy and dietary needs are confirmed with staff.
• WhatsApp (Meta). Message content and the sender's phone number, only when the conversation is on WhatsApp.
• Google Places. If an operator searches for their business, the search query goes to Google.
• Authorities. When the law, a court, or a competent regulator requires it.
• A buyer of the business. If we sell or reorganise the service, under a duty to use the data only for the same purposes.

Some of these providers store or process data outside India. [Counsel: write the cross-border transfer wording against the Digital Personal Data Protection Act, 2023, and any Central Government restriction in force on the publication date.]

6. How long we keep it

We keep data only for the reasons above. The periods are not fixed in this draft. [Counsel: set the retention periods before publication, in particular for the audit trail, diner visit records, security logs, backups, and records kept after a workspace closes. Statutory tax records follow the period Indian law already requires.]

• Operator and staff accounts. The Indian mobile number, role, and, for the operator, the Google email, name, and profile photo, for as long as the account or workspace exists, then for the backup window counsel sets.
• Terms acceptance. The operator's acceptance, for as long as we need to show that the business accepted that version. Staff do not accept.
• Table visit. The diner's name, orders, table chat, one-time code use, and bill summary for that visit, so that restaurant can run and look back at the visit. We do not build a diner account, and we do not keep a diner phone number from the table. We do not match a diner across restaurants.
• WhatsApp. The sender's phone number and the message, because WhatsApp supplied them, for the restaurant's conversation and the retention period counsel sets.
• Audit trail. Staff actions on orders, for the restaurant's operations and for disputes, for the period counsel sets.
• Menus and photos. For the life of the workspace. After the operator closes it, we delete or return them on the schedule counsel sets, except what we must keep for law, security, or a dispute.
• Our fee records. Invoices we must keep under Indian law, for the statutory period.

7. Your rights

The Digital Personal Data Protection Act, 2023, gives people rights to ask about personal data, to correct it, to ask for erasure when the Act allows it, to raise a grievance, and to nominate another person where the rules allow that. This page does not try to restate every rule. Write to connect@refinerack.com. We may need to check that you control the Indian mobile number, the Google email, or the WhatsApp number the request is about before we act.

A diner at the table has given a name and has no account and no phone number on that flow. A request about a table visit may need the restaurant's help, because the restaurant decides why that visit record exists and its staff can see it. We process that guest data on the restaurant's instructions.

Erasure is not always immediate. We may refuse or delay where the law tells us to keep the data, where a dispute is open, or where another person's rights require it. An audit entry that records who did something may be kept with the name removed or replaced if we can do that without breaking the restaurant's record of the action.

You may complain to the Data Protection Board of India after using this grievance path, as the Act provides.

8. Security

Access to a workspace is limited by role. Operators and staff sign in with a one-time password to an Indian mobile number. A diner does not sign in. The waiter's one-time code locks that table session to that party. Table sessions are separated by restaurant and table. Database rules reject client writes that the role is not allowed to make. No method of transmission or storage is perfectly secure. If we learn of a personal-data breach that the Act requires us to report, we will tell the Board and affected people as the Act requires.

9. Cookies and similar storage

We use browser storage that the service needs in order to keep an operator or staff member signed in, to remember a table session, and to protect sign-in, including fraud checks from our authentication provider. We do not use advertising cookies. The only analytics question in this draft is the Firebase Analytics note in section 3.

10. Changes

We will post the current policy on this page and change the date. A material change to the commercial terms is accepted again by operators only, not by staff. Diners have no account. Their table visit is covered by the policy on this page when they use the QR.

11. Grievance contact

Questions, correction requests, and grievances:

• Email: connect@refinerack.com