Privacy Policy

1. Who we are

Alfred Ops Limited (“AlfredOps”, “we”, “our”) is a company registered in England and Wales, company number 16973220, whose registered office is at 10 Putney Park House, 69 Pleasance Road, London SW15 5HJ. We are registered with the UK Information Commissioner's Office under reference ZC155617. We provide an operations intelligence platform for the hospitality industry. For any privacy-related enquiries, please contact us at info@alfredops.com.

We are not required to appoint a Data Protection Officer, and have not appointed one. We are established in the UK, so we are not required to appoint a UK representative either. Privacy enquiries reach us at the address above.

2. Who this policy covers

It covers three different groups of people, and the answers are not the same for all of them.

• Website visitors: people who use alfredops.com and may send us a request-access enquiry. Sections 3 and 4.
• Staff who use the product: employees of a hospitality business that holds a contract with us, using the web app or the iOS app. Sections 5 to 12.
• Guests of our customers' venues: people whose bookings, feedback or public reviews reach the product through the systems their restaurant has connected. Section 13.

AlfredOps is an employee app, not a consumer product, and there is no self-service route in. Sign-up at our authentication provider is restricted to invited addresses, so an account cannot be created at all unless your email address has been invited first, either by an administrator at your employer or by us at their request. The provider's user directory therefore holds only people who have been invited to a workspace, and it is the invitation rather than the sign-up that creates any access to your employer's data.

For staff data, our customer (your employer) decides what is collected and why, and we hold and process it on their instructions. Our customer contracts make this explicit: the customer is the controller and we are the processor, under data processing terms intended to satisfy Article 28 of the UK GDPR. We process personal data only on the customer's documented instructions, we keep the people who handle it under confidentiality obligations, and we are committed to assisting the customer with data-subject requests and with their own security, breach-notification and impact-assessment duties.

A request about staff data therefore goes to your employer first. They can act on your record directly, and we support them. If you send a request to us, we will help your employer answer it or route it to them. Section 11 sets out what we can and cannot do ourselves.

The lawful basis for that processing is your employer's to set, and it is their own employment documentation rather than this page that states it. For our current customer, staff data is processed to perform your contract of employment, to meet legal obligations such as tax and statutory benefits, and, less often, in their legitimate interests in measuring things like absence levels across the workforce. Where the data falls into a special category, an absence recorded as sickness being the obvious one, they rely on the grounds available to an employer for carrying out obligations and exercising rights under employment law. Other customers may rely on different bases, and their own staff documentation will say so.

3. Website visitors: what data we collect

The request-access form on our website has a single field: your work email address. Submitting it does not send anything to our servers. It opens a message in your own mail application, addressed to info@alfredops.com, with the address you typed in the body.

So what we receive is whatever you choose to send from your own mailbox: your email address, your name as your mail provider presents it, and anything else you add to the message before you send it. The website itself stores none of it.

We do not run analytics on the website. There is no analytics package, tag manager, tracking pixel or advertising script in the site's code, and we set no advertising cookies. Serving any website does produce ordinary request logs at the hosting layer; those sit with our hosting provider (Vercel, section 9) rather than in anything the application stores.

We are on Vercel's Pro plan with extended observability switched off and no log drain configured, so those logs are held for around a day and then roll off. They go nowhere else, and we do not query them for anything to do with you.

4. Website visitors: how we use your data

We use the personal data you provide to:

• Respond to your enquiry about our product
• Provide you with information about AlfredOps and our services
• Communicate with you about product updates and availability

We will not send you unsolicited marketing communications without your explicit consent. You may opt out of any communications at any time by contacting us.

We do not sell or rent your personal data, and we do not share it with third parties for their own marketing purposes. The providers that handle data on our behalf are listed in section 9; where it is stored is described in section 10.

5. Staff data: what the product holds

The list below describes what the product actually stores about a member of staff. Not all of it applies to every customer; most depends on which systems your employer has connected.

Identity and account

