Voice Agents for UK Franchise Groups: Multi-Location Setup

A 15-location UK gym franchise had one voice agent running outbound from a single London 020 number. Answer rate in their North West locations sat at 14%. In London: 31%. The only variable was caller ID. Prospects in Manchester saw a 020 number, assumed a sales call from head office, and hung up before the agent reached the offer. After provisioning local 0161 and 0114 numbers per region, North West answer rate moved to 27% in three weeks — no script change, no new model, no prompt engineering. Just the right number showing in the right region.

That 93% lift came from a telephony config change. It also exposed how much multi-location deployments differ from single-site ones. Copying a working single-site agent across 15 locations is not a scale strategy. Here is what the multi-location stack actually requires.

Why single-site voice agent architecture breaks when you add a second location

A single-location voice agent typically runs with one Twilio number, one agent config, one calendar integration, and one Postgres schema. The location name and business context are baked into the system prompt. That works until you open a second site.

The problems compound quickly:

• Caller ID mismatch: Prospects in Birmingham calling back a missed call from a London 020 number see "London" in their call history. For local service businesses — gyms, dental practices, estate agents — this erodes trust before the callback conversation begins.
• Config bleed: If the system prompt says "we're at Canary Wharf" and the agent is calling leads from Sheffield, the agent sounds wrong in its first sentence.
• Calendar routing failure: A single booking URL sends all appointments to one calendar. The Leeds site manager ends up triaging London bookings and vice versa.
• Data aggregation without isolation: If all 15 sites write call logs to the same Postgres table without row-level security, a franchisee in Bristol can, depending on your query layer, see call records from Cardiff.

The fix is not a separate agent per site. That path leads to 15 manually maintained configs, stale scripts, and a rollout process that takes days. The right approach is a config layer that parameterises everything site-specific while the underlying flow logic stays shared.

Per-location number pools: local caller ID provisioning in Twilio for UK geographic numbers

UK geographic numbers follow Ofcom's numbering plan. The 01 and 02 number ranges are allocated by geography: 0161 is Manchester, 0113 is Leeds, 0114 is Sheffield, 0117 is Bristol. These prefixes carry local recognition in a way that 03 or non-geographic numbers do not.

Provisioning in Twilio requires a regulatory bundle for GB local numbers with address verification per region. For a 15-location rollout, use a single Twilio account with numbers tagged by location rather than 15 separate subaccounts — subaccounts add billing overhead and complicate aggregate reporting without meaningful isolation benefit at the number-pool level.

For outbound dialling, Twilio's CallerId parameter sets what the prospect sees. Here is a minimal Node.js function for selecting the right outbound number at call time:

// number-selector.js
const LOCATION_NUMBERS = {
  london:     '+442071234567',
  manchester: '+441611234567',
  sheffield:  '+441141234567',
  leeds:      '+441131234567',
  bristol:    '+441171234567',
};

function getCallerId(locationKey) {
  const number = LOCATION_NUMBERS[locationKey];
  if (!number) {
    throw new Error(`No number configured for location: ${locationKey}`);
  }
  return number;
}

One number per site is the minimum. For sites running more than 200 outbound dials per day, provision two numbers to avoid carrier rate limiting and maintain PECR-compliant call pacing. New numbers also require a warm-up period before high-volume use — the process and UK-specific recovery steps are covered in our post on phone number warm-up and spam flag recovery. The full dial-rate and SIP cost breakdown is in our post on SIP trunking costs for UK voice agents.

Configuration templating: the YAML structure that lets one flow definition serve 15 locations with local variables

The core flow logic — qualification questions, objection handling, transfer conditions — is identical across all 15 sites. What changes is: the outbound number, the booking URL, the location name in the script, and site-specific operating hours.

A templated YAML config per location handles all of this:

