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

PRE-ANSWER MESSAGE

Status
Not open for further replies.

Layne5

Technical User
Aug 8, 2008
50
BE
Hi,
Customer has an ACD group for the IT servicedesk.
They're regular (RAD)message is "WELCOME TO THE IT SERVICEDESK".
BUT when a general problem occurs (eg. mailserver down), they want to play a message like "if you call for the mailserver issue, we're aware of the problem and working on it, if you're calling for another issue, just stay on the line".
Using the ACD-RAD message on this path is not an option, because when the callers call for the general problem and they hang-up, the ACD statistics are influenced (lot of lost calls), and the customer don't want this.

They rather don't want an automated attendant because then extra input of the caller is necessary.
But besides the A.A. i don't see a solution.
Anyone any idea?

Thnx!
 
What about an ACD path with no agents in it in front of the normal path. Have calls camp on to that group even with no agents logged in. That pre ACD path could then play an emergency message. Have the calls then overflow after a set time into your regular ACD group. If you DND that first path to the second you can bypass that emergency message. You would then only remove the DND on the first path when you need the emergency message. Don't know if that meets your needs.
 
Does the site have an ACD reporting package?

Loopylou's suggestion will work if not.

I have another that will work in a reporting environment

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Hi Loopylou, thanks for your answer.
I also thought about that but in that case the overflow is done after a set time. Sometimes they have long messages, other times just short ones, so the time always has to be set through the ESM.

KwbMitel, yes, they have CCM for reporting.

Thnx for the help!
 
If you want something that will dynamically adjust according to the length of the message then prepare yourself for disappointment.

If you are prepared to do a minimal amount of adjustment on your system to accomodate different message lengths in "Emergency" situations then this solution should work for you AND maintain your reports.

The option below is a more permanent solution but it has a pretty major fault. If there are no agents available at the time the call tries to overflow, then the call can get stuck in queue against an empty queue group. I have decided to mention it anyway as it does have its application and to prevent you from implementing it without understanding the fault should someone else choose to suggest it.

- Create a new ACD Agent group and allow queue to this group if no agents are logged in.
- Make the new ACD group the Primary group for the existing Path.
- Make the existing ACD group with live agents the overflow group (not interflow, overflow)
- Make the "Emergency Message" the first Rad on the Path and adjust the existing rads down one step with appropriate timing.
- Set your overflow timer to a time slightly greater than the length of your message (this is the value to adjust on the fly)

Option 2 - the KISS method

Have pre-recorded messages available for use.
Upload when necessary for RAD #1
Adjust timer for Rad #1

Done

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
You can have front end messaging which you can enable buy some simple programming if required plus chge the message to suit.

The way the below solution works is that is normal situation calls would still go straight to path, you can then press a button and the inbound calls will be greated by a message first, then if they hang on the call will be routed to the path.

A little complex to write about and sounds complex but works a dream.

1) Renumber you Help Desk Path DN
2) Create a PHANTOM hunt group with the DN that was the Path Number (the one everyone knows)
3) Create a VOICE Hunt Group
4) Re route always the PHANTOM group to the path
5) First Altenative the PHANTOM group to the VOICE HG
6) Create a New RAD that you will use as your front end message
7) Re Route Always the VOICE HG to the RAD DN
8) First Alternative the VOICE HG to the Path
9) On the Help desk phone or Phones, set up a key as CDE speedcll with the DND Remote Feature code follwed by the DN of the Phantom HG. ie *591234

So what wll happen is when people dial the old number it goes to the PAHNTOM DN which unr nrmal conditions goes to the path.
Then if you have an emergency, record up upload a message to the new RAD (and test in case you need to adjust the message legh timer in the RAD COS) and then put the PHANTOM group into DND. The PHANTOM group is designed to follow the First Alt when in DND so will go the te VOICE HG, This is then Re Routeed to the RAD. Once the RAD has played it drops back to the VOICE HG and follows the First ALt, which is to the Path. Just make sure the COS of the RAD as the messagelengh timer etc set properly.

Like i said sounds complex but doesn;t take very long andworks well. This way your stats aren;t affected
 
MitelMatt: I asked if the user had a reporting package.

Answer Yes - CCM

Step # 1 in your solution would be a problem for some users and conflicts with your statement "This way your stats aren;t affected"

As for the rest, I can see several issues. I suspect you were writing too quickly and may have missed something if you've used this method before. Additionally, your description of the call flow when using Call Rerouting seems to based on an incorrect assumption. (explaination to follow). Finally, even if I grant your description of the callflow I don't see any way that the call does not either fail at the RAD or fail at the voice huntgroup. In either case the call would not proceed to the Path by my analysis.

Call flow when using Call Rerouting.
It is a common mis-perception that the call flow when using Call Rerouting "Hands off" to the next device when routing takes place.
e.g. (wrong analysis) DN 1000 Call reroutes always to DN 2000. DN 2000 reroutes on 1st alt to 3000. Therefore a call to 1000 will route to 3000 if 2000 does not answer. Note: There is some handoff, but only after the timer on the primary DN has expired. This example probably will end up at 3000 but at double the timeframe expected.

e.g. (Correct Analysis) DN 1000 Call reroutes always to DN 2000. DN 1000 reroutes on 1st alt to 3000. Therefore a call to 1000 will route to 3000 if 2000 does not answer.

If as in the example above:
1000 = Phantom HG
2000 = Voice HG
3000 = Rad
4000 = Path

1000 would need to be RRT All to 2000
1000 would need to be RRT 1st to 3000
1000 would need to be RRT 2nd to 4000

All that being said, This solution does not meet the guiding principle in my signature below.

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

Sorry mate you do it your way and i'll do it mine, i've set this up and it works fine as described

I think it may b you who are under some misconcpetion. Phantom hunt groups are designed specifically for this that even though it is RRA when in DND it follows the FA.

Also, the method used to play the RAD and handoff is a documented mehtod. Put both together and it works fine.

This way the callers listen to the message and if it's about that emergency it won;t reflect as an abondoned call as described in the original note. Granted it won;t peg at all

This forum is about giving options and everyone is etitled to give options

Your methods are not always the only ones the work for people. The idea is people can take all options andmake the own mind up what works fr them.

This works, period. If they don;t want to except it, then they don't have too

Please don;t crit if you haven;t tried it

No offence
 
MitelMatt, no need to be so defensive. I never said it wouldn't work as you seem to have understood. I only suggested that you may have missed a step in your description. You feel you have not. Nuff said.

Re-read my part about how re-routing works. It might help you sometime.

TTFN

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

I do understand how routing works thanks mate. maybe you should try my suggestion too
 
Hi,
Thanks all for your answer.
I have 2 remarks:
1/Mitelmatt, i can't seem to get your solution working. When the "phantom group" is in DND, the call goes to the RAD but never gets to the path. Am i missing something?

2/ kwbMitel, in your solution, the downside indeed is that the calls can get stuck against an empty queue group.

Greetz
 
Mitelmatt, I've re-read your response to my rebuttal of your post again twice thru. I do not see a suggestion. The closest I can see is "Please don;t crit if you haven;t tried it" or the paraphase "don't knock it if you haven't tried it"

I can see how from your viewpoint this might be a suggestion. However, from my viewpoint, it gives me permission to critisize as I have in fact, tried it.

Regardless, The only points I made against your solution were

1) - your statement that "This way your stats aren;t affected" was misleading
2) - I couldn't see how it could work as written
3) - The way you described re-routing was incorrect
4) - It didn't meet my criteria of simple (this is the only personal view point)

I find it telling that Layne5 was not able to follow your directions and get it to work.

Layne5 - Are you comfortable with changing the Path number and understand how this would affect your reporting. If so, let's play.

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

Assuming your answer to changing the path number is Yes.

My first choice would be Loopylou's solution (first responder above)

My second choice has more faults but less work for the End user (one of your stated requirements)

- If your call volumes in the "Emergency Situations" are not too excessive (greater than 10 per length of message)

You might want to try this:
-Change the Path DN to a new number
-Set up a Voice Hunt group that matches the old Path DN
-Set up a Voice mailbox matching the Hunt Grp (Announcement type)
-Configure the Attendant dial zero point of the Mailbox to be the DN of the path.
-Record a generic emergency greeting in the mailbox.
-Setup a phone to allow Third Party Call forwarding
-Configure a Feature Access code for third party call fwd

Normal call flow - Voice Hunt group Fwd'd to Path number
Call queues to path

Emergency Call Flow (user changes forwarding of voice hunt group)
Voice Hunt Grp fwd to voicemail
voicemail plays greeting (of whatever length it might be)
upon completion of greeting the call transfers to Att (dn of path)
Call queues to path

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

Make sure the voice hunt group also has a first alternative to the Path dn (not back to the phantom hunt group)
 
Hi all,

Thanks again for the input!

@KwbMitel, This seems a good solution, BUT if i make a Voice mailbox type "information" or "transfer only", i get a default message: "thank you for calling, if you have a touchtone phone...blah blah blah....you are being transfered to the operator" and then the transfer to the path is done. Is there any way to clear this "standard" message?

@Mitelmatt, i've made sure the voice hunt group also has a first alternative to the Path dn, but after the "emergency" message is played, the call just hangs up?
You have implemented this in the field and it's working?
So i must be doing something wrong? I would say that it's normal behaviour to hang up after playing the message, but maybe that's just the advantage of a phantom group?

 
Layne5: My bad, Yes, the Information MB returns to the Main Autoatt not Transfers to the Att. That one fell under the catagory of "Works in my head" as opposed to "Works in the field"

Thinking.....

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top