Skip to content
EECRequest access

Privacy Policy

Last updated: 2026-08-15. Draft — pending legal review.

This policy describes what EEC actually does today. The app now has user accounts, so unlike earlier versions of this page, it does hold personal information on servers we control.

It also now holds details of people who are not our users at all — the guests, crew and drivers our customers are organising. That is a materially different kind of responsibility from holding a colleague's email address, and the sections below marked TODO are not padding: they are the parts a lawyer has to write before this page can be published.

Who this applies to

EEC is sold to companies, not to individuals. If you have an account, a company created it for you. That company decides who has access and what they can see.

What we hold about you

When your company sets up an account for you, we store:

  • Your email address. It is how you sign in and how we send you an invitation or a password-reset link.
  • Your name, if you choose to enter one. Leaving it blank is fine.
  • Which company you belong to, and your role in it.
  • A record of what you do in the app — when you sign in and out, when you invite a colleague, when you change your password or your account details, and when you create, change or archive an event or one of its functions. This is visible to everyone at your company, on the Audit trail page, and cannot be edited or deleted by anyone.
  • A record of each individual change you make to a record — which field, what it was before, what it became, and when. This is kept for every change, not a sample, and it names you as the person who made it. It is not shown on any screen today; it exists so that when teams work offline at a venue, two people editing the same record cannot silently overwrite one another. Like the audit trail, it cannot be edited or deleted from inside the app.

What your company puts into EEC

Separately from your own account details, your company stores its working records here. Today that means:

  • Events — a name, a client name, and dates — and the functions inside them, each with a name, a time and a venue. A client name may be a person's or a family's name.
  • People at those events, and the households they belong to. See the next section, which is the important one.

These records belong to the company that entered them, not to us. We hold them so the app can work, and for no other purpose.

Events are archived, never deleted. Finishing with an event moves it out of the way; nothing in the app removes it. That is deliberate — an event carries a year of records that outlive anyone's interest in the list it sits on — but it means "archived" is not "deleted", and the retention section below is where that has to be properly addressed.

Guests, and everyone else who never signed up

This is the most consequential thing on this page, and it is not finished.

Our customers are event companies. To do their work they enter details of guests, crew, artists and drivers — people who have no account here, never agreed to anything with us, and in most cases have never heard of us. Today that includes:

  • their name and title,
  • their phone number and email address, where the company has them,
  • the household they belong to and who else is in it,
  • which side of the family or which team they belong to,
  • when they arrive and leave, and whether they leave and come back,
  • a status the company marks them with, and free-text notes,
  • and any field the company chooses to add themselves — see below.

Companies using Guest Communications record more than that (added 2026-08-19). Where that module is switched on for an event, the company can also record, for each guest:

  • how the guest should be addressed in a message, which is often not their name,
  • a second phone number,
  • the name, phone number and email address of somebody who answers for them — an assistant, a parent, a manager. That is a third person's contact details, entered by our customer, about somebody who is not the guest and not a user either.
  • their date of birth,
  • their gender, typed freely rather than chosen from a list,
  • and how far along their travel documents are, as one of four states.

Date of birth and gender are new categories for us, and the date of birth is what the app uses to work out a guest's age at the event — the age is never stored, only calculated. Both are ordinary personal data rather than special-category data in most jurisdictions, but they raise the same unanswered questions as everything else in this section: nobody tells the guest, and the guest has no relationship with us. A date of birth also makes it materially more likely that the app is holding identifiable details of a child — see the TODO list below, where that has moved from anticipated to live.

From 2026-08-20 the same module records what was said to a guest, and that is a different kind of thing from everything above it. For each event a company can now keep:

  • which functions each guest is invited to — a decision the company and its client make, never asked of the guest,
  • the date each round of contact reached them — the save-the-date, the final invite, and whatever else the company chooses to call its rounds,
  • and a log of every call and message about them: the day it happened, how they were contacted, what it was about, and free text describing what was said, plus any follow-up promised and a note about it,
  • where they are sleeping and when — which property they are at, which room they have been given, the day they check in and the day they check out, whether the room is single or shared and with whom, how many extra beds, who is paying for the room, and free text holding whatever the property said back about them.