• Your name and email address, held in our authentication provider's user directory, plus the display name, profile photo, language and timezone you set inside the app.
• A workplace record: your email address, your role level, your job title, the sites and brands you are allowed to see, your account status, and the date you were invited.
• Your mobile number, where your employer has connected their rota system and uses text-message invites. It is kept in a separate, deliberately minimal file that holds the number and the workforce ID your employer's rota system uses for you, and nothing else: no name, email, address or any other field can be written into it. That ID is pseudonymous, not anonymous. It does not carry your name, but the reconciliation record in the next bullet can resolve it to you.
• Where your employer has connected their HR, rota, point-of-sale or training systems, a reconciliation record linking the different identifiers those systems use for you: your employee ID, your work email, your site, your job title, whether you are recorded as a leaver, and the spellings of your name each system holds.

Work and performance

• Shift and clock records pulled from your employer's rota system. Each record holds your employee ID and name, the site, whether the shift was front of house or kitchen, your job title, your contract type and the shift type, the shift date, the scheduled start and end, the shift length, the actual clock-in and clock-out timestamps, and how many minutes early or late each of those was against the schedule. It also carries any exception the rota system flagged (a missing clock-in or clock-out, a late or early clock-in or clock-out, or a clock-in or clock-out with a mismatched or missing location), the reasons recorded against those, and any comment left on the shift. The same records are rolled up into a monthly per-person summary.
• Performance measures derived from your employer's point-of-sale and guest-feedback systems, such as spend per head and dish-level feedback attributed to the person who served the table.
• Absence recorded by your employer's rota system, by category (for example holiday, sick or maternity), used to separate paid-but-not-worked time from worked time.

Nothing in AlfredOps makes a decision about you on its own. What the product produces is a measure, a summary or a suggestion; the decision that follows is your manager's, made with their own judgement and the rest of what they know.

An absence category of sick or maternity is data concerning health, so it is a special category, and our data processing terms have been amended to say so rather than to claim that none is processed. We hold it on your employer's instruction and under their basis for it, described in section 2.

Pay information

To calculate labour cost, the product reads a pay rate for each pay line from your employer's rota system. The cost figures it writes and keeps are a site-level daily total: hours, cost, headcount and the front-of-house / kitchen split. There is no per-person wage record: no rate, no pay, no cost is stored against you.

Alongside that total we keep the actual clock-in and clock-out times from those same pay lines, against the workforce ID your employer's rota system uses for you. Your employer's rostered times were already held (section 5); this is what was actually worked rather than what was planned. It is kept so that patterns a manager should act on, a shift running long after the last guest left, or someone repeatedly working with too little rest between shifts, can be seen at all. As everywhere else in this product, what it produces is a measure or a suggestion; the decision is your manager's.

No record the product writes contains bank details, a National Insurance number or a date of birth. Those fields sit next to the ones we do read in the source system, so the one file that comes closest to them is defined with a strict schema and an explicit list of forbidden keys (bank, sort code, National Insurance, date of birth, home address) which the schema rejects outright.

The credentials our customers issue us do not expose payroll data. Bank details, National Insurance numbers and dates of birth are not readable to us in the first place, rather than read and then discarded. What is read is the pay rate attached to a scheduled pay line, and what is written and kept is the site-level daily total and the clock times described above, never the rate itself. Our customer contracts also commit us to access only the data needed for the agreed purpose and to follow any access limitation the customer specifies.

Training and development

• Quiz attempts and scores, including pass or fail and the date
• Certifications, with their completion and expiry dates
• Training assigned to you, and a record of when you engaged with it
• Your answers to team pulse questions
• Guest reviews that mention you by name

Where your employer has connected a public review source, the product can show you a review that names you. It does this only when you are the only person on your site's roster with that first name; if two people share it, nothing is shown to either of you. What is displayed is the date, the star rating and the review text. The reviewer's own name is deliberately left out.

Things you type, say or upload

