AI Telephony
for SMEs

Overview

Contents

Executive Summary

What matters

AI telephony is not a question of the voice; it is a question of the process. Those who know beforehand what should happen after a call end up with a dependable tool. Those who do not end up with an expensive answering machine that pronounces things nicely.

The ten core statements

1. An AI voice assistant does not replace staff. It ensures that staff enter a conversation with complete information.
2. What should be automated are repeatable processes with nameable required information, not judgment calls.
3. Every use case needs a defined conversation goal, fixed required fields, permitted statements and clear escalation rules.
4. The caller must learn at the outset that they are speaking with an AI system, and must be able to reach a human at any time.
5. The voice is not proof of identity. Disclosing personal data requires an additional check.
6. Permanent call recording is not a default but a decision that must be justified.
7. Write actions in connected systems require validation, confirmation and an audit-proof log.
8. The works council must, as a rule, be involved in the rollout. That belongs in the schedule, not the retrospective.
9. A business case built on the per-minute price is not a business case. What counts is additional answered calls, reduced follow-up work and avoided misroutes.
10. Quality is measurable. Without metrics, judging a solution comes down to taste.

The starting point: why the phone endures

Despite portals, forms and messaging apps, the phone remains the first channel for many SMEs when things get urgent. And that is exactly where it meets teams that are already stretched.

Customers report faults, ask about appointments, need information or want to discuss a job. They pick up the receiver because the request rarely fits into a form field, because they want a firm answer, or simply because they know the call works. This is especially true in the skilled trades, in technical service and in project business – wherever customers have a problem rather than an order to place.

On the other end there is rarely a dedicated call center. Reception, the back office, dispatch and customer service handle the phone on the side. Someone in the middle of costing a job, writing an invoice or briefing a field technician either does not pick up at all or picks up under pressure. Both have consequences.

What the missed call actually costs

The lost call is the obvious damage, but not the most expensive. More costly are the knock-on effects that hardly anyone in the business traces back to a single cause:

• Lost enquiries. A prospect who reaches no one on the second attempt calls a competitor. An existing customer is more patient, but not indefinitely.
• Incomplete notes. The slip on the desk holds a phone number and the word “heating”. Clarifying it costs a second call and half a day of delay.
• Wrong transfers. The caller lands in the wrong department three times and explains their request anew each time. The time is lost across everyone involved.
• Interruptions. Every incoming call pulls someone out of another task. Getting back into it costs focus that appears in no statistic.
• Inconsistent answers. Depending on who picks up, the customer receives a different answer to the same question.

Where AI telephony comes in

An AI voice assistant answers calls, understands the request, asks for the missing details and transfers the information into a defined business process. Depending on the use case, it prepares callbacks, coordinates appointments, creates service tickets or hands the call to a member of staff in a targeted way – complete with a summary of what has already been discussed.

The decisive difference from older voice systems is not audio quality. It is that such an assistant can classify freely phrased requests, ask targeted follow-up questions and pass the result on in a structured form. A call becomes a record that a member of staff can work with straight away.

Terms: phone menu, voicebot, AI voice assistant

Three technologies are sold in the market under the same buzzword. They differ fundamentally in what they can do, what they cost and what preparation they demand.

Why the distinction matters in practice

A phone menu is not inherently bad. For a company with three clearly separated departments and low call volume, it can be the most economical solution. The mistake arises where it is meant to take on tasks it was never built for: capturing requests, asking follow-up questions, judging urgency.

The rule-based voicebot partly solves this, but every phrasing variant must be anticipated in advance. That produces a maintenance burden which grows with each use case and eventually finds no one willing to carry it.

The AI voice assistant built on large language models reverses this: it also understands what no one wrote down beforehand. That strength is also its risk – a model allowed to phrase freely will phrase freely even when it does not know the answer. Hence the principle running through this whitepaper:

A fourth term: the voice agent

The term voice agent is increasingly common. It refers to an AI voice assistant that carries out several steps on its own: look up, check, book, notify. Technically it is the same category, and the most demanding one. The more a system may decide for itself, the more precise its permissions, checks and logs must be. A voice agent with write access across several systems is the wrong place to start.

What AI telephony can do

A good AI telephony solution is more than a digital answering machine. It does not merely record messages; it guides conversations in a structured way and prepares a concrete next step.

The value is not in the voice

It is tempting to judge an AI telephony solution by how natural its speech output sounds. In a vendor demo that is the most striking difference. In operation it is the least important one.

The decisive value comes from the combination of four things: telephony, conversation logic, company knowledge and existing business systems. If one of these is missing, the rest is ineffective. A perfect voice that cannot get an appointment into the calendar has not improved the process. It has extended it by one step.

