Ok, free mars bar to anyone who can crack this one, it seems to be baffling the egg-heads at 3CX Towers. Incoming call from Sip Trunk is fielded by receptionist. She speaks to the caller and then makes an attended transfer to Extension 2345 User at 2345 isn't there, the call starts to go to VM, so the receptionist aborts the transfer attempt. Receptionist speaks to caller again and establishes his secondary preference, and starts an attended transfer to 3456 As SOON as she presses the TRFR key, the call is gone. It does appear to be a factor that the first attempted transfer went to VM, BUT if the receptionist has then retrieved the call, not completed the transfer, surely that should not be a factor. If she abandons the transfer and goes back to the caller BEFORE the first extension goes to VM, it never happens. As it is, it only "sometimes" happens. But often enough the customer is getting Quite Cross. UNLESS - and I don't see how but - unless somehow the receptionist returning to talk to the caller *hasn't* ceased the first attempted transfer and so when she presses TRFR again, that's seen by the system as the *completion* of the original attended transfer. (If it matters - 3CX V12 - latest SP *not* yet applied - Receptionist uses a Yealink T.46G - Sip Trunk is from Gamma. 3CX have reminded me this is an "unsupported" supplier but frankly, the customer is more likely to chuck 3CX and go Asterisk than they are to change Sip Trunk, the deal is too good. There's also an ISDN trunk (Patton gateway) and I'm wondering if I should try forwarding the sip trunk to that and see if the problem persists when the incoming call is via ISDN.