A multi-office real estate brokerage we work with had a specific complaint. Their receptionist — in this case an AI receptionist we'd built for them, but the same thing happens with a human on a PBX — would answer a call and transfer it to an agent's cell phone. The agent's phone would ring, and instead of showing the customer's number, it showed "Spam Likely," or "Scam Likely," or sometimes it just didn't ring at all.
The obvious explanation is that the phone system was doing something wrong. It wasn't. It was doing exactly what it was asked to do, and that turned out to be the problem.
What the phone system was trying to do
When you transfer a call, there's a choice about what caller ID the person receiving the transfer sees. The intuitive answer is: show them the original caller's number, so they know who's calling and can call back. So the PBX (or the AI) places a new outbound call to the agent's cell and sets the caller ID to the customer's number.
That is, technically, spoofing. A benign, well-intentioned kind — you're passing along a real number that really did call you — but from the carrier's point of view, your phone trunk just sent a call claiming to be from a number your trunk doesn't own. And there is now a whole system built to catch exactly that.
STIR/SHAKEN, briefly
Robocalls with faked caller ID got bad enough that U.S. carriers were required to implement a framework called STIR/SHAKEN. The details are dense, but the practical part is simple: when a call leaves a carrier's network, the carrier signs it with a cryptographic "attestation" that says how confident it is about who's calling. There are three levels:
- A (full attestation) — the carrier knows the customer placing the call and knows the customer is authorized to use that caller ID number. This is what you get when your trunk sends a number that's actually assigned to your trunk.
- B (partial attestation) — the carrier knows the customer, but can't vouch that they're entitled to use that specific number.
- C (gateway attestation) — the carrier is just passing the call along and can't vouch for much of anything.
The receiving carrier reads that signature and decides what to do with it. Major mobile carriers may label or block low-attestation calls, and their thresholds are their business — they change, and they aren't published in a way you can rely on.
Putting the two together
Now the transfer problem explains itself. Your trunk sends a call to the agent's cell with the customer's number as caller ID. Your carrier looks at that number, sees it isn't one of yours, and signs the call at B or C. The agent's mobile carrier sees a low-attestation call and labels it, or drops it. Meanwhile, if the receptionist had transferred to a desk phone inside the building, everything would have looked fine — because that call never crossed a carrier boundary. That inconsistency is usually the first clue.
There's a second thing people try that also doesn't work: putting "who's calling" text in the SIP display name. On a desk phone, that works, because your PBX controls the display. Out on the mobile network, carriers ignore the display name entirely and look up the number in a caller-name database (CNAM). So a transferred call can carry a perfectly descriptive name in the header and the cell phone will still show whatever CNAM has for the number — or "Spam Likely."
The fix that actually works
Stop trying to make the transfer look like it's from the customer, and instead:
-
Send a number your trunk actually owns. Use your main line, or a dedicated "transfer from the office" number, as the caller ID on the outbound leg. Your carrier can now sign it with A-attestation, and the mobile network treats it as a legitimate call from a known business. The agent's phone shows your office number and rings reliably.
-
Deliver the caller's identity out-of-band. The agent still needs to know who's on the line and how to call them back. So send that information alongside the call rather than inside its caller ID:
- a screen-pop or text message to the person receiving the transfer — "Transferring: Jane Doe, 555-0123, asking about the listing on Oak St." — sent the moment the transfer starts;
- a whisper announcement the recipient hears before being connected ("Transfer from the front desk: Jane Doe about a listing"), which the caller doesn't hear.
-
Keep the callback number in the message. Since the caller ID on the phone will now be your office number, make sure the real caller's number is in the text or the summary that follows the call, so a missed transfer can still be returned.
For the brokerage, that meant the AI now transfers using an owned office number, and the receiving agent gets a text with the caller's name, number, and reason for calling as the phone starts to ring. Same information as before — actually more — but delivered in a way that doesn't get the call flagged.
Why this is worth understanding, not just fixing
If you run a business where calls get transferred to cell phones — sales teams, agents, on-call staff, anyone working from their car — this affects you whether you've noticed it or not. Some of your transfers are probably being labeled. The people receiving them may have quietly learned to ignore calls from certain numbers, and you'd never see that in a report.
It also comes up immediately when you add an AI receptionist, because an AI transfers everything it can't handle, and it transfers a lot of it to mobile phones. Getting the caller-ID strategy right is part of deploying one properly. It's not a setting; it's a design decision about how identity moves through your phone system.
If you're seeing "Spam Likely" on your own transfers, that's the conversation to have with whoever runs your phones — or with us.