What is realistic today

A well-configured assistant holds a natural conversation with pauses, follow-up questions and the option to interrupt it. It copes with background noise, mobile-network quality and regional accents. It usually understands names and addresses, but confuses similar-sounding letters and therefore has to confirm them back. It keeps a latency that does not make the dialogue unpleasant.

What it cannot do: reliably read irony, infer a fact from a tone of voice, or capture a request for which it lacks the underlying data. Those who account for these limits in the conversation design get a dependable system. Those who ignore them produce calls that annoy the caller.

Why the answering machine no longer suffices

An answering machine leaves it to the caller to state all the important information. That works for people who are practiced at it. For everyone else, gaps appear that someone has to close afterwards.

In practice, customer numbers, locations, callback times, equipment names or details of urgency are therefore regularly missing. The message then reads: “This is Mr. Schuster, please call me back.” Whether it concerns maintenance, a complaint or an emergency stays open until someone calls back.

The difference is the follow-up question

An AI voice assistant can ask targeted questions, in the order the process needs:

This produces structured records instead of incomplete voicemails. Staff can respond faster and have to chase fewer details afterwards. The callback no longer begins with “What was it about again?” but with an answer.

Two side effects that are often overlooked

Prioritization becomes possible. Once urgency, location and equipment type are captured, the callback list can be sorted. Twelve equivalent slips become an order of work. On an on-call evening, that is the difference between a calm shift and a hectic one.

Data quality rises measurably. An assistant that repeats and confirms the callback number produces fewer undeliverable callbacks than a voicemail in which the number was mumbled once. It is unspectacular and, in day-to-day work, one of the most noticeable effects.

Suitable inbound use cases

The best entry point is not to automate every call at once. It makes more sense to take one clearly bounded use case with low risk and measurable value.

Structured call answering

The assistant captures name, phone number, request, customer number and preferred callback time, then creates a task or a call note. It makes no decision and gives no information. That makes this the lowest-risk entry point of all: even if the assistant misunderstands something, a human checks the result before anyone acts.

Low riskValue measurable quicklyNo write access needed

Appointment requests

The system determines the type of appointment, the location and availability. Depending on the permissions granted, it can propose, reserve or directly book a slot. The three levels differ considerably in risk: a proposal is harmless, a reservation blocks capacity, and a booking creates an expectation for the customer and in the schedule. Start with the proposal and work your way up.

Medium riskCalendar integration required

Fault reports

The AI asks for the equipment, location, symptom, time and impact. Critical cases are escalated by defined rules. Here the escalation logic is the actual core: what counts as critical? Who is informed, and when? What happens if no one answers? These questions must be answered before the first call, not after the first incident.

Medium to high riskEscalation chain mandatory

Smart routing

Callers are directed by their request to the responsible department, location or on-call service. The advantage over a phone menu is that the caller can state their request in their own words instead of working through seven options. The prerequisite is a clean responsibility matrix – and the willingness to keep it up to date.

Low riskImmediately noticeable to callers

Status enquiries

After a suitable identity check, the assistant can provide released information on orders, deliveries, appointments or service cases. The critical point sits in the first half-sentence: without a reliable identity check, no personal information may be disclosed. Chapters 12 and 16 cover this in detail.

High risk without identity checkRead access to the specialist system

Suitability check: does the use case fit?

The matrix below helps to classify a candidate before any effort is spent. The more answers fall in the left-hand column, the more suitable the case is as a starting point.

The typical fallacy

Many companies choose as their first use case the one that costs the most time. That is understandable and usually wrong. The most time-consuming call is, as a rule, also the most complex, the most emotional and the one with the most exceptions. It is the worst candidate for a start – not because it could not be automated, but because with it everything can go wrong at once and no one can say what caused it.

Choose instead the case that is frequent, dull and easy to describe. It brings less spectacular figures, but it delivers something more valuable: a working path from the phone system into the target system, on which everything else can be built.

Outbound calling and its legal limits

On paper, outbound calls look like the logical extension. Legally they are a different matter – and the area in which companies get into trouble fastest with AI telephony.

The decisive difference from inbound

With an incoming call, the caller chose to make contact. With an outgoing call, the company decides, and the person called has to put up with the contact. German competition law draws clear consequences from this.

What is unproblematic in outbound

Not every outgoing call is advertising. Permissible and practically useful are, in particular, calls that concern an existing case and that the customer expects:

• Appointment confirmations and reminders for an agreed visit
• Callbacks the customer requested themselves
• Notice of delays in an ongoing job
• Reminders about missing documents in a case already underway
• Clarifying questions on a job that the customer initiated

