Finding your customers

Your customers live in your own systems, not in oHallo. Before the assistant can recognise a returning caller, verify someone’s identity, or link a conversation to one of your records, it has to look the person up in your system. This page is where you tell it how.

This runs first, on every message and every call. Until it is set up, three things do not work:

Security questions, because there is no record to ask questions from.
Sending a verification link, because the link goes to the address on your own record.
Recognising a returning caller, so every conversation starts cold.

What you’re telling us

For each way a customer can arrive, you point at one of your own tools and name three things:

Which tool finds a customer. From your MCP hub, the tool that answers “who is this person”.
Which input carries the value. The tool input that takes an email address, or the one that takes a phone number. You name it; we send exactly that.
Where your reference sits in the answer. The field in the tool’s reply that holds your own customer reference (the id your systems use). We store that reference and nothing else from the lookup.

Setting it up

Open Settings, then Customer records. There are five rows:

From an email address, for email conversations and chat visitors who give an address.
From a phone number, for calls and WhatsApp.
The email on the record, where a verification link is sent, read from your record rather than the address the customer typed.
The eID reference on the record, the identifier the customer’s own eID login stored in your system, which National eID verification compares against.
A national identity number, read from your record when a national scheme needs it, relayed to the scheme and never stored.

Click Set up on a row, or Change if it is already configured. Pick the MCP connection, then the tool. A tool that declares what it accepts and returns gives you dropdowns for the input and the field; a tool that does not lets you type them exactly. Save, and the row then shows the outcome of the last real lookup, so a wrong choice becomes visible in normal use rather than months later as a customer who was never recognised.

The last two rows show the connection and tool you chose rather than a live outcome, because they are read only when a link is sent or a scheme needs the number.

When a row is not working

Each row shows its current state in plain language. When something is wrong, it says what, in one line:

What you see	What it means
Working	The last lookup found the customer and read your reference.
No lookup configured	You have not set up this row yet.
The tool is no longer offered by that connection	The tool you picked is gone from that connection.
The tool does not accept an argument by that name	Pick the tool input that carries the value.
The answer carried no value at that field	The tool replied, and nothing sat at the field you named.
Blocked by policy	Set the tool to a read classification in the MCP hub.
Your system returned an error or timed out	The tool errored or did not answer in time.
Working. The tool answered and did not know the last person looked up	Normal. Your system answered, and this person is not one of your customers.

The last one is not a fault. It is what a real lookup says about someone who is not your customer.

What oHallo stores

Only your customer reference, against the conversation. The attributes the tool returns are read live each time they are needed; oHallo does not copy your customer database. What lands in oHallo is the link (this channel identity is this customer of yours), not the record.