Skip to content
EEC
Sign inRequest access

Privacy Policy

Last updated: 2026-10-03. 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 companies you belong to, and your role in each. One account can belong to more than one company. Each company sees that you are one of its members; it cannot see which other companies you belong to.
  • Which of a company's events you can open, with your role on each, who gave you that access and until when, the teams you are in, and any permission given to you or taken away (added 2026-09-29). Your company sets these, and can see them. Access given until a date stops by itself after that day; the record of it stays until somebody removes it or you leave the company, when it is removed with your membership.
  • Invitations sent to you. When a company invites you, we store your email address, who invited you, when, until when the invitation is open, and whether you accepted, declined or it was cancelled. The inviting company can see that record, including that you declined. Before you accept, all you can see of the company is its name and who invited you.
  • Whether a company has suspended you, when, until when, and who did it. Anybody at that company can see this on its Team screen. When a company removes, suspends, or signs you out of every device, the Audit trail records who did it and when, and any reason they typed — which we do not send to you. The email we send you says only what happened and, for a suspension, until when.
  • An authenticator app, if you set one up. Supabase stores the secret the app uses to make its codes, so it can check them; we never see a code itself. Your company can see whether you have one set up (so somebody can reset it if you lose your phone), not the secret. A company can also require one for all its members.
  • Who is working where, while they are working (added 2026-09-30). While you have one of an event's sheets open and are looking at it, colleagues in the same company who can open that event see your first name (or, if you have not given a name, the part of your email address before the "@"), which sheet you are on and which cell you are on. It is passed between browsers while it happens and not stored: when you leave the sheet, switch away, or close the app, it is gone, and there is no record of it afterwards.

TODO — needs legal review before publishing. Added 2026-09-30 with "see who else is on the sheet". Showing colleagues somebody's live activity — the sheet and cell they are on — is a use of a member's name and behaviour that did not exist before. It is limited to one company, never stored and never sent outside the company, but confirm whether it needs its own mention here, whether members must be told before it applies to them, and whether a way to hide oneself is required (none is built).

  • Notices about your tasks (added 2026-10-22). When a task is given to you, when the status of a task you made or are on changes, the day before a task you are on is due, and when it becomes overdue, a line is kept in your Inbox: which task, what happened, who did it (or that the app did) and when. Only you can read your notices, and only while you can still see the task. The comments on a task, and who they mention, are kept with the task and can be read by everybody who can see it. Nothing is sent by email.
  • Which guest a task is about (added 2026-10-23). A task can name one guest of its event, and one of their stays, tickets, journeys, transport requests or conversations. The task shows the guest's name only to people who could already see that guest; to anybody else it says "a guest you can't see". The link is kept with the task; if the guest is later destroyed, the task stays and no longer names them. A repeating task's schedule is kept with its tasks, and the next task (a copy of the last, with the same people and guest) is made automatically each time one falls due.

TODO — needs legal review before publishing. Added 2026-10-22 with task notices and task comments. Notices are kept with no end date (read ones drop off the Inbox after a month but stay stored); a notice and a comment go when their task is destroyed, which does not happen yet (the Trash purge for tasks waits on approval). Decide whether a retention period must be stated, and whether a person has a right to have their comments removed from a company's tasks after they leave it.

  • When you last signed in, and whether you have a second sign-in step set up (added 2026-10-10). Colleagues who may see who is in the company can see, on the Users screen, the date you last signed in ("Today", "3 days ago", or a date; "Never" if you have not) and whether your authenticator app is enabled or started but not finished. This is taken from the sign-in service's own record, is shown only to people in your company, and never shows the secret behind the authenticator app. It is when a password or code was last entered, not a record of when you used the app, and nothing new is stored for it.

TODO — needs legal review before publishing. Added 2026-10-10 with the Users screen's "Last online" and "2FA" columns. Showing colleagues when a member last signed in, and whether they have two-step sign-in, is a new use of sign-in data about a person. It is limited to the company, read-only and adds nothing to what is stored, but confirm whether members must be told before it applies to them, and whether it needs its own mention here.

