When verification fails: what customers hear
When the assistant cannot verify someone, it says so in plain language without revealing anything about the record. There are four things a customer hears, and they are the same for every workspace.
The four messages
Section titled “The four messages”Locked out. The customer has reached the limit on failed verifications. Three counters run in parallel: one for the contact, one for the number the call came from, and one for the record being asked about, so an attacker rotating numbers against a single customer is stopped by the third.
“I’m sorry, but I can’t continue verification right now. Please try again later or contact us another way.”
Out of answers. The customer went past the wrong-answers allowance, or no enabled question could be asked on this channel.
“I wasn’t able to verify those details. For your security I can’t continue.”
Verification is not set up. No question is enabled, no email channel can send the link, or the customer-record lookup is not designated, so there is nothing to ask and nothing to send. The Channels tab tells you this before a customer meets it: see the Will a caller be verified? section in Setting up identity verification.
“I’m not able to verify you on this line right now.”
The email link was requested. This reply is sent whether or not an address was found on the record, so it reveals nothing either way.
“If an email address is on file for that, I’ve sent a secure link to it. Please open the link to verify.”
When a National eID approval does not complete
Section titled “When a National eID approval does not complete”Where National eID is enabled, three further outcomes exist, and each keeps the same information-poor stance.
Declined or lapsed in the app. The approval request in the customer’s MitID or BankID app stays open for a few minutes and then closes. If the customer declines it, or the window closes without an answer, that attempt ends and the record stays untouched. The customer’s next message can verify by another method you have enabled.
The verification link expired. On an email channel where the reply carries a verification link, and in live chat where the reply carries a verification button, a link that expires unused is announced plainly on the next message: the assistant says the previous one expired and that asking again brings a fresh one.
Verified as someone else. A verification binds only when the identity the scheme proves matches the record on file for the request. When it does, the conversation resumes; any other completion shows one page, “We could not verify you for this request”, with the same wording for every reason. A link that has expired, been replaced or already been used shows “This link is no longer valid”. Both pages hold back which record was asked about and why the attempt did not verify.
What the customer does not hear
Section titled “What the customer does not hear”The assistant never says, in any of these:
- The names of the tools that were blocked.
- The contact or account identifier of a matched record.
- Whether a record exists for the details they gave.
- Which question they got wrong.
This is deliberate. The wording is information-poor so that someone probing for valid identifiers cannot read an answer out of the difference between two replies. It is why the email-link message is worded as a conditional, and why a link that is dropped for exceeding a per-record send limit produces the same reply as one that is sent.
Changing the wording
Section titled “Changing the wording”These four messages are the same across every workspace today. If your brand needs different wording, raise it with your oHallo account team.