• Chat conversations with the assistant, stored against your account as a full message history so you can reopen a thread
• Photos and documents you upload: inspection photos and PDFs, attachments on a thread, files added to the library, and your profile photo
• Notes and logs written in the product, including end-of-day manager logs brought in from your employer's systems as free text
• Notifications sent to you, and whether you read or dismissed them

Anything typed into a free-text box or spoken into the microphone may contain personal data about you or about other people. Please treat those fields the way you would a work email.

Records that predate the contract

Where a customer asks us to load historical operational data at the start of an engagement, the product can hold sales, covers, reservation and workforce records reaching back well before the contract began. Our current pilot backfilled operational data from August 2024. The contract covering that processing is dated to the day processing actually started, not to the day the evaluation went live.

6. The mobile app

The iOS app is a wrapper around the same web application, signed in the same way. It does not keep a separate copy of your data on the device beyond what a browser would.

Permissions iOS will ask you for

• Notifications: so the app can send you push messages. See section 7.
• Microphone: only if you use voice input in chat. The app declares this to iOS as: “AlfredOps uses the microphone so you can ask questions by voice.”

Those are the only two. The app declares no camera or photo-library permission, so iOS will not prompt for one; uploading a photo goes through the system file picker. The app does not use location, contacts, calendar or health data, and it contains no advertising or analytics SDK.

7. Push notifications

If you allow notifications, Apple issues the app a device token. The app passes that token to AlfredOps, where we store it alongside a snapshot of who you were at the moment you subscribed: your user ID, your role, and the brands and sites you are allowed to see. That snapshot is what lets us send a notification to the right people rather than to everyone.

To deliver a notification we send its title, body and destination link to Apple's Push Notification service, which passes it to your device. The same feature works in a web browser through your browser vendor's push service. If Apple tells us a token is no longer registered, we delete the record.

You can turn notifications off in iOS Settings, and switch individual notification types off inside AlfredOps.

8. AI features, chat and voice

AlfredOps uses large language models to write summaries, answer questions in chat, draft replies and generate quizzes. To do that, the relevant business data and your question are sent to our model provider, Anthropic. Chat threads are saved against your account so you can reopen them.

We do not use customer data to train our own models, and none of our AI providers train on the data we send them. That covers Anthropic, our speech provider and the embeddings provider named in section 9, and it rests on the business terms we hold with each of them.

Where voice input is enabled, the recording is sent to our speech provider, ElevenLabs, to be turned into text, and spoken replies are generated the same way. The audio itself is not written to our storage and is not logged; only the resulting text continues into the conversation.

9. Who else processes the data

These are the third parties actually wired into the product. We do not sell or rent personal data, and we do not share it with third parties for their own marketing purposes. Where a customer contract requires it, we give advance notice before adding a new sub-processor, currently at least ten business days, with a reasonable opportunity to object.

Running the service

• Clerk: sign-in, and the user directory holding your name and email address. United States.
• Vercel: hosting for the web application. United States.
• Amazon Web Services: object storage for the data lake, uploaded files and photos; a PostgreSQL database; and job queueing. EU, Stockholm.
• Anthropic: the language models behind the AI features. United States.
• Voyage AI: embeddings of library documents, so that library search works. United States.
• Resend: transactional email, including invites, and scheduled briefs and reports that may contain staff names. United States.
• Apple: push delivery to iOS devices.
• Stripe: subscription billing. This concerns the business that buys AlfredOps, not individual staff.
• ElevenLabs: speech-to-text and text-to-speech, used only where voice is switched on.
• Vonage: text messages, used only where a customer has enabled SMS invites.

Systems we read from, on your employer's instruction

These are your employer's own accounts, and which of them apply depends entirely on what your employer has connected. By category, they are point-of-sale and sales reporting, rota and workforce scheduling, reservations, guest feedback, stock and purchasing, training and compliance records, and public review sites.

