Imagine the following scenario, you have two VoIP Providers. One gives you excellent calling rates during the daytime, and the other gives you a great deal for calls during the nighttime. Obviously, as a business, you want to save the most amount of money.

So, you can create a Route Selection that utilizes Time Groups to schedule the time and days that your calls go through specific trunks.

Here, we are assuming that you have already created your trunks and outbound routes with the appropriate dial patterns.

So now, let’s go to PBX > Incoming Call Tools > Time Groups. Here, we are going to create schedules that will match the time when it is most beneficial for us to go through our outbound routes.

First, let’s create our daytime time group. This is a simple Time Group, but we will see more complex ones later. For now, we establish the Time to Start as 06:00 hours and the Time to Finish as 18:00 hours. What this does is it makes this Time Group TRUE when the time matches in this timeframe. So, any time of the day between 06:00 in the morning and 18:00 in the evening will match this Time Group. Remember to Save and Apply Changes.

For the Nighttime Time Group, it is similar.

We make the time group’s Time to Start at 18:00 hours and the Time to Finish at 06:00 hours.
Save and Apply Changes.

Now, you just need to create a Route Selection with both of your outbound routes and select the Time Groups accordingly.

Don’t forget to Save and Apply Changes. With this, you now have a route selection you can use with a Class of Service for a least-cost routing environment. This means that whenever the time matches, you will be using the outbound route and trunk that gives you the best rate at all times.

Time Groups can be more complex, as you can specify the days of the week, for example, during weekdays you will use one of the outbound routes and the other during the weekend. We will see more complex Time Groups later on, but for now, this example gives you a clear idea of how to do Least Cost Routing with VitalPBX.

There are two tabs in the IVR module, the General and the Entries tabs. In the General tab, as the name implies, we will do general configurations for how the IVR menu will operate. First, we will add a Description to identify this IVR menu. Next, we will define the number of Invalid Tries. This is how many times a caller can input invalid responses before being transferred to the Invalid Destination, which can be any destination of your liking. To the right of this, we have the Timeout time and the Timeout Tries. This is the time you will give the caller to input anything, and the tries are the number of times the caller can timeout.

Next, we have a set of messages that will playback to the caller. The Welcome and the Instructions Messages will playback to the caller when they reach this IVR.

The welcome and instructions messages are separate, as you can playback just the instructions message after the Timeout and Invalid Retries. The welcome message is only played back after these retries if you have the Welcome After Timeout and Welcome After Retry enabled. The Invalid Retry and Timeout Retry Messages are played back after every Invalid and Timeout retry. The Invalid and Timeout Messages are played back right before the call goes to the Invalid or Timeout Destinations. These messages are sound files that you have uploaded using our Recordings Management module, as we saw in a previous lesson.

Finally, you have the Direct Dial feature. When enabled, this will allow callers to dial numbers directly from the IVR. If this is enabled, we have a default Class of Service called Extensions Only pre-selected. This is for security purposes, as you need to be careful about the numbers callers can dial from the IVR. If you have a permissive Class of Service, callers might be able to dial valid outbound numbers and this can lead to abuse of your trunks. So, if you require callers to Direct Dial anything else than your local extensions directly, make sure you create an appropriate Class of Service so they only dial what you expect them to dial.

Now, let’s move over to the Entries tab. This is the basis for the IVR to operate. Here, you define the digits the caller will be able to press and take them to their selected destination. First, you will enter the Digit the caller can enter, then select the Module/Destination this will take them, and finally, you can Enable or Disable this option, as well as Delete it. You can add multiple digits, by clicking the green Add button.

With this, you can now click on Save in the lower right-hand corner, and Apply Change.

Note: It is true that we can create as many entry options as we want with the IVR
module in VitalPBX. As a general recommendation and rule of thumb, we don’t
recommend adding more than 4 entries at a time for an IVR menu. This is for
general customer satisfaction and operation. Customers will start to forget the
options they are given after hearing more than 4 entries and might need to listen
to the instructions message again. If you truly require more than 4 options, the
best solution is to create sub-menus. This means that an IVR entry option will
take you to another IVR menu with the rest of the options.

Now that you have an IVR menu created, you can use this as a destination for your inbound routes. So whenever a customer calls your business, they will be presented with an elegant menu and options to direct them to their desired destination.

We have seen Time Groups in previous sections with the Least Cost Routing configurations, but in this section, we will add more details to the Time Groups.

So, to begin our configurations we must go to PBX > Incoming Call Tools > Time Groups. For this guide, we will do an example of setting business hours for our Incoming Calls Routing.

First, let’s add a Description to identify this time group. Next, we will add our schedules. In this example, we will define the Business hours as follows.

• Monday – Friday, from 09:00 to 17:00
• Saturday, from 09:00 to 14:00
• Sundays, closed

To configure this, we will need two defined schedules. The first one will have the Time to Start at 09:00, Week Day Start as Monday, Time to Finish at 17:00, and Week Day Finish as Friday. Next, click the green Add button, and set the Time to Start at 09:00, Week Day Start as Saturday, Time to Finish at 14:00, and Week Day Finish as Saturday.

With these settings, whenever the system clock is within the defined schedules, the time group will return TRUE, matching our business hours.

Now that we have a Time Group with our Business Hours, we can apply them to a Time Condition. For this, we go to PBX > Incoming Calls Tools > Time Condition.

Time conditions allow us to choose a destination based on a time group. First, we will define a Toggle Code, which will allow us to manually toggle the current status of the time condition. Next, we set a Description to identify the time condition, and we select the Time Group we have created.

Afterward, we have an extended feature only available with the Starter License or any of our Licensing Plans. This is the Time Zone option. This allows you to define a time zone specific to this time condition.

Then, you can enter an Authorization PIN for security purposes, so you need to enter this PIN when changing the status manually using the toggle code. You can also change the Status from here as well. You can choose one of the following options.

• Temporary Matched – The time condition will redirect calls to the If Time Matches
  Destination temporarily, until the next time the Time Group does not match.
• Temporary Unmatched – The time condition will redirect calls to the If Time Does Not
  Match Destination temporarily, until the next time the Time Group matches.
• Permanently Matched – The time condition will redirect calls to the If Time Matches
  Destination temporarily until this is changed directly.
• Permanently Unmatched – The time condition will redirect calls to the If Time Does
  Not Match Destination temporarily until this is changed directly

Afterward, you can enable or disable the BLF Inverted. By default, when monitoring Time Conditions with a BLF key, the light is green when the time matches and red when the time does not match.

Finally, we have the Destination if the time matches and does not match. This is the principle of how time conditions work. When the Status is set to Default, the time condition will be based on the time group. When the system time matches the time group you will be taken to a destination, and when it doesn’t you are taken to the other destination. You can choose the destination of your liking for these options.

With this configured, you can now Save and Apply Changes.

Now, you have a time condition created with a time group. You can add this time condition to an IVR or Inbound Route, for example. This way, whenever someone calls into your VitalPBX, they will taken to the time condition and if the time matches they are taken to destination A, and if it doesn’t match, they are taken to Destination B.

Announcements are very simple to configure, you just need to enter a Description to identify your announcement, select a Custom Recording you uploaded using the Recordings Management module, and set a Destination after the recording plays.

Afterward, click on Save in the bottom right-hand corner, and Apply Changes. You can now use these announcements as a destination in IVRs, Time Conditions, Inbound Routes, and anywhere you want to playback a sound file.

Now, enter a Name and a Description to identify this language router. The name cannot have any spaces or special characters. Select the Language from the dropdown menu. For more language options refer to the Asterisk Sounds section and lesson. Finally, set your intended Destination. Save and Apply Changes.

With this set, you can place this language router in between your origin and intended destination. This is most commonly an IVR where you have the option to “press 2 for Spanish,” for example. This entry is set to the language router we created, and the call is then taken to the Final Destination we set. Remember to Save/Update and Apply Changes.

Now all the voice prompts from here on will have the new language prompts play back.

All we need to do for our night mode is to enter a Toggle Code to enable and disable it from any extension, add a Description to identify it, and select the Destinations when it is Enabled and Disabled. Then we can Save and Apply Changes.

Additionally, you can add an Optional Password, so you need to enter this password to enable or disable the night mode. You can change the State of the night mode from here, instead of dialing the Toggle Code. You can also Ignore the Global Mode, so it is not affected by the feature code *81 for the Global Night Mode Toggle. Lastly, you can enable Generate Hint so you can use the generated BLF Hint code to monitor the night mode status with a BLF key.

You can now use this night mode as a destination, and change the destinations with the toggle code.

To create the CID Lookups, we must go to PBX > Incoming Call Tools > CID Lookup.

The CID lookup can use any of 4 sources, an HTTP/HTTPS request, a MySQL query, OpenCNAM, and a VitalPBX Phonebook. You can use the [CIDNUM] variable in your query to retrieve the CID Name information from your database.

Any of these source types will show you the necessary fields to perform your connection and enter your query.

A sample HTTPS/HTTP request can be as follows.

https://mycrm.com/cid.php?cidnum=[CIDNUM]&customer=vip 

For MySQL, the query can look as follows.

select `name` from `customers` where `number` = ‘[CIDNUM]’

The easiest option is to use VitalPBX Phonebooks. Since this allows you to upload a contact list using a CSV file, any contact in the phonebook can be used for CID lookup. Simply choose a Phonebook you have created and this is now your database for CID Names.

You can then apply the CID Lookup to your inbound routes, and the CID Name information will be populated by the CID Lookup response.

A common use is to add information to know the inbound route or trunk the call is coming from, or the DID the caller dialed to reach us. This way we can utilize the appropriate salutation for the incoming call.

To create your CID modifiers you must go to PBX > Incoming Call Tools > CID Modifiers. There are three types of Sources for the manipulation of CID information. Static, which is the standard way, by defining a hard-coded way to manipulate the CID information. MySQL to perform a MySQL query to modify the CID information based on the MySQL response. And finally, HTTPS/HTTP Request, so the CID information is based on the response.

First, we must enter a Description to identify this CID Modifier. For a static CID modifier, we have CID Number and Name Settings. For the CID Number, you can enter how many characters to Skip, the total length of characters you are keeping, any characters or digits to Prepend before the CID Number, and any characters or digits to Append after the CID Number.

For the CID Name Settings, you can Prepend anything before the CID Name, Append anything after the CID Name, and outright Replace what the CID Name is.

Below the CID Number and Name settings, you have a Simulation section. This section allows you to enter sample CID information so you can see how this is modified.

You can then Save and Apply Changes. CID Modifiers can then be added to Inbound Routes under PBX > Calls Routing > Inbound Routes. This will apply the CID modifier through every incoming call that goes through this Inbound Route.

For MySQL and HTTP/HTTPS requests, you can use the following variables for your queries.

• [CIDNUM] – This will return the Caller ID Number.
• [CIDNAME] – This will return the Caller ID Name.
  

This type of Source also provides the necessary fields for you to establish your connection.
A sample MySQL query can be as follows.

select cidname, cidnumber from customer where phone = ‘[CIDNUM]’ 

The response should return the cidname and cidnumber columns for the CID information to be modified.
Similarly with HTTPS/HTTP requests. A sample query can be as follows.

https://mycrm.com/cid.php?caller=[CIDNUM]&callername=[CIDNAME]

The URL execution must return a result in JSON format containing cidname and cidnumber attributes in order to modify the CID information.
You will now have the Caller ID information just how you need it, and operate following your standards and information handled.