Delivery Policy User Guide

Overview

A Delivery Policy is a set of rules basis which invites are sent out. Messages and their schedules determine how and when the invites are sent to the customer, fatigue rules determine how often to send invites to the same customer, and business rules define the days and the time when these invites should be sent out. These settings are configured in the Delivery Policy page.

1. Messages & Schedules - These settings help you set up a message lineup, choose the channels (Email or SMS) through which to send the survey link, and schedule the time and delays to send these messages.

   For each message that is sent out, Delivery Policy runs a few checks before sending them out. First it checks if the customer has unsubscribed to the service or not using the unsubscribe link provided in a past invite’s Message Template. Additionally, if they have signed up for a DND service (if configured in Delivery Policy) and then check for fatigue and business rules before sending out the survey invite. Also, in case the customer has responded to an invite, then no new message from the message lineup will be sent out to that customer for the given interaction with the brand.

   For example, the first message can be set to be sent via email that can be delayed to be sent after the system receives a file with customer data, and the second message via SMS an hour after the first email is sent.

2. Fatigue rules - It is recommended as best practice that a company or a brand do not over-survey a customer by sending them multiple invites over a short period even if the customer has interacted with different touchpoints with the brand. Over-surveying may lead to higher unsubscribe rate and reduced customer engagement.

   Fatigue rules work based on a Unique User Identifier (UUID). A UUID could be an email, mobile number or any other unique identity associated with a customer to whom invites are sent out. Once setup, UUID helps prevent sending an invite again to someone who has already received one in the past (if pending response), or if a certain number of invites have been sent to the customer in the past, depending on how this is configured.

   Please note, that these invites (or Tokens) have a validity period as well. So based on the 2 possible settings, fatigue rules will apply:

   • If a token is still valid and pending response, fatigue rules when switched ON, will prevent a new invite from going out to the same customer
   • If a certain number of invites have been sent to the customer in the past set number of days, irrespective of if they have responded to them or not, a new invite will not be sent to the same customer
   For example, if first fatigue rule is enabled and setup with email as UUID, and John Doe is sent an invite to his email ID john.doe@email.com then assuming John Doe interacted with the brand again in a few days, fatigue rules will prevent a new survey invite from going out to him until he responds to the first one or it expires based on the set expiry period in Token Template.

   Note that out of the available fatigue rules, the 1st one works according to the corresponding Delivery Policy. In the above example, if invites are setup to be sent to John Doe using the Delivery Policy ‘a’ in the account, then the fatigue rules setup in Delivery Policy ‘b’ will not interfere. Invites will still be sent using Delivery Policy ‘b’, even if the invite sent using Delivery Policy ‘a’ is pending response. This is useful in case you want to send invites out across 2 completely different touchpoints and do not want to apply fatigue rules, but avoid over-surveying if the customer has interacted with the same touchpoint multiple times over a short period of time.

   In case the 2nd fatigue rules is enabled, for the same example, John Doe will not receive another invite as per the set rule for the selected questionnaire or across all questionnaires. This rule does not take the delivery policy into consideration and works across all delivery policies.

   A UUID in most cases is also a Personally Identifiable Information (PII). This poses a risk from a privacy standpoint. In our Invitations module, this data is always hashed in the database to ensure that it is not human readable. This is done to ensure that privacy of customer data is maintained.

3. Business Rules – This is a set of rules that define the days of the week and hours of the day during which the invites should be sent to customers. Using these settings, you can ensure that invites are sent out to your customers in a specific time slot during the day. In case too many invites are lined up to be sent for a day, and the system hits the cut-off time for the day, all pending invites are queued up to be sent out on the next setup day and time slot.

   For example, invites are set to be sent during only weekdays (Mon – Fri) between 8:00 AM and 5:00 PM. In this case, on Friday 5:00PM, if there are more invites pending to be sent out, they will be queued up to be sent on the next Monday morning at 8:00AM. Additionally, any invites added to the queue over the weekend will also be queued for Monday morning, 8:00 AM as per this setup.

4. Do Not Disturb Web hook - This is an external URL that helps Experience Management check if any given customer has opted for Do Not Disturb service on email or SMS to stop receiving any kind of messages from the company or the brand. Only email ID (for invites being sent via email) or mobile numbers (for invites being sent via SMS) are checked in the DND database. This check is conducted each time, just before sending the invite. For example, if a customer received the first invite, and signed up for DND service for that channel, before the second invite is due to be sent to them, then the second invite will not be sent out.

   DND service works only if configured correctly in Experience Management. If left blank, no DND check will be conducted for invites setup with that Delivery Policy.