# configs/locations/manchester.yaml
location_id: manchester
display_name: "Manchester Deansgate"
outbound_number: "+441611234567"
timezone: "Europe/London"
opening_hours:
  mon_fri: "07:00-22:00"
  sat: "08:00-20:00"
  sun: "09:00-18:00"
booking:
  calendar_id: "manchester-gym-bookings"
  slug: "manchester-deansgate"
agent:
  base_template: "gym-membership-outbound-v3"
  overrides:
    system_prompt_vars:
      location_name: "Manchester Deansgate"
      postcode_area: "M3"
      local_transport: "Deansgate Metrolink"

The base_template field references a shared Retell agent config stored centrally. At runtime, the agent loader merges the base prompt with the location-specific system_prompt_vars. Prompt updates — new objection handling, revised pricing — deploy once and reach all 15 sites in a single release.

Adding a new site means creating one new YAML file. The loader validates against a JSON schema and refuses to start if required keys are missing. Secrets (booking API credentials, Twilio auth tokens) are injected at runtime from a secrets manager, never stored in the YAML. For the full call-flow design approach that underpins this, see our call flow design for voice agents post.

Data isolation requirements: GDPR and franchisee data segregation in a shared agent infrastructure

Under UK GDPR, the franchisor and each franchisee are likely to be independent data controllers for their respective call data. The ICO's guidance on controllers and processors is clear: where two organisations each determine purposes and means for the same data, both are controllers. A Bristol franchisee cannot rely on the franchisor's privacy notice to cover outbound calls made on behalf of their site.

The infrastructure implications:

• Row-level security in Postgres: Tag every call record with franchise_id. Add a row security policy restricting franchisee-level database users to their own rows. A shared calls table without RLS is a compliance liability.
• S3 path isolation: Store call recordings at s3://qa-voice/{franchise_id}/{call_id}.mp3. IAM policies restrict each franchisee service account to its own prefix.
• Separate data processing agreements: If the central platform processes calls on behalf of franchisees, a DPA is required between the franchisor and each franchisee.
• Per-site retention schedules: A Cardiff franchisee applying a 90-day retention policy should not be overridden by the franchisor's 12-month default. Implement per-franchise_id retention configuration in your data lifecycle layer.

Booking system integration across locations: routing to the right calendar without a central dispatch layer

A central booking dispatcher seems tidy until you account for what it adds: 200–400ms of latency per booking confirmation and a single point of failure that takes every site down together. The pattern that works better is resolving the caller's location at the start of the call — from the outbound number metadata, not from asking the caller — and injecting the correct calendar ID directly into the booking tool call.

// booking-resolver.js
async function resolveCalendarId(locationId) {
  const config = await getLocationConfig(locationId);
  return config.booking.calendar_id;
}

// In your Retell tool definition:
{
  "name": "book_appointment",
  "parameters": {
    "calendar_id": {
      "type": "string",
      "description": "Auto-populated from location config — do not prompt the caller"
    },
    "preferred_time": { "type": "string" },
    "contact_name":   { "type": "string" }
  }
}

The calendar_id is never exposed to the agent's LLM as a decision it needs to make. The middleware injects it before the tool call executes. This blocks the failure mode where a misconfigured prompt causes the Manchester agent to book appointments into London slots — something that actually happened in an early version of this deployment before the injection pattern was added.

Multi-location QA: aggregate scoring with per-location drill-down and the alerting threshold per site

Call QA across 15 sites requires two views: the aggregate (are quality bars being met overall?) and the per-site drill-down (which site is drifting?).

The alerting threshold is where most teams get this wrong. A global alert — "booking rate below 20%" — fires constantly for high-volume sites and never fires for low-volume ones. Set thresholds relative to each site's own 7-day rolling average. A site that normally converts at 18% dropping to 11% is an incident. A site that normally converts at 12% sitting at 10% is noise. For the concurrency and batching architecture that sustains multi-site dial volumes without carrier pushback, see our post on voice agent dialler concurrency and batching.

The full QA scorecard structure, including the rubric prompt template, is documented in our post on voice agent QA scorecards. For multi-location deployments, every query in that setup gets a location_id filter added.

Franchisor compliance controls: what head office retains and what each franchisee configures locally

Head office needs to enforce two things: the brand script and the QA floor. Everything else can be franchisee-configurable.

Franchisor controls (locked in base config): - Core qualification script and required compliance phrases - PECR-compliant consent capture flow - DNC list (national TPS suppression plus franchisor-level opt-out list) - Minimum call recording retention period for dispute resolution - Transfer-to-human triggers and escalation paths

Franchisee configures locally: - Operating hours and voicemail fallback behaviour - Local promotions and site-specific offers - Booking URL and calendar routing - Language preferences (Welsh for applicable sites in Wales)

The base config is versioned and deployed by the franchisor. Franchisee overrides are additive — they add fields but cannot override locked ones. Implement this with a config merge order: base → regional → site, with a locked: true flag on any field the franchisor controls. A franchisee who removes the DNC check from their config should get a validation error, not a silently broken compliance flow.

What changed in 2025–2026: Twilio regional numbers and Retell multi-agent workspace features

Two developments have directly changed how multi-location stacks are built.

Twilio UK regulatory bundles: In 2025, Twilio consolidated the regulatory documentation process for UK geographic numbers. The updated regulatory bundle flow allows bulk address verification for multi-site operators, cutting provisioning time for a 15-location rollout from 3–4 weeks to under a week. Previously, each new area required a separate support ticket and manual review cycle.

Retell multi-agent workspaces: Retell introduced workspace-level agent management in 2025, allowing teams to deploy multiple agents with shared knowledge bases but separate phone number bindings. This fits the franchise model: one workspace per franchisor, separate agent instances per site sharing the same flow definition. Per-agent analytics are available at the instance level, which gives the per-location drill-down without requiring a custom analytics build.

Counterpoint worth testing: Not every franchise use case benefits from local caller ID. Ofcom's research on unsolicited calls and number presentation shows that awareness of number spoofing is increasing among UK consumers. In some demographics — particularly over-55s who've been targeted by scam calls using local numbers — a local number is now more suspicious, not less. Before committing to full regional number provisioning, run a two-week A/B test: local number vs. 03 number for the same site. The gym client's data favoured local numbers for their 25–40 demographic. That result does not generalise automatically.

Good / Bad / Ugly: three multi-location deployment architectures and what broke at scale

Good: One shared agent with per-location config injection

One Retell agent definition. One YAML config per site. The middleware injects location variables before each call starts. Prompt updates deploy once and propagate to all 15 sites. Maintenance overhead is low. The one real risk is that a bad prompt change affects all sites simultaneously — mitigate this with a staging environment that mirrors the full 15-site config before any production deploy.

Bad: 15 separate Retell agents, manually maintained

One agent clone per location, for "maximum isolation." In practice: when the offer changed in month 3, the ops team updated 15 agent configs individually. Two sites ran the old offer for 11 days before anyone noticed. A pricing mistake on one site required checking all 15 to confirm the others were correct. Rollout coordination became a part-time job. The isolation benefit — the ability to change one site without touching others — is real but can be achieved through the config override layer without copying the full agent definition.

Ugly: Shared single-tenant infrastructure with no data isolation

One Postgres table, one S3 bucket, no row-level security. Call data for all 15 sites mixed in the same store. When a Bristol franchisee submitted a GDPR data subject access request, the only extraction method was a manual triage of the full call log — over 40,000 records across all sites. The inability to isolate one data subject's records in a reasonable timeframe is itself a compliance failure under Article 5(1)(e). The fix required a data migration and two weeks of downtime across the platform. Isolation is not a nice-to-have for multi-entity deployments. It is the baseline.

For a worked example of voice agent infrastructure at this scale, see our voice AI and document analysis case study.