Attention: Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au

Skip to end of banner
Go to start of banner

AVE-14 Do not engage Solution Evaluation

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 15 Next »

Status

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

Decision

NOT DECIDED

On this page

❓ Problem statement


We need a way to distinguish between an individuals contact preferences which is a legal requirement to adhere to and the University of Sydney’s decision on how they want to engage or not engage with an individual. Proposition is to build a ‘do not engage’ / ‘Communication Blockout’ check-box with associated start and end dates and a reason picklist. (e.g. under investigation, vulnerable). These would trigger business rules on how we engage and on what type of content people should still receive SAM and similar content but we do not want to engage them for solicitation. It would also give us a time frame to build reviews and or extend to other business areas in single CRM like students with as an example an exam blockout.

💡 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 - eg flagged in media as under investigation or we have concerns around due diligence
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.
Our Choice - often we make a deliberate choice to not contact someone, no way of determining this was our choice not the individuals and as such legally we are able to contact them in the future if circumstances change

📊 Solution hypothesis


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. This is not a flag that is explicitly followed by 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 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

to build a ‘do not engage’ / ‘Communication Blockout’ check-box with associated start and end dates and a reason picklist. The start and end date could potentially indicate the validity of the block-out period. We can possibly also run a scheduled flow to set and unset the checkbox based on the start and end date at midnight to ensure when marketing segments their data, the blockout is checkbox is set or unset based on these start and end dates.

Screenshot

Benefits and risks

(plus) fields are easily accessed by marketing automation so we can build out business rules for exclusions in the future.

(plus) Save us costly storage space

(plus) As the purpose of this differ from the rest of the Special Handling

(minus) 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.

(minus) 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

(minus) 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?

(minus) this field which is specifically used only for events and programs may not be scalable to be used for marketing automation in the future

(minus) this can be a band-aid solution which entails rework to back-end formulas, reports and SQL scripts.

(minus) Saving on storage cost may not be significant as it will also increase storage in contact object.

(plus) 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?)

(plus) 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”.

(minus) 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.

(minus) 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)

(minus) 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)

Criteria

Component

Need to create new component

Existing Components + new component to make it more usable

Daniel (Architect) Endorsement

no data

Yes

✅ Follow up

Decision

Status

Next steps

DECIDED / IN REVIEW / OTHER

  •  

💎 Source files

Type /link to add links to design files.

  • No labels