TODO — needs legal review before publishing. Added 2026-09-28 with removing and suspending colleagues. (a) Reasons typed when somebody is removed, suspended or signed out are kept on the company's Audit trail, which cannot be edited or deleted, and are about the person — they may be personal data the person has a right to see; decide whether and how. (b) A colleague at one company can sign a person out of every device and reset their authenticator app, which reaches the person's use of other companies too; confirm this needs stating here and in the terms. (c) No retention period is set for the record of a suspension once it has ended (the row is cleared; the trail entries stay).

TODO — needs legal review before publishing. Added 2026-10-12 with column access. A company can now hide or protect single pieces of a person's data (phone, date of birth, documents, its own columns) from some of its roles — a data-minimisation control the company operates, not us. (a) Decide whether to describe it here as a safeguard the company is responsible for configuring, and whether the default (every role sees what its switches allow; a new company's RSVP Manager does not see costs) needs stating. (b) Each change to who sees which column is kept on the company's Audit trail, which cannot be edited or deleted; it names roles and columns, never a person's data. (c) A file exported before a column was hidden still holds it — confirm whether that needs saying.

TODO — needs legal review before publishing. Invitations are kept after they are answered or expire, as a record the inviting company can see; no retention period for them is decided. Nor is it decided whether the inviting company, or the person invited, is the controller of a declined invitation's record, or how either can have it removed.

  • 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.

  • Which devices you are signed in on, so that you can see them and sign one out remotely. For each device that is currently signed in we store the identifying line your browser sends with every request — which tells us roughly the browser and operating system, and nothing that identifies the machine itself — along with when that sign-in happened and when it was last used. We do not store your IP address or any location for this, and the screen shows neither.

    Only you can see this list. It is not visible to your company, to other people at your company, or on the Audit trail. What is visible to your company is the fact that you signed a device out, in the same way signing in and out is already recorded — the entry says that it happened, not which device it was.

    A device's entry is deleted when that device is signed out, whether by you, by signing out normally, or by changing your password. Nothing is kept about devices that are no longer signed in.

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.
  • Tasks — the team's to-do list: a title, a description, who is doing it, a due date, and optionally the event it is about. A task's words are whatever the team types, so they can name guests or colleagues. Added 2026-10-21.

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, including — since 2026-09-24 — a phone number and title read from a transport file the company imports, which adds the people it names to the event's guest list (it only fills a blank; it never overwrites what is already held) — including companions named alongside a guest in that file, who are added as people of their own. Where two entries look like the same person, a company user may merge them: the details of one fill the other's blanks and the one merged away goes to Trash. The company's decision that two entries are different people is also stored, with who made it,
  • 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,
  • what they have asked for in a room, as free text a planner types — for example "ground floor, near the lift", which can reveal a health or mobility need the guest never gave us directly,
  • and copies of the rooming lists a company marks as sent to a hotel — guests' names, room numbers and dates as they stood at that moment, kept so later changes can be shown. A copy lives as long as the event it belongs to and is removed with it.

TODO — needs legal review before publishing. Room preferences can carry health or accessibility information (special-category data under several regimes), and the kept rooming-list copies are a second store of where named people slept. This draft describes both; it does not yet say what lawful basis covers them, or whether a guest can ask for the copies to be removed before the event is. Added 2026-09-14 with the Accommodation screen.

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.

From 2026-09-20 a change to a guest's RSVP answer also records where the news came from — and one part of that is a new kind of thing for this app to hold. Against each change we now keep:

  • who told us, chosen from a list the company writes for that event,
  • how they told us — a call, a message, an email,
  • the day they told us, which is not the day somebody typed it in,
  • what made the change, where it was not a person typing: an import, or a find-and-replace across a column (added 2026-09-21),
  • and, where the company says so, which logged conversation the answer came out of (added 2026-09-21) — a pointer to a record described above, never a new copy of it.

