Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DNIS Report question

Status
Not open for further replies.

todd1019

IS-IT--Management
Nov 11, 2002
134
0
0
US
Here is the situation.

DNIS 1234 calls come in and route to CDN 3044 thru the master script.

CDN 3044 plays a prompt and then transfers the call to CDN 3045.
CDN 3045 which offers to a skillset and then queues if no agents are available.

When the prompt was included in CDN 3045 it negatively impacted service levels so it was moved to its own CDN in order to report the service level from when the call was offered to the skillset. The prompts were mandotaory from clients but we should not be penalized by their upfront prompt requirement.

This does cause a reporting issue for folks that run reports and do not understand the routing.

If 10 calls were recieved and routed to CDN 3044 and then sent to CDN 3045 to be answered the DNIS reports 20 calls were recieved. Each CDN report only shows 10 but it looks as though the DNIS report adds the total for all CDN calls.

IS there a better way to handle the upfront prompts and not negatively impact service levels or a way to make the DNIS report only report on the calls recieved from the carrier and not add the CDN calls together?
 
PS hoe this make sense if not I will tryt ot better explain the question.

Also this is Symposium 4.2 with the web client 4.0.
Nortel Option 81C
 
That is bizzare that the DNIS is showing double figures, usually this happens if a script or Meridian Mail sends the call back out to the DDI? Are you using call pilot or Meridian Mail? Access link/VPE?


Cheers,

Killian
 
I think the DNIS report in the Symposium may be created to SUM the CDN calls to the DNIS total calls answered field.
 
You could try handling the CDN transfer at the LD 49 IDC tables. Just program them on your incoming route and make it so:

1234 3044

Since 3044 is a CDN acquired by SYmposium it will immediately look at the Master Script. At this point you can play the required message by saying this in the master script:

Where CDN EQUALS

Value 3044:(Play prompt here)
Execute Script 3045

END WHERE

That should prevent the need to transfer the calls back into the system carrying the DNIS digits back in with it.

Once you have done this you can run an application report instead of a DNIS report and get the Service Level information. This is the best way to do this since its how it was intended to work. Its all about where you collect your information from...

There is a service level % for applications and you just have to set up the Threshold values in the Application Thresholds for them to be correct.

In short collect your Volume data for each 800# at the DNIS level but collect the service level numbers from your application level. This will require a one to one ratio of DNIS to scripts(Applications)if you are required to get service level numbers from each incoming number.

If that still doesn't solve your problem try routing the call through an analog phantom number on your switch and turn off all the digit passing features on the set. That should hopefully strip the incoming DNIS information off your calls before presenting it back into Symposium like it was originated from internal to the PBX. Just use the DCFW feature and push it to the 3045 CDN.

 
What you have descrided is exactly how I am handling the calls.
Only problem is the DNIS report sums the CDN offered calls instead of realizing they are the same call.

I think it may be the formula on the report.
 
todd1019 - Do you make use of customized reports?

Your problem sounds familiar to me, during the time we were still using SCCS 1.5. We had outsourced the managed of our SCCS system. All call routing was based on CDN and through scripting we made no use of DNIS.

Perhaps you should take a look at the call by call data, if possible through ODBC connection straight at the DB table, and check the event sequence.

If possible post some more detail info. In the end I built a custom reporting engine to extract call by call and convert each call to 1 record.

Greetings,
Michel
 
We are working to create customized reports through Crystal Reports. When we finish this I think my issue will be resolved.
 
you could try putting it back to how it was, and resetting the call timer once the message is given
 
Jimbobp :: resetting the call timer, I'm interested in this statement. How do you apply this and what effect does this have?

Greetings,

Michel
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top