The line is crossed where the confirmation of an appointment becomes a pointer to a further offer. That one sentence turns a service call into an advertising call.

Further points to settle for outbound

• Caller ID. The number must not be withheld or falsified. It must genuinely belong to the company.
• Objection. An objection to calls, once raised, must take effect in the system, not merely in a note.
• Calling times. Even outside advertising: an automated call at 9:30 pm is felt as harassment, regardless of its lawfulness.
• Transparency. In outbound too, it must be clear at the outset that an AI system is speaking. See Chapter 14.
• Voicemail. Define what the system says to an answering machine – and whether it should say anything at all.

Where automation has to stop

Not every conversation should be completed by an AI. A responsibly designed assistant recognizes its limits and actively steps aside.

With complaints, contract questions, binding price commitments, payment details, safety-critical situations or complex professional decisions, a member of staff must be involved – not because the technology could not, but because the consequences of a mistake outweigh the time saved.

The reasons to hand over

An assistant offers the handover when one of the following applies. This list belongs in the configuration as rules, not in the presentation as an intention:

• The caller asks for a member of staff. Without a follow-up question, on the first request.
• The request is repeatedly not understood – as a rule, after the second attempt.
• Confidential or sensitive information is involved.
• A binding decision is required.
• A safety risk could exist: a smell of gas, escaping water, danger to persons, equipment failure with knock-on effects
• The conversation is visibly escalating.
• An interface or data source is unavailable.
• The caller is clearly in an exceptional situation.

What happens when no one is there

The handover assumes a human is reachable. At 10 pm that is often not the case. For that there must be a defined, honest fallback path:

• An on-call number, where an on-call service exists
• A prioritized callback promise, with a concrete window, not “as soon as possible”
• An alternative contact route the caller can use immediately
• For hazards: a pointer to the emergency number or the utility’s fault service

The principle

AI telephony should not hide staff; it should ensure they enter the conversation with the right information. A system that blocks the way to a human may improve the statistics short term while damaging the customer relationship exactly where it should be dependable.

The business process decides success

A natural dialogue alone is not enough. The company has to define what happens after a call. This chapter describes the minimum that must be set down in writing for that.

The ten definitions per use case

1. Goal of the conversation

What is achieved at the end? One sentence. Example: “A complete callback task sits in the CRM, assigned to a department.”

2. Required information

Which fields must be filled so a member of staff can work without a follow-up call? What happens if one stays empty?

3. Permitted statements

What may the assistant say on substance? Prices, deadlines, commitments and legally relevant statements usually are not among them.

4. Data sources used

Where does each piece of information come from? How current is it? What applies if it is unreachable?

5. Permitted system actions

Read, write, change, delete – separated by system and use case. When in doubt, less.

6. Responsible department

Who handles the result? Who deputizes during absences?

7. Escalation rules

Which features trigger an escalation, to whom, by when, with what fallback level?

8. Human control points

At which point does a human check – before or after the action, a sample or in full?

9. Documentation requirements

What is logged, kept for how long, viewable by whom?

10. Quality metrics

How is it measured whether the case works? Which value triggers a correction?

Why this work must come first

The ten definitions look like bureaucracy and are the opposite of it. They are the part of the project someone has to do anyway – at the table beforehand or later, under pressure, in live operation. Clearing it up in advance costs two workshops; clearing it up afterwards costs conversation quality every day.

In practice, this preparatory work is the real value of an AI telephony project. Companies often find that responsibilities are unclear, that three departments answer the same question differently, or that a process has only worked because one person keeps it in their head. These findings are uncomfortable and valuable, whether or not an assistant is introduced in the end.

Technical architecture

An AI telephony solution consists of several building blocks that can be procured individually. Those who understand how they interact can compare offers and assess failure scenarios.

The chain from ring to answer

Latency: the underrated factor

Every building block costs time: recognition, understanding, data retrieval, phrasing and output add up. Above roughly one second the conversation feels sluggish; beyond about two seconds, callers talk into the pause or ask whether anyone is still there.

The most common driver of latency in SME projects is not the language model but data retrieval from a legacy system. If the ERP customer lookup takes three seconds, the caller notices. Two remedies work: an intermediate data store for read access, or a conversation designed to fill the wait, for instance by confirming the details already captured.

Barge-in

An assistant you cannot interrupt feels rude. The ability to react to a caller speaking over it and to cut off its own output makes a big difference in daily use and is rarely shown in demos. Ask about it explicitly and try it.

Resilience: what happens when something fails

A phone line is part of a company’s reachability. It must not depend on every component being available at all times. For each failure there must be a defined response.

Operating models compared

For most SMEs the middle path is the right one: a platform for telephony and speech processing, connected to process logic and data access that the company controls itself. This keeps a change of platform vendor possible without rebuilding the entire specialist logic.

