“Hi, it’s Meier. I’ve got an appointment tomorrow at ten. Can you move it to Friday?”
The voice assistant actually finds a Mr Meier booked at ten. It may even see the vehicle or service type in the CRM. The story fits. None of that proves the person on the phone is that customer.
Caller identity becomes painful when a Voice AI project addresses it too late. One extreme is an assistant that reveals or changes too much because the caller knows a name and appointment. The other is forcing everybody through a heavy identity check before answering a basic question about opening hours.
A better design uses progressive, risk-based verification. General service stays easy. The system steps up authentication only before it discloses sensitive information or commits a consequential customer action.
Voice AI caller verification starts by separating intent from identity
A modern voice model may be good at understanding what somebody wants. That is not evidence of who they are.
NIST SP 800-63B frames authentication as establishing that a claimant corresponds to a previously bound subscriber identity. The document is designed for digital identity systems and is not Swiss law for phone assistants. Its conceptual separation is still useful: knowledge of an account is not automatically proof of authority over it.
Switzerland’s FDPIC/EDÖB has stated that the Federal Act on Data Protection applies directly to AI-supported personal-data processing. A voice workflow that retrieves customer information therefore needs real attention to data protection and transparency rather than assuming a conversational interface changes those obligations.
a name, appointment time, address or vehicle detail can be useful matching information without being a strong authentication factor.
Recommendation: set the verification level according to the requested action, not according to the fact that the caller is speaking to an AI.
Decide what can happen before identity is proven
A large share of service calls are low-risk. Opening hours, directions, public service information and taking an anonymous callback request usually do not need identity verification.
Even when the system finds an existing customer, it should minimise what it says before verification. “I can help you with an appointment” is safer than reading back detailed history simply because the caller mentioned a surname.
Step-up verification makes more sense before revealing account history, invoices, sensitive records, stored contact data or before changing payment information, cancelling an order or modifying an existing customer transaction.
Example from a garage: “Do you fit winter tyres on Saturdays?” is public service information. “Change the stored phone number and billing address on my customer record” is account control. Those calls should not have the same security path.
Build verification into the conversation, not in front of it
A good call should not feel like an interrogation. Ask for stronger proof only when the requested next step requires it.
- Understand the reason for the call first. Let the customer describe the task.
- Classify the action. Public, account-related, sensitive or binding.
- Step up only when necessary. Use a one-time code to an already registered channel, a verified link or another method selected for the business risk.
- Do not rely solely on guessable facts. Name, date of birth, address, licence plate or appointment time may be known to other people.
- Limit failed attempts and information leakage. After a small number of failures, move to a human or controlled callback path rather than revealing more clues.
- Scope the verified session. Verification for changing an appointment does not have to grant broad access to every customer field.
There is no single method every Swiss SME must use. Risk, verification and the permitted action should be mapped explicitly.
Better security can actually make the call feel easier
Poor customer experience often comes from verification that happens too early or without explanation.
“Before I change your billing address, I need to verify that it’s really you. I’ll send a code to the number already on file.” That feels more reasonable than a surprise series of personal questions.
Sequence matters too. If the assistant asks five identity questions and then discovers that the caller only wanted the opening time, the friction was self-inflicted.
The escape path is equally important. Customers change phone numbers, lose mailbox access or cannot enter a code while driving. The assistant needs a safe alternative: a callback from a known channel, a staff review or a secure asynchronous step.
It should not improvise weaker “security questions” in order to finish the call. That turns customer experience pressure into a security bypass.
A minimum pilot with three action levels
Do not apply a new verification system to every call on day one. Select three common actions: one public information request, one moderate account change and one clearly sensitive action.
For each, document what may be said before verification, the approved method, the maximum failed attempts and the human route after failure.
Test more than the happy path. Include two customers with the same surname, an outdated registered phone, poor audio, Swiss German speech and a caller who knows several correct account details but cannot satisfy the actual verification factor.
Track successful verification rate, drop-off during verification, extra call time added, handover rate caused by verification problems, sensitive actions correctly blocked without sufficient verification, and customer complaints or support contacts caused by the verification flow.
A high success rate can be meaningless if the check is weak enough to let everyone through. A very strict check can simply push work back to staff. The target is proportional control.
The practical conclusion is that Voice AI does not need to fully identify everybody. It needs enough evidence for the action about to happen. Keep public questions lightweight and put a real identity boundary around customer data and consequential changes.
Our guide to Voice AI and data protection covers disclosure and recording. For consequential actions, draft, approve, execute adds operational control.
Sources
FAQ
Is a name plus appointment time enough?
No. It can help locate a record but is not strong proof that the caller controls that customer identity.
Does every call need authentication?
No. General information and non-sensitive enquiry capture often do not.
What verification method should we use?
It depends on risk and available systems. A factor sent to an already registered channel is often stronger than knowledge questions based on guessable facts.
What if the customer cannot receive the code?
Offer a human or asynchronous recovery path rather than silently lowering the verification level.
Is NIST SP 800-63B Swiss law?
No. It is US technical guidance used here as an architecture reference, not a Swiss legal mandate.