Night Mode delay before voicemail

[dza888]

Hi All,

We currently dont make use of day/night mode but I wish to implement it for a few reasons, but my experience is limited.... Using a Mitel 3300.

I want to know firstly how do I interrogate the system to find out what mode it is in currently? how can you tell??
I assume its a feature key I need to add to an extension because I can't find it in the system director...?

In the call rerouting table, I note that there are only one set of options for first and second alternatives... Which is great for Day mode as we want unanswered calls diverting to secreteries then to the receptionist**. However once I implement Night mode, I want the phone to ring at the normal extension then go straight to voicemail.. ie. Have a different first alternative in night mode as opposed to day monde....
I know I can make it go straight to voicemail by adding an 'always alternative' route against the night1/2 modes but this wont allow the extension to ring first (in case people are working late and they need a chance to pick it up). how can this be achieved?

also are there any other considerations I should make before trying to implement day/night switching? any 'gotchyas'?

**another slightly unrelated question but if the call makes it to second alternative (receptionist) can that person put the call back through directly to the original called extension's VM? will the orignal extension be remember so a simple transfer to the general voicemail number will actually find the right voicemail?

many thanks

[x-man]

Look in feature access codes and you will find the dial strings for night 1 and 2 and day (it will be something like *590 for day *591 for night 1 *592 for night 2 and *60 for check)

I think you will have to use name tag hunt bgroups for your night service scenario. So divert will point to a extension which will divert on no answer  (from the always alternative)to a name tag hunt group (from the first alternative of the nametag hunt group number) which will be your voicemail. You then will put a key on the phone which is the MWI for the nametag hunt group voicemail.


I think you will have to use the feature provided for direct transfer to VM box.

[ralph]

**another slightly unrelated question but if the call makes it to second alternative (receptionist) can that person put the call back through directly to the original called extension's VM? will the orignal extension be remember so a simple transfer to the general voicemail number will actually find the right voicemail?

With a couple of exceptions the original called extension number is what get's passed to voice mail.   As for a call back, if you call an extension number and it's rerouted to a second alt number, you can still put a call back against the original extension as long as the call isn't already answered.

More on the Mitel Call Back Feature here

Ralph

[dza888]

Look in feature access codes and you will find the dial strings for night 1 and 2 and day (it will be something like *590 for day *591 for night 1 *592 for night 2 and *60 for check)

Thanks, got it.

I think you will have to use name tag hunt bgroups for your night service scenario. So divert will point to a extension which will divert on no answer  (from the always alternative)to a name tag hunt group (from the first alternative of the nametag hunt group number) which will be your voicemail. You then will put a key on the phone which is the MWI for the nametag hunt group voicemail.

Yes, I think I get what you mean here. although to clarify, is a 'name tag hunt group' just another way of saying 'hunt group' or are they not the same...?
I gather using a hunt group is the best way to create a dummy type number that can be rerouted via the routing table?

I think you will have to use the feature provided for direct transfer to VM box.

uhh, what feature do you mean?

Thanks

[dza888]

**another slightly unrelated question but if the call makes it to second alternative (receptionist) can that person put the call back through directly to the original called extension's VM? will the orignal extension be remember so a simple transfer to the general voicemail number will actually find the right voicemail?

With a couple of exceptions the original called extension number is what get's passed to voice mail.   As for a call back, if you call an extension number and it's rerouted to a second alt number, you can still put a call back against the original extension as long as the call isn't already answered.

More on the Mitel Call Back Feature here

Ralph

Thanks Ralph, I don't think I was too clear because I didnt mean to refer to 'call back' at all in terms of feature I just meant 'put the call back through to VM'

RE the transfer to voicemail, I have noticed that when I dial our VM pilot number it asks for my mailbox number etc.
I can get to the option for leaving a message by dialing: pilot#extension but for transferring it would be better if our receptionist didnt have to dial the #extension part, but rather just transfer to a number and due to the origin of the call it knows which VM to go to....?

maybe I'm asking too much but if the call remembers the extension that was originally dialed, SURELY I can just transfer to a VM number and have the system chose the right extension.. (and how do i find out what number it is - I have just taken over managing this system and I dont want to have to outsource this stuff that should be basic setup!)

thanks again! Dion

[ralph]

Sorry.  I had to re-read your post a little more carefully.
I have a couple of additional questions.
Your receptionist, is it a console or a phone?
When the diverting a call via call rerouting, are you routing to a key on a console or a hunt group?

In general, I think if you simply forward whatever number you're rerouting to on RNA or Busy, reroute that number in night1 and Night2 directly to voice mail.   As long as you don't have some strange class of service or hunt group, the call should end up in the mailbox of the extension that was originally called.

Ralph