This page is for you to validate. It describes exactly how the demo IVR identifies a caller
and chooses where to route them. We modeled it on your existing flow, with a few deliberate
clean-ups noted in amber. If any step doesn't match how
Wedgewood actually works — or should work — tell us and we'll change it. Nothing here is fixed.
The IVR gathers identity from two things: the number the caller is calling from
and, if we don't recognize it, the account number they tell us. The line they dialed
sets the brand (Wedgewood vs. Blue Rabbit) — unless the customer's own record says otherwise.
Decision
Identified / proceed
Hand to a person
Step 1 — Recognize the caller's number
Caller calls in
We take the caller's phone number and standardize its format (e.g., 404‑609‑1991 → +14046091991).
Does this number match a customer record?
We look for a customer whose phone number equals the caller's number.
Exactly one match
Recognized. Greet them by name and continue. → Step 3
More than one match
Two people share this number — we do
not guess. Hand to a person with what we know.
No match
Unknown caller. → Step 2
To validate: in the demo we match on the Contact's Phone field. Your production
process matches four phone fields (Asst, Other, Phone, Primary Contact — all E.164). Confirm the
exact fields and order you want us to search.
Step 2 — Unknown caller identifies themselves
Are you a pet owner or a prescriber?
The caller states their role first (this steers the rest of the conversation).
"What's the phone number on your account?"
The caller says the number. We read it back digit‑by‑digit and get a yes before looking anything up.
Does that number match exactly one account?
Exactly one
"Ok, I've got you — welcome back." Identified. → Step 3
None, or more than one
Try again — up to
3 attempts total — then hand to a person.
To validate: 3 attempts, confirm-back before searching, and "ambiguous always goes to a
person." These mirror your documented rules — confirm they're still correct.
Step 3 — Decide the brand (Wedgewood vs. Blue Rabbit)
Does the customer's record name a brand/portal?
Yes — record wins
Use the brand on the record (e.g., a Blue Rabbit customer is treated as Blue Rabbit)
even if they dialed the other line.No brand on record
Use the brand of the
line they dialed.
To validate: the customer's record overrides the dialed line. This matches your Portal_Type
override — confirm the precedence is right (record beats line).
Step 4 — Route to the right place
The AI establishes the facts; the phone system does the routing.
The AI never picks a queue — it records who the caller is, their brand, and what they want. Fixed rules then choose the destination, so routing is predictable and auditable.
| If the caller is… | They go to… |
|---|
| A prescriber (any brand) | Prescriber queue |
| A Blue Rabbit pet owner | Blue Rabbit queue |
| A Wedgewood pet owner | Wedgewood support queue |
| Unidentified, ambiguous, or anything unclear | Wedgewood support queue (a person always gets it — no dead ends) |
To validate: these are the demo's queues. Tell us your real queues/skills and the exact
intents that should reach each, and we map them.
The rules in plain English (the part to challenge)
1. A recognized number is greeted by name with no questions asked.
2. If a number matches more than one customer, we never guess — a person takes it.
3. An unknown caller states their role, then gives an account number we read back and confirm before searching. Three tries, then a person.
4. The customer's own record decides the brand; the dialed line only decides it when the record doesn't.
5. The AI gathers facts; deterministic rules route the call. The AI never chooses a queue.
6. No dead ends — every path a caller can take ends with either a resolved answer or a person, never a hang‑up on an error.
What we cleaned up vs. the original flow (for your sign‑off): your existing process searches
contacts and accounts with slightly different fields and had a couple of inconsistencies (a count
that filtered on active/owner while the fetch did not; a duplicate dead branch). The demo uses one
consistent lookup in both places. If you'd rather we reproduce the original behavior exactly —
quirks included — we will. Your call.