Night Service Not Working?

[KyleTO]

IP Office 406 (3.1.56) and VMPro (3.1.18)

Not sure if I am doing this correctly, but I have two Hunt Groups setup, [Main] and [MainNight]. I have a time profile associated to [Main] from 8:00 to 17:00 and have [MainNight] setup as the Night Service Fallback Group. In VMPro, I have a seperate module for each group, as the [MainNight] group plays some different recordings and options for callers outside of normal hours.

My problem is that when 17:00 rolls around, all it does is take calls coming in to [Main] and routes them to the [Main] VMPro greeting. From what I read in the help documentation, it should instead route it to the Night Service Fallback Group, but when I pull up the IP Office configuration after hours, it still shows all the groups as "In Service." Shouldn't it automatically move the Service Mode over to "Night Service" operation once the the time is outside of the Time Profile so that the [MainNight] greeting plays?

 

[jml2665]

the night service fallback is activated via a shortcode, usually on the reception telephone I add the key to activate night service,

the time service profile is usually setup in your incoming call route, towards the bottom of that form

I usually stay away from time profiles and use VMPro Conditions, that way if you have holidays you can keep the closed greeting playing or send it to a holdiday greeting

 

[PrivateBuild]

Hi KyleTO,

When a Time Profile puts a group into Night mode, it wont change the groups Service mode setting. Also, short codes shouldnt be able to override the time profile.

Can you test without the VMPro callflow to see if a call to Main will ring on the MainNight huntgroup after the time profile has activated?

 

[IPGuru]

1) Time profiles do not put the group into Night service but cause the calls to be routed to the Night service fall back group - it sounds like a strange concept untill you read it a few times & look at what happens (or to be exact dosnt happen) in the cfg.
this means that if a shortcode is used to manualy switch to n/s the group will stay in n/s regardles of the time profile - I set this up soi that customers can override thier timeprofiles when they want to close early & to cover holidays

2) if the Main group has VM enabled then this will be seen as the start point for the VM call flow regardles of the n/s state, as previously advised use conditions/route by call status to overcome this.

 

[BigNads]

VM is target based so because your call has hit Main group first when it goes to VM it will always start there.

Unless.........you put a virtual user 220 in the night group and forward that user unconditionally to a short code

500 "#Extn220" 0 vmcollect

This short code would drop you into 220's mail box and you could then create a custom call flow for that user under the leave mail action to do whatever you flippin well liked.

The last thread about putting a group in n/s manually is all well and good until you consider the fact that you cannot take the group out of night service whilst the night time profile is active. It physically will not come out of N/S manually until the profile has deactivated itself. Its a quirk.

 

[IPGuru]

I know what you mean about being unable to override a timprofile activated n/s, this is because the time profile does not put the group into n/s (I said this statment requires a bit of re-reading)

a work around for this is to create an outof servie fall back group & place the main group oyut of service to overrid the time profile

In practice I find people want to activate n/s early more often that they want to disable it.