Content Comparison

Status

Status

colour	Yellow
title	IN PROGRESS

Owner

rommel.ngo jessica.wood AlainGasquet Yeng Sembrano Liz Enright Adriana Sung

Contributors

rommel.ngo jessica.wood Yeng Sembrano AlainGasquet Liz Enright

Approved

Due date

14 Oct 2022

Decision

Status

title	NOT DECIDED

On this page

Table of Contents

maxLevel	2
minLevel	2

❓ Problem statement

We need to build a ‘do not engage’ / ‘Communication Blockout’ check-box with associated start and end dates and a reason picklist. (e.g. have been convicted of crimes). These people should still receive SAM and similar content but we do not want to engage them for events/programs for example.

💡 Research insights

In Speaking with Prospect Development we could have the following reasons
Vulnerable - (which would supersede our vulnerable checkbox)
Under Investigation - this would trigger a business process to review these periodically to ensure they are moved in or out of this flag
Requires Approval - this would be a higher level flag for people who have criminal histories, illegitimate revenue sources as an example. Instead of being super specific the thought process is something like this to capture and a business process that requires these people to be approved to be included in activities.

📊 Solution hypothesis

currently Currently if someone is vulnerable, example being if we have been notified they have dementia by their family and as such we don't want to solicit, but we still want to send them particular alumni communications. We would in the current practice mark them as do not solicit but this . This is not a flag that is explicitly followed by development the Development team as there is a significant number of contacts that were marked as DNC or DNS by Development staff instead of other handlings to stop the phone programming program contacting them. This that we do not know if it was us or them. This opens us up to inconsistent use of the same fields. By separating out actions decided by us eg don't engage with someone as they are under investigation this will also allow these fields to be reviewed and then removed based on dates or time frames, it also gives us an additional layer of protection, they contact us about something we can see that quickly and manage the situation accordingly, having to look through 10’s of campaigns buried in someone's contact record is not very user friendly which will also create barriers to people looking for it. We are also using alerts as a portfolio to flag these things like due diligence concern stand alone, these alerts only work at a one to one level, these flags do not stop someone from being pulled into lists as this is not a preference. I think we need to really build our own rigour and business rules to ensure we are consistent across the portfolio as we merge with other instances of salesforce.

🌈 Design options

		OPTION A: New fields	OPTION B: Use Special Handling Campaigns
Overview
Screenshot
Benefits and risks		fields are easily accessed by marketing automation so we can build out business rules for exclusions in the future. Save us costly storage space It seems inconsistent if we have to refer to additional fields to look for data that have a similar purpose as the rest of the existing special handling. we could end up with a lot of fields that we need to look out for when pulling data which pose more risk if something gets missed unless we make the reason picklist multi select, it’s only going to be one or the other. And multi select picklist might be an overkill?	No need to define new fields for which in history there were only a handful of cases for which we have to use this for (but possibly because of lack of functionality available for the purpose being proposed?) We stay consistent with where we currently store special handling. If we have to migrate them all at later stage, we migrate them just from “one place”. So campaigns aren't really designed to manage handling preferences and this is something that will really need to change as we move to a single CRM and look at marketing automation. creates a storage issue, campaign member takes up 21% of total storage used. However I think storage will be less of an issue when we have more due to SINGL CRM and archiving (not 100% sure of this) hard to manage, need multiple objects to get to report on the Do not engage in order to be relatively useful, need to build report or any mechanism to easily capture them in reporting or viewing purpose, example as in screenshot (filtered on campaign category) need awareness for users to know how they are used and that they exist (to be fair it’s just going to be probably 3 more additional special handling campaign, one for each reason) having to report on the campaign members, it will not be possible to export a report to excel larger than 100k rows thus it is quite limiting. Campaign members for the opt-outs could easily exceed 100 rows.
Criteria	Component	Need to create new component	Existing Components + new component to make it more usable
	Daniel (Architect) Endorsement	no data	Yes