One thing I did for a specific program series was to build a data designer that mirrored the participant criteria for the program. Given some of the criteria was time-based or consumption based, it was intended to be used to answer the “Would X receive Y program if it were sent today?”. 

I would also send an email in advance to anyone that had participants who would receive the upcoming email so they could take action if needed.

The reporting gets a bit more complicated if you have multiple steps but conceptually can help do some of the lifting.

Document the journey and recipient criteria for each program and publish in a common place.  Then provide resources where users can self-serve this information (i.e. dashboard reports, C360) and identify the targeted criteria points.

I would advise against the multi-picklist for “opting in” method. That requires individuals to be on top of manually keeping those lists up to date in a timely fashion. Also, the mismatch/confusion between customers opting out of emails and keeping this multi-picklist updated. Anytime you introduce manual dependencies into automation, you’re gonna have problems (and likely increase the volume of virtual shoulder taps from users).

Love both of these ideas. 

Currently have a report set up for a weekly executive outreach email (based on usage criteria) to allow potential recipients to be opted out prior to that program’s send date.

I’m currently updating our documentation, and actively exploring the idea of building out dashboard(s) to self-serve this information. C360 makes it difficult because most of our CSMs (with numbers of accounts approaching triple digits) don’t want to look at a specific account, they want a consolidated list, when they want it (not delivered in a recurring report).

@darkknight, would you think using a multi-picklist field as an “opt-out” method might work? The boolean fields start to take up too much space, but that could potentially be a way of adding multiple subscriptions and letting the CSMs opt those individual users out of those emails that way (and could still be used in the dashboards/reports).

@dayn.johnson you’re probably asking the wrong person, because I’m of the mind that if we are allowing individuals to be opted out of individual emails we’re sending, then why are we sending that email in the first place - because it sounds like it’s probably not delivering value.

Also, that picklist is gonna grow and grow and grow. IMO it’s a band-aid for a digital strategy that needs some TLC.

@darkknight thank you!

I’m thinking the field would be less of a “specific email” opt-out, and more of a “type of emails”. Ex:

• Automated CSM outreaches
• Product updates
• Upcoming webinars
• Training recommendations

It’d be awesome if the CSMs had visibility into whether clients had opted out, but also, we’re running into issues where the CSMs don’t want to be sending emails operationally to certain clients, and they want us to make specific exclusions on a case-by-case, person-by-person basis (and to give them custom reports), so I’m just trying to figure this out as we’re scaling our programs.

@dayn.johnson sounds to me like they want to have their cake and eat it too. What’s more important to them: having these emails automated or having granular control over who receives what message?

Have they given you valid reasons for wanting to opt individuals out of receiving specific emails? Just because someone wants something doesn’t mean they need it. If it is based on requests from customer contacts to opt out, then if your opt-out settings contain the appropriate categories, the CSM can just advise the contact to opt themselves out of a specific category. 

Speaking from my own personal experience, if emails sent through Gainsight are A) timely and targeted to the appropriate persona and delivering tangible value, then circumstances requiring an opt-out should be rare, i.e. problems with a customer’s renewal.

If this were me, I might concede to a category-based opt-out flag at the Company level - if there is a valid reason to have it. But not at the individual person level. There is just too much room for manual error on the user’s part that can result in oversights and more Ops tickets asking “why did/didn’t this happen?”  and additional criterion to remember to include for every program. I would ensure that the “Email Opt-Out” flag is visible and editable on the Person section so that they can opt individuals out of receiving all emails if needed. I believe if that Email Opt-Out flag is set, it’s automatically honored by programs so you don’t have to explicitly remember to add it to logic (unless that has changed).

Just my 2c.

Amazing question @dayn.johnson , and becoming more of a priority as we layer automation and digital CS into our programs.

I sense two items here:

1. What’s the perspective on permissioning CSMs or other internal stakeholders to opt customers or users out of automated comms?
2. How do internal stakeholders know what’s happening around them, and on their behalf, so the customer experience remains cohesive?

I’m hard-pressed to add to the outstanding input of @bradley and @darkknight . I do believe process wins the day here: Whatever the decision, ensure it’s clear and understood by your stakeholders.

That said, I’m typically quite reluctant to permission folks to opt their customers or users out. A lot of thought typically goes into a good customer journey. Thus, altering it should have a very high bar. I liken it to driving: In the US, we drive on the right side of the road, and when we all do that, we all become more efficient and effective (and safe). There are sometimes reasons to drive elsewhere: an emergency vehicle may be coming or construction might guide us into a different pattern. That’s fine, but even that is governed by norms (in Ops, we might call it process), not by someone unilaterally deciding it would be more convenient for them to drive on the left today.

Amping up visibility on automated messaging is great. By sharing which programs are running and under what occasions, folks will get more accustomed to them running. And I highly value Bradley’s suggestion of showing who would be “in” if the program ran now. It’s quite like the sportscasters who say, “If the season ended today, here’s who is in the playoffs.”

Phenomenal response as always, @matthew_lind! Looking forward to meeting you in-person at Pulse (already signed up for the roundtables).

We have “CSM Check-in opt-outs” (two, at the company and the individual level) so CSMs can have granular control over which clients receive those messages. We also have a “distro email” checkbox for those use cases.

Moving forward, I’m planning to start sending these particular CSM check-in emails (as they’re the ones people are most frequently asking about) through dynamic JO.

Please correct me if I’m wrong, but my thinking is that I should be able to create a Data Design Template for use as a source in those programs (they’re sent as ad-hoc manual emails), and use that SAME Data Design Template to create a report that can be shared monthly (or as needed) with the CSMs whose accounts/users will receive that email. Does that logic track? 

Hard yes on the fact opt-out shouldn’t be in the hands of sales or CSMs. The recipient should be in the driving seat here and always. 

We have a map of who receives what based on engagement model and (to an extent, role, although we’re always in contact data quality fighting mode) which makes it clear to everyone that they can expect X, Y or Z for account profile 1 or 2.