Auto Attendant call handling on busy extension

[what4tom]

We have a DID come in on PRI that is picked up by an Auto Attendant. When the AA transfers to a busy extension the call ends up at our reception desk. I need to stop this from happening.
When the calls show up on the reception phone the display shows 'return 501' where 501 a member of the integrated voicemail calling group.

Is there a way to have the caller simply get a busy tone? The extension the AA transfers to will often have 3 calls stacked up and I don't want to add any more system access lines.

Our system:
Magix Release 2.2 v7.2
Merlin Messaging Release 2.5

 

[merlinman]

The system won't deliver a BUSY SIGNAL, but it can stop the calls from getting to the operator.

I believe what is happening is the Auto Attendant is trying to transfer to an extension that has no voice mail box, but is assigned to the Voice Mail Cover Group. Therefore, when the Call attempts to go to the Voice Mail, it can't, so it becomes a TRANSFER RETURN to the Operator.

Thus, the answer is to remove the extension from the Voice Mail Cover Group. That way, when the caller attempts to be transferred, the AUTO ATTENDANT will say "Your call cannot be transferred to extension 123." The caller will then be given back to the AA Announcement.

Also, make sure there's no other cover Buttons assigned on other extensions for extension 123.

http://merlinmanswebpage.yolasite.com

 

[what4tom]

I wondered if that was the case too but the extension being transferred too is not part of the coverage group (I did a print just to be sure).
Here is a bit more detail on our setup in case you see something that might be relevant:
- The phone system is used at a radio station
- Calls coming to the DID are for on air contests
- The AA reminds callers to turn down their radios and has other options like transferring to a news room
- When they transfer to the on air studio the call goes to a phantom extension
- A physical set has shared system access keys with the phantom extension but the buttons are set to 'no ring'. We "modify" the physical set to get audio in and out of the phone. The shared system access no ring allows calls to stack without ringing from another call being heard while on a call.
- An analog extension covers the phantom and has a strobe light on it. This way the strobe goes off when we have calls.
- Only extension 335 is included in vmail coverage so the AA picks up.

PRI DID 335 --> AA3 --> option 1 transfer to phantom 392 --> physical set extension 7133 has shared system access no ring on 3 of extension 392 system access buttons
--> analog port is covering 392 and has phone strobe light

Convoluted yes, but functional.

Does anything in the description above point to why calls return to reception when the system access buttons are all used on the phantom?

For now, I have emailed the telco to see if they can limit the number of calls that can stack on the DID.

 

[Telecomboy]

Did you print all the coverage groups? It might not be included in vm coverage, but could be apart of another cover group. If an extension does not have coverage and does not have a voicemail box assigned it should just ring and ring. I would also print hunt groups as well just in case 392 is in a group that is failing over to reception.

 

[wireboy]

consider that ''vmsaa transfer return time and coverage intervals'' are often programmed in conflict with one another. over and above that, be aware that how a programmed solution to your request turns out could become your personal responsibility for its entire lifespan. few people may be able to logically unravel its complexity.

42

 

[merlinman]

I would also suggest printing all extensions involved in order to attempt to analyze the call flow. Just a thought, but it could help figure this out.

http://merlinmanswebpage.yolasite.com

 

[what4tom]

Thank you all for your responses. The service limited the number of calls that can stack to match the number of system access buttons which has made the problem go away. I still need to follow @Telecomboy suggestion and print all coverage groups to verify something else is not going on in the background.

@wireboy, that ship has long sailed on being responsible for phone programming. The Merlin Magix systems just keep working and we keep getting better at programming them.