Restrict voicemail users from recording personal greetings?

I set up a FreePBX system for a small office with four users. There are no personal voicemail boxes for the four users. There is just a general voicemail box. It is configured as a virtual extension with voicemail enabled. The inbound calling logic is as follows:

Business Open

  • Call to main number → Business Hours Time Condition (business open) → Ring Group (rings two phones) → Announcement – No Answer → General Voicemail Box

Business Closed

  • Call to main number → Business Hours Time Condition (business closed) → Ring Group (rings all phones) → Announcement - Closed → General Voicemail Box

As you can see from the inbound calling logic the only difference between the two is whether the caller hears the “no answer – we can’t get to the phone” announcement or the “we’re currently closed” announcement. Both are then forwarded to the same general VM box. The problem I’m having is the users keep recording outgoing temporary greetings on the general VM box which means the inbound caller hears both the no answer (or closed) announcement and then the temporary greeting on the general VM box. Is there any way to prevent a user from recording any of the outgoing greetings on the general VM box? – Thanks!

An HR problem tell them to “stop doing that” , if they don’t, fire them! :wink:

One of the four is the owner and they’re just not very technical. I migrated them from a 2-line cordless phone with an answering machine to FreePBX with five Sangoma S705 phones, a cordless phone, weather call flow control, holiday & business hour time conditions, ring groups, parking lots, conference calling, music on hold, etc, etc, etc. Their heads have already exploded. :grinning:

You can set use linux to set the voicemail announcements to be “immutable”

One of the vm destinations available is <mailbox> (No Message). If you use that option after your announcement, does it suppress playing the temp greeting?

image

Hi Lorne, Thanks for the suggestion. I currently have it set to (Instructions Only) so the caller hears what their options are. That setting does not suppress the temporary greeting so I suspect the (No Message) option will behave the same. Since this is a production system I’ll have to test elsewhere. However, I like the (Instruction Only) option so this won’t really solve the issue.

Dicko, I’m not sure I follow but if it involves modifications outside of the FreePBX framework and its associated backups I’d prefer not to go down that path.

Then you wil need to ‘follow the yellow brick road’ :slight_smile:

No, the temporary greeting always wins. In order to use the Unavailable or Busy greetings you need to tell VoiceMail() to use them with either the u or b options. If you want to skip instructions then you do the s option. Not setting the u or b options will use the default greeting. In all cases if the temporary greeting is recorded, it will use that over the u, b or default options.

I have tested this. Sending a call to Voicemail - No Message (invoking the s option) will play a temp greeting if it is found but ignore unavailable or busy greetings if they are set.

Tom, Thanks for the additional detail regarding the various voicemail settings. It seems there is no easy way to prevent users from recording their own greetings without impacting the rest of the functionality, so I think I’ll just continue reminding them to NOT do that until it sinks in. I also tried to make it as easy as possible for them by programming buttons on the phone to quickly change the announcements if needed. The more they understand how the new phones system works the less likely they’ll need to change the greetings (as there are already announcements for when they are typically closed, when there is a weather event, or when it’s a holiday). I also programmed buttons to easily override the normal business hours settings or holiday settings. And of course, there is a button to trigger a weather event as well.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.