Tag a call from the beginning to the end 1

[Joledur]

Hi,

I'm looking for a way to tag a call that enter from a specific DID and keep this tag even if the call leave VMPro to go in a queue.

Tag set in ICR is working fine with $TAG, but it hide the clid of the caller.CPx and $DDI are reset when the call leave the VMPro to the IPO, Then I cannot use these values in the next queue.

Thanks

 

[janni78]

Might be easier to give you pointers if you say what the use case is.

"Trying is the first step to failure..." - Homer

 

[Joledur]

Thank you for the reply janni78.

Here is an exemple: An "agent" receive calls from multiples DID, in case of no answer the calls are routed to a VMPro node. In this node, the call is dispatched according with the source DID (or a tag). If the call is comming from a specific DID or if he have a tag, he will be routed to another agent, if not, he will be send to the mailbox of the agent.

 

[tlpeter]

Fix the way agents answer calls.
If an agent does not answer a call then you have a problem as an agent should log out or answer the call.

BAZINGA!

I'm not insane, my mother had me tested!

 

[janni78]

On the DID were it should go to another agent route the call to a sequential huntgroup instead, why take the detour through VM Pro?

"Trying is the first step to failure..." - Homer

 

[Greybeard191]

I want to echo what is done noted above... this is much easier if done within HG and HG overflows.

Nevertheless I think you can:

1. test for a DDI (and cascade these tests at 14 tests per variable routing action, no match goes to another set of 'test for 14 more DDI's etc etc)
2. tie a positive match for a DDI to a transfer action that has something entered on the description field... this field is the equivalent of the "tag" in the ICR, I believe.
3. rinse, lather, repeat
4. tell the customer every time they want you to even look at it is $500.
5. bemoan the fact you ever built it

good luck

GB

 

[Joledur]

Yes, but sequential hunt group prevent to receive multiple calls like "collective call waiting" mode. To accomplish what is needed here I should have a "sequential call waiting" mode.

Let me explain, I have put agent in quote"" because they are not real agents, they are regular office worker and receptionnist and this is why I cannot use standard agent feature like what tlpeter suggest.

Exemple: The receptionnist is the first in row for the tagged calls, even if she is talking with someone for her receptionnist job, she must be able to answer tagged call that ring on the other call apperance. In the sequential group, the call will go directly to the next agent.

 

[gknight1]

you could create a separate vm module for each user or group that misses the initial call, then you would be able to set a TAG for each one before its transferred back out to whomever it needs to go.

 

[Joledur]

Greybeard, DDI variable work only untill the call leave the voicemail.

The tag in the ICR work fine and it is stick on the call for his whole life. The problem with the ICR tag is that is replace the caller id.

I'm looking for something that do the same exact job than the ICR tag but without altering the caller id.

I love the power of the VMPro, Im certain that there is a way to do it perfectly.

 

[janni78]

Use Collective Call Waiting then and overflow to another.

"Trying is the first step to failure..." - Homer

 

[Joledur]

A collective call waiting group for each one, good idea, pretty sure that it will work for my particular call flow, I will test it tomorrow.

Thanks

 

[Greybeard191]

I don't think the tag replaces the CLID, it just pushes it "down"? Have you tried hitting the down arrow on the scroll wheel to see if the CLID is there?

GB

 

[Joledur]

FYI

The solution of janni78 work fine using the overflow list of the first group in row.

Greybeard, I will test it just for curiosity, but hitting a key to see the caller id is always too painfull for a client as you surely know!

Thank you very much everyone!