When verification fails: what customers hear

When the assistant cannot verify someone, it says so in plain language without revealing anything about the record. It words each outcome itself, in the language of the conversation, from the outcome the platform reports. The outcomes, and what each one tells the customer, are the same for every workspace.

The outcomes

Verification is not available here. No method on the channel can verify the customer for this request: none is switched on for the channel, no email channel can send the link, or the customer-record lookup is not designated. The assistant tells the customer it cannot verify them in this conversation, and a teammate is notified to follow up on the request. The Channels tab tells you this before a customer meets it: see the Will a customer be verified? section in Setting up identity verification.

The request needs a stronger verification. Some requests need high-assurance, which a completed National eID verification reaches (see Assurance levels). When National eID cannot run for the request, the assistant tells the customer that this particular request needs a stronger confirmation than this conversation can offer, without saying they are unverified, and a teammate takes the request over. The email link is never offered for such a request, because it reaches identified at most.

The email link was requested. The link goes to the email address your own system holds for the customer the request is about. The assistant tells the customer that, if an address is on file for it, a secure link has been sent there. The reply is the same whether or not an address was found, so it reveals nothing either way.

When a National eID verification does not complete

Where National eID is enabled, the following outcomes exist, and each keeps the same information-poor stance.

Not completed in the app. On a call, the approval request in the caller’s MitID or BankID app stays open for a few minutes and then closes. When it closes without an answer, the attempt ends and the record stays untouched. The assistant tells the caller that the request was not completed, gives no reason, and offers to verify again. A customer already verified for other requests stays verified for them.

Declined. When the person a request was sent to declines it, or someone other than the person a request or link is for approves it or signs in on it, National eID ends in that conversation. No further request goes to the customer’s app and no further verification link is sent in that conversation. What follows is your setting After the customer declines, on the National eID tab under Settings, then Verification:

• Hand the conversation to your team, the default: verification ends in the conversation. The assistant tells the customer it cannot confirm their identity here, gives no reason, and a colleague takes over: on a call the assistant offers to bring one in, and by email and in chat a teammate is notified and follows up. Anything verified earlier in that conversation stops counting, and a link or approval that arrives afterwards verifies nothing.
• Let the customer verify another way: the assistant tells the customer their identity is unconfirmed, gives no reason, and offers to verify them another way. The methods on the channel that reach identified, such as the email link, stay available for requests that need identified; a request that needs high-assurance goes to a colleague.

A new call, chat or email thread starts afresh.

Stopped at the scheme’s login. After following a verification link, the customer cancels the MitID or BankID login on the scheme’s own login page, or the scheme ends the login there without a result. The page they return to says “Login not completed” and asks them to return to the conversation and open the link again: the same link works until it expires. Nothing in the conversation changes, and Identity events records the attempt, at most once in 15 minutes for the same link. With BankID, direct in Sweden, the BankID step runs from the verification page itself, and a cancel in the BankID app shows “We could not verify you for this request”; the same link can be opened again.

The verification link expired. In live chat, where National eID arrives as 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, and counts as a decline in the conversation that started it. 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 your team sees

Each outcome that hands the request to a teammate shows in the conversation as a hand-off card. Under Why a person, the card gives the reason in one sentence and names the tool the request needed, as the conversation’s Inspect panel shows it (see Reading a conversation). The reasons, with example tools:

The card says	When
Verification ended in this conversation after an eID approval was denied, so the request for get_invoice goes to your team.	With Hand the conversation to your team, the default, a decline ends verification in the conversation (Declined above), whoever declined or approved; every later request in that conversation goes to your team with the same sentence and its own tool.
The verification methods on this channel give a lower level than the request for get_invoice needs.	The request needs a stronger verification than the channel offers.
The customer’s own record stays unlinked in this conversation, and the request for get_invoice needs it linked.	The request opens the customer’s own records, and the secure sign-in that links them is unavailable in this conversation.
The customer verified, but their own record stays unlinked in this conversation, and the request for update_address needs it linked.	The customer verified, and the request still needs their own record linked.
The change update_address makes needs its own approval, and asking the customer again is unavailable in this conversation.	After an approval, a further change needs an approval of its own, and asking for it is unavailable in this conversation. The assistant tells the customer this change needs a separate confirmation and that a teammate follows up.
Verification is unavailable in this conversation, so the request for get_invoice goes to your team.	Any other outcome that ends verification, such as the attempts used up or verification switched off for the channel.

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.
• Why a request in the app or a sign-in did not verify them.

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 reply 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.