Overview
AI Voice Agents on ServiceNow can now reset passwords, pull up account details and act on behalf of callers — all over a phone call. The moment a call connects, one question matters above everything else: is this really them?
WithYokohama Patch 13, we introduced a built-in caller verification framework for user identification and authentication, handled natively for voice.
Identification: who is the caller?
Before the voice agent can act, it needs to know who is on the line. Identification supports two methods and they work in sequence.
-
Automatic Number Identification (ANI):
ANI is attempted first, if configured. The caller’s phone number is automatically matched with their ServiceNow record, requiring no input from the caller.
ANI support is available when the primary identification question is set to the phone number category during KBA question setup, or when you are using the default phone number question provided out-of-the-box. Otherwise, ANI support is not enabled.
-
Knowledge-Based Authentication (KBA):
If ANI does not match or is not configured, KBA takes over. The voice agent asks the caller a security question configured by the admin and the answer is validated against ServiceNow tables or external systems via a custom script. Admins have the option to configure a fallback question, if desired.
Note:
- Five out-of-the-box questions ship with the product and admins can add custom ones.
- Once identified, the voice agent can serve personalized responses for non-sensitive requests without requiring authentication. Authentication is only triggered when the request involves sensitive data or actions.
Authentication: proving it's them
When the request requires it, the identified caller must verify they are who they claim to be. The framework supports six authentication factors, configurable as single-factor or MFA per voice service:
- KBA — caller answers security questions validated against their user record (5 OOB + custom)
- Soft PIN — caller enters a 6-digit numeric PIN stored in ServiceNow
- TOTP — caller reads a time-based code from their authenticator app
- SMS OTP — a one-time code is sent to the caller's registered phone number
- Email OTP — a one-time code is sent to the caller's registered email address
- Okta Push — a push notification is sent to the caller's enrolled device for approval in the Okta Verify app
Callers respond via voice or keypad on all factors except Okta Push, which requires approval on the device. There is a shared retry limit across identification and authentication — once exhausted at either stage, the call falls back to live agent transfer or ticket creation.
How it works
Why this matters
Voice agents can handle a growing range of support requests — from account lookups to password resets to case updates. Without a verification framework, those interactions are limited to public information.
With identification and authentication in place, voice agents can serve personalized responses for everyday requests and securely handle sensitive actions for verified callers, reducing the volume that needs to reach a live agent.
Learn more
Product Documentation: Authentication factors
AI Voice Starter Guide: AI Voice FAQs and more
