call-outcome-tracker

---
name: call-outcome-tracker
description: Builds the record of what actually happened to every booking call, booked, no table available, caller changed their mind, lost to a competitor, so a venue can see the pattern instead of relying on what staff remember at the end of a shift. It works out what has to be kept because it is now a contract term, how long the record itself can be kept, and whether the venue even needs a formal data protection register to keep it at all. Use whenever you want to know why calls are not converting into bookings, and before you decide how long to keep the outcome log.
---

# What actually happened to every call that came in

You give this the calls your booking line receives and what happened to each: booked, no table available for the requested time, caller did not proceed, or lost for a stated reason. You get back one structured record per call, a retention rule for the log, confirmation of which details in it are now contract terms rather than notes, and a check of whether this counts as processing a small venue needs a formal register for. It will not let "we think most calls get a table" stand in for an actual count.

## What it does

1. **Record the outcome of every call, not just the ones that booked.** A venue that only logs successful bookings cannot see the calls it lost, which is precisely the information worth having. Every call gets one outcome from a fixed, short list: booked, no availability for the requested time, caller did not proceed, or lost, with a one-line reason where known.

2. **Treat anything promised on the call as a term, because the law already does.** Where a call results in a booking, regulation 13(6) of the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 states that "information provided by the trader to the consumer under this regulation shall be treated as included as a term of the contract." The outcome log is therefore not just a sales record, it is the business's own evidence of exactly what it told a particular caller, which matters if a dispute ever arises about what was agreed.

3. **Decide how long the log is kept, and write the reason down.** Article 5(1)(e) of the UK GDPR requires personal data to be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." An outcome log that still identifies individual callers from two years ago, with no stated reason for keeping it that long, has drifted past what the analysis actually needs.

4. **Check whether a formal written record of this processing is required at all.** Article 30(5) of the UK GDPR exempts "an enterprise or an organisation employing fewer than 250 persons" from the detailed records of processing activities otherwise required, unless the processing carries a likely risk to data subjects, is not occasional, or involves special category or criminal offence data. An ordinary venue logging call outcomes for its own operational review is very likely inside this exemption, and knowing that stops a legitimate record-keeping habit being abandoned out of an unfounded worry about GDPR paperwork.

5. **Count "no availability" separately from "caller did not proceed," because they point at different fixes.** A high rate of "no availability" says the venue needs more capacity, different hours, or a waiting list; a high rate of "caller did not proceed" after availability was offered says something about the offer itself, the price, the wait, or the way it was presented. Folding both into one generic "lost booking" category hides which problem is actually the bigger one.

6. **Review the pattern on a schedule, and compare it against the last period rather than looking at it in isolation.** A single month's outcome log tells you what happened; comparing it against the previous month tells you whether whatever you changed made a difference.

## Then it checks

1. Every call in the period has a recorded outcome from the fixed list, not left blank or marked "other" by default.
2. Every booked outcome has its terms (price, deposit, cancellation position) recorded exactly as stated on the call.
3. A retention period for the log is written down, with a stated reason, and is shorter than "indefinitely."
4. The Article 30(5) exemption has been checked against the actual processing rather than assumed either way.
5. "No availability" and "caller did not proceed" are counted separately, with their own totals, not merged into one lost-booking figure.
6. This period's outcome totals are compared against the previous period's, not reviewed alone.

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.
- Never record an outcome as "other" or leave it blank where the actual outcome is known; the fixed list exists so every call lands somewhere specific.
- Never keep the outcome log, with individual caller detail attached, for longer than a stated, written reason justifies.
- Never merge "no availability" and "caller did not proceed" into a single lost-booking figure; they point at different problems and need separate counts.
- This output is a working document prepared for the owner to check against their own booking records and retention settings, and for their data protection adviser to check where the Article 30 exemption or a longer retention period is in doubt. It applies the Consumer Contracts Regulations and the UK GDPR to a draft tracking process; it is not legal advice and it is not confirmation that a given tracking process complies.

## Built from
- Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, regulation 13, https://www.legislation.gov.uk/uksi/2013/3134/regulation/13/made, read 4 November 2026: the contract-term effect of information given on the call, behind step 2.
- UK GDPR, Article 5(1)(e), https://www.legislation.gov.uk/eur/2016/679/article/5, read 4 November 2026: the storage limitation principle behind step 3.
- UK GDPR, Article 30, https://www.legislation.gov.uk/eur/2016/679/article/30, read 4 November 2026: the small business exemption from a formal processing register, behind step 4.

# call-outcome-tracker

## You are given
A list of booking calls for a stated period: date, time, and the outcome as recorded by staff (free text or already categorised). For booked outcomes, the price, deposit and cancellation position stated on the call. The business's stated employee count. The retention period currently set, or intended, for the outcome log. The previous period's outcome totals, if available.

## Produce
Write into a `./call-outcome-tracker-output/` folder:

1. `outcome-log.csv` with columns: `call_ref`, `date`, `time`, `outcome`, `reason_detail_verbatim`. `call_ref` is O0001 upward. `outcome` is exactly one of `booked`, `no availability`, `caller did not proceed`, `lost`. Any supplied outcome that does not map cleanly onto one of these four is listed in `gaps.md` rather than forced into one.
2. `booking-terms-check.csv`, completed for every `booked` row, with columns: `call_ref`, `price_stated_verbatim`, `deposit_stated_verbatim`, `cancellation_position_verbatim`, `all_terms_recorded`. `all_terms_recorded` is `yes` only where all three preceding columns are non-blank.
3. `outcome-totals.csv` with columns: `outcome`, `count_this_period`, `count_previous_period`, `change`. `change` is the numeric difference, calculated, never estimated, and left blank where no previous period was supplied.
4. `article30-check.csv` with columns: `employee_count`, `processing_occasional`, `risk_to_data_subjects_likely`, `special_category_data_involved`, `exemption_applies`. Same structure and logic as in call-log-and-missed-call-analysis.
5. `retention-record.csv` with columns: `retention_period_stated`, `retention_period_days`, `reason_stated`.
6. `gaps.md` - a numbered list of: any call with no outcome or one that does not map onto the fixed list; any `booked` row with `all_terms_recorded` of `no`; a blank or open-ended retention period; an `article30-check.csv` result of `exemption_applies` being `no`; and, where a previous period exists, any outcome whose count moved by more than a stated threshold without a noted reason.

## Rules
- Codex counts, matches and records. It never decides which of the four outcomes a vague note should map to without asking, never invents a price or deposit figure, and never recommends an operational fix beyond stating the counted pattern.
- Every count and change figure is calculated from the supplied rows, never estimated.
- `no availability` and `caller did not proceed` are always counted and reported separately, never merged into a single lost-booking figure anywhere in any output file.
- Never connect to a booking system or CRM, and never contact a customer.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write; flag rather than correct one in supplied text.
- Every file ends with this line: this is a working document prepared for the owner to check against their own booking records and retention settings, and for their data protection adviser to check where the Article 30 exemption or a longer retention period is in doubt. It applies supplied rules to a draft tracking process and is not confirmation that a given tracking process complies.

## Return
The absolute path of each file written and the row count of each CSV. The outcome totals for this period, and the change against the previous period where supplied. The number of booked calls with incomplete terms recorded, listed by reference. The retention record as written. The Article 30 check result. The `gaps.md` item count in full.