Reception Key Appearances on phones

[RDECIT]

We have a client with a recpetion phone which has 8 single line key appearances for dummy numbers that appear in a huntgroup which is the main pilot number for the entire compnay. This was done for the following reason:

They wanted calls to come in on what appeared to be lines like their old system. Because they are single lines, if two calls came in they would be stacked on each key in a terminal fashion. Allowing calls to be held on the button (parked if you like) so that other calls could be dealth with. We couldn't use Mulitcall keys, as the single appearance would be able to collect more than one call.

Now the plan has changed and they want two reception phones with the second being a mirror of the first. The problem we have, is that because we have use single line key appearances we are not allowed to use it on another set. Has anyone had expereienced this type of configuration before who could suggest a btter way of doing it or how we could get this solution working.

The unit is an MXe II with the last service pack of MCD.

 

[kwbMitel]

I would do 3 things.

Change the keys to be KeyLine Appearances giving the same existing functionality on multiple phones.

I would reduce the number of keys to 3 keys (or 2 even)

I would program a Group Park Key as a 4th key.

Instead of using Red Key Hold where the order of the calls is uncertain, the receptionist would use the group park key. The calls will stack on the group Park key as a first in first out basis and will stack up to 99 calls. Both receptionists can then answer calls in their exact order and let the system take care of the sequencing.

Using this method, you could also get away with using Multicall keys. The only reason to have more than 1 answering key is to have a visual and audible indications of additional calls.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[RDECIT]

The problem we have found with group park on the Mitel, is that the user/receptionist needs to remember which slot they have parked a specific caller to. I will try the key line's out.

 

[kwbMitel]

The problem we have found with group park on the Mitel, is that the user/receptionist needs to remember which slot they have parked a specific caller to.

Then you are doing it wrong.

The group Park key requires nothing to remember. (as long as the DN that the call will be parked against is defined as part of the key programming)

If you have an active call and you press the key, the call will be parked in a first in / first out basis. The key will then illuminate to inform you that at least 1 call is queued.

If you do not have an active call and you press the active Group Park key, the call that has been queued the longest will be connected.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[LoopyLou]

I think he means that if they park a call, they may wish to retrieve the one there parked 4th rather then the one that has been parked the longest. Kind of how it used to be on the SS7 consoles that you could place calls on hold and grab a specific call by using a specifc key or a user by dialing the console then held slot number.

..least thats what I think he means.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[kwbMitel]

@ Loopylou - More likely is that the key has not been defined against a specific DN. This being the case, when you press the key, it requires you to enter a DN to park the call against. Same for retrieving the call. If you define a DN however (I would use the hunt group master DN in this case) then you simply have to press the key once to park and once to retrieve with no entry required.

When you have multiple keys you really have no certain idea on the order the calls came in. Especially when it is busy.

e.g. - with keys.

Calls come in on lines 1,2,3 and are answered and put on hold.
While talking on line 1, calls come in on 4,5 (4 and 5 placed on hold
Clear line 1 and talking on line 2 when calls come in on lines 1 and 6! (placed on hold)
Assuming you are lucky enough not to receive and further calls before dealing with line 5, what it the likelyhood that the receptionist will know that line 1 has precedence over line 6? (zero in my opinion)

e.g. with group park key
Calls come in on 1,2,3
Calls are parked in order 1,2,3
While talking on line 1, calls come in on 4,5 (parked in 3rd and 4th position respectively)
Clear line 1 and talking on line 2 when calls come in on lines 1 and 6 (parked in 4th and 5th respectively)

Assuming you are lucky enough not to receive and further calls before dealing with line 5, the next call due to come out of the park key is the one that arrived on line 1. Exactly as it should be.

The Goup Park Key advantage becomes even more apparent when there are multiple receptionists answering the same lines. They do not need to communicate about which calls came in or in what order. They can simply park the additional calls and let the system handle the priority.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[wireman50]

I had a similar problem but with a need for anyone to be able to pick the call up from any phone.

So programmed three group park keys on all phones , so the first call is parked on GP1 then GP 2 and then GP 3. Three is enough because the GP key becomes free again once the call is taken (even if has to be retrieved by the operator). Works for my customer very well.

Call is announced by operator as call for Fred on GP 1 etc.

Can't for the life of me remeber why I used GP rather than just call park...

 

[kwbMitel]

Yes Wireman50, I use the group parks for Park and Page as well. Typically I use 2 which is what you would otherwise need when using System Park and Park Retrieve.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[RDECIT]

Lou is right, having one key for parking calls means that you only have one flashing appearance. First in first out is no good as the receptionis might want a caller to pickup someone who is on hold that is in postion 3 or 4 of the parked slots, meaning that they need to rememebr the number. The current solution works because they can hold a single caller to a key and have a visual indication what slots are filled, they can then collect them by pressing the button.

KWB, that is an interesting solution with the park function and I never thought about the down side to using the keys they way we are. The client is happy with it though, which is the main thing.

I will test this in our lab.