Avaya MOH and Announcements

[jherman]

I’m hoping someone can help me with our situation.  We have TServers (1 primary and 1 backup using HotStandby) on release 7.2 with VTO for our music and announcements.  We would like to try using Avaya (S8700, rel 3.1) for our music and announcements instead of VTO.  Does anyone know how to do this?  Here is our setup:

Avaya Vector 1 – VDN 18897 (main strategy)
1. wait 1 secs hearing silence
2. adjunct routing link 3
3. wait 5 seconds hearing silence
4. queue to skill 896 pri l
5. announcement 11921
6. wait 30 secs hearing music
7. announcement 11922
8. go to step 6 if unconditionally
9. stop

Avaya Vector 2 – VDN 18898 (MOH)
1. wait 1 secs hearing silence
2. adjunct routing link 3
3. announcement 11921
4. wait 30 secs hearing music
5. announcement 11922
6. go to step 4 if unconditionally
7. stop

Genesys Busy Treatment

Treatment        Timeout
IVR                   999
Pause               2

Parameters       Value
Target               18898@ERS_Statserver

The voice treatments are working fine in this setup, but Genesys stated in a document not to have Vector 2 in a “forever” loop as shown above.  How do you program the systems to only play the Announcement 11922 and music for the duration of the call on hold?  Announcement 11921 is just a welcome announcement (“Thank you for calling….”) that should typically be heard only once. Also, we are unable to figure out how to handle the calls when the TServer loses connection.  We do not want calls to be sitting in a loop forever.  Any help will be greatly appreciated!

JoAnn

[Daimonas]

Here is example...

Main VDN: 52026 w/ Skill 1st being 507
Vector:27
01 wait-time    0  secs hearing silence
02 goto        step  13  if staffed-agents  in skill 507          =  0
03 announcement 51719
04 adjunct      routing link 1
05 adjunct      routing link 7
06 wait-time    5  secs hearing ringback
07 queue-to    skill 507  pri t
08 wait-time    45  secs hearing music
09 announcement 51712
10 wait-time    60  secs hearing music
11 goto        step  8  if unconditionally

Genesys Treatment VDN: 58140
Vector:363
01 wait-time    0  secs hearing silence
02 adjunct      routing link 1
03 adjunct      routing link 7
04 announcement 51719
05 wait-time    35  secs hearing music
06 route-to    number 58136            with cov y if unconditionally
07 stop

Default VDN: 58136
Vector: 359
01 wait-time    0  secs hearing silence
02 queue-to    skill 1st  pri m
03 wait-time    10  secs hearing music
04 announcement 51712
05 wait-time    180 secs hearing music
06 announcement 51719
07 wait-time    300 secs hearing music
08 goto        step  6  if unconditionally
09 stop             

As you can see, the default VDN collects the 1st skill from the main VDN, therfore you can re-use this treatment in any Genesys strategy and still have default routing for cases where Genesys does not respond or unable to route the call.

Questions?

[Daimonas]

Other thoughts: You would need additional treatments to play music on hold or other announcements. If you just want to play thank you for call once, include this announcement prior to the adjuncts in your first vector.

If you are going to use Avaya for treatments, I recommend you use type of IVR with compatible mode, which works best.

[jherman]

Thank you for your response.  We do have a few questions:
1. What is your "IVR Treatment" timeout in IRD?
2. I'm guessing you have a strategy loaded on the Main VDN and not loaded on the VDNs 58140 and 58136.
3. You mention that the default VDN collects the 1st skill from the Main VDN.  Wouldn't you need that skill entered on the Default VDN.
4. You mentioned playing the announcement before the adjunct steps.  Wouldn't this be a mandatory announcement?  We weren't looking to play a mandatory announcement, just a first announcement if no agents are available.

Thanks,
JoAnn

[Daimonas]

Answers:

1. Depends on the treatment, for announcements usually 10 seconds and for music 30 seconds.
2. Correct, only a strategy on main VDN.
3. No, as long as "Allow VDN Override" is set to "N" on the main VDN. This 1st skill will follow the call where ever its routed.
4. That is correct, one way you can get around this is to create two target blocks, the first one playing the treatment if there is no agents available and have 1st target block timeout to the 2nd after the treatment is played. Both target blocks should have the same target and VQ and leave clear target un-checked so you don't double count the call. Alternatively, you can use one target however you need enough treatments for the caller to hear without looping back to your first "Thank you for calling" prior to getting answered.

Note: keep in mind you can't play the same treatment VDN twice (in a row), you can use the same vector but must be diffrent VDNs. Also note you should also have a longer wait time on the vector then the timeout in IRD.

[victor]

Jherman,

Avaya script is fine; however, you need to be very very wary of:

11 goto        step  8  if unconditionally

If for some reason your URS decides to go down under for a weekend and gets drunk while you still have calls waiting in queue, you will never be able to retrieve those calls (even after feeding Colombian super-strength coffee into your URS and rebooting it) and they will be stuck forever. On smaller call centers, people don't really care about it, but on larger ones, you will need to address this.

Therefore, you will need to add an adjunct inside there and create a strategy that will route the calls to default or some special overflow DN, and load it on VDN in question. Since you will be using Treatment object to define your Music VDN in your original strategy, as long as your URS does not crash, it will completely ignore EventRouteRequests issued by your music VDN. But, should it crash and be restarted, it will not recognize EventRouteRequest's ConnId as one of the calls currently being treated and therefore will launch your Emergency strategy to dump the stuck calls somewhere.

Tell me if you want me to post the script and sample strategies.
Best regards,
Vic

[Daimonas]

Victor: The only way a caller would get to that step is if the Adjuncts failed and the switch took over the call anyways. URS is done

[victor]

Hi, Daimonas:

thank you for your comment. I think you are mistaken.
Ask yourself - when the call is parked on 58136 , there is no way for it to be retrieved other than by direct command from URS. So, if URS crashes, your call would be looping there forever. Check it out and you will see what I am talking about!

Vic

[jherman]

Vic,
Did you mean to reference the step in the Default VDN rather than the Main VDN?

08 goto        step  6  if unconditionally

Then I think what you are saying applies.

JoAnn 

[Daimonas]

Ok....Victor, what you say is true for the VDN jherman provided, VDN 18898: 6. go to step 4 if unconditionally

However, VDN 58136 is perfectly ok, this is a default VDN used ONLY by Avaya, Genesys has no idea what it is, nor should it.

For example, If a call comes into VDN 52026 w/ skill 1st being 507 and VDN override turned off, they will reach the Genesys adjuncts. At this point Genesys has 5 seconds to respond (while ringback played) before the switch takes over the call by routing the call to an ACD queue. By default, this action will CANCEL the genesys route request and Genesys has NO control over the call.

Another example would be, say no agents are available and Genesys responds with a Please Hold treatment (VDN 58140) within 1 second. The call would leave (divert) from VDN 52026 and queue to VDN 58140. At VDN 58140, the switch will again give Genesys control by requesting route with adjuncts. In this case however, Genesys is configured for a treatment so it will not respond to the switch, so the the switch will play (non route canceling function) music for the duration specified in the vector.

Now here comes in VDN 58136 you referred to. Genesys has 35 seconds to answer the route request, otherwise Avaya will CANCEL the route request and route the call to VDN 58136, where Avaya will default route and use the 1st skill associated to VDN 52026.

This is how it works on Avaya switchs, maybe you are referring to a diffrent switch?

[Daimonas]

Here is a real world example, that happened some time ago...

There was a site that had only 1 T-Server, no backup. So the vectors only had 1 adjunct CTI link for the single T-Server. At some point, a backup T-Server was installed and 2nd CTI link was created. This new CTI link was added to the main vectors but not the treatment vectors used by Genesys (as the Genesys treatments are kinda hidden).

So one day, the Primary CTI link decided to fail and the Backup T-Server took over. Do you see where I am going with this?

If not, what happened was the main vector took the call, got route instructions from Genesys and Genesys routed call to a treatment VDN. The call then queued and abanonded on the Genesys side.

What happened was, since only the primary CTI link was on the vector for the treatment VDN, the active T-Server never got the route instructions, therefore router dropped the call and abandoned the call from the VQ.

Since the treatment vector never got a responce from Genesys in the time allowed in the vector, the call was routed to the default VDN  (example of VDN 58136) and routed the call via the switch, instead of Genesys.

End result, all calls were still answered, as no calls were being routed by Genesys and the switch took over.

[victor]

Hi, guys, thank you for the follow up!

I see that I missed this line in 58136:

02 queue-to    skill 1st  pri m
which essentially queues the call to the main skill. With that line in, call essentially is owned by Avaya so, it will behave exactly as Robb said. (but read on!)

Original MOH given by JoAnn is going to make a lo of calls held indefinitely should Genesys crash.Robb's script will work but there is a very big and fat but: it is not suitable for multi-skill environment. On top of that, you will end up with a possible race condition where both URS and PBX will route the call to the same agent.

By adding adjunct inside the loop, and creating a strategy to handle "lost" calls loaded on MOH vdn, you can effectively avoid race conditions or rely on hard coding skill routing into PBX and instead rely on Genesys URS. It will also allow you to take that call back into a queue while giving it the extra prirority it might deserve.

The disadvantage of what I propose is that if you are unable to restart Genesys URS for some reason then the call will still be stuck in queue without any way of getting it out.

At the end of the day, both of approaches work, and I think you will find something in between to fit in exactly as you need it. We usually avoid sending default calls to a PBX skillset because it might arrive at the same time as URS-routed call and cause one of the calls to disconnect.

Best regards,
Vic

[Daimonas]

Hi Vic,

      I agree the point you bring up, and think it is a good one. I will work on getting your idea implemented along with the default VDN in the future. Thanks!

[jherman]

Thank you both for your responses.  I really appreciate it.  We're going to do some testing and I'll let you know the outcome.

Happy Holidays!
JoAnn