This is a product-independent setup process for businesses. Exact menus and features vary by supplier. A configuration is ready only when the saved outcome and the human follow-up process have been checked; a working greeting is not sufficient evidence.
Key takeaways
The main points for configuring an AI phone assistant are:
- Direct bookings or CRM updates need additional permissions, confirmed system results and a clear alternative when something fails.
- The setup runs through eight steps: conversation brief, approved knowledge, introduction, fields and actions, number and schedule, a worked example, ownership, and approval with monitoring.
- A configuration is ready only when the saved outcome and the human follow-up process have been checked; a working greeting is not sufficient evidence.
01 / 10
1. Write a short conversation brief
Describe the assistant's assignment on one page. A conversation brief for an AI phone assistant covers these points:
- business identity
- audience
- language
- permitted tasks
- prohibited promises
- available handover destinations
- when the assistant answers
- who processes the work it creates
A concrete brief could say: “The assistant collects service enquiries outside office hours. It asks for a name, the request and a confirmed callback number. It can state approved opening hours. It does not promise prices or appointments. Open requests go to the service queue.” Each boundary can later be tested separately.
Have the person responsible for the work review the brief. You cannot clarify your internal rules simply by giving the assistant longer instructions. If staff currently give contradictory answers, establish the operating rule before trying to automate it.
02 / 10
2. Build knowledge from approved information
Reviewed sources. Use current, manageable information about services, locations, opening hours and common questions. Importing an entire website without review can introduce conflicting instructions, expired offers and information intended for another branch.
Owner and validity. Give important entries an owner and a validity context. Holiday hours belong to specific dates; prices need a defined service scope and applicable conditions. The assistant should be able to treat missing information as unknown and collect a question for staff.
Similar service names. Pay attention to similar service names. If maintenance, repairs and emergency attendance have different owners, the knowledge should explain that difference. Short, concrete operating rules are often more useful than lengthy marketing descriptions.
Updates. Define how updates reach the assistant. If a temporary closure is announced only in a staff messaging group, the phone system may continue giving yesterday's answer. Knowledge publication needs to be part of normal operational change management.
03 / 10
3. Create a clear introduction
Synthetic example: “Hello, you are speaking to Example Service's AI phone assistant. I can answer general questions or take a callback request. How can I help?” The real wording must reflect the approved scope.
A brief introduction should make the business identity, basic purpose and AI use understandable. The European Commission explains transparency obligations for certain AI systems applying from August 2026. Required privacy and recording information must be designed for the specific service; this greeting is not a complete legal template.
Listen to the introduction over a telephone connection. Text that looks short on screen can take a long time to say. Callers should not need to listen to extended advertising before explaining why they called.
04 / 10
4. Specify fields and actions individually
A callback request often needs only the issue, contact name, callback number, availability and responsible queue. Mark required fields and define useful states for missing information. A caller without email should not be blocked by an unnecessary mandatory field.
The table lists four assistant actions with their prerequisite, confirmed result and failure path.
| Action | Prerequisite | Confirmed result | Failure path |
|---|---|---|---|
| Give information | Valid approved source | In-scope answer | Collect a question |
| Create callback | Confirmed contact and request | Task identifier and owner | Monitored exception queue |
| Transfer call | Approved available destination | Defined handover outcome | Callback or alternative route |
| Book appointment | Permitted category and current availability | Stored appointment | No booking promise |
Actions should run through defined interfaces rather than letting the conversation decide freely what data may be changed. Technical permissions must reflect the scope. A narrow prompt paired with unrestricted write access creates an avoidable mismatch.
Specify what the caller hears after each result. “I have recorded your request” differs from “your appointment is confirmed”. Those statements should follow the actual system state, not whichever sentence sounds most reassuring.
05 / 10
5. Connect the telephone number and schedule
Agree the inbound route with the telephone provider. Forwarding is often one possible starting point, but charges, caller ID and conditions vary. IONOS's assistant availability instructions illustrate an assigned assistant number and forwarding of existing calls.
That is guidance for the relevant product, not a universal setting for your phone system. Record the actual numbers, office hours, holidays and fallback destinations. Also check behaviour when the simultaneous-call limit is reached.
Document how the change can be reversed. The business should not depend on one external supplier being the only person who knows how to restore the previous telephone service. Retain the earlier routing plan and identify who can apply it.
Got a workflow like this?
Tell me about it. Honest take and a rough price, usually within a day.
06 / 10
6. Start with one complete worked example
Synthetic test: A caller wants a service appointment, but direct booking has not been approved. The assistant collects the preference, confirms the callback number and creates a task. The task contains the preferred time, request and an explicit statement that no appointment has yet been agreed.
Second and third run. On the second run, the caller provides no callback number. The assistant explains a permitted alternative instead of inventing a number or treating caller ID as confirmed. On the third run, the destination application is unavailable. An owned exception must now become visible.
What the runs show. Those three runs test successful intake, missing information and technical failure within the same business task. They reveal whether the process is complete. Ten slightly different greeting demonstrations would not expose the same gaps.
Staff view. Inspect the staff view after each run. Can the recipient distinguish what is known, what is missing and what has already happened? If staff need a verbal explanation from the tester, improve the record before accepting the flow.
07 / 10
7. Assign ownership for configuration and access
Owners. Name a business owner and a technical owner. The business owner approves knowledge and commitments; the technical owner manages connections, permissions and failures. Changes should be traceable through a date and brief reason.
Test and production. Separate testing and production where the product supports it. Test calendars and synthetic contacts prevent demonstrations from changing real customer records. API credentials belong in protected integration settings, not conversation prompts or knowledge documents.
Data handling. Define how audio, transcripts and work items are handled. Collect and expose the information the task actually needs. Keeping everything indefinitely “in case it helps” makes ownership, review and deletion harder to manage.
08 / 10
8. Approve the workflow and monitor its outcomes
After each acceptance call, inspect the destination record, ownership and closing statement heard by the caller. Document deviations and repeat affected cases after a change. Include the person who processes these tasks daily in the review.
The launch needs a named incident contact, visibility of unresolved exceptions and regular checks of outcomes. Measure complete tasks, follow-up effort and accepted handovers. The assistant is well configured when its authorised tasks work traceably and its limits remain clear in both the conversation and the working system.
09 / 10
Take the worksheet
Worksheet
Download the editable CSV table
| Briefing item | Decision | Bounded example |
|---|---|---|
| Task | Supported requests | Opening hours and callbacks |
| Knowledge | Authoritative source | Approved location information |
| Required fields | What the next task needs | Request, confirmed number, team |
| Actions | Permitted changes | Create callback task |
| Limits | Human takeover conditions | Complaints and ambiguous ownership |
| Failure | Available alternative | Agreed telephone destination |
Columns to fill in, in the file: Your value / observation, Owner, Next action.
Download the editable CSV table (CSV). Add your own values, owners and open actions. This worksheet contains no measured client results.
10 / 10
Related decisions
These pages cover the service overview and the related decisions for setting up an AI phone assistant:
- AI phone assistants: functions and boundaries
- Testing an AI phone assistant in Austria: acceptance guide
- Human handover and callbacks for AI phone assistants
- Measure AI phone assistant quality in operation
For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.
