Need NCC design hints 1

[BenSlimed]

We have two Version 6 CCMS/CCMA co-res nodal servers networked via NCC. All of our incoming calls come in to the Detroit PBX and these calls are immediately queued to a network skillset that includes agents in both Detroit and Lansing. Our goal is to find the longest-idle agent in either Detroit or Lansing, and we have been able to accomplish this goal via some fairly simple scripting. However, we have some side effects that we are wondering about.
The first side effect is that our Network Consolidated application RTD's seem to "double-tally" the incoming calls in the ARRIVED column. Detroit's site shows the calls under the "Sales_networked" application, while Lansing's site shows the very same calls under the "Network Script" application. Is this design intent? If so, how can we avoid double-counting while accomplishing our goal of finding the longest available agent in either city?

The second side effect is that we can't seem to figure out how to view agent RTD's from both sites within one RTD window. Is this somehow possible? Or are we stuck with the summary data offered by the Network Consolidated Agent RTD?

The third undesirable side effect is that we can't figure out how to get detailed reporting on our agents without pulling the same reports from both nodal servers. Again -- are we stuck with Network Consolidated Historical Reports or is there a method to pull the required detailed agent data from a single report?

We appreciate any feedback that is offered.

 

[Milesprower]

You are experiencing normal operational issues in a Nortel network environment. To your first point, yes the real time display is operating correctly.

The key point is that each CCMS is a distinct entity with its own database. The NCC only coodinates commication between the individual sites. When you run a consoldated display or report, the NCC pulls the data from each site and merely puts it on one screen or page. There is not a consoldated database.

It is very easy to doublecount calls as you have observed. You will want to get network report training from Global Knowledge. Nortel's documentation is weak or silent on how to interpret network displays and reports.

 

[BenSlimed]

Thanks for you input, Miles. I was afraid that this would be the answer. Again, appreciate you piping in.

Ben

 

[picklemogg]

Howdy- we just went through this transition recently and I can appreciate what you are experiencing. I agree with Miles 100%.
As far as network reporting goes (and where peg counts happen, etc) you just need to setup a test queue and bang away at it for a few days and learn that way. Like Miles had mentioned, Nortel's documentation is weak. Almost laughable. Global knowledge training isn't any better. After all, their training is based off Nortel documentation. So- don't waste your money there. The network application for reporting purposes is fairly pointless. All calls peg at that local application that the call is being sent from anyway like you had mentioned. Like I said the best way is to test yourself. Good luck.

 

[Milesprower]

While I agree the Global Knowledge training has a lot of fluff (and little substance), the only place where I have seen network skills based routing call pegging defined for Real Time Displays and Reporting is in Global Knowledge documentation from their SCCS Networking Class. They have a couple tables that define how calls are pegged and examples of "edge" or glare conditions where a call may be abandoned during the transfer between sites.

There are some basic real time display definitions in the NCC Administrator's Guide for CCM. There is also a very basic network pegging example in the Historical Reporting and Data Dictionary.

Nortel had promised to update documentation to include more information on networking with CCM, but it does not appear to have been done (at least I cannot find it).