Where somebody is sleeping is a different kind of fact from the rest. A name and a status say who a person is to our customer; a room number and two dates say where a named individual can be found on a given night. Held together with a phone number and a passport number, which this app also holds, that is a materially more sensitive record than any single field in it, and it is listed separately here rather than folded in with "contact details". The same applies to who is sharing with whom: two names against one room is a statement about a relationship that neither person gave us.

The property's own remark is free text with the same problem as the conversation log below — nothing asks for it, nothing limits it, and in practice it will hold what a hotel thought worth passing back.

The free text is the part that deserves attention. Everything else this app holds about a guest is a field with a shape — a name, a date, a status. "What was said" has no shape at all, and in practice it will hold whatever the person at the desk thought worth writing down: that a guest is unwell and cannot fly, that a marriage has broken down, that somebody is estranged from the family, who is paying for whom. None of that is asked for by a field, and none of it is something we can see, filter or limit. It is entered by our customer about a person who has no relationship with us and has not been told the record exists. The same is true of a query — a conversation the company marks as needing an answer from somebody else, which is then held open, given a deadline, and recorded against a named holder, who is often a third party such as a client or a hotel.

Practically, this means the free-text log is at least as likely as the custom fields below to end up holding special-category data — health, religious belief, family circumstances — without anybody having decided that it should. It is listed here rather than left implicit, and it is on the TODO list below.

Every change to a logged conversation is kept, field by field, with the name of the person who made it, exactly as for the rest of a guest's record. A company can delete a logged conversation from its own list; the record that it existed and was deleted remains in the change history.

Companies can add their own fields, and we cannot see what they will hold. The app lets a company create extra fields on a person. In this industry those will predictably include dietary requirements, accessibility needs, and details of children attending. Some of that reveals religious belief or health information, which most privacy law treats as a special category needing stronger justification than ordinary data. We have not yet decided or documented how that is handled, and it is the largest single gap in this document.

Every change to a guest's record is kept, field by field, with the name of the person at the company who made it. Nothing in the app edits or removes that history.

We also record who logged each conversation, so a company knows whose call it was. That is one of our own users, and it is covered by "What we hold about you" above.

We do not contact guests, profile them, or use their details for anything except making the app work for the company that entered them.

Bringing a guest list in from a spreadsheet

A company can import their own Excel or CSV file. That file is read inside the browser of the person importing it, and is never uploaded to us. Nothing crosses to our servers until they have seen exactly what will change and approved it, and what crosses then is the resulting guest records — never the file. An import that is abandoned part-way leaves no copy of the file, and no copy of anything in it, anywhere in our systems. We do not keep the original spreadsheet at any point.

The records an approved import creates are the same records described above, held on the same basis, and every one of them carries the same field-by-field history naming the person at the company who imported them.

Importing never deletes anybody. A person already in the app who is absent from an imported file is reported to the person importing and otherwise left untouched.

TODO — needs legal review before publishing. This section describes what the software does. It does not yet address: whether reading a file client-side changes the controller/processor analysis (we think it does not — the company remains the controller either way), nor what a company must tell guests whose details they import in bulk rather than enter one at a time. Both need a lawyer, not a guess.

Taking a guest list back out

A company can export their list as an Excel or CSV file at any time. The file is built in the browser of the person exporting it — we do not generate, store or keep a copy of it, and it is not written to any server. What it contains is chosen by the person exporting: they pick the columns.

Every file we produce carries an identifier of ours in a final column, marked do not edit, so that a file which is edited and brought back can be matched to the right people. That column contains no personal information — it is an internal reference and nothing else.

Once a file has been downloaded it is outside this app, and outside our control. A guest list sent to a hotel, an airline or a client is a disclosure made by the company, not by us. Companies should treat an exported file as they would any other document holding their guests' personal details.