We do not list the individual products here, because they differ from one employer to the next. The systems connected for your employer are named in their agreement with us and in the authorisation pack they hold. Your employer can tell you which they are, and we will confirm them on request.

Not all of these are live API connections. For some customers, training and compliance records reach the product as a file exported by hand from the source system, which means a person at your employer chooses what is in that file.

We also call OpenWeatherMap for weather and GOV.UK for the bank-holiday calendar. Neither receives personal data.

Not in use

Voice transcription through OpenAI exists in the codebase but is switched off by default and returns an error unless a deployment deliberately re-enables it, so no voice audio goes there. Google Firebase is wired for future Android push and is dormant. Social media ingestion is built but not active.

Every provider listed above appears on the sub-processor schedule our current customer has approved.

A data processing agreement is in place with each provider listed above, in most cases as part of the standard terms we have accepted with them. Our customer contracts commit us to impose terms on every sub-processor that are no less protective than the ones we owe the customer, and we remain liable for what they do.

10. Where data is stored, and how access is limited

Product data is held in Amazon S3 object storage and a PostgreSQL database on Amazon Web Services, both in the EU (Stockholm) region. That is inside the EEA and outside the UK. There is a single storage bucket and a single database cluster, and although the bucket has “uk” in its name, its contents are in Sweden.

One part of the system sits elsewhere, and it is easier to say so than to round it off. The background pipeline that queues and tracks scheduled work, such as building a site's daily brief, runs in the London region, which is in the UK and outside the EEA, along with the small table that records the state of those jobs. The records a brief is built from, and the finished brief itself, stay in Stockholm.

Several of the providers in section 9 operate outside the UK and EEA, principally in the United States: Clerk, Vercel, Anthropic, Voyage AI, Resend and OpenWeatherMap. Where personal data is transferred outside the UK we rely on the transfer terms carried in each provider's standard data processing agreement, which is ordinarily the UK Addendum to the EU Standard Contractual Clauses.

Rather than promise an outcome, here is what the software does, alongside what we have committed to contractually. Traffic to the application and to every provider above goes over HTTPS, with TLS 1.2 or later. Objects in storage are encrypted at rest with AES-256 under keys the storage service manages, the database is encrypted at rest, and the job queue is encrypted too. Public access is blocked at the storage layer. Each customer's data sits under its own storage prefix and its own database scope, so a request made for one customer does not read another's, and an automated check runs nightly to confirm that isolation holds. Within a customer, requests are checked against your role level and the list of sites you are allowed to see. Administrative actions are recorded in an audit log.

If personal data is breached, our customer agreements commit us to tell the affected customer without undue delay and in any event within 24 hours of becoming aware, and to give them what they reasonably need to meet their own obligations, including notifying the Information Commissioner's Office within 72 hours where that applies. Notification may come in stages as we learn more. An unsuccessful attempt, or an event that does not compromise the confidentiality, integrity or availability of the data, is not a reportable breach.

11. Your rights

Under the UK General Data Protection Regulation (UK GDPR), you have the right to:

• Access the personal data we hold about you
• Request correction of inaccurate data
• Request deletion of your data
• Object to or restrict the processing of your data
• Request portability of your data

To exercise any of these rights, please contact us at info@alfredops.com.

If you are a member of staff using AlfredOps at work, the data is your employer's. Start with your employer, who can act on your record directly; we will help them, or route your request to them. See the support page.

Before we act on a request we may ask you for enough information to confirm who you are. That is to make sure we do not disclose or delete someone's data on the word of a person with no right to it, and it matters more here than on most products, because much of what we hold sits under a workforce identifier rather than a name.

There is no charge for making a request. If a request is clearly unfounded, excessive or repetitive we may charge a reasonable fee to cover the cost of dealing with it, or decline it, and we will explain why if we do.

If you are unhappy with how we have handled your personal data, tell us first so we can put it right. If you are a member of staff, raise it with your employer as well, since they are the controller. You can also complain to the Information Commissioner's Office at any point, at ico.org.uk or on 0303 123 1113. Complaining to us or to your employer first is not a condition of going to the ICO.

