call-overflow-routing

---
name: call-overflow-routing
description: Builds the rule for where a call goes when the main booking line is busy, engaged elsewhere or unanswered, and checks whatever receives it, a second handset, a manager's mobile, or a paid answering service, is actually allowed to hold the caller's details under a proper contract. It will not route an overflowing call to a third party without first checking whether that third party is a data processor who needs a written agreement before it ever hears the phone ring. Use before you set up call forwarding, a shared mobile, or a paid answering service for your booking line.
---

# Where the call goes when the first line is busy

You give this your current overflow setup, every destination a call can land on when the main line is busy or unanswered, and whether any of those destinations is a paid third party rather than someone employed by the business. You get back the routing rule in order, a check of which destinations need a written processing agreement before they are used, and a security note on each route. It will not treat an answering service as a free extra pair of hands with no paperwork attached.

## What it does

1. **Write the routing order down as a rule, not as whoever happens to be free.** A caller who gets a different answer depending on which staff member's phone happened to have signal is not being served by a system, they are being served by luck. The rule states, in order, where an overflowing call goes: a second handset, then a specific mobile, then an answering service, then voicemail, naming each destination and the condition that sends a call to it.

2. **Decide whether each destination is part of your business or a separate one, because that changes what is owed.** Where an overflow destination is a person employed by the venue, the caller's details stay inside the same organisation. Where it is a separate company, a paid answering service, a remote receptionist, a booking platform's call handling, that company is processing the caller's personal data on the venue's behalf, and Article 28(3) of the UK GDPR requires that "processing by a processor shall be governed by a contract...that is binding on the processor with regard to the controller," covering, among other things, "the subject-matter and duration of the processing" and the instructions the processor may act on.

3. **Check the contract exists before the first call is routed there, not after.** Article 28(3)(a) requires the processor to "process the personal data only on documented instructions from the controller." A venue that has signed up to an answering service with a standard terms page and nothing specific about what the service may do with a caller's name, number and booking request has not necessarily met this; the specific instructions and the specific data covered need to be identifiable, even where they sit inside a wider commercial agreement.

4. **Check what happens to the data when the overflow destination is finished with it.** Article 28(3)(g) requires that, at the controller's choice, the processor "deletes or returns all the personal data" after the services end. A venue switching answering services, or dropping one, should know whether the old provider still holds a list of its callers afterwards, and should have chosen deletion or return in the contract rather than leaving it unaddressed.

5. **Keep the route itself secure, whatever it is.** Article 5(1)(f) of the UK GDPR requires personal data to be "processed in a manner that ensures appropriate security." Forwarding a business line to a personal mobile that several staff share the passcode for, or to an answering service accessed through a shared login with no individual accountability, is a security choice worth naming in the rule, not an accident of convenience.

6. **State what the caller is told, since the rule changes who is actually speaking to them.** Where a call lands with a paid answering service rather than venue staff, the caller is entitled to a reasonably clear sense of who they are now speaking to, especially where that person will take a deposit, a card number or a booking in the venue's name.

## Then it checks

1. The routing order is written down, with the condition that sends a call to each destination, rather than left to chance.
2. Every destination that is not a direct employee of the venue is identified and marked as a processor.
3. Every processor destination has a written contract or agreement that names the processing, the data covered and the instructions, dated and on file.
4. The contract or agreement states what happens to caller data when the service ends, deletion or return, rather than leaving it silent.
5. No overflow destination relies on a shared login or shared device passcode with no individual accountability recorded.
6. The caller-facing script for an answering service destination identifies who is actually answering, where that differs from the venue's own staff.

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 route a caller's details to a third party answering service with no written processing agreement in place, however short notice the arrangement is.
- Never describe a paid answering service as "part of the team" in a way that hides from the caller that a separate company is now handling their booking and their data.
- Never leave a processor contract without a stated outcome for the caller data once the arrangement ends.
- This output is a working document prepared for the owner to check against their own call-handling setup and any supplier contracts, and for their data protection adviser to check where a processor agreement is missing or unclear. It applies the UK GDPR to a draft overflow rule; it is not legal advice and it is not confirmation that a given arrangement complies.

## Built from
- UK GDPR, Article 28, https://www.legislation.gov.uk/eur/2016/679/article/28, read 4 November 2026: the processor contract requirements behind steps 2, 3 and 4.
- UK GDPR, Article 5(1)(f), https://www.legislation.gov.uk/eur/2016/679/article/5, read 4 November 2026: the security principle behind step 5.

# call-overflow-routing

## You are given
Every overflow destination the booking line can reach when busy or unanswered, in the order it is tried, and the condition that sends a call to each (no answer after N rings, line engaged, outside opening hours). For each destination: whether it is a venue employee or a separate company, and if separate, its name and whether a written agreement exists. Any existing contract or terms document with that company, as text or a summary. How login or device access to each destination is controlled (individual login, shared login, shared device, personal mobile).

## Produce
Write into a `./call-overflow-routing-output/` folder:

1. `routing-order.csv` with columns: `order_ref`, `destination`, `destination_type`, `trigger_condition`. `order_ref` is 1 upward, in the order a call is tried. `destination_type` is `employee` or `third party`.
2. `processor-check.csv` with columns: `destination`, `destination_type`, `agreement_exists`, `agreement_names_processing`, `agreement_names_data_covered`, `agreement_states_end_of_service_handling`, `verdict`. All `yes`/`no` columns apply only to `destination_type` of `third party`; left blank for `employee` rows. `verdict` is one of `agreement adequate`, `agreement missing or incomplete`, `not applicable - employee destination`.
3. `access-control.csv` with columns: `destination`, `access_method`, `individually_accountable`. `access_method` is one of `individual login`, `shared login`, `shared device`, `personal mobile`. `individually_accountable` is `yes` or `no`.
4. `caller-disclosure-check.csv` with columns: `destination`, `destination_type`, `script_identifies_handler`, `script_text_verbatim`. Applies to `third party` destinations only.
5. `gaps.md` - a numbered list of: any `third party` destination with `verdict` of `agreement missing or incomplete`; any destination with `individually_accountable` of `no`; any `third party` destination with no caller disclosure script or one that does not identify the handler; and any routing order entry with no stated trigger condition.

## Rules
- Codex counts, matches and records. It never drafts a processor agreement, never decides whether an existing agreement is legally sufficient beyond checking the four named elements are present in the text supplied, and never invents a destination or a trigger condition not supplied.
- `agreement_names_processing`, `agreement_names_data_covered` and `agreement_states_end_of_service_handling` are marked `yes` only where the supplied agreement text contains a passage covering that point; the matching passage is quoted in a `matched_text` note alongside each `yes`.
- Never connect to a phone system, a CRM or a third party answering service, and never forward, dial or route an actual call.
- 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 call-handling setup and any supplier contracts, and for their data protection adviser to check where a processor agreement is missing or unclear. It applies supplied rules to a draft overflow setup and is not confirmation that a given arrangement complies.

## Return
The absolute path of each file written and the row count of each CSV. The routing order as written. Every third party destination and its `processor-check.csv` verdict. The number of destinations with no individual accountability on access. The caller disclosure result for every third party destination. The `gaps.md` item count in full.