5. SandBox Delivery Policy – This helps users to set up a new Dispatch for a new questionnaire, or make changes to an existing setup, without disturbing the existing invites being sent to the customers.

   Sandbox Delivery Policy should be used only for testing out settings before creating a new Delivery Policy. Users can check how a message lineup will work with the fatigue and business rules applied. This gives a clear understanding of how invites will be sent to the customers without having to create new or make change to any existing policy or Dispatch.

   Sandbox Delivery Policy skips the queue of any pending invites, and sends out test invites immediately. This is helpful when users are testing out policies. They don’t have to wait for the queue of existing invites to clear up.

   IMPORTANT – Before creating a Delivery Policy, make Microsoft Azure or Amazon SQS queue is configured in CX Setup > Account Settings > Integrations > Invitation Queue, in Experience Management. Microsoft Azure or Amazon SQS are channels that are used to push Tokens to a queue from Experience Management, which is then picked up by the message vendor to send out the invites. Azure or SQS queue will allow Delivery Policy to send invitations to the queue much faster, removing the dependency of rate limit or time limit in Experience Management. Without this setup Delivery Policies cannot be created.

Accessing Delivery Policy

1. Sign in to Experience Management. Once the dashboard loads, switch to CX Setup using the menu button on the top left of the screen. Select CX Setup.

   

   
   

2. Under CX Setup go to Invitations and Tokens > Invitations > Delivery Policy in the left navigation menu.

   

Creating a New Delivery Policy

1. On the landing page, you will notice a table with the Sandbox Delivery Policy available as default. To create a new policy, click on the “CREATE NEW” button on the top right.

   

   
   

2. Give a name to the new Delivery Policy. Use names that are unique and easily identifiable. This helps to select this Delivery Policy without confusion in other parts of the product.

   

   
   

3. Messages & Schedules is where a user can a choose how many messages should be sent using this Delivery Policy.

   a. Send Message Via - For each message in the lineup, select a channel. This could be email or SMS.

   

   b. Delay Delivery By – Here you can set a delay between two messages in a lineup. Delays can be set up from an hour, up to 30 days. This allows Experience Management to send out messages for the same invite using different channels one after the other based on the set delays.

   Delay can also be added for the first message. This will be applied to the first message from the time the customer data file to send invites is received to be processed.

   

   
   
   Please note, the delay set here is the time delay between this and the previous message.
   
   
   IMPORTANT: Please ensure that the token validity set in Token Template used with this Delivery Policy is more than the total time period (delays) set between first message and the last message in the Delivery Policy. This is to ensure that the survey URL is still valid and the customer has additional time after receiving the last message to respond to the survey.
   
   

   c. Add a Message – Multiple messages can be added to the lineup. The most popular scenarios here are adding multiple messages to be used as reminders, or sending invites across multiple channels. Users can add any number of messages to a Delivery Policy. However, it is recommended to keep this number low.

   Users can add messages in-between two messages at anytime. While doing this, please ensure that the delays are setup correctly. Also, take note of this while deleting a message from the lineup. Messages can be deleted individually by clicking the ‘Trash’ icon on the top right for each message block.

   

   
   
   As mentioned in the overview, each message goes through a set of checks before sending it out. Checks applied for each message is shown on the header bar of the message block.

   

   
   

4. Fatigue rules - Select a UUID basis which the fatigue rules will be applied. As explained earlier, UUID selected here will be automatically hashed to prevent storing PII data on Experience Management.

   UUID selected here will be used to check if any other invite sent to the same customer is pending response and is still valid. If found so, the next invite to the same customer will not be sent to avoid over-surveying.

   
   

   

   
   
   UUID can be changed in a Delivery Policy; but this will reset the fatigue rules database. Because the new UUID may not have been stored for the customers to whom invites were sent in the past, a few of them may receive an invite again.

   The first rule is selected by default and is the recommended setting. You may additionally choose the 2nd fatigue rule and set values for number of invites, across all questionnaires OR the one selected for the delivery policy, and the number of days to check for before sending another invite to the customer.

   In case both fatigue rules are enabled, they both will function together in succession. The 1st fatigue rule will check for any invites that may be pending response from the customer sent using this Delivery Policy and if there is none, the 2nd rule will check for the number of invites that were sent to the customer for the questionnaire selected in the Delivery Policy OR for any questionnaire in the last set number of day.

   
   