TODO — needs legal review before publishing. Export is the point at which personal data leaves the system, which usually needs saying explicitly: what a company is agreeing to when they download, and whether anything here should constrain it. Not drafted, because guessing at the wording of a disclosure clause is worse than leaving the gap visible.

When something is deleted

TODO — this section states a real retention period and therefore needs actual legal review and sign-off before it is published. It is drafted, not approved. It also does not yet cover what happens when an account or a company closes, which is still an open product decision — see the TODO list at the end.

Deleting something does not destroy it straight away. When somebody at your company deletes a guest, a stay, a logged conversation, a room, a property or a column, it stops appearing anywhere in the app — no list, no count, no export, no search — but the record itself is kept for 30 days and shown on a Trash screen, where anybody at that company can put it back exactly as it was.

After 30 days it is destroyed automatically, by a scheduled job, without anybody doing anything. One qualification, because it should not be overstated: that job runs while the service is running. If a company's project has been dormant long enough to be suspended, the clean-up resumes when it wakes, so a record can outlive the 30 days by the length of that gap.

Anything in Trash can be destroyed immediately. An owner at the company can delete a specific thing permanently, or empty the whole trash, and that removal is real and final — it is not recoverable by them, by us, or from the Trash screen. This is the mechanism for acting on a request to erase somebody's data: deleting them and then destroying it from Trash removes it now rather than in 30 days.

Two things are never deleted this way, and both are deliberate:

  • Events are archived, not deleted. An archived event is finished, not discarded, and everything inside it stays.
  • The audit trail and the field-by-field change history cannot be deleted at all, by anyone, including us through the app. They are append-only by design. A deletion is itself recorded in the audit trail, which means a note saying that something was deleted outlives the thing.

When a company leaves

Deleting a company removes everything belonging to it — its events, its people, its households, and the whole change history — in one operation. That is total, and it does not go to Trash: closing a company is not the same gesture as tidying a list, and it is not reversible. What happens to a company's data at the point it closes its account is still an open question; see below.

We never see or store your password. Authentication is handled by Supabase (see Third parties below), which stores only a one-way cryptographic hash of it. Nobody at EEC can read your password, and we cannot recover it for you — only reset it.

We do not collect analytics, use tracking cookies, or build any profile of you. The only cookies EEC sets are the ones that keep you signed in.

What's stored on your own device

Your appearance and behavior preferences — theme, accent color, interface size, chosen landing page — are saved in your browser's local storage, on your own device only. They are never transmitted to us and we have no way to see them. Clearing your browser's site data clears them.

EEC also remembers how you left each table — how wide you dragged its columns, which columns you hid, how it was sorted, how many rows a page, what you last filtered or searched it for, and which cell you were in when you closed it. This is saved in the same place, on your own device only, filed under the account you are signed in as so that two people sharing a computer never see each other's. It is never transmitted to us and we have no way to see it.

Some of it can contain guest information. A saved filter or search holds the words you filtered or searched by, which may be a guest's name, a family name or a status; the remembered cell identifies the row you were reading, which is a particular guest. Because of that:

  • Signing out erases everything you had filtered or searched to, and which row you were on, on that device, for that account. What is kept is only how the table was laid out — column widths, which columns show, rows per page — which says nothing about any person.
  • Clearing your browser's site data erases all of it.
  • None of it leaves the device it was saved on, so it does not follow you to another computer and is not part of anything we hold or could export.

If you contact us

The home page has an early-access form. It does not send anything to a server. Typing an address into it and pressing the button opens your own email application with a message already written, addressed to us. Nothing leaves your device unless you then choose to send that email yourself. If you do, we receive an ordinary email and keep it in our inbox, used only to reply to you. Ask us to delete it and we will.

One company can never see another's data

Every record in EEC belongs to exactly one company, and the separation is enforced by the database itself rather than only by what the screens choose to show. A signed-in person can read their own company's records and nothing else.

Where your data is stored

