Questions about abandonment capture

[zkhandwala]

Hi All,

I'm looking at the way we do our reporting here, and I have some concern about the way we capture our abandonment volume. I'm hoping someone can help me with the following:

1. We currently capture abandonment at the Application level, which I've been told is correct, but I'm seeing something called SkillsetAbandonment in the SkillsetStat table, and finding that the total SkillsetAbandonment volume is greater than the total Application abandonment volume which we report. Might we be under-reporting our abandonment here? What's the relationship between skillset abandonment and application abandonment?

2. For whatever reason, we don't currently include abandonment volume for the Master_Script application in our totals. Is this standard practice? Does it make sense to ignore this?

3. Also, we don't include Network_Script abandonment volume in our aggregate. Thoughts?

Cheers,
Zain

 

[captaingadget]

Here's my view on skillset abandonment:

I assume that the calls are not force anwered by your agents and the phone rings until an agent decides to anwser it. In which case this is the period when the calls are being abandoned. The job of the script is to deliver the calls to an agent, when it has done this i.e. the agent phone is ringing, the script terminates and therefore will not capture the call abandoning, so this is pegged against the skillset. It maybe that the return to queue timer is too long such that the caller is listening to ring tone until the call is answered. Or it maybe that the agents are continually regecting the call and putting back in the queue, you can run a report which will show this.

You're correct to ignor calls abandoned in the master script as they can only have been VERY short duration.

The network script SHOULD rarely do anything but could indicate agents rejecting calls. It's worth running some reports to see.

Hope this helps.

 

[zkhandwala]

Thx for the response, Captain.

Actually, our calls are force-answered, so I don't think this can be the case. Admittedly, I don't fully understand the Applictaion-Skillset relationship. Is it not the case that a call can actually be 'in' a skillset/queue (i.e. somewhere between an Application and a handset) for some time before it is actually transferred to an agent's handset?

I agree with you on the Master Script abandonment, but am still perplexed by the Network Script. Again, I don't fully understand this script. Is it the script that handles all calls coming in across the network (we have two sites)?

Thx again,
Zain

 

[Milesprower]

Incoming network calls are pegged to the network application and show up in the real time display and application reports under the Network application heading. However the network script itself only takes control and handles calls when the target agent becames unavailable in the short time (~ 2 seconds) it takes to transfer the call from the original site.

Example: Call enters site A and is queued by the primary script to a network skillset. The call is under control of the site A primary script. If an agent in the network skillset at site B is picked to handle the call, the site A SCCS directs the site A PBX to transfer the call via the Network CDN at site B. The call is pegged under the network application on site B's real time display and in reports.

If the site B agent pressed the not ready key as the call was being transfered, the network script at site B assumes control of the call when it arrives. The network script has a limited set of commands. The intent is to requeue the call at site B.

There are all sorts of "edge" conditions (depending on the timing of when a call is abandoned) where the call can peg as abandoned in the site A primary script, the site B network script, or both.

 

[zkhandwala]

Miles, thx for the very helpful post! I'm beginning to get a grasp of the relationships here, but it's your last paragraph on 'edge conditions' that troubles me a little. Would you be able to give me an example of each of the abandonment pegging cases (i.e. when it's pegged 'Site B Network', and when it's pegged against both)? Basically, I'm realizing that I probably need to factor the network abandonment into our reporting, but I'd like to know when that might lead to double-counting.

Also - in the case where the Site B Network Script Application re-queues the call due to agent unavailability (such as in the case you cite), does this mean that the call goes to a Primary Application at Site B, or does it get queued directly to a skillset at Site B (I apologize if this is an ignorant-sounding question, but the Application-Skillset-queue relationship is one that's only just beginning to take shape in my mind).

Regards,
Zain

 

[Milesprower]

By Edge conditions, I mean the short time interval (sometimes called "glare") when the call is traveling between the originating and destination site and one or both sites believe they are in control of the call. As these are two independent systems, and NOT one integrated system, there is a chance that the call gets pegged on both systems. In other words, there is not a clean hand-off of the call from site A to site B.

The Nortel documentation has not been very clear about this. It is covered best during the networking class at Global Knowledge. However, the NCC Administration Guides have been updated over time and I believe that the latest one does spell out these "glare" conditions and how a call that is networked pegs on both the origination and destination systems.

 

[captaingadget]

I always enjoy reading milesprowers postings, very usful info. I think it may be worth expanding on the network script usage as there are other scenarios where it takes control.

As miles says it takes over from the point the originating application lets go i.e. when the call arrives at the network agent.

If the calls are force answered then no problem, if the calls are manual answered the agent can reject the call and put it back in the queue.

The call will stay at the distant site and will not queue anywhere else. This means that the caller will be left listening to ring tone until they abandon or are answered.

Also if the queue closes during this period the caller will be left listing to ring tone for ever.

It is worth putting a holding loop in the network script or an "IF NOT QUEUED" check. You cannot put a "queue to network skillset" command in a network script, you will get a validation error.

So basically once a call arrives at distant site it stays there unless you use a "ROUTE CALL" command.

 

[Milesprower]

Thanks Captain for expanding on the Network script. It acts as a backup and provides limited call processing capabilities at the destination site for calls whose target agent is no longer available.

The key here is "limited". In order to prevent calls from bouncing around the network (tromboning) forever (and gobbling up resources), the command set is intentionally curtailed.

 

[zkhandwala]

This is very helpful information, MP and CG. Thx much, and now I need to make a decision as to whether or not to include Network Script abandonment in our numbers. Based on your collective experience, what's common practice here? It seems to make sense to do so, but I'm a little concerned about double-counting (though it would appear that the edge conditions occur infrequently).

 

[captaingadget]

I would say that you only need to look at network script if you think you have a problem. I would guess that 99.9% of the calls would be answered normally by a network agent, after all the call will only arrive at a distant site when an agent is available.