Why the AI sometimes sees the wrong number (the CLIP problem)

What CLIP is — in one paragraph

CLIP stands for "Calling Line Identification Presentation" — plainly: caller ID. It is what makes the caller's number appear on your display. Technically it is a piece of information the telephone network passes on from exchange to exchange. And it is exactly on that journey that it can be lost or replaced when a call is forwarded.

Why forwarding "swallows" the number

What matters is who forwards the call. If your provider's network carries out the forwarding — set up by key code on your mobile, by landline code or in the customer portal — the forwarding destination generally receives the original caller's number, unless the caller withholds it; for mobile, the standard lays this down. It is different when a device forwards: your FRITZ!Box or phone system answers the call and sets up a second call to the destination — customer → your line → assistant. For that second call leg, technically your line is the caller. Whether it may send the customer's number along (the technical term is CLIP no screening) is up to your provider; if it is not allowed, your own number arrives at the destination. This is not a fault of the assistant — it is line behaviour, and it turns out differently depending on the provider and the forwarding route.

What this means in practice

If your own number arrives, an AI phone assistant cannot capture the caller's number automatically. Day-to-day consequences:

• The call log shows your own number instead of the customer's — the callback goes nowhere, or to you.
• Features built on the caller's number (recognising regular customers, for instance) do not work.
• Without a countermeasure, every caller the device forwards would be "anonymous".

Important for setting expectations: this mainly affects forwarding that the FRITZ!Box or phone system carries out itself. Forwarding set up by key code on a mobile, by contrast, is carried out by the mobile network. The basics of the forwarding routes are explained in "Setting up call forwarding: the four routes and their pitfalls".

Three remedies — from simple to thorough

1. Forward network-side. Forwarding carried out by your provider's network — by code or in the customer portal — generally passes the caller's number through. If you need the forwarding in your phone system, ask your provider whether the line may pass the caller's number on. That is the first and simplest lever.
2. Asking during the call. An assistant can read a dictated callback number back digit by digit until the caller confirms. That protects against mishearing and catches callers who withhold their number — those exist even with perfect CLIP transmission. Against the CLIP problem itself it only helps if the caller actually dictates the number: if they accept the transmitted one, your own number is what gets noted. So asking complements the test call; it does not replace it.
3. A direct SIP connection. Leave forwarding out altogether and wire the assistant straight into your telephony, and the caller data comes through cleanly — provided the assistant's provider offers this at all. It is a project with an IT partner though, not a five-minute setup — and unnecessary for most small businesses.

How to test your own forwarding

Five minutes, two phones:

1. Set up forwarding as planned — on the mobile, at the provider, or on the FRITZ!Box or phone system.
2. Using a second phone — a colleague's, your private mobile — call the forwarded number and let it ring.
3. Check which number arrives at the destination: the second phone's (good) or your own (the CLIP problem).
4. If your own arrives: set the same forwarding up network-side at your provider and repeat the test.

Honestly: there is no guarantee

Network-side forwarding is no assurance either — the behaviour can differ by provider and line type, which is what the test call is for. On top of that: some callers withhold their number anyway — then asking during the call is all that is left. Against the CLIP problem itself, though, only the test call and, where needed, network-side forwarding hold: reading back protects against mishearing, not against a wrongly transmitted number. How reliably an AI captures a dictated phone number is examined in the article "How reliably does an AI capture a phone number?" — in short: reading back digit by digit is the decisive difference in quality.

At scoco.ai the assistant offers a transmitted caller number as the callback number — if the caller accepts, it is taken without being read back; with a forwarding that has the CLIP problem, that is your own. A dictated number it reads back digit by digit; it asks for the callback number explicitly when no number is transmitted. The number shown in the inbox and putting known callers straight through also depend on the transmitted number, so make the test call. scoco.ai is connected by call forwarding; there is no direct SIP connection. You keep your number, and basic setup takes about 10 minutes.