regulars-list

---
name: regulars-list
description: Turns the people who came to one night into a list you may lawfully email again, by recording for every name where the address came from, which PECR route permits the next message, what they were told when they gave it, and who must be removed. Produces the sign up wording, the privacy line and the unsubscribe handling. Use before you email anyone about the next event.
---

# Turn one good night into the list that fills the next one

You give this the sources you actually hold, being the ticket buyers, the booking system, the sign up sheet, the prize draw entries and the business cards in the till drawer. You get back one list split by what the law permits for each person, the route named per row, the wording that was or should have been shown at the point you collected the address, the privacy information the collection needs, and a removal list you must act on before anything is sent. It will not merge in a bought list, and it will not tell you it is safe to email someone it cannot show a route for.

## What it does

1. **Sort every name by where the address actually came from, before deciding anything about sending.** One row per person, and the source is a specific event and mechanism, not a category: bought a ticket for the night on 14 November through the booking system; wrote an address on the sign up sheet on the bar; entered the prize draw; enquired about a private hire and did not book; handed over a business card; was added by a member of staff from a table booking. The permission that follows depends entirely on which of these it was, and a list that has already been merged into one spreadsheet cannot be sorted back out afterwards. If provenance is already lost for a group of names, say so and treat the group as having no route.

2. **Name the route for each row, because there are only two and the difference decides everything.** Regulation 22(2) of the Privacy and Electronic Communications (EC Directive) Regulations 2003 is the default: "a person shall neither transmit, nor instigate the transmission of, unsolicited communications for the purposes of direct marketing by means of electronic mail unless the recipient of the electronic mail has previously notified the sender that he consents for the time being to such communications being sent by, or at the instigation of, the sender." The alternative is the soft opt in at regulation 22(3). Every row is `consent`, `soft opt-in` or `no route`. A row that cannot be assigned one of the first two is not a marginal case to be decided later, it is a name you may not email.

3. **Test the soft opt in against all five of its conditions, not the one people remember.** The ICO sets them out: "You obtained the recipient's contact details", "You did so while selling or negotiating to sell a product or service", "You are only marketing your similar products and services", "You provided the recipient with an opportunity to refuse or opt out when you collected their contact details", and "You give the recipient an opportunity to refuse or opt out in every subsequent communication." The fourth is the one that fails most often in hospitality, because an address taken over the phone during a booking with nothing said about marketing has no opt out at collection and therefore no soft opt in, however genuinely the person is a customer.

4. **Do not stretch "negotiations for a sale" and do not stretch "similar".** The ICO is precise on the first: "A person doesn't need to actually buy anything from you. It's enough if 'negotiations for the sale' took place. This means that they must actively express an interest in buying your products or services." Someone who enquired about a Christmas party and went elsewhere qualifies; someone who was in the building qualifies for nothing. On the second it says the test is "whether, based on previous interactions, people reasonably expect direct marketing about your product or service." For a venue that ran a quiz night, another quiz night is similar and a wedding brochure is a stretch worth writing down as a decision rather than assuming.

5. **Bin every address you did not collect yourself.** The ICO: "You must obtain the contact details directly from the person you want to send the electronic mail marketing to. The soft opt-in doesn't apply if someone else obtains the contact details for you, even if it's another organisation within your own group structure." So the promoter's ticket list, the other venue's mailing list, the addresses a supplier offered, and anything bought are not usable on the soft opt in, and consent obtained by somebody else for their own sending is not consent for yours. This is the step that removes the largest number of rows and saves the most trouble.

6. **Write down what each person was actually told when they gave you the address, and where that wording still exists.** Article 13 of the UK GDPR requires that, where personal data are collected from the person, they are given the controller's identity and contact details, the purposes and legal basis of the processing, the retention period or the criteria for it, and their rights including the right to complain to the Commissioner. A sign up sheet headed only "email" told them nothing. Where the wording exists, keep a copy with its date. Where it does not, record that, because it decides whether the fourth soft opt in condition was met and it is the first thing anyone will ask for later.