The "who told us" list can name a real person who is not the guest and not a user. It is the company's own list, written per event, and in practice it will hold entries like "the bride's assistant" or somebody's mother alongside the four we start it with. That is a third party's name, stored against a guest's communications, entered by our customer about somebody who has no relationship with us and has not been told the record exists. It is far narrower than the free text above — a short list of words, chosen from, not typed per change — but it is the same kind of problem in a smaller shape, and it is listed here rather than folded in with "contact details".

Removing an entry from that list never changes what was already recorded. A change keeps the word it was given at the time, so a company tidying its list next month cannot alter what last month's record says. That is deliberate — a history that rewrites itself is not a history — and it means a name entered on that list persists in the change record even after the list itself no longer offers it.

TODO — needs legal review before publishing. Three things this draft describes but does not resolve. (1) What lawful basis covers storing a named third party — an assistant, a parent — as the source of a guest's answer, when that person is neither our user nor the data subject of the record they appear in. (2) Whether such a person can ask to be removed, given that removing the list entry deliberately leaves the recorded word in place, and what we would actually do if they did. (3) Whether tying a status change to a logged conversation changes anything about the conversation's own basis, or is simply a pointer between two records already covered above. Added 2026-09-21 with the status-source build. Do not fill these in by invention.

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 guest list we produce — the Namelist and the Master — 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.

A company can save templates for exporting and importing: which columns go out, in what order, how the list is filtered and sorted, and — for importing — which heading in their spreadsheet matches which of our columns. Templates are shared across the company's team. They hold no guest rows, and the spreadsheets themselves are never kept; but a filter holds whatever words were typed into it, so a template filtered on a guest's name keeps that name until the template is changed or removed.

TODO — needs legal review before publishing. Whether a filter holding a typed name needs saying at all, and how a guest's deletion request should reach a template that names them (today it does not — removing the guest does not edit templates). Added 2026-09-24.

A company can also download a rooming list for a hotel — guests' names, room numbers, dates, room preferences, notes for the hotel and a contact phone number. That file is built on our server at the moment it is asked for and handed straight to the person downloading it; it is not stored.

To keep one account from asking the server for hundreds of files a minute, we keep a short record, in our own database, that an account asked for a server-built download (the rooming list, a summary as a spreadsheet) and when: the account's number and a time, nothing about the file or its contents. It is not shared with anyone and is not currently deleted.

TODO — needs legal review before publishing. How long that record of download times is kept (today: indefinitely; trimming it is a deletion that needs the product owner's decision) and whether it needs a line of its own. Added 2026-10-19.

Once a night we also note the figures on each summary tile a company has built on its Overviews — the totals the tile shows (how many stays, and how many in each group it splits them into), never a guest's row — so a tile can say how its figure has moved since a week ago. The group names are the words the tile itself shows; a tile grouped by a guest's name would therefore note names, as it already displays them. The notes are kept in our own database, readable only by the company's people who can read the tile itself, and are removed with their tile or event. They are not otherwise deleted.

TODO — needs legal review before publishing. How long these nightly figures are kept (today: as long as their tile or event; trimming them is a deletion that needs the product owner's decision), and whether noting a tile that groups by a person's name needs wording of its own. Added 2026-10-19.

TODO — needs legal review before publishing. A rooming list sent to a hotel is a disclosure to a third party that may need its own wording. Added 2026-09-15. (Updated 2026-09-24: the other half of this note — that guest-list exports had moved to the server, contradicting "built in the browser" above — no longer applies. The event's Export screen that did so was retired, and every guest-list export is built in the browser again.)

Downloads made from the Import / Export screen are built the same way, in the browser of the person exporting, from rows they could already see. Each one is written to the company's audit trail: who downloaded it, which tables, when, in which format and how many rows and columns — never what the file contained. Since 2026-10-11 the same line also keeps what was chosen for each table — the template, the columns, the filters and the sort — so the person can run the same export again from a "Recently used" list. An import from that screen leaves a similar line with the column matching it used (which heading in their file fed which column). These hold column names and filter choices, the same as a saved template; a filter can name a value, such as a status, a hotel or, if somebody filtered by it, a name. PDF files are built in the browser too, by a library bundled with the app — no outside service sees them.

TODO — needs legal review before publishing. Whether a filter value kept in the audit trail (which may occasionally be a guest's name) needs its own mention, given the audit trail cannot be deleted. Added 2026-10-11.

Saved versions of an export

This is the one place we keep a copy of guest information beyond the lists themselves. When a person exports a table and chooses Save as version, we keep a copy of what went out — the columns they chose and the words in every cell, for every row — so the next export can be compared with it and show what has changed since. Until they choose it, nothing is kept: a quick download leaves no copy behind.

  • Who can see it. Only people in the same company who are allowed to export that table. A copy is kept apart from the lists and can be read only through our servers, which check who is asking. A person sees only the columns their role can see: a column hidden from them is left out of the copy they get, even if the person who saved it could see it.
  • How long it is kept. Until the company deletes it from the Versions screen — one at a time or several together; deletion is permanent and the copy does not go to Trash. Old copies also tidy themselves every night: only the latest 20 for each table are kept, and nothing older than 180 days, unless the company chose to keep one. Saving was switched on 2026-10-26.
  • When a guest is removed for good — when the Trash is emptied after 30 days, or sooner — their rows are removed from every saved version too, kept ones included, and the version records how many it lost.
  • What is not in it. The file itself is never uploaded; the copy is made from what was already on the person's screen. The Rooming list is not kept this way, because each line names everyone in a room.
  • The audit trail records who saved, renamed, kept or deleted a version — with its number and name — never what was in it.

TODO — needs legal review before publishing. Saved versions are copies of personal data held by us on the company's behalf, which changes what we say about storage, retention and processors. Needs a lawyer, not a guess: the retention periods (20 versions / 180 days are proposals, not decided law); whether deleting a guest must also remove them from versions immediately rather than at the next Trash purge; and how the company is told that a downloaded file keeps its highlights after the version is deleted. Added 2026-10-17.

TODO — needs legal review before publishing. Whether recording who exported what, and keeping that record for as long as the rest of the audit trail, needs its own wording for the company's team members. Added 2026-09-24.

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.

Pages a company shares with its own client

A company can make client links for an event: a page anybody holding the link can open, without an account. The company decides who it sends a link to and, as the app grows, what the page shows. From the moment a link is sent, everybody it reaches can see what that page shows until the company turns the link off — which it can do at any time, and which stops the link working at once. A link turned off is kept, so the company has a record of what it shared, but it can never be opened again.

A page can include the company's records of its conversations with guests, each with every update written in it — and, where the company chooses, the name of the team member who wrote each update. So a company's own team members' names can be seen by its client. TODO (legal): whether the company needs to tell its team members this, or ask them, before it shares a conversation list; and whether the page should show initials only.

The page may offer to be added to the client's home screen. If they add it, their phone keeps only the icon, the event's name and the link's address — nothing the page shows is kept for use without a connection. If they close the offer, their browser remembers that (in its own storage, on that device only) so it is not offered again.

Each link opens only with a passcode the company sends separately. When the right passcode is typed, the page leaves a small cookie on that device — a sealed note naming the link, not the person — so it is not asked again for 12 hours; changing the passcode makes every such note stop working. When a wrong passcode is typed we keep, with the time and the link, a scrambled copy of the internet address it came from, so that guessing can be slowed down and the company warned.

When a client link is opened we record when, the kind of device (phone, tablet or computer) and the browser ("Chrome on Android"), read from what the browser says about itself, and a device tag — a random code the page gives a browser, in a second cookie kept for up to 400 days for that link's address only, when the passcode is first typed there. The tag lets the company see how many different devices opened a link and which came back ("Device 3"); it does not say who, and we record no location — no city, no country. Opens recorded before 27 October 2026 hold only their time. The company's team can see each link's record of opens and download it as a spreadsheet. TODO (legal): whether the device tag cookie needs consent where the client is (it is not strictly necessary for the page to work); and whether the device kind, browser and tag together are personal data under the DPDP Act and the GDPR.

Where the company lets the client download a list as a spreadsheet, we record each download — which list, when, and a scrambled copy of the internet address it came from, so that very many downloads can be slowed down. A downloaded file is the client's copy: once saved, it is beyond the company's reach and ours. TODO (legal): the company's duties for guest data it lets its client download. When somebody opens an address that matches no link, we keep a scrambled copy of the internet address it came from (a one-way code, never the address itself) with the time, so that somebody trying address after address can be slowed down. Neither record is shown to anybody outside the company's own team, and the client's page runs no usage analytics. TODO (legal): whether the 12-hour cookie is strictly necessary (so needs no consent banner) where the client is; how long these records are kept — today they are kept until the event is destroyed, and the scrambled addresses indefinitely; whether a scrambled address is personal data under the DPDP Act and the GDPR; and how the company, as the one sending the link, is responsible for whom it sends it to.

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.

TODO — needs legal review: tasks are not destroyed yet (2026-10-21). A deleted task goes to Trash like everything else, but for now nothing destroys it — not the 30-day clean-up and not "delete permanently" — until the rule for destroying tasks is approved (docs/plans/to-do/tasks.md, Stage 5). Until then the paragraph above does not hold for tasks: a request to erase somebody's data that reaches a task cannot be acted on from the Trash screen, only by editing the task's words. This must be resolved, or stated, before this policy is published.

TODO — needs legal review: one deleted conversation entry is kept until restored (2026-10-24). An update or a follow-up closing note can now be deleted on its own from a conversation. It goes to Trash, but nothing destroys it — not the 30-day clean-up and not "delete permanently" — because the company chose to keep them until somebody restores them. So the paragraphs above do not hold for these: they are kept with no end date, and a request to erase somebody's data that reaches one cannot be completed from the Trash screen. Decide whether a retention period must be stated, or the purge approved, before this policy is published.

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 use advertising or tracking cookies, and we do not build a profile of you. The only cookies EEC sets are the ones that keep you signed in. EEC does not collect usage analytics: it does not report which screens you open, what you click, or when something on a screen breaks, to us or to anyone else.

TODO — needs legal review before publishing. A usage-analytics service (PostHog) was added on 2026-10-03 and taken out again on 2026-10-27, before it was ever switched on for the live site, so nothing was collected. This paragraph is back to saying EEC collects no analytics; a lawyer should confirm that is still the wording wanted, and that if analytics or error reporting is ever added again, the policy is changed in the same change.

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. Part of that is kept on your own device and part of it with your account on our servers, and the difference matters.

On your own device: how wide you dragged its columns, which columns you hid or pinned, their order, how many rows a page, and which cell you were in when you closed it. The Allocate screen also keeps here which tab you were on, what you searched the guests and rooms for, and which filters you had on. This is saved in your browser's local storage, 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.

  • Signing out erases which row you were on, your undo history, and the Allocate screen's searches and filters, 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.
  • Signing a device out remotely is different, and it is worth being clear about. It stops that device reaching your company's records — the next thing it tries, it is asked to sign in again. But it cannot reach into that browser and erase what is saved there, because that erasing happens on the device itself. If you are worried about what a browser you no longer control might still be holding, signing it out remotely is not enough on its own: the remembered row and the Allocate searches go when somebody signs out on that device, or when its site data is cleared.
  • Clearing your browser's site data erases all of it.

With your account, on our servers (since 2026-10-24): how each table was narrowed — its sort, the filters you had on, what you searched it for, which saved view or list was open — for the Master, the Namelist, the Transport Master, Travel, Meet & Greet, Transport Requests, Contracted Rooms, a hotel's rooms, Interactions and Tasks. It is kept so the table opens the way you left it on any computer, without loading twice.

  • It can contain guest information. A filter or search holds the words you filtered or searched by, which may be a guest's name, a family name or a status.
  • Only you can read it, and only while you can still open what it is about — the event, the hotel, or your company. Colleagues, including your company's Owners, cannot see it.
  • Signing out keeps it, because it is not on the device. A borrowed or shared laptop holds none of it.
  • It is deleted when the event it is about is permanently destroyed, and when you leave or are removed from the company. A newer version replaces the older one each time you change how a table is narrowed.

TODO (legal review): this stores guest names typed into filters and searches on our servers, per user, and keeps them across sign-outs. Needs review of: whether this is covered by the existing basis for processing the client's guest data (it is the planner's working state, not a new purpose); whether it must be listed in data-export / access requests for the user (it is personal to the user but mentions guests); whether retention "until the event is destroyed or the person leaves" is acceptable or needs a time limit; and the wording on guests. Do not publish until reviewed.

The figure cards above the Namelist, the Master, the Transport Master, Travel and the Transport Requests are saved on your own device, per event, under your account. Unlike the remembered row, they are kept when you sign out — they are treated as a way of laying out the screen, like column widths. A card that counts rows where a column says a particular answer holds that answer (and a card can hold several such conditions), which can be a status or, if you chose one, a family name. Clearing your browser's site data erases them.

If somebody who manages your company's setup makes a set of cards your company's starting set, that set — including any answers its cards count — is stored with your company's settings on our servers, like the rest of your company's configuration, and is shown to colleagues who have not arranged cards of their own.

How long screens take to appear (since 2026-11-08). When you open the app or click through to another screen, your browser sends us the screen's name with any identifying part removed (for example, "events / [id] / namelist"), whether you are on a laptop or a touch screen, how many milliseconds it took, and which company it was for. It does not record who you are, which event it was, or anything about any guest. We use it only to make the app faster. It goes with the company's data if the company is deleted.

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.

Inside a company, a person can read the records of an event — its guests, their details, rooms and journeys — only if the company has given them access to that event, or their role covers every event (since 2026-09-29). This too is enforced by the database.

TODO — needs legal review before publishing. Whether "access to an event" should be described as a data-minimisation measure, and how it relates to the company's own obligations as controller of its guests' data.

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 and passwords. Data is held in the Mumbai region described above.
  • Vercel — hosting. Serves the app to your browser and runs its server-side code. Since 2026-10-31 that code keeps, in its working memory only, a copy of a sheet a person has just read, so their next read can skip the database while nothing on it has changed. The copy is exactly what that person may see, is never handed to anybody else, never written to disk, and is gone when the server restarts. (Draft wording — for legal review.)
  • Resend — sends the emails your account itself generates: confirming a new address, resetting a password, and inviting a colleague. Resend necessarily sees the recipient's address and the contents of each of those messages (a short notice and a link — never anything from inside the app's records). An invitation to somebody who already has an account also names the company and the person who sent it. Since 2026-09-28 Resend also sends the short notices when a company removes or suspends you, lets you back in, or resets your authenticator app, and the warning to a company that somebody's suspension ends tomorrow (naming that person). Sent from app.teameec.in. Since 2026-09-28 it also sends a short notice when your role at a company changes (naming the new role, not who changed it), and one to each side when a company's ownership is handed over. Since 2026-09-29 it also sends a notice when you are given access to an event (naming the event, the company and your role there), and a reminder the day before access given until a date ends — to you, and to whoever gave it (naming you).

TODO — needs legal review before publishing. A company can now upload a logo, stored with the rest of its data in Supabase and shown only to its own members. It is the company's material rather than personal data, but a logo can contain a person's name or likeness; confirm whether it needs a mention here or only in the terms of service.

  • WhatsApp (Meta) — only when a team member chooses Open WhatsApp chat on a phone number, since 2026-10-15. The app opens a WhatsApp link holding that one number; WhatsApp then has it, as it would if it were typed into WhatsApp by hand. Nothing is sent automatically, and no other detail goes with it.

TODO — needs legal review before publishing. Whether opening a guest's number in the team member's own WhatsApp needs wording beyond this line (the number leaves through the team member's device and account, not EEC's).

  • An uptime checker and a monitoring account — to tell us when the app is down or the database is under strain, since 2026-10-28. The checker asks one address that answers "fine" or "not fine"; the monitoring account reads the database's own measurements (processor, memory, connections). Neither receives any company's or guest's data.

TODO — needs legal review before publishing. Name the two services once chosen, and say whether the checker's request logs (our server's address, the time) need a line of their own.

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.