In Mumbai, India (Supabase's ap-south-1 region). This was chosen deliberately rather than accepted as a default, because the data this app will hold is largely about Indian people. It cannot be changed later without moving to a different database.

Third parties

  • Supabase — the database, and the service that handles sign-in, passwords and the emails that carry invitation and reset links. Data is held in the Mumbai region described above.
  • Vercel — hosting. Serves the app to your browser and runs its server-side code.

No other third-party service receives data from this app. We do not sell or share your information with anyone.

The spreadsheet reading described above adds no third party: it runs as code inside your own browser, and the file it reads goes nowhere.

TODO — sections this document still needs before it can be published

These are deliberately left unwritten rather than guessed at. Each needs input from an actual lawyer, and some need decisions that haven't been made yet:

  • Retention and deletion — partly answered, and only partly. "When something is deleted" above now states the 30-day rule for everyday deletions, and names permanent deletion as the way to erase something sooner. What is still undecided is the harder half: how long records are kept after an account or a company is closed, and what "delete my account" actually does, given that the audit trail is append-only by design and that deleting an account leaves its audit entries in place with the actor removed. Two things still make this urgent: the app never deletes an event, only archives it; and the field-by-field change record is kept indefinitely, is not visible or removable through any screen, and is not covered by the 30 days.
  • Your rights, and how to exercise them. Access, correction, deletion, portability, objection — under India's DPDP Act, and under GDPR/UK GDPR if the app is ever used from or sold into those jurisdictions. Needs a named contact and a stated response time.
  • Legal basis for processing, and who is controller versus processor. EEC is likely a processor acting for the customer company, which changes what this document has to say and what belongs in a separate data-processing agreement instead.
  • Guests' data. The people whose details customers put into EEC are not our users and have no relationship with us. This is no longer hypothetical — the app holds their names, phone numbers, household structure and movements as of 2026-08-15. This is the most consequential gap on this list and it needs proper advice before anything is publicly reachable. It needs to cover, at minimum: who tells the guest their details are here, on what legal basis, and how a guest exercises any right at all when their relationship is with the event company and not with us.
  • Special-category data reaching us through fields we don't control. A company can define its own fields, and in this industry they will hold dietary requirements and accessibility needs — proxies for religious belief and health. Needs a decision (do we restrict what such a field may hold? warn the company? contract for it?) before advice can even be sought.
  • Breach notification — what we commit to, and within what time.
  • Children's data. The product already can hold details of minors attending events — a child is just another person in a household, and nothing stops a company entering one. As of 2026-08-19 it can hold a guest's date of birth and works out their age from it, which makes "is this record about a child" a question the app can now answer and therefore one this document can no longer avoid. This needs specific treatment, and it is a live gap rather than an anticipated one.
  • Contact details of a fourth party. Guest Communications records the name, phone and email of whoever answers for a guest — an assistant, a parent, a manager. That person is neither our user, nor our customer, nor the guest, and has no relationship with any of the three that anyone has told them about. Needs the same advice as guests' data, and probably the same answer.
  • Gender, recorded as free text. Deliberately not a fixed list, because a list is one somebody's guest is not on and the field exists to fill in a form for a hotel or an airline. That also means we cannot say what it will hold. Needs a decision alongside the special-category question above.
  • Free-text notes about a guest, written by our customer. From 2026-08-20 the app keeps a log of every call and message about a guest, including an open text field for what was said. Unlike every other field this is unbounded in what it can hold, and the realistic contents include health, family circumstances and financial arrangements — none of it asked for by a field, none of it visible to us, and all of it about somebody who has not been told the record exists. Needs the same decision as the special-category question above, and probably more urgently, because a field with a shape at least tells you what it is for.
  • A query held by a named third party. A conversation can be marked as needing an answer from somebody outside both us and our customer — a client, a hotel — recorded by name with a deadline against them. That name is a fourth category of person again, and the same advice is needed.
  • Sub-processor list and international transfers, stated properly rather than as the informal list above.

Changes to this policy

This document is kept in sync with what the app actually does, in the same change that introduces a new capability — not after the fact. It has not been reviewed by a lawyer, and must be before this app is publicly reachable.