7. **Write the sign up wording and the privacy line you will use from now on, and make the opt out visible at the point of collection rather than afterwards.** The wording names the venue, says what will be sent and roughly how often, gives the opt out at the point of signing, and links to the privacy information. Article 21(4) of the UK GDPR is explicit about the objection right: "At the latest at the time of the first communication with the data subject, the right referred to in paragraphs 1 and 2 shall be explicitly brought to the attention of the data subject and shall be presented clearly and separately from any other information." The ICO adds the sender side: "You must not disguise or hide your identity in messages to either type of subscriber. You must provide a valid contact address for recipients to opt out or unsubscribe."

8. **Build the removal list first and act on it before the send, not after the replies.** Article 21(2) of the UK GDPR gives an unqualified right: "Where personal data are processed for direct marketing purposes, the data subject shall have the right to object at any time to processing of personal data concerning him or her for such marketing, which includes profiling to the extent that it is related to such direct marketing." Article 21(3): "Where the data subject objects to processing for direct marketing purposes, the personal data shall no longer be processed for such purposes." There is no balancing test and no grace period. Every previous unsubscribe, every "take me off this", every verbal request at the bar and every bounce that indicates a dead address goes on the list, and the list is applied before the send rather than reconciled after it.

9. **Write the list out with the route, the source and the evidence on every row, and keep the count that matters.** The deliverable is not a column of addresses. Each row carries the name, the address, the source event and date, the mechanism, the route, the evidence for that route and where it is held, the wording shown at collection, the date of the last send, and the removal status. Then two numbers on the front: how many rows you may lawfully email, and how many you hold but may not. The second number is the one that tells an owner whether the sign up process is working, and it is the only honest way to stop a list of eight hundred addresses being described as a list of eight hundred addresses.

## Then it checks

1. Every row names a specific source event and a specific collection mechanism, and no row reads "customer", "from the system" or "historic".
2. Every row is assigned exactly one of consent, soft opt in or no route, and no row is left pending, probable or to be decided.
3. Every soft opt in row is tested against all five conditions individually, with the fourth condition evidenced by the wording shown at collection and where that wording is held.
4. No row on the sendable list came from a third party, another organisation, a promoter, a supplier or a purchase, and every such row is recorded as no route rather than removed silently.
5. The removal list is compiled from every channel including verbal requests and bounces, is dated, and has been applied to the sendable list before any send is prepared.
6. The front of the list states the number of rows that may be emailed and the number held but not emailable, and the two add up to the total held.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is. An email written as though the owner wrote it goes to the owner first.
- Refuse to add, merge, enrich or email any address obtained from a purchased list, a promoter, another venue, a supplier, a scraped source or a social media follower export. The soft opt in does not apply to details somebody else collected, and consent given to another organisation is not consent given to you.
- Refuse to guess a route. A row whose provenance cannot be evidenced is `no route`, and no argument about how obviously the person is a regular changes that.
- Never treat silence, a past booking, a table reservation or a tagged photograph as consent. Consent has to have been given, and the absence of a refusal is not the presence of a permission.
- Never remove a person from the removal list because they came back, spoke to you, or booked again. An objection stands until that person themselves asks to be added again, and reinstating somebody because the room was quiet is exactly the complaint the ICO receives.
- Never state an open rate, a click rate, a list growth benchmark or a typical unsubscribe rate for a single independent venue. No such published figure exists and an owner who targets a borrowed number will damage a healthy list chasing it.
- Never state that the list is compliant or that a send is lawful. This file records routes and evidence so that the owner and their adviser can decide; it does not decide.
- This output is a working document prepared for the owner to check against their own booking system, sign up records and privacy notice, and for their data protection adviser or trade body to check before anything is sent. It applies published rules to the records supplied; it is not legal advice and it does not certify that any send complies with PECR or the UK GDPR.

