Phone call experience

Phone call is the only channel that needs nothing at all from the employee — no app, no browser, no login, no data connection. A factory supervisor with a desk phone, a driver on the road, an employee locked out of their laptop on day one: all of them can dial a number and talk to the assistant.

It is also the only channel where the assistant can hand the employee to a real person mid-conversation.

The trade-off is that a phone call has no screen. Everything the assistant would normally show — links, forms, sources, attachments — has to go somewhere else, and that shapes the whole design of this channel.

For number provisioning and provider credentials, see Voice & SMS setup. For the in-app equivalent, see Voice Call.

How employees start a call

The employee dials the number provisioned for your organisation from any phone, mobile or landline. The call is answered by the assistant, and the number they dialled is what identifies which assistant they've reached.

Because the call arrives over the public telephone network with no logged-in session behind it, the assistant has no idea who is calling until it asks. That's what authentication is for.

If the assistant has been disabled from the dashboard, the call is rejected as soon as the assistant is identified — before authentication, and before any conversation. The caller hears the standard disabled message and the call ends. Nothing from that call is saved to chat history.

Authenticating the caller

There are three options. Pick one per assistant.

OTP

The familiar flow, and the simplest to operate:

1. The assistant looks the caller up by the number they're calling from, against the phone fields on the employee record.
2. If exactly one employee matches, a six-digit code is sent by SMS to that same number.
3. The caller enters the code on the keypad.
4. On a match, the conversation begins.

Callers get three attempts on the code itself. Partial or empty entries are counted separately, so someone who mistypes and has to start over isn't immediately locked out — the assistant tells them how many digits it actually received and asks them to enter all six again.

The constraint is unavoidable: if the caller isn't dialling from a number on their record, OTP cannot identify them. Use KBA instead.

KBA

Knowledge-based authentication asks for digits from two fields on the employee record, so the caller's phone number is irrelevant:

1. The assistant asks for the first mandatory parameter — for example, "Please enter the last 4 digits of your Employee ID using your keypad, then press pound."
2. The caller enters the digits and presses #.
3. The assistant asks for the second mandatory parameter and collects it the same way.
4. It then performs a single lookup using both values combined.
5. One match means the caller is in.
6. Several matches means the assistant asks for a tie-breaker parameter to separate them.
7. No match after the retry limit ends the call.

The two values are never looked up in the clear — they're combined and hashed, and the hash is matched against a pre-built index. When you create or change the KBA configuration, that index is rebuilt in the background so it reflects the current employee records.

What admins configure

Set per assistant, alongside the phone number itself:

• Phone number — the E.164 number assigned to the assistant, for example +14155551234.
• Authentication method — OTP, KBA, or none.
• KBA parameters — exactly two mandatory fields plus exactly one tie-breaker. For each, you choose the profile field, the wording the assistant speaks, whether to take the first or last digits, and how many. Digit counts must be between 4 and 6.
• Human transfer number — see below.

Talking to a human

This is the phone channel's unique capability, and it exists on no other channel.

When the conversation needs a person, the assistant can transfer the caller to a real phone number rather than telling them to raise a ticket and wait. Two conditions have to hold:

• A valid E.164 destination number is configured on the assistant.
• The call is an actual phone call. Transfer cannot work on the in-app voice call.

If no valid number is configured, the assistant is never even offered the option, so it won't promise a transfer it can't perform. The number is read at the moment of transfer, so if you update it mid-call the next attempt uses the new value.

During the call

Once authenticated, the conversation works the way the in-app voice call does: natural turn-taking, the caller can interrupt mid-sentence, and the assistant gives short acknowledgements and progress updates while it works in the background.

What it can't do is show anything. There is no button to press, no card to read, no form to fill. Choices have to be spoken, which means flows written for a screen — "pick one of these eight options" — need rewriting for voice. Anything requiring a form is a poor fit and should hand off rather than be attempted on the call.

Where the information goes

Because there's no screen, non-speakable content is routed to two places.

The transcript, in the web app

The full conversation — what the caller said and what the assistant said — is written to their chat history in the Leena AI web app. Links, sources and attachments that came up during the call are rendered there exactly as they would be in a text conversation. The employee signs in afterwards and finds the call waiting for them, with no extra step, because the same identity that authenticated on the call backs their web session.

Where Chats is enabled, each call becomes its own chat rather than being appended to the main conversation. For KBA calls that chat is created once authentication succeeds, since until then the assistant doesn't know whose chat to create.

Links, by SMS

Some things are needed during the call, not after it. For those the assistant says it's texting the link across, and an SMS goes to the caller's number while they're still on the line.

Links sent this way are rewritten to work in an SMS context rather than a web one, so the employee taps a link scoped to their own identity on that channel.

SMS is a prerequisite, not an optional extra

For link delivery to work, the assistant must have the Twilio SMS channel configured, and the caller must resolve to a known SMS recipient on that number.

If SMS isn't configured, the call still connects. The employee still authenticates, still asks questions, still completes anything that doesn't produce a link. But the moment the assistant needs to send something, nothing happens — the failure is logged on our side and the caller is simply never texted, having possibly just been told they would be.

Treat SMS as a hard dependency before enabling phone call in production. See SMS for how that channel behaves.

Compared with chat and the in-app voice call

The short version: the phone loses everything visual and gains reach plus the ability to escalate to a person.

Things to tell your employees

• Have your employee ID or whichever detail your organisation asks for ready before you dial.
• Enter digits on the keypad, and press the hash key when you're done.
• If the assistant texts you a link, open it while you're still on the call — it's easier than finding it later.
• You won't be read a web address. Anything like that arrives by text, or waits for you in the app.
• Ask to be put through to a person if the assistant can't resolve it.
• The whole conversation is saved in the app, so you can go back and read it.

Setting up the channel

Number provisioning, provider credentials and telephony configuration are covered in Voice & SMS setup. Voice persona and language settings live in Voice. For the request lifecycle, latency design and hosting model shared with the in-app voice call, see Voice Architecture.