SOLVED

Consult then transfer to call queue is not working

Brass Contributor

Hi,

 

We are using teams with direct routing option.

Everything is working fine but we cannot use the option consult then transfer to a call queue.

You can call the call queue and get a user on the phone but the option to transfer the call disappears.

 

Consult and transfer to a direct users is working fine!

And a direct transfer without consult to a call queue is also working fine...

 

Anybody has the same issue and is there a solution for this problem?

Hope you can help!

 

Greetings,

 

Lars

 

80 Replies

@Thorsten Stiebig Hi Thorsten, any news on that one? I have a similar problem here, regarding ALL consulted transfers, not only to call queues. We already identified that the chance of successful transfer is higher if one uses a fully qualified E.164 number as a target. Some Microsoft SBCs seem to normalize number correctly, some don't. And you never know, what users will dial ... thus we implemented a full-blown set of normalization rules so that the target ist always a full E.164 number. Nevertheless ... still get unsuccessful transfer in numerous calls. Any new hints to the root cause?

 

Thanks in advance!

 

Best

Dominik

@CDZoeller 

Hi Dominik

I recently had a meeting with an actual engineer from Microsoft.
That was the answer:

"This being said, the engineering team is currently working on two work items in that regard, namely one with hiding call queues from the search for consultative transfer while the scenario is not supported, second with adding support to consultative transfers to call queues.

At this point there is no ETA and PG is working on the available options to implement such, being in the engineering scope of decision, to implement the functionalities and update regarding the timelines for such."

For the time being, they said, we should use call merge.
https://support.microsoft.com/en-us/office/merge-calls-in-teams-15fd64cf-1500-4143-b199-1bbda98fd695
So you initiate the call with "consult, then transfer" and then merge the two active calls.

Regards,
Thomas

Reading the last reply here, I may certainly hope that they will fix it or leave it as it is, and not begin with
"hiding call queues from the search for consultative transfer while the scenario is not supported"
That is a bad idea as well. Why?
Because at this point you can still consult the call queue, someone in the queue picks up (person X), they say it's ok to transfer to them, then you have to leave call with person X , resume call with client , 3 dots more actions - transfer - type person X --> Go...

It's annoying, but it does the job.

If they disable consulting the call queue, you have to consult one person at a time and constantly know who is in the queue, which is even worse.

 

Merge call is perhaps a workaround if available, but it's equally annoying.

Anybody got some update about this case?

If i see how long ago i created this topic i don't have hope the are going to fix this!

I have given up.
I said we will use the call merge feature, but this has still not been released. According to M365 message center, this feature will be released until end of may.

@tomae_bfh 

this problem has resurfaced again, I had this fixed in my tenant, and it was working fine, but it has now resurfaced and there is another call within MS for this.

 

will check back later once I find out what the issue is.

@TeamsDR 
So, you had it fixed how?

Under Teams Admin Centre, Org Wide Setting then Teams Settings there is an option:
Scope directory search using an Exchange address book policy - this was set to 'on' which messes with the search function. but this is not the issue now, something new. I have just filled in the detail for MS to ascertain the issue.

@Lars86 

 

We are experiencing the same issue, as in when accepting a call from a "Call Queue" you can select to consult with a colleague, but don't have the Transfer option to transfer the original call to the "consultant". However, have discovered a workaround (if this helps). just ask the consultant to hang up then you are free and able to transfer the original call to them. Bit of a faff, but better than nothing.

 

Just to confirm all is fine is one is called direct (not via a call queue), then one has the option to consult with a transfer button

 

 

 

@Lars86 If I recall correctly, call merge works.
I can't test at the moment to verify this.

I have no open ticket, because Microsoft is not willing to look into this.
Hi,

we have to accept this issue . Microsoft knows this issue and they will Not fix it Right now. That is the official feedback from Microsoft.

Sad but true.

@Thorsten Stiebig 

 

Yes indeed sad but true!

Going to test call merge and hope the end users are helped with that feature..

@Lars86 

Did anyone get any further feedback on this from MS ? Is there something logged on uservoice ?

@wvaneyken there is no uservoice i am aware off... and our tickets at microsoft are all on a dead end! 

@Lars86 

 

We had the same issue in our organisation. Enabling Conference Mode under Call Queue (Call Answering) seems to have fixed this issue. Can anybody comfirm this or tell me if that "fixes" the issue for you?

arnevh_0-1656078925704.png

 

Unfortunately, this option has been active in our company for a long while now, and the issue is still there.

Enabling Conference mode resolved the issue for me.

@John_G_Schmidt 

Glad to hear that. The strange part is that even when we asked a Microsoft engineer, he said this behavior was not to be expected and we should change the way we work.

In their own documentation I can read that conference mode in a queue should improve connection times but also enable consult/transfer. So they clearly know ... .
https://docs.microsoft.com/en-us/microsoftteams/create-a-phone-system-call-queue?tabs=call-answering...

arnevh_0-1656483491258.png

 

@Lars86 

 

We are now using the merge option then to pass a call to a queue to a end user, works fine, and the person who picked up the call queue just leaves. This leaves the caller chatting with the transferred user.

 

But (there is always a but) the transferred user does not have an option to transfer the call on again.