We acknowledge a request within five working days and complete it within one month, which is the period the UK GDPR allows, and sooner where we can. Where a request reaches us rather than your employer, that clock starts when we receive it.

Our customer agreements commit us to make erasure of an individual's personal data available on request at any time during the contract. That commitment is wider than what the product's erasure function does on its own, so meeting it involves manual work. The rest of this section sets out exactly where the line falls.

The erasure function can be run by an administrator at the highest role level, or by an AlfredOps super-admin, against a member of staff. It is worth being exact about its reach, because it does not cover everything the product holds about you.

What the erasure function does today

• Deletes outright: your chat threads and the messages in them, your notifications and notification preferences, the actions you ticked off on a daily brief, your quiz streak, your spaced-repetition schedule, your onboarding progress, and your pulse assignments.
• Unlinks and keeps: your quiz results and your certifications are moved into a file named with a random identifier, and the user ID recorded on that file is replaced with a placeholder, so aggregate training numbers still add up. For quiz results this is a clean break, because an individual result carries no identifier of its own. For certifications it is not. Each certification record inside the file keeps its own copy of your user ID, and the move does not replace that one, so a certification can still be traced back to you. We would rather tell you that than let the word anonymised do work it has not earned.
• Replaces your ID with a placeholder inside shared files: quiz and document assignment lists, reminder audit trails, feedback you left on a daily brief, library comments and library feedback, and the platform audit log for the previous 24 months. The entry stays, so counts and audit chains hold; the link to you goes.

What it does not touch

Running it leaves all of the following in place, unchanged and still linked to you:

• Shift and clock records, and the monthly per-person summaries built from them
• Performance measures derived from point-of-sale and guest-feedback data
• The identity reconciliation record described in section 5, and your mobile number where one is held for text-message invites
• Your workplace record: email address, role level, job title, sites and brands, and invite date
• Photos and documents you uploaded, including inspection photos and PDFs, thread attachments, library files and your profile photo
• Free-text notes and end-of-day manager logs, and daily briefs that name you
• Your training engagement log: an append-only record of every time you opened a self-view, completed a quiz, answered a daily question or did a refresher. It is kept against your user ID, it is never pruned or overwritten by design, and erasure does not reach it.
• Your push notification registrations: for each device you turned notifications on for, the device token and a snapshot taken at that moment of your user ID, your role and the brands and sites you could see. These are removed when the device stops accepting notifications, not when erasure is run.
• Your sign-in account, which is held by the authentication provider and has to be closed there separately

Two further limits, both of which a reader would otherwise have no way of guessing. First, the shared-file step above runs only across the sites the administrator running it can see. A record held at a site outside their access is left as it is. Second, the erasure function works on our object storage only. The product can also mirror notifications, quiz results and certifications into a SQL database, each row carrying your user ID, and erasure does not reach those rows. Team pulse answers are mirrored too, but those rows carry no identifier for you in either store.

That database mirror is controlled by per-deployment feature flags. Those flags are off in our current deployment, and object storage is the source of truth, so the mirrored rows described above do not exist today. If the mirror is ever switched on, erasure has to be extended to cover it before it is.

If you want anything in the second list removed, email info@alfredops.com, and if you are a member of staff tell your employer as well, since they are the customer we act for. Removing those records is a manual job today. The erasure function will not do it for you.

Records the erasure function does not reach are removed by us by hand, on the same one-month clock, and we confirm in writing when it is done.

12. Data retention

We retain your personal data only for as long as necessary to fulfil the purposes for which it was collected, or as required by law. An enquiry sent from the website arrives as an email and stays in a mailbox we own and control. We keep enquiry emails for 12 months from our last exchange with you and then delete them, unless the enquiry has turned into a customer relationship, in which case they are kept for as long as that relationship lasts.

For the product, we would rather tell you what is genuinely automated than describe a policy that nothing enforces. A job runs nightly at 03:00 and is written to trim three things. Only one of the three currently acts on live data, and we would rather say so than let you assume more is deleted than is:

• Library search logs, after 90 days. This one takes effect. The job deletes the daily search-log files that the library search feature writes.
• Notifications you have both read and dismissed, after 30 days. This one does not currently take effect. The job looks for your notifications at a storage path that is not the one the application writes them to, so it finds nothing and trims nothing. Read and dismissed notifications are kept until the erasure function in section 11 deletes them, or someone deletes them by hand. Unread ones would have been kept in any case.
• Entries in a legacy tenant-level chat index, after 90 days. Nothing in the current application writes that index, so in a normal deployment there is nothing there to trim. Your actual chat history is stored per person and is covered below.

Everything else has no automatic expiry: daily briefs, training and quiz records, certifications, your training engagement log, performance and clock data, the identity reconciliation record, audit logs, notifications, and uploaded photos and documents. Those are kept until someone deletes them deliberately.

Deliberately means one of two things, and they are not the same. The erasure function in section 11 removes or unlinks the records listed there, and nothing beyond them. Everything outside that list stays put when erasure is run, among them your shift and clock records, performance measures, the identity reconciliation record, your workplace record, your training engagement log, your push notification registrations, and the photos and documents you uploaded. Removing those is a manual job today. If you want them removed, start with your employer and email info@alfredops.com. Section 11 sets out exactly what erasure reaches, what it leaves, and what is still undecided about removing the rest.

One property of the storage is worth naming, because it changes what deletion means. The bucket keeps previous versions of an object, so removing something replaces it in the product without removing the earlier copy underneath. Until those earlier versions are cleared as well, a deleted record is out of reach rather than gone.

Chat needs a specific caveat. The store the app writes to is per person, and the nightly job above does not reach it. Your thread list shows your 50 most recent conversations; when an older thread drops off that list its messages remain in storage. They are deleted when the erasure function is run for you.

When a customer's contract ends

Our customer agreements commit us, on the customer's request, to stop processing their data, to provide a full export in a machine-readable format within 24 hours, to delete their data from the AlfredOps data lake within 72 hours, to instruct our sub-processors to delete what they hold on a best-efforts basis, and to confirm in writing once deletion from the data lake is complete. Routine backups are overwritten on their ordinary cycle rather than deleted on demand.

Nothing in the product performs a customer-wide deletion on its own. We carry it out by hand, across object storage, the database and the job queue, and confirm in writing once it is complete. The written checklist noted in section 11 covers this as well.

How long staff records are kept

We keep staff records for as long as the customer's contract with us lasts, unless the customer or the individual asks for them to be removed sooner. Beyond the three automated items above, nothing expires on its own, so removal during the life of a contract means someone deciding to remove it. Sections 11 and 12 set out exactly how that happens.

13. Guests of our customers' venues

Where a customer connects their reservation, guest-feedback or public review systems, the product processes some data about guests. Your relationship is with the restaurant, not with us: they are the controller, and a request about your data should go to them first.

What the product is designed to hold about a guest:

• A pseudonymous reservation identifier and aggregate booking data: covers, times and spend
• Guest feedback, processed without identifiers for the guest who left it
• Public reviews, held as the date, the star rating and the review text

Guest names, contact details, marketing-consent flags and free-text booking notes are not retained at rest. For public reviews, the reviewer's own name is deliberately left out of what the product stores and displays, though review text is written by the reviewer and can of course name them or someone else.

No guest identifier survives ingestion. Names, contact details, consent flags and free-text booking notes are dropped as the data comes in rather than deleted after it has been stored, so they do not reach the raw files in our storage either.

14. Changes to this policy

We may update this privacy policy from time to time. Any changes will be posted on this page with an updated revision date.

15. Contact

Alfred Ops Limited
Privacy enquiries: info@alfredops.com
Help using the app: support@alfredops.com, see the support page