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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

3300: Program Attendant Overflow to RAD's

Status
Not open for further replies.

pichels

Technical User
Aug 1, 2005
313
US
Hi,

We have a LDN 5799 w/ Call Re-route to 1st Alt set to 5918(RAD).

Works fine - answers and music on hold while waiting.
Problem is when we program a 2nd RAD - 5919, and put it in as Call Re-route 2nd Alt - the caller will route to the 2nd Alt immediately, once the 1st RAD is cleared down.

We built a Voice and a RAD hunt group w/ no members having 5918 and 5919 as the 1st and 2nd RAD.
Got ring no answer.(RNA)

Any ideas what we can do next?

-P
 
I have never tried to do this but the method you are attempting does not sound right. Second Alt is used for calls when the first alt is not available or does not answer. I'm not even sure if what you want to do is possible.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Hi kwbMitel,

Weare trying the Operator hold queue suggestion that you mentioned in an earlier post.

An incoming call goes to the Operator and it triggers the RAD - it give the "Welcome to our company bit..." and then goes to our MOH(Music on Hold) if the Operator is busy.

Well, we want to enable another or 2nd RAD as a courtesy message to say "Thank-you for your patience..." - this is our problem!

In the process - this is where the RAD timer on the first RAD doesn't work and goes straight to the 2nd RAS without waiting and won't wait X secs/min!

Make sense?
Need more details?

We have this in production now and now is complaining yet.. <smile>
Any quick help is appreciated.
Thanks,

-P





 
if ive understood what your saying the way round this would be to create a dummy acd path and route the call to this path. create your rads, record the messages and input into the path as required.

its a bit fiddly but a reasonable work around if im understanding your requirements correctly
 
Hi james1982,

We'll try it - I'll see what happens and let you know.
Thanks for the tip!

-P
 
An ACD path cannot help in this endeavor.

We want the call to continue ringing the console (right?)

When all else fails read the elp files (RTFM)

Program Attendant Overflow
To program Attendant Overflow:

Program the Recorded Announcement Device (RAD).

Set the Call Forward No Answer Timer in the attendant’s Class of Service to the interval from the first ring until ringing is applied to the RAD port.

Assign a first alternate destination point for the attendant’s directory number, on the Call Rerouting Assignment form.

For supervisory sets program the rerouting destination as the directory number of the softkey assigned as the trunk answer point.

In the Call Rerouting First Alternative Assignment form, set the No Answer condition of the attendant directory number to route to the directory number of the RAD.

In the Call Rerouting Second Alternative Assignment form, program rerouting for the attendant’s directory number to reroute to the second alternate (if required). This routing is not controlled by a timer. The caller will route to the second alternate immediately, once the first RAD has cleared down.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Hi kwbMitel,

As we explained in the first post - we know that the after the first RAD is cleared down we'll route directly to the second Alt/RAD.
We have tested and that is what we don't want!
But, I guess there is no way around that...correct?

Maybe we could buy an ACD license and possible solve this issue?

We want to have two queues or Alt's - one for "music on hold" and one for a "courtesy mesg" that say's "please wait for the operator to answer - she is busy".
And these queues have to hold the e calls until the Operator can get to them.

Caller calls into main nu,ber - welcome to Compoany and then MOH.
Then after 30 secs or so - go to wnd Alt/RAD and play --> "please wait as your call is being answered in the order it is recieved."

Make sense?

Thanks for your replies and help!

-P








 
Yes you make perfect sense but the system is not designed to provide dual messaging for attendant is busy. You have 2 options.

1 - Play a message and hold in queue for the attendant
2 - Play a message and redirect elsewhere.

Using ACD queues to provide messaging will not allow the call to be answered in the order it was received at the switchboard. Switchboards cannot belong to ACD queues. They can be used to play the message but the call would be unanswerable at the switchboard. What would be the point?

Do you have Tenanting enabled? Embedded Voicemail? It might be possible to place the switchboard in a different tenant.(or everybody else) This would allow unique system hold to play for the switchboard that is different from everyone else. Custom MOH .wav file could be uploaded (need embedded vm)and the "Second" comfort message could be incorporated into the MOH and looped every minute or so.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I've thought about my Tenanting MOH solution and I am unsure if it would work. Not sure if the MOH would be based on the Switchboard, RAD, or Trunk tenant.

When it really comes down to it. Why bother? I've never had a customer request it and realistically if the callers are going to wait long enough for a second message to be useful you have other issues to address. The Attendant is busy message is designed to handle unusual call volumes. If your normal call volumes are more than the switchboard can handle then you need more people not electronics.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Hi kwbMitel,

So far, people aren't complaining about the MOH.
Perhaps we'll just let it be.

I understand your points above and think our Operator is handling the calls just fine.

I've tried to minimize calls thru the Operator by creating more direct extensions for employees so customers/callers can call to their phone without hassling or creating more work for our Operator.

Thanks again for all your responses and insight.
Question closed. <smile>

Happy Holidays.

-P





 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top