Hello

I have quite a challenging implementation situation.

General Concept

There is a known GC behavior, that when on a call (from a queue), then, consulting with external Participant

The Caller Id is not set as the Caller Id of the queue in which the call came from, but GC refer to the "Outgoing Consultation call" as a new call that is not

On behalf of a queue, and there is no option to select queue, so, we stuck with the site Caller Id or the trunk Caller Id

My Situation

I have specific situation in which, every team has numerous DID Numbers that sending calls to them via Queues, and the number of DID Numbers

In the Org is much more then 100 DID's,

And unlike other Orgs, each DID is unique and has no relation to the other, so if the Agent Consulting with external participant, he must have the 

Specific Caller Id of the Queue that the inbound call came from.

Cumbersome Solution
So, ideally, if GC was automatically setting the caller Id as the Caller Id of the Queue it was the perfect solution, but that's not the current behavior of GC

So, the practical solution is to handle this gap between raw system capability to the business need, is by:

setting multiple Sites, each site for each group of DID's, and then, setting number plans on the site, that routes calls to different trunks

by the prefix that the Agent type before the dialed number, for example if Sales Q is prefix 9, and Service Q is prefix 8, so:

"9<dialed number>" is routed to Trunk 1, and "8<dialed number>" is routed to Trunk 2

Then in each Trunk has different Caller Id, essentially creating as much trunk as the number of DID's in the Org,

Thus, if the Agent wants to go with the Sales Q Id in the consult call, he will type 9 before the Dialed number and for the Service Q he will type 8 receptively.

This is very cumbersome solution, reminding me of Avaya systems and Old Legacy Solutions

I'd be very happy to hear about Simpler practical solutions

Many thanks in advanced

Hello Shahar,

You should be able to change the Prioritized Caller Selection feature on your trunk so that it will use the Call Source (Queue/Campaign/User DID) for the caller ID info.

Hello

I have quite a challenging implementation situation.

General Concept

There is a known GC behavior, that when on a call (from a queue), then, consulting with external Participant

The Caller Id is not set as the Caller Id of the queue in which the call came from, but GC refer to the "Outgoing Consultation call" as a new call that is not

On behalf of a queue, and there is no option to select queue, so, we stuck with the site Caller Id or the trunk Caller Id

My Situation

I have specific situation in which, every team has numerous DID Numbers that sending calls to them via Queues, and the number of DID Numbers

In the Org is much more then 100 DID's,

And unlike other Orgs, each DID is unique and has no relation to the other, so if the Agent Consulting with external participant, he must have the 

Specific Caller Id of the Queue that the inbound call came from.

Cumbersome Solution
So, ideally, if GC was automatically setting the caller Id as the Caller Id of the Queue it was the perfect solution, but that's not the current behavior of GC

So, the practical solution is to handle this gap between raw system capability to the business need, is by:

setting multiple Sites, each site for each group of DID's, and then, setting number plans on the site, that routes calls to different trunks

by the prefix that the Agent type before the dialed number, for example if Sales Q is prefix 9, and Service Q is prefix 8, so:

"9<dialed number>" is routed to Trunk 1, and "8<dialed number>" is routed to Trunk 2

Then in each Trunk has different Caller Id, essentially creating as much trunk as the number of DID's in the Org,

Thus, if the Agent wants to go with the Sales Q Id in the consult call, he will type 9 before the Dialed number and for the Service Q he will type 8 receptively.

This is very cumbersome solution, reminding me of Avaya systems and Old Legacy Solutions

I'd be very happy to hear about Simpler practical solutions

Many thanks in advanced

Hello

I have quite a challenging implementation situation.

General Concept

There is a known GC behavior, that when on a call (from a queue), then, consulting with external Participant

The Caller Id is not set as the Caller Id of the queue in which the call came from, but GC refer to the "Outgoing Consultation call" as a new call that is not

On behalf of a queue, and there is no option to select queue, so, we stuck with the site Caller Id or the trunk Caller Id

My Situation

I have specific situation in which, every team has numerous DID Numbers that sending calls to them via Queues, and the number of DID Numbers

In the Org is much more then 100 DID's,

And unlike other Orgs, each DID is unique and has no relation to the other, so if the Agent Consulting with external participant, he must have the 

Specific Caller Id of the Queue that the inbound call came from.

Cumbersome Solution
So, ideally, if GC was automatically setting the caller Id as the Caller Id of the Queue it was the perfect solution, but that's not the current behavior of GC

So, the practical solution is to handle this gap between raw system capability to the business need, is by:

setting multiple Sites, each site for each group of DID's, and then, setting number plans on the site, that routes calls to different trunks

by the prefix that the Agent type before the dialed number, for example if Sales Q is prefix 9, and Service Q is prefix 8, so:

"9<dialed number>" is routed to Trunk 1, and "8<dialed number>" is routed to Trunk 2

Then in each Trunk has different Caller Id, essentially creating as much trunk as the number of DID's in the Org,

Thus, if the Agent wants to go with the Sales Q Id in the consult call, he will type 9 before the Dialed number and for the Service Q he will type 8 receptively.

This is very cumbersome solution, reminding me of Avaya systems and Old Legacy Solutions

I'd be very happy to hear about Simpler practical solutions

Many thanks in advanced

The Caller Id development 'might' cover your scenario, though it is not clear if it is for consult.

https://genesyscloud.ideas.aha.io/ideas/TEL-I-345

Hello

I have quite a challenging implementation situation.

General Concept

There is a known GC behavior, that when on a call (from a queue), then, consulting with external Participant

The Caller Id is not set as the Caller Id of the queue in which the call came from, but GC refer to the "Outgoing Consultation call" as a new call that is not

On behalf of a queue, and there is no option to select queue, so, we stuck with the site Caller Id or the trunk Caller Id

My Situation

I have specific situation in which, every team has numerous DID Numbers that sending calls to them via Queues, and the number of DID Numbers

In the Org is much more then 100 DID's,

And unlike other Orgs, each DID is unique and has no relation to the other, so if the Agent Consulting with external participant, he must have the 

Specific Caller Id of the Queue that the inbound call came from.

Cumbersome Solution
So, ideally, if GC was automatically setting the caller Id as the Caller Id of the Queue it was the perfect solution, but that's not the current behavior of GC

So, the practical solution is to handle this gap between raw system capability to the business need, is by:

setting multiple Sites, each site for each group of DID's, and then, setting number plans on the site, that routes calls to different trunks

by the prefix that the Agent type before the dialed number, for example if Sales Q is prefix 9, and Service Q is prefix 8, so:

"9<dialed number>" is routed to Trunk 1, and "8<dialed number>" is routed to Trunk 2

Then in each Trunk has different Caller Id, essentially creating as much trunk as the number of DID's in the Org,

Thus, if the Agent wants to go with the Sales Q Id in the consult call, he will type 9 before the Dialed number and for the Service Q he will type 8 receptively.

This is very cumbersome solution, reminding me of Avaya systems and Old Legacy Solutions

I'd be very happy to hear about Simpler practical solutions

Many thanks in advanced