It is understood that T-server / URS debugging log files contain sensitive business data and cannot be posted! It makes the trouble-shooting process harder!
Most URS options look fine.
[u]use_ivr_info[/u]
Brief option usage is extracted from URS 7.2 manual; please verify its manual for the version you are using
Use Cases:
• Turn this option off when IVR is used for mandatory treatment, such as when each caller is greeted with a welcome message. In this case, when IVR returns the call to the routing point, URS continues the strategy right after the mandatory treatment.
• Turn this option on only if you expect IVR to return new data to the routing strategy. In this case, URS starts the strategy from the very beginning so that the new data will be evaluated.
[b]"Some calls after completing the busy treatment are landing on to default queue with...".[/b]
Does it mean that "landing to ACD position" cases occur only after end of busy treatment?
If yes, it could be configuration issue in URS strategy with VTO busy treatment!
(I personally love and hate implementing busy announcement using Genesys URS/VTO.)
Let's go back to call queuing design.
A typical simple queue waiting could be (an example only):
1. ringing for 12 seconds
2. play 1st busy announcement (all agents are busy, please wait)
3. music on-hold for 30 seconds
4. play 2nd busy announcement (all agents are still busy, please hold thank you for your patient)
5. go to step 3
Others queue waiting options such as queue position / Expected Waiting Time announcement and voice mail deposit invitation may be required but not discussed here.
Genesys URS and VTO (for mandatory and busy treatment) work in following manner.
- URS gets call interaction control at Route Point from switch (via CTI-link to T-server)
- If URS strategy selection target is configured with busy treatment, call interaction is transferred by URS (via T-server, of course) to a VTO port which is also controlled by URS (it is why all VTO ports appear in URS strategy loader!).
- Voice file(s) is played by VTO port (in this case, GVP is used)
- If agent is available, URS introduces T-server transferring call at VTO port to the selected agent (in this case, to agent's extension)
[u][b]The simplest implementation method:[/b][/u]
- in URS strategy:
Target object --> busy treatment --> ringback (duration=12)
--> PlaceGroup_BusyTreatment (duration=999999)
--> selection list --> [skill expr-1], [skill expr-2], [agent group],...
- GVP / VTO:
1. play 1st busy announcement (all agents are busy, please wait)
2. music on-hold for 30 seconds
3. play 2nd busy announcement (all agents are still busy, please hold thank you for your patient)
4. go to step 2
Note: yes! it is an infinite loop!
Loop counter may be used to align duration (999999) in URS strategy
Pros and Cons:
+ simple implementation
+ less call 'legs' involved
- call is parked at physical VTO (GVP) port while queuing
[u][b]Other implementation method:[/b][/u]
Note: there may have limitation to transfer call from a RP to the SAME RP.
if it does, two RPs loaded with same strategy help to overcome such restriction.
- in URS strategy 1 at CDN-1:
- a key/value must be defined to flag call states
e.g., key = queueState, value: empty=new call, "1stBusyAnn"=1st busy ann. played,
"moh1"=music onhold played after 1st busy ann.,
"2ndbusyAnn"=2nd busy ann. palyed,
"moh2"=music onhold played after 2nd busy ann.
if queueState = empty
Target object --> busy treatment --> ringback (duration=12)
--> PlaceGroup_BusyTreatment (duration=length(1stBusyAnn))
--> selection list --> [skill expr-1], [skill expr-2], [agent group],...
^^^ may need to align with selection targets along waiting time!
else if queueState = 1stBusyAnn
Target object --> busy treatment --> PlaceGroup_BusyTreatment (duration=length(musicOnHold))
--> selection list --> [skill expr-2], [agent group],...
^^^ may need to align with selection targets along waiting time!
else if queueState = moh1
Target object --> busy treatment --> PlaceGroup_BusyTreatment (duration=length(2ndbusyAnn))
--> selection list --> [skill expr-2], [agent group],...
^^^ may need to align with selection targets along waiting time!
else if queueState = 2ndbusyAnn
.....
.....
- in URS strategy 2 at CDN-2:
similar to strategy 1 at CDN-1:
- GVP / VTO:
if queueState = empty
play 1st busy ann.
queueState = "1stBusyAnn"
else if queueState = "1stBusyAnn"
play music file
queueState = "moh1"
else if queueState = "moh1"
play 2nd busy ann.
queueState = "2ndBusyAnn"
else if queueState = "2ndBusyAnn"
play music file
queueState = "moh2"
else // in case of missing KV-pair!
play music file
queueState = "moh1"
end
// if there is limitation/restriction transferring call from current controlled RP to the same RP
if current CDN = CDN-1
transfer call to CDN-2
else
transfer call to CDN-1
end
Pros and Cons:
+ VTO (GVP) ports are shared for queuing calls
- more complex implementation
- many call 'legs' involved
Note: URS transfer_time (default 15 seconds) is used to keep track of lose interaction.
In this case, if VTO port transferrring call from CDN-2 fails and disconnects, virtual queue reports "abandoned" after 'transfer_time' seconds.
URS keeps interaction data for 'transfer_time' interval; thus, avoid treating the interaction as separate call.
Sorry to make this lengthy reply; URS/VTO implementation is a bit messy.
It would be great if there is any better method available!
