A dental group with four locations in the Phoenix metro deployed one shared AI receptionist in March. Same prompt, same knowledge base, one deployment — that was the selling point: "one brain, four front desks." By June they had a problem no dashboard flagged: the AI was quoting four different cancellation policies, depending on which page of the knowledge base it happened to retrieve from.
The mechanics were boring. Location pages had been written by each office manager. The Downtown page said cancellations inside 24 hours incur a $50 fee. The Arcadia page said $75, plus "after two no-shows we may dismiss you from the practice." The Scottsdale page said "fees may apply at management's discretion" — which the AI, trained to be concrete, resolved into a flat $40. The fourth location's page had never been updated after a policy change and still described a policy discontinued in 2024.
A patient who rotates between locations for scheduling convenience got three different answers in one week: "$50," "actually it's $75," and "we don't charge for cancellations." She posted all three screenshots in a Google review. It's still up.
This is the multi-location policy fork, and it's the natural end state of every "one knowledge base for all our locations" deployment that doesn't have a canonical policy layer. I've now audited it at the dental group, a fitness studio chain (5 gyms), an auto repair group (3 shops), and a restaurant group (7 locations). The numbers are consistent: between 9% and 23% of policy questions received answers that were correct for a location but wrong for the customer's location. Nobody had noticed, because each individual answer looked confident and internally coherent.
Here's the math on why it's expensive. A customer who receives two conflicting answers to the same question trusts neither. In the transcript review at the fitness chain, 31% of customers who hit a contradiction asked the question again — burning minutes of handle time — and 12% of the contradicted cohort mentioned the conflict in a review, a cancellation, or a complaint. You don't lose these customers with one bad answer. You lose them with two correct-looking answers that disagree.
Why one knowledge base almost always forks
Four mechanisms, in order of how often I find them:
1. Location pages edited locally. Each manager owns "their" page and updates it when their policy changes. Nobody downgrades the change to "location-specific" vs "brand policy." Six months later the brand policy changed at HQ and three of five locations updated. The AI retrieves whichever page matches the customer's phrasing best.
2. Copy-paste drift. The chain's template was duplicated per location, then each copy evolved. A rule that started as one sentence ("no refunds on packages") now exists in five slightly different wordings — and one of them, after an edit, dropped the word "on packages." The AI reads it as a blanket no-refund policy. That's how the auto repair group's AI told a customer that packages were non-refundable entirely — the packages were the one thing that was refundable.
3. Unversioned hours and seasonal rules. Holiday hours, summer schedules, seasonal pricing. Each location updates at different times (or not at all). The retrieval layer sees all of them as equally current. The restaurant group's AI quoted three different closing times for the same Friday, per location, two of which were a year out of date.
4. Retrieval doesn't know about geography. The customer asks "what's your cancellation policy?" — no location named. The retriever scores all pages by text similarity and returns whichever wording happens to match. The customer gets a policy for a store 22 miles away. The AI doesn't know it made a choice; to it, there was only ever one answer.
The common thread: the knowledge base stores facts, but nobody defined ownership and scope. The fix isn't better retrieval. It's a canonical policy layer that says which facts are brand-wide, which are location-specific, and what the AI must do when the customer's location is unknown.
The fix: a canonical answer table with scope
Rebuild policy content as a table, not prose pages. This is the structure I deploy:
POLICY TABLE (one row per rule):
| id | scope | question pattern | canonical answer |
|------|--------------|-----------------------|-----------------------------------|
| CXL1 | brand | cancel/reschedule fee | $50 inside 24h, all locations |
| CXL2 | brand | fee exceptions | medical emergency, one waiver/yr |
| NS1 | brand | no-show consequences | 3 no-shows = booking restriction |
| HRS1 | loc:arcadia | hours | M-F 7-7, Sat 8-2, Sun closed |
| HRS2 | loc:downtown | hours | M-F 8-6, Sat 9-1, Sun closed |
| PKG1 | brand | package refunds | unused sessions refundable in 30d |
| SEAS1| loc:scottsdale| summer hours | June-Aug: closed Sundays |
RULES:
- Every row carries a scope. Brand rows must be identical across
every surface. No location page may restate a brand row.
- Every row carries last_reviewed date. Rows older than 90 days
surface in the monthly audit.
- If the customer's question matches a row but their location is
unknown AND the row is location-scoped → ask which location
first. Never guess.
Then the system prompt gets one hard rule: location-scoped questions without a known location get a location question, not a guess. "Which location do you usually visit?" costs one turn. The wrong policy costs a review.
The dental group rebuilt 43 policy facts into 28 brand rows and 15 location rows in one afternoon. The fork rate — transcripts where two policy answers in the same week contradicted each other — went from 4.1% of all transcripts to zero in the six weeks I tracked.
The contradiction audit: 30 minutes, monthly
You can find existing forks before customers do. Pull 40 random policy-question transcripts and run this:
- Cross-location collision. Group transcripts by question topic. If the same question topic received materially different answers across the month (different numbers, different rules), you have a fork. List both answers and their source pages.
- Brand-rule restatement. For every answer about a brand-wide rule, check whether the answer matches the brand canonical text or a location's local wording. Local wording on a brand rule = drift.
- Ghost policies. Grep for policies mentioned in answers that exist on no current page — leftovers from deleted docs the retrieval layer still indexes. (At the restaurant group, 6 of 31 distinct policies the AI quoted existed nowhere in the current knowledge base. They came from a deleted doc still sitting in a vector index.)
- Unknown-location guesses. Count answers to location-scoped questions where the customer never named a location. Each one is the AI silently picking for the customer.
- Stale rows. Any policy answer sourced from a page untouched in 90+ days gets a review flag. Hours and seasonal rules: 30+ days.
The fitness chain ran this in 27 minutes and found 11 forks. Nine were real, live, customer-facing disagreements between locations — including one where the AI charged a member a cancellation fee that only existed at a gym she'd visited once, 14 months earlier.
The location-confirmation script
When the location is unknown and the rule is scoped, the AI needs one rehearsed move:
"That can vary a bit by location — which one do you usually go to?"
And when the customer is comparing locations:
"Downtown waives the first no-show; Arcadia doesn't. Since you move between them, I'll note your question applies to both."
That second script matters more than it looks. Customers who use multiple locations are your highest-value, highest-contradiction-exposure cohort, and naming the difference turns a trap into transparency.
The weekly scorecard
Week of: ______
Policy questions answered: ____
Cross-location contradictions found: ____
Brand rules answered from local wording: ____
Answers citing ghost/deleted sources: ____
Location-scoped Qs answered w/o location: ____
Rows past 90-day review: ____
Customers who asked the same Q twice: ____
The metric that matters most is the first counter. Contradictions found by your audit are cheap; contradictions found by customers are the Google review that quotes both answers side by side. Target: audit finds ≥90% of forks before any customer does — which you can check, because every contradiction the audit missed has a customer transcript attached to it.
Eight weeks after the dental group deployed the table: zero cross-location contradictions, the review with three screenshots got buried under 40 newer reviews, and — the part the owner liked most — their monthly policy updates went from "email all four managers and hope" to editing one table row, scoped, dated, and live in every location's answers within minutes.
The 12-line card
[ ] Every policy fact has a scope: brand or location:id
[ ] Brand rules restated nowhere locally; local rules never brand
[ ] Unknown location + scoped rule → ask, never guess
[ ] Every row carries last_reviewed; 90d audit, 30d for hours
[ ] Contradiction audit: 40 transcripts, 5 checks, monthly
[ ] Ghost policies (deleted-source answers) hunted monthly
[ ] Location-confirmation script rehearsed, one turn, no apology
[ ] Multi-location customers get differences named, not hidden
[ ] Policy updates = one row edit, one owner, no manager email chain
[ ] Retrieval index diffed against live table monthly
[ ] Two contradicting answers in one customer's week = incident
[ ] Fork rate (contradictions / policy Qs) on the ops dashboard
If you only do one thing, search this month's transcripts for your two most-asked policy questions and compare the answers across weeks and locations. In the four chains I've audited, every single one had at least one live fork on their top-three question — and none of them knew until the transcripts were side by side.
The canonical policy table template, the contradiction audit worksheet, and the location-scope prompt block are in the kit I run on deployments: Agent Audit Pack
Top comments (0)