Overview

Cordial's Quiet Hours scheduler allows you to schedule a window of time when contacts won't receive messages. This gives you the ability to ensure compliance, keep from waking up customers with intrusive messages, and guarantee that promotional content gets in front of your customers at the optimal time.

You can set a quiet hours window in both event-triggered message automations and Podium orchestrations.

Set quiet hours in an event-triggered automation

1. From the Cordial Dashboard, navigate to Message Automation and select Create New Automation or Email Automations.

2. From within your message automation, select Event Triggered from the Sending Methods sidebar on the left.

3. From the Trigger Events pane, select the Enable quiet hours checkbox.

4. Upon enabling quiet hours, you can set the window of time to disallow sending. Although a default time window will be given, the start and end times to prevent sending are easily customizable.

Set quiet hours in a Podium orchestration

The Podium orchestrations quiet hours option is available when using a contact profile data trigger or real-time behavior trigger within the Delay menu.

1. Navigate to Message Automation > Podium Orchestrations and create or select an automation.

2. Click the Delay pane in your orchestration and select Enable quiet hours.

The quiet hours option is not available when the action is a data job.

3. Upon enabling quiet hours, you can set the window of time to disallow sending. Although a default time window will be given, the start and end times to prevent sending are easily customizable.

Handle processing during quiet hours

Choices for handling processing during quiet hours include:

• Queue the send for the next allowable time following the end of quiet hours.
  • If selected, messages will start to process to send at the next allowable time (e.g. 8:01 am).

• Cancel processing
  • If selected, messages triggered to send during the quiet hours window will be canceled and a stop-message-qh event will be fired.

Customize by contact

The account should have an attribute designated as the Primary Time Zone, and contacts should have a value set for the attribute. If the Primary Time Zone attribute does not exist or has not been set for a contact, the account's time zone will be used as the default.

Contacts with a phone number will have their time zone attribute based on their SMS area code if there is not one already set.

Examples

Example 1: No delay in message send

Below are three examples of what you can expect when an event is triggered to process immediately.

• When the action occurs outside of the quiet hours window, it behaves as expected. In this case, FirstName is changed and the message is triggered before quiet hours starts.
• In the instance where the action occurs within the quiet hours window, the corresponding message postpones sending until the next allowable time outside of the window (in this case, 8:01 am).
• In the third example in this scenario, the action is initiated and canceled within the quiet hours window, which will cause no action to occur when the quiet hours window ends.

Example 2: Delay and process immediately

In this set of examples, you can see how the quiet hours window affects an action that has been set to process after a two-hour delay.

• In the first instance, the action occurs outside of the quiet hours window, but the two-hour delay falling within the quiet hours window causes the message to be sent at the next allowable time (8:01 am in this example).
• The next timeline conveys an example of an action and the delayed message both occurring within the quiet hours window. Like in the previous case, the message is not sent until the quiet hours window ends (8:01 am).
• The final example in this illustration shows you a scenario with an action happening inside of the quiet hours window—but the triggered event's two-hour delay ends after the quiet hours window has already ended. Here, you can see that the message is sent exactly as planned after the two-hour delay (8:30 am).

Example 3: Delay and cancel process

The following examples illustrate three outcomes for choosing to cancel processing an event after a two-hour delay.

• In the first example, when an action of changing FirstName occurs outside of the quiet hours window but the triggered event of sending a message falls within the quiet hours window, the process is canceled and the message does not send.
• The second example shows an instance of an action and the delayed event both falling within the quiet hours window. Because the cancel process option was selected for this action within quiet hours, the event never triggers. In this case, the message does not send.
• Finally, you can see that if the delay is set to end after the quiet hours window has already ended, an event will trigger just as it would if it were originally scheduled outside of the window.

Example 4: Delay and restart

This individual example demonstrates a specific instance for an event that is scheduled for a two-hour delay before processing with a directive to restart the delay if an event is triggered within the delay.

• Originally, this event fires at 8:00 pm and again at 9:30 pm, causing the two-hour delay to restart. As a result, the original (10:00 pm) and updated (11:30 pm) actions both fall within the quiet hours window and must wait until the next allowable time to trigger (8:01 am in this scenario).