## Built from
- The Privacy and Electronic Communications (EC Directive) Regulations 2003, regulation 22, https://www.legislation.gov.uk/uksi/2003/2426/regulation/22 and https://www.legislation.gov.uk/uksi/2003/2426/regulation/22/made, read 16 September 2026: the consent rule in regulation 22(2) and the three soft opt in conditions in regulation 22(3), which are steps 2 and 3.
- Information Commissioner's Office, "How do we comply with the PECR electronic mail marketing rules?", https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/how-do-we-comply-with-the-pecr-electronic-mail-marketing-rules/, no publication date shown on the page, read 16 September 2026: the five condition list in step 3, the meaning of negotiations for a sale and of similar products and services in step 4, the obtain directly rule in step 5, and the identity and valid contact address requirement in step 7.
- Information Commissioner's Office, "Electronic mail marketing", Guide to PECR, https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/, no publication date shown on the page, read 16 September 2026: the plain statement of the soft opt in and the requirement to give "a clear chance to opt out, both when you first collected their details, and in every message you send", behind steps 3 and 7.
- UK General Data Protection Regulation, Article 13, https://www.legislation.gov.uk/eur/2016/679/article/13, read 16 September 2026: the information that must be given at the point of collection, in step 6.
- UK General Data Protection Regulation, Article 21, https://www.legislation.gov.uk/eur/2016/679/article/21, read 16 September 2026: the unqualified right to object in paragraph 2, the consequence in paragraph 3 and the duty to bring the right to attention clearly and separately in paragraph 4, in steps 7 and 8.

# regulars-list

## You are given
Every source of email addresses the UK hospitality business actually holds, each supplied as its own separate file and never pre-merged: the ticket buyer export with the event name and date, the booking system export, the sign up sheet transcriptions with the date each sheet was on the bar, the prize draw entries, the enquiry records, and any addresses held by a member of staff. For each source: who collected it, by what mechanism, on what date, and the exact wording shown or read to the person at the point of collection, with a copy of that wording or a note that none exists. The venue's current privacy information and its version date. The existing unsubscribe records, any verbal removal requests with the date and who took them, and the bounce log. The previous send log if one exists. And the judgements already made by Claude: the route assigned to each row, the reason for each `no route` assignment, and the decision on what counts as similar products and services for this business.

## Produce
Write into a `./regulars-list-output/` folder:

