Clinic decision tool / 01
Test the whole call journey. Not just the voice.
A polished demo is a starting point. A useful pilot shows where a caller ends up when the answer is unclear, the calendar is unavailable, or a person needs to step in. This plan helps your team agree on the test before routing live enquiries.
A practical planning tool · No patient data needed · No outcome promise
Decide what may happen before a call arrives.
Write down the administrative tasks in scope, the questions that go to staff, and the information the assistant may use. Do not infer a feature from a sales page: ask the provider to demonstrate your proposed configuration.
In scope, if demonstrated
- Answer approved practice-information questions.
- Take an appointment request or pass it to reception.
- Record a callback request using only agreed fields.
Keep a person responsible
- Clinical questions and uncertain answers.
- Urgent concerns under your clinic’s own escalation policy.
- Changes to hours, fees, schedules and contact details.
These are test categories, not claims about what DrKing currently does in every installation. The practice must approve its own scope and professional obligations.
A test matrix that checks the destination.
Use fictional callers, an approved test number and an isolated calendar or message destination. Record what happened in the connected system—not only what the assistant said. Do not call emergency services or use a real patient record to test a scenario.
| Scenario | Expected destination to define | Evidence to inspect |
|---|---|---|
| Routine opening-hours enquiry | Approved answer or staff handoff | Answer matches the current practice information |
| Appointment request | Confirmed booking or an explicit request for staff | Actual test-calendar entry or assigned message |
| Caller asks for a person | Agreed transfer or callback path | Connection, message receipt and owner |
| Unapproved or ambiguous question | Admit uncertainty and refer onward | No improvised clinical or pricing answer |
| Connected system unavailable | Do not imply a booking succeeded | Fallback message and recovery owner |
| Outside staffed hours | Approved after-hours path | Next-business-day task or on-call route, as configured |
Mark each scenario demonstrated, not demonstrated, failed, or out of scope. A spoken promise is not proof that the downstream action occurred.
Use a simple pass, revise, or stop decision.
Do not set a universal accuracy percentage. Agree your own acceptance criteria and the person who can approve them. Keep the test record free of real patient details.
Proceed only if
Each in-scope path has a witnessed outcome, the team understands its exceptions, and the owner accepts the data and handoff arrangements.
Revise or stop if
A booking is claimed without confirmation, an uncertain answer is presented as fact, or a transfer has no known destination or fallback.
A pilot has an owner after launch.
Assign someone to update approved answers and routing, review failed handoffs, and decide whether to expand or reverse the pilot. Compare observations with your starting call process; avoid promising savings from a demonstration.
Bring your test plan to the demo.
Ask the DrKing team to show which proposed workflows can actually be demonstrated for your practice. Availability and configuration need to be confirmed, not assumed.