Every answer the IVR gives traces to one of these. Nothing is scripted.
The demo runs on three sources. Two are real and queried live during every call; one is a clearly‑labeled simulation standing in for a system you'd connect in production. The demo records themselves are synthetic — realistic, but not a real customer's data.
A real Salesforce org, queried live over secure API auth on every call. Identity, prescriptions, order status, and open cases all come from here — change a record and the next call reflects it.
| Object | Fields the IVR reads | Used for |
|---|---|---|
| Contact | Name, Phone, Customer_Type__c, Portal_Type__c, AccountId | Identify the caller; owner vs. prescriber; brand |
| Prescription__c | Pet_Name__c, Medication__c, Dosage_Form__c, Refills_Remaining__c, AutoRefill__c, Last_Order_Status__c, Tracking_Number__c, Cold_Chain__c, Order_Date__c | Answer "where is my order?"; judge on‑track vs. overdue |
| Case | CaseNumber, Subject, Status, Description (open only) | Recognize an existing issue the caller mentions |
To validate: these are demo field names. Map them to your real Salesforce schema (object and field API names) and we point the IVR at yours.
Fourteen Wedgewood policy articles the IVR can consult. For order timing it retrieves the
processing‑time policy (compounded medications typically ship within ~5 business days) and
the system compares that policy to the order's Order_Date__c to decide, in code,
whether an order is on track or overdue. The judgment is a calculation on real data — not a guess,
and not a fixed sentence.
To validate: the processing‑time window and the "overdue" threshold are ours to set — give us your real policy numbers.
The one simulated source. A function returns canned tracking — current status, city, ETA, and a
cold‑chain indicator — keyed by the prescription's Tracking_Number__c. The tool
interface is identical to a live carrier; in production you swap in the real UPS/USPS/carrier feed
and the IVR behaves the same with zero logic change.
To validate: tell us which carrier(s) and API you use and we wire the real one in.
The two phone numbers a call uses (who's calling, which line they dialed) are simulated on the test console so any scenario can be run from one phone. In production they come straight from the real inbound call.