Status |
| ||||||
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 |
| ||||||
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 |
|
| |
Criteria | Component | Need to create new component | Existing Components + new component to make it more usable |
Daniel (Architect) Endorsement | no data | Yes | |
fields are easily accessed by marketing automation so we can build out business rules for exclusions in the future.
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.✅ Follow up
Decision | Status | Next steps | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
💎 Source files
Type /link to add links to design files.