1. `sources.csv` with these columns in this order: `source_ref`, `source_name`, `source_event`, `source_date`, `mechanism`, `collected_by`, `collected_directly_by_this_business`, `rows_supplied`, `wording_at_collection_verbatim`, `wording_copy_held`, `wording_location`. `source_ref` is S001 upward. `mechanism` is exactly one of `ticket purchase`, `table booking`, `sign up sheet`, `prize draw entry`, `enquiry not booked`, `business card`, `added by staff`, `third party list`, `unknown`. `collected_directly_by_this_business` and `wording_copy_held` are each `yes` or `no`.
2. `list.csv` with columns: `row_ref`, `name`, `email`, `source_ref`, `source_event`, `source_date`, `mechanism`, `route`, `route_reason`, `evidence_description`, `evidence_location`, `wording_shown_at_collection`, `opt_out_offered_at_collection`, `last_sent_date`, `removal_status`, `sendable`. `route` is exactly one of `consent`, `soft opt-in`, `no route`. `opt_out_offered_at_collection` is `yes`, `no` or `not recorded`. `removal_status` is exactly one of `active`, `objected`, `bounced`, `duplicate`. `sendable` is `yes` or `no`, and is `yes` only where `route` is `consent` or `soft opt-in` and `removal_status` is `active`.
3. `soft-opt-in-test.csv` with columns: `row_ref`, `condition_1_details_obtained`, `condition_2_sale_or_negotiations`, `condition_3_similar_products`, `condition_4_opt_out_at_collection`, `condition_5_opt_out_every_message`, `all_five_met`, `first_condition_failed`. One row for every row assigned `soft opt-in` and every row considered for it and rejected. Each condition column is `met`, `not met` or `not evidenced`. `all_five_met` is `yes` or `no`.
4. `removal-list.csv` with columns: `email`, `name`, `objection_date`, `objection_channel`, `recorded_by`, `wording_verbatim`, `applied_to_list_date`. `objection_channel` is exactly one of `unsubscribe link`, `reply`, `verbal`, `in person`, `bounce`, `other`. Every email in this file has `sendable` of `no` in `list.csv`.
5. `collection-wording.md` - the sign up wording and the privacy line as supplied by the owner, reproduced verbatim under two headings, with the version date and where each will be displayed. Written empty with a note if none was supplied.
6. `counts.csv` with columns: `metric`, `figure`. One row for each of: total rows held, rows sendable, rows held but not sendable, rows by route (three rows), rows by mechanism (one row each), rows removed by objection, rows removed by bounce, duplicates removed, and rows whose provenance could not be established.
7. `gaps.md` - a numbered list of: every source with no wording copy held; every source not collected directly by this business; every row with `route` of `no route` grouped by reason; every soft opt in row where any condition is `not evidenced`; every row with `opt_out_offered_at_collection` of `not recorded`; every objection with no `applied_to_list_date`; any bounce not carried into `removal-list.csv`; any missing sign up wording or privacy line; and any source whose `rows_supplied` does not reconcile to the rows present in `list.csv`.

## Rules
- Codex measures, records and checks. It never invents, never rewords the owner's wording, and never makes the judgement that was supplied to it. Collection wording is recorded exactly as written, including punctuation and capitalisation.
- Never assign, upgrade or infer a route. Routes are supplied. A row arriving with no route is written as `no route` and listed in `gaps.md`.
- Never mark a row `sendable` where the route is `no route`, where any soft opt in condition is `not met` or `not evidenced`, or where `removal_status` is anything other than `active`.
- Never include a row from a source where `collected_directly_by_this_business` is `no`. Such rows are written into `list.csv` with `route` of `no route` and `sendable` of `no`, never omitted, so that the count of what is held but unusable stays honest.
- Never remove a row from `removal-list.csv`, never set `sendable` to `yes` for an email that appears in it, and never reinstate a row on the basis of a later booking, visit or interaction.
- Never merge, deduplicate across sources, or enrich the list from any external source, lookup, social platform or data provider. Duplicates within the supplied files are marked `duplicate` in `removal_status` and counted, not deleted.
- Never send, upload, sync or connect to any email platform, CRM or booking system. Every file produced is a list for a person to check before anything is sent.
- Never write an open rate, a click rate, an unsubscribe benchmark, a list growth figure or any industry average. No such published figure exists for a single independent venue and none is to appear in any file.
- Never record the list as compliant, lawful or safe to send. The files record routes and evidence; they do not reach a conclusion.
- Counts are counted, not estimated, and `rows sendable` plus `rows held but not sendable` must equal `total rows held`. Where they do not, the discrepancy is the first item in `gaps.md`.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write, and any supplied wording containing one is recorded verbatim and flagged in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check against their own booking system, sign up records and privacy notice, and for their data protection adviser or trade body to check before anything is sent. It is not legal advice and it does not certify that any send complies.

## Return
The absolute path of each file written, the row count of each CSV, total rows held, rows sendable and rows held but not sendable with confirmation that the two sum to the total, the count by route and by mechanism, every source not collected directly by this business with its row count, every source with no wording copy held, the number of soft opt in rows failing at each condition with the first condition failed named, the removal list row count with the breakdown by channel and the earliest objection not yet applied, the number of duplicates marked, the number of rows whose provenance could not be established, whether the sign up wording and privacy line were supplied, and the `gaps.md` item count.