5. Business Rules – By default, set to Monday to Friday, All Day. This will send out invites through all weekdays and through all hours of the day. This should be edited if required, to the days of week and hours of the day during which you wish to send invites.

   

   
   
   IMPORTANT: The time window during a day should be large enough to process and send emails without blocking and choking the queue. This will depend on factors like the speed or rate at which the emails are sent out using the configured vendor (Custom SMTP would be relatively slower compared to bulk vendors). So it is important to test this over a few cycles to ensure that most emails set to go out for a day are being processed within the set time window. This is necessary to avoid a huge queue starting the next day that may further delay the next day’s batch.

6. Do Not Disturb (External) - Add the external webhook URL to check DND status of the customer before sending out an invite to them. DND webhook can be set up for different channels (email and SMS) separately. Please ensure that this is set up correctly for both in case invites are being sent via email and SMS.

   

   
   

Editing and Managing Delivery Policy

Delivery policies can be edited at any time by clicking on the policy in the table and making changes as desired.

Some edits may automatically pause the Dispatches using this Delivery Policy. These are detailed below.

1. Change Name – This will have no impact on invites being sent using the policy.

2. Add, Edit or Delete a message in the lineup – Adding a message poses risk to the live policy. The invites cannot be sent unless a Message Template is assigned to this newly added message in the Dispatch config page. In this case all Dispatches using this Delivery Policy will be paused. A summary of the paused Dispatches will be available in the popup after the user updates the settings. You must edit each Dispatch by attaching a Message Template to the newly added message in the lineup and re-enable the Dispatch manually.

   In case of edits made to the message lineup, the same precaution must be taken. Editing the delays will take effect immediately upon updating and messages will be sent as per the new schedule.

   Deleting a message from the lineup will stop sending that message. This will not impact invites sent via Dispatches using this policy as it will just skip the deleted message and move to the next one. This is a destructive action, and cannot be undone.

3. Edit Fatigues Rules – As mentioned earlier, UUID can be changed in a Delivery Policy later. But this will reset the fatigue rules database. Because the new UUID may not have been stored for the customers to whom invites were sent in the past, a few of them may receive an invite again, in case they are eligible for it based on a repeat transaction made with the brand or company.

4. Change Business Rules – This will impact the time window during which the invites are sent, and will take effect immediately after updating. This may impact invites already queued up to be sent, and delay them further.

5. Edit DND Webhook – Editing this is similar to changing UUID under fatigue rules. Unless the new database for the updated webhook has complete DND data, some customers might end up receiving invites even thought they signed up for DND. This change should be made carefully keeping in mind the legalities related to DND in each region.

Deleting A Delivery Policy

Deleting a Delivery Policy is an action that cannot be undone. This will immediately pause all Dispatches using the deleted Delivery Policy. You must manually update these Dispatches with a new policy and re-enable them to resume sending of invites.

Pausing A Delivery Policy

In certain situations if invites from multiple dispatches using the same Delivery Policy have to be paused from being sent, you can pause that Delivery Policy. This is a good way to resolve issues before sending any more invites. But it is important to understand whether to pause the policy, or just the dispatch. Pausing a Dispatch may be enough to resolve most issues. This way, other invites from other Dispatches using the same policy will not be impacted.

Sandbox Delivery Policy

Sandbox Delivery Policy should be used only for testing things out before setting them up in actual Delivery Policies. Users can use this Sandbox Delivery Policy to check how a message lineup will work with the fatigue rules applied. This gives you a clear picture of how the invites will be sent to the customers, without actually impacting an existing policy or Dispatch.

In the Delivery Policy listing page, a Sandbox Delivery Policy is available by default. This cannot be deleted by any user, and will always be visible in the table. Users can set this up to test a message lineup along with fatigue and business rules. Once setup, this sandbox Delivery Policy can be used with any Dispatch and Message Templates from the respective sections. Users who want to make changes to an existing Delivery Policy can copy all the settings from the existing policy to the sandbox Delivery Policy. Then make changes to the sandbox Delivery Policy. This way you can run the test without impacting the invites that use the original policy.

The Sandbox Delivery Policy is used like any other Delivery Policy. Simply create a new Dispatch for any questionnaire and use sandbox Delivery Policy. Next, assign message and token Templates to this Dispatch and setup the invites to be sent out using this Dispatch. To copy settings from an existing policy to sandbox one, open an existing Delivery Policy and click on the “Copy Setting From Here To Sandbox Delivery Policy” link in the right pane on the screen.