Integration with existing systems

The financial value rises when the captured information does not have to be transferred by hand. This is precisely where it is decided whether a project saves time or merely shifts it.

Typical integrations

Integration usually takes place through defined programming interfaces. With them the voice assistant can search for customer data, check appointments, create tickets or store conversation results.

Reading is not writing

The most important distinction in the whole integration topic is between read and write access. A read error produces a wrong piece of information that is noticed and can be corrected. A write error changes the data and keeps having an effect, often unnoticed.

Write actions such as appointment bookings or ticket changes therefore need additional checks, confirmations and logs:

• Validation. Is the combination of customer, location and equipment plausible? Does the appointment fall within the permitted window?
• Confirmation in the conversation. The assistant repeats what it is about to do and has it confirmed.
• Idempotence. A repeated call must not create three tickets. On abort and retry, the system must recognize that the case already exists.
• Log. Which action, triggered by which conversation, with which values, at what time.
• Reversal. How is a faulty booking undone, and who is allowed to do it?

Least privilege for permissions

The assistant should only be able to access data and functions that are necessary for its specific purpose. In practice this principle is often violated because an existing technical account with broad rights is the quickest route. That is convenient and creates a risk that no one wants to roll back later.

Instead, set up a dedicated technical account for each use case with exactly the rights needed. The callback assistant needs no access to prices. The appointment assistant needs no access to open items.

Conversation design and the human handover

Conversation design decides whether a caller experiences the call as helpful or as an obstacle. It is craft, not gut feeling.

The structure of a dependable conversation

1. Greeting with transparencyCompany, a note that this is an AI system, and the purpose – one sentence. Example: “This is the digital assistant of Müller Ltd. I take down your request and pass it on.”
2. Open opening question“What can I help you with?” rather than a list of options. The caller answers in their own words.
3. Classification and targeted follow-upAsk only for the details the process needs. Every extra question lengthens the call and raises drop-off.
4. Confirmation of critical valuesRepeat and confirm phone numbers, customer numbers, appointments and addresses – the values that break the process if wrong.
5. Announcement of the action“I’ll create a ticket, and the technical team will get in touch by noon tomorrow.” The caller knows what happens, and by when.
6. Close with a way outWhat to do if the callback does not come? A concrete pointer, not a platitude

Principles of phrasing

The handover: the moment everything is decided

A handover succeeds when the caller need not repeat their request. The member of staff needs three things on screen before accepting: who is calling, what it is about, and what the assistant has captured or promised. In a warm handover the caller stays on the line while the summary arrives; in a cold handover the call is passed on and the summary follows. The warm variant is more pleasant and more demanding technically. Where it is not possible, the summary should at least reach the member of staff before the phone rings.

Design for accessibility

Not every caller speaks clearly, quickly or in the local language. An assistant that aborts at the first uncertainty shuts people out. What helps: a second attempt with simpler phrasing, a longer answer window, a clear route to a human and, where warranted, a second language.

Data protection under the GDPR

Phone calls regularly contain personal data: name, phone number, voice, customer number, location or details of a specific request. Data protection is therefore not an appendix but part of the design.

The questions that must be answered before deployment

• Which data is processed?
• Are conversations recorded permanently?
• Is a transcript stored?
• Where is the data processed?
• Which service providers and sub-processors are involved?
• How long is conversation data stored?
• Is data used to train models?
• Who may access conversation content?
• How are data-subject rights implemented?
• How are people informed about the use of AI?

Determining the legal basis

Every processing operation needs a legal basis under Article 6 GDPR. For AI telephony, three come into practical consideration, and they are not freely interchangeable:

Data processing and place of processing

Platform providers, speech-service providers and model operators are, as a rule, processors under Article 28 GDPR. What is required is a data processing agreement, an overview of sub-processors and a provision for how you are informed when they change.

The place of processing is one of the few questions that demands a clear answer. Does the processing take place exclusively within the EU? If data reaches third countries: on what basis, with what additional measures? A vendor who answers this question with a general assurance of security has not answered it.

Data protection impact assessment

A data protection impact assessment under Article 35 GDPR is required where a processing operation is likely to result in a high risk to the rights of data subjects. With AI telephony there are good reasons to consider this seriously – particularly where voice recordings are processed, transcripts stored or conversation content systematically analyzed.

Even where there is no obligation, a documented threshold assessment is worthwhile. It costs little and later answers the supervisory authority’s question of why you reached your conclusion. The list of processing activities for which an impact assessment is mandatory is published by the German supervisory authorities; a look at the list of the authority responsible for your federal state belongs in the preparation.

Implementing data-subject rights in practice

Access, rectification and erasure must also work for conversation data. That sounds self-evident and, in practice, fails on a simple question: where exactly is what?

Setting retention periods

Set a period for each type of data and justify it. A proven pattern, to be checked in each case:

• Audio data: no permanent storage; processed only during the call
• Transcript: a short period, if needed at all – around 30 days for error analysis
• Structured conversation result: retained under the rules of the target system, that is, like a regular call note
• Technical logs: a short period, without conversation content as far as possible

Recording, transcripts and confidentiality

Whether conversations are recorded is often decided in passing during projects – usually in favor of recording, because it is delivered as a technical feature. That is the wrong way round.

Recording is the exception, not the default

Permanent call recording should not be enabled automatically. It requires a defined purpose, a legal basis and, as a rule, valid consent from both sides. In Germany, secretly recording the non-public spoken word is a criminal offense (Section 201 of the Criminal Code) – aimed at individuals, not companies, but a sign of the weight the spoken word carries.

Often it is enough to process speech only during the call and store structured results – sufficient for the process, simpler for data protection and far less intrusive for the caller.

Three storage levels compared

For most SME use cases the first level suffices in regular operation. The second is useful in the pilot phase and should then be time-limited or switched off. The third requires explicit justification.

What to clarify in any case

• Is audio buffered, and if so, for how long and where?
• Are transcripts produced even when recording is not enabled?
• Does the speech-service provider store data for its own QA?
• How long does erased data remain in backups?
• Who may view transcripts, and is access logged?
• Is the recording announcement, if any, clear and timely?
• What happens if the caller objects to the recording?

EU AI Act: transparency duty from 2 August 2026

For AI telephony, the EU AI Act is not a future topic. The duty to inform callers about the use of AI becomes applicable on 2 August 2026 – and it was not postponed by the political debate around the Digital Omnibus.

What Article 50 requires

Article 50 of the AI Act (Regulation (EU) 2024/1689) sets out transparency duties that apply regardless of a system’s risk class. An AI voice assistant is, as a rule, not a high-risk system – and is nonetheless covered by Article 50. For telephony, paragraph 1 is chiefly relevant: AI systems intended for direct interaction with people must be designed so that the person concerned recognizes that they are interacting with an AI system. An exception applies only where this is obvious from the circumstances anyway – which is not something to rely on with a naturally sounding phone assistant.

Provider or deployer – or both

The duties are distributed differently. Whoever buys a phone assistant as a finished product and uses it is a deployer. Whoever offers the solution under their own name, substantially modifies it or changes its purpose can become a provider – with far more extensive duties. For SMEs the standard case is the deployer role. The classification should nonetheless be documented, because it determines the set of duties.

Penalties

Breaches of Article 50 fall under Article 99 of the Regulation. The range is up to 15 million euros or 3 percent of worldwide annual turnover, whichever is higher. Small and medium-sized enterprises receive special consideration in setting the amount. In Germany, the Federal Network Agency is to become the responsible market surveillance authority.

What this means for the announcement

The caller should learn at the start of the conversation, clearly and understandably, that they are speaking with an AI system. The notice must not be hidden inside a long greeting. It should also explain what task the assistant performs and how, if needed, a human contact or an alternative route can be reached.

For many companies the notice feels like a disadvantage. Experience suggests otherwise: callers who know from the start whom they are dealing with phrase things more clearly and briefly and are more forgiving of a misunderstanding. Deceived callers are not – and they almost always notice.

AI literacy under Article 4

Since 2 February 2025, providers and deployers must, to the best of their ability, ensure that their staff and contractors have sufficient AI literacy – measured against their role, their prior knowledge and the context of use. For AI telephony this means, concretely: anyone taking over conversations that an assistant has prepared must understand what the system can do, where it makes mistakes and how to spot a wrong result. A two-hour session with the affected teams and a short record usually meet this requirement better than an online course with no bearing on your own process.

Implementation in five steps

1. InventoryWhich AI systems are in use or planned? The phone assistant is rarely the only one.
2. Role clarificationAre you a deployer, a provider or both? Document the classification with reasons.
3. Technical implementationAdd the disclosure to the greeting, anchor it in the conversation design, test it.
4. Contracts and governanceReview vendor contracts: who fulfills which duty? Name the responsible person in the company.
5. Documentation and trainingMake what you have done demonstrable. In case of doubt, what is written down counts.

Co-determination and employee data protection

This chapter is regularly overlooked in projects – and it is the most common reason why a finished system is not allowed to go live.

Why the works council must be involved

Where a works council exists, it has a co-determination right under Section 87(1) no. 6 of the Works Constitution Act on the introduction and use of technical devices designed to monitor the conduct or performance of employees. Case law reads this broadly: it is enough that the device is objectively suitable for monitoring. No intention need be present.

An AI voice assistant is regularly suitable for this. It records when a handover occurs, who accepts it, how long the follow-up conversation lasts and whether a callback was made within the promised deadline. Whether you want to analyze this data is irrelevant. What matters is that you could.

What belongs in a works agreement

• Purpose. What is the system used for, and expressly not used for?
• Data captured. Which data with a personal reference to employees arises?
• Analysis. Which analyses are permitted? Aggregated or individual-level?
• Exclusion of performance monitoring. An express purpose limitation that excludes conduct and performance monitoring is the core of most agreements.
• Access. Who may view analyses? Is access logged?
• Retention. How long is personal data kept?
• Involvement on changes. What happens with new use cases or a change of vendor?
• Employee rights. Access, objection, point of contact.

Handling concern within the team

The question “Does this replace me?” is in the room whether asked or not. It is answered not by a presentation but by what the system does. Where an assistant makes the callback list complete and the on-call evening calmer, that speaks for itself. Where it arrives while jobs are being discussed, no communication measure helps.

It has proven effective to involve the staff who answer the calls today in the conversation design. They know which follow-up questions clarify a request, which phrasings customers use and where the exceptions lurk. That knowledge is the best basis for the configuration, and their involvement takes much of the sting out of the rollout.

Information security and permissions

A phone assistant with access to specialist systems is an entry point into the company. It deserves the same attention as any other entry point – and it has one peculiarity the others do not: anyone can call it.

The particular attack surface

A language model processes what the caller says, which makes the caller an untrusted input source. This creates risks that classic systems do not have:

• Manipulation through speech. A caller tries, with targeted phrasing, to move the assistant to unintended statements or actions. The countermeasure is not a better system prompt but a technical limit: what the assistant may not do, it also cannot do when talked into it.
• Impersonation. “This is accounts payable at Company X, I need the order status.” Without a check, that is data handed to a stranger.
• Information harvesting. Many harmless calls form a picture: who is responsible, what the systems are called, when no one is there. An assistant that answers everything is an information bureau.
• Channel abuse. Automated calls in bulk cause costs and block reachability.

The countermeasures

Measuring quality: metrics and error classes

Without metrics, judging a phone assistant comes down to taste. And matters of taste, in a company, are decided by the person who is loudest in their dissatisfaction.

The metrics that carry

The baseline decides

Every metric needs a comparison value from before the rollout. These values cannot be determined after the launch. Take two weeks for a measurement of the current state: call volume by hour, answer rate, average call duration, share of incomplete callback notes. Without this baseline you will not be able to prove the value – neither to management nor to yourself.

Error classes: not every error is equal

A shared language for errors is the prerequisite for making improvement plannable. Without it, the feedback from operations reads “the thing doesn’t work” and no one knows where to start.

How the review works in practice

1. Weekly in the pilot phaseOne hour, fixed participants: department, IT, process owner. Go through ten conversations from the sample, classify errors, derive three actions.
2. Monthly in regular operationLook at the metrics, check outliers, bundle adjustments. Do not tinker with the dialogue every week – that produces instability.
3. On every changeA regression test with a fixed set of test conversations. A set of twenty calls covering all use cases and the critical edge cases is enough for an SME.
4. Feedback from operationsA way for staff to flag a poor conversation – without a form, without having to justify it. These reports are the most valuable input you will get.

Building a realistic business case

The economics of AI telephony do not hinge on the per-minute price, but on what an unanswered call costs in your business and how much rework you do today.

The benefit side

The cost side

A per-minute figure alone says little. Costs are typically made up of:

Model calculation

Assumed company: technical service provider, 35 employees, 60 incoming calls per working day, 20 working days per month, current answer rate 82 percent, internal hourly rate €55.

The three most common calculation errors

• Booking staff costs as savings. As long as no one leaves, no one saves money. Time gained is real, but it flows into other tasks. Reckon with relief, not savings – unless a position is genuinely not refilled.
• Ignoring the current cost. The comparison is not “assistant versus nothing” but “assistant versus today’s solution”. The answering machine, the phone service, the overtime in the back office – these are ongoing costs that belong in the counter-calculation.
• Forgetting the pilot effort. The time the department and IT put into design, testing and tuning is real effort. It occurs once and is often the largest single item of the rollout.

Choosing the right provider

The market is crowded and growing fast. Providers differ less in what they show than in what they commit to in writing.

Evaluation matrix

Weight the criteria to your situation and rate each provider. What matters is less the total score than the discussion that emerges while filling it in.

Warning signs

The test that really counts

Do not just have something demonstrated to you. Arrange a limited test under your conditions, and define beforehand what success means. A sound test scenario includes:

• Your callers. Five staff from operations call in with real requests – from a mobile, from the vehicle, from the construction site.
• Your terminology. Equipment names, place names, technical terms. An assistant that does not understand “Ostfildern” becomes a problem in operation.
• Your edge cases. The caller who immediately wants a human. The one with three requests at once. The one who is angry. The one who speaks indistinctly.
• Your systems. At least one real interface, even if it is only filing a note. Everything else remains theory.
• Your result. At the end comes the question: what is now in my system? Is the record complete and correct?

Consultant, platform or both

Three constellations are common in the market. The pure platform provider delivers technology you configure yourself – cheap if you have the capability, otherwise expensive by the detour. The systems integrator delivers a solution on a third-party platform – higher cost, but one contact for the result. The full-service provider delivers both from one source – convenient, with the risk that a later switch affects both parts.

For most SMEs the second variant is the right fit: the platform is replaceable, while the process logic and the specialist data stay under your own control. With the integrator, make sure the process work is taken seriously and not merely configured.

Rolling out in eight controlled steps

A good pilot starts outside business hours or with the structured capture of callback requests. Only after quality is proven are further functions added.

1. Analyze actual call volume Measure for two weeks: calls by hour and weekday, answer rate, call duration, share of recurring requests. These values become your baseline later. Without them you cannot prove any value. 2 weeks
2. Select a suitable pilot process Frequent, repeatable, low-risk, measurable. Not the most demanding case, but the dullest one with volume. The suitability matrix from Chapter 5 helps with the decision. 1 week
3. Define the target process and responsibilities The ten definitions from Chapter 8, in writing, with the people who answer the calls today. This step is the most demanding and the most valuable. Anyone who cuts it short pays twice later. 2 to 4 weeks
4. Review data protection and risks Legal basis, record of processing activities, threshold assessment for an impact assessment, processing agreement, retention periods. In parallel: involve the works council and settle the transparency announcement. Runs alongside step 3, not after it. in parallel
5. Develop conversation logic and interfaces Build the dialogue, implement the required fields, establish the connection to the target system, set up permissions, configure fallback paths. 3 to 6 weeks
6. Run realistic tests With your own staff, your own terminology, your own edge cases. From the mobile, from the vehicle, with background noise. Including the cases meant to go wrong: an interface dropping, a request for a human, a hazard. 2 weeks
7. Start limited live operation One time window, one number, one use case. The fallback path active and tested. A named person with the authority to switch off. Daily review in the first week. 4 to 8 weeks
8. Measure quality and expand under control Set the metrics against the baseline, classify errors, tune. Only once the first case runs stably does the second one come. Not in parallel. ongoing

Who is needed in the project

Communicating internally and externally

Internally: inform the affected teams before the first handover rings. Explain what the assistant does, where it makes mistakes and how to report a poor experience. Involve the staff in the conversation design – they know more about the calls than any consultant.

Externally: an announcement to customers is possible but rarely necessary. More important than the announcement is the notice in the conversation itself. What you should not do: conceal the use and hope no one notices. Someone notices, and then the question is no longer the technology but trust.

The transition to regular operation

A pilot does not end by continuing to run. It ends with a decision. Define beforehand what you base it on:

• No Class A error in the last four weeks
• Completeness rate above the agreed target
• Answer rate improved against the baseline
• No open complaint about the assistant from the department
• Fallback path tested successfully at least once
• Operations, maintenance and point of contact settled and named
• Data-protection documentation complete

If these points are met, the case moves into regular operation and the next one can begin. If they are not met, it is improved or discontinued. A pilot without an exit option is not a pilot but a rollout with a grace period.

Practical examples from SMEs

The following examples are typified scenarios, not customer accounts. They show how a use case is tailored and where the critical point lies in each.

What these examples have in common

• A tight scope. No case tries to take on every call. Each covers a clearly bounded slice.
• A deliberate omission. In every case there is something the assistant deliberately does not do – book, decide, judge. This omission is the design decision, not a limitation.
• A verified source. Every piece of information comes from a maintained store with an owner, not from the language model.
• Safety before efficiency. In doubt, it transfers. The rate falls, and so does the risk.
• The value lies downstream. The gain is not the conversation but the state afterwards: complete, prioritized, in the right system.

Common mistakes and how to avoid them

The patterns repeat. Those who know them spare themselves the experience.

Working material

Checklist for management

Twelve questions that should be answered before a project is approved. If you cannot answer more than three of them, the project is not yet ready for a decision.

• Do we know our actual call volume and answer rate?
• Is the pilot case named, bounded and chosen with reasons?
• Is a process owner with decision authority named?
• Are the conversation goal, required information and permitted statements set down in writing?
• Is it clear who handles the result of each conversation – including during holidays and sickness?
• Are the escalation rules defined and agreed with the department?
• Is the legal basis of the processing clarified and documented?
• Is the works council involved, if one exists?
• Does the transparency announcement meet the requirement of Article 50 of the AI Act?
• Is the fallback path on failure contractually committed and tested?
• Are baseline values for the metrics in place?
• Is a person named who may switch the assistant off without consultation?

Data protection checklist

• Legal basis per processing purpose determined and documented
• Record of processing activities updated
• Threshold assessment for a data protection impact assessment carried out and documented
• Data processing agreement under Art. 28 GDPR concluded
• Sub-processors known, duty to inform on changes settled
• Place of processing clarified; for third-country transfers: basis and additional measures documented
• Use of data for model training excluded in writing or switched off
• Retention periods per data type set and technically implemented
• Handling of backups and their retention period clarified
• Privacy notice adapted and reachable for callers
• Process for access, rectification, erasure and objection described and tested
• Recording: purpose, legal basis, consent and announcement clarified – or recording switched off
• Access permissions for transcripts and analyses defined and logged
• Procedure for a data breach, including reporting routes, defined

Information security checklist

• A dedicated technical account per use case, separated into read and write
• Permissions granted on the least-privilege principle and documented
• Permitted system actions defined as an allow list; everything else technically excluded
• Identity check defined before any disclosure of personal data
• Write actions secured with validation, confirmation and idempotence
• Rate limits set for actions per conversation and per phone number
• Ceiling on concurrent conversations defined
• Alerting on anomalous patterns set up
• Logging of all system actions with assignment to the conversation
• Regular review of the logs scheduled and owned
• Fallback path on failure configured and tested at least once
• Kill switch set up and assigned to a named person
• Behavior defined for the unreachability of each interface
• Assistant included in the incident response plan and the record of processing activities
• Procedure for model and version changes, including a regression test, defined

Acceptance checklist

These tests belong before going live. All are to be carried out with real phones, not in the vendor’s web interface.

• Caller says in the first sentence: “I would like to speak to a human.” → immediate transfer without a follow-up question
• Caller describes a hazard → emergency-number pointer and immediate handover, no further questions
• Caller states three requests in one sentence → a coherent response, no crash
• Caller speaks indistinctly or with a strong accent → a second attempt, then a handover
• Caller interrupts the output → the assistant stops and listens
• A call from a mobile with background noise → a usable result
• The target system does not answer → the conversation continues, no invented information, post-capture takes effect
• Caller asks for something the assistant cannot know → an honest answer, no invention
• Caller aborts mid-capture → no half record, no duplicate ticket
• The same call twice in a row → no duplicate case in the target system
• The transparency announcement comes in the first sentence and is clear
• Handover to a member of staff → the summary is present before acceptance
• Fallback path: assistant switched off → the diversion takes effect within the committed deadline

Reference

Glossary

Barge-in

The ability to interrupt the assistant by speaking. It stops its output and listens. A key feature for a natural conversation.

Completion rate

The share of conversations that reach the defined goal. Measured per use case, not overall.

Data protection impact assessment

An assessment under Article 35 GDPR of processing operations likely to result in a high risk. Should be considered for AI telephony, particularly where recordings are involved.

Deployer

Whoever uses an AI system under their own responsibility. The standard role for SMEs, with fewer duties than a provider.

Fallback path

The defined behavior on a failure, for example an automatic diversion of the phone number to a target number specified in advance.

Handover

The transfer of a conversation to a member of staff, ideally with a summary that reaches the person before acceptance.

Idempotence

The property whereby a repeated action produces no additional effect. Prevents duplicate tickets on an abort and retry.

Intent recognition

The classification of a request into a defined category, the basis for further conversation control.

IVR

Interactive Voice Response, the classic phone menu with key presses or fixed keywords. Not to be confused with an AI voice assistant.

Latency

The delay between the caller’s and the system’s turn. Above roughly one second, the conversation feels sluggish.

Least privilege

The principle of granting only the minimum rights necessary. Central to the security of a phone assistant.

Provider

Whoever develops an AI system or places it on the market under their own name. Bears more extensive duties than a deployer.

Regression test

A re-check with a fixed set of test conversations, especially after a model or version change.

SIP trunk

A technical connection for internet telephony over which the assistant answers calls.

Transcript

The written record of a conversation. Contains everything that was said and is therefore subject to data protection.

Voicebot

A rule-based voice system with predefined paths. A middle stage between a phone menu and an AI voice assistant.