AI receptionist prompt and call-control pattern

This record documents how Cortana Solutions structures an AI receptionist before a controlled pilot: the approved operating brief, conversation rules, system actions, record handling, and conditions that return a call to a person. Recording consent, retention, integrations, and escalation rules must be approved for each implementation. It is a reference architecture, not a deployed-client case study, client-performance claim, or legal opinion.

Situation

A vague prompt can cause inconsistent answers, missed intake fields, or claims the business did not approve.
Recording, transcripts, and summaries create consent, access, retention, and deletion decisions.
Booking, CRM updates, callbacks, and human transfers need explicit rules rather than conversational improvisation.

Approach

An approved operating brief covering business identity, facts, hours, service boundaries, prohibited claims, and uncertainty fallback.
A call flow covering the opening, required intake fields, qualification questions, booking or callback rules, and next-step confirmation.
Optional recording and transcript controls covering disclosure, access, retention, deletion, and review responsibilities.
Deterministic CRM output, urgent-call triggers, human transfer conditions, test calls, and versioned review.

What to prove

Does every answer trace back to an approved business fact or an explicit uncertainty fallback?
Are recording and record-handling controls approved for the locations and systems involved?
Does each completed call produce a visible next step in the booking, callback, or CRM workflow?
Can a caller reach a person when urgency, uncertainty, policy, or customer preference requires it?

Operating answers

Practical controls before a pilot.

What belongs in an AI voice receptionist prompt?

An AI voice receptionist prompt should function as an approved operating brief, not a loose script. It should define the business facts the system may state, required caller questions, booking and routing rules, prohibited claims, uncertainty fallback, CRM fields, and the exact conditions for human transfer.

Approve business identity, services, hours, service areas, pricing boundaries, and allowed disclosures.
Define required intake fields, follow-up questions, booking rules, callback timing, and next-step confirmation.
Test routine, ambiguous, urgent, and out-of-scope calls before expanding use.

Can an AI receptionist record calls?

An AI receptionist can use call recording when the selected platform supports it, recording is enabled, and the business has approved the applicable consent and disclosure process. Audio, transcripts, summaries, access, retention, and deletion should be configured separately rather than treated as one automatic default.

Confirm the consent and disclosure requirements for the callers and locations involved.
Limit access to the people and systems that need the record for an approved purpose.
Set retention, deletion, and review rules before recorded calls begin.

What should happen after an AI receptionist call?

Each completed call should end in an explicit operational state: booked, callback required, transferred, disqualified, or unresolved. The approved contact details, qualification answers, summary, and next task should reach the designated system so a person can review and continue the work.

Write only approved fields to the CRM or scheduling system.
Assign an owner and due time for callbacks or unresolved calls.
Keep exceptions visible instead of silently marking every call complete.

Evidence boundary

What this record does not claim.

This is a reference architecture, not proof of a deployed client implementation, a legal opinion, or a measured customer outcome.

Related capabilities

How this work is structured.

Each industry study maps to the same operating sequence: diagnose the constraint, redesign the workflow, validate the intervention, and keep the economics inspectable.