Best practice: scaled CSx control/visibility into email recipient subscription for recurring emails

  • 15 April 2024
  • 9 replies
  • 64 views
dayn.johnson
Rank
Userlevel 5
Badge +3

Curious — (how) do you deal with requests from CSXs asking whether a certain user and/or organization will receive a particular email? (ex: CSM check-ins, monthly product/event newsletters, usage emails)

 

Our current situation:

Emails are sent through advanced JO using queries (multiple queries, in multiple programs). We have various opt-out options (boolean) at both the company level and person level for certain programs, and use those opt-out fields within the query to allow our CSx’s to opt users or companies out of certain communications (CSM check-ins, re-engagement programs, etc.) as required.

The issue:

As we’re scaling our CSM model, and are beginning to send CSM check-in emails (and other emails) to more users, I’ve been getting more and more requests asking questions such as:

  • Will {user} receive this month’s CSM check-in?
  • Can you pull a list of all my users who will receive {this specific} email?
  • Did this user receive {this specific} email?

THIS IS NOT SCALABLE.

We’d originally considered creating segments for these various types of emails, but by design, these don’t give CSMs visibility into (or control over) the users that receive those emails, which is something the CSMs seem to want. Furthermore, segments don’t seem to play well with the new dynamic JO for our purposes.

My thinking is that creating a multi-select picklist field (similar to a user “role” field) that could be initially set up to “opt-in” to use for “Email Subscriptions” could serve our purposes. My goals with this field would be:

  • Including this field in future queries as a way to include clients in the communications
  • Giving CSMs visibility into which emails their clients would receive

Something like this field could then be added to one of our “Active Users” dashboards available to our CSMs so they could filter their users by that subscription option to see who would or would not receive the communication

Future state:

We’re in the planning stages, but will soon start converting our current advanced JOs to dynamic JOs. I would like to be able to utilize the data designer templates to have a core set of query templates (ex: All Active Users, users > 90 days old, etc.) that I could then pull in that field as the program required. 

For our use case, we have to make a significant number of changes to our standard queries on a program-by-program basis depending on the subsets of users we’re targeting.

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide

9 replies

bradley
Rank
Userlevel 7
Badge +6

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.

darkknight
Rank
Userlevel 7
Badge +3

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

Jeff Kirkpatrick
dayn.johnson
Rank
Userlevel 5
Badge +3

Love both of these ideas. 

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.

☝ 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.

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

☝ 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).

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide
darkknight
Rank
Userlevel 7
Badge +3

@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.

Jeff Kirkpatrick
dayn.johnson
Rank
Userlevel 5
Badge +3

@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.

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide
darkknight
Rank
Userlevel 7
Badge +3

@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 B) 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.

Jeff Kirkpatrick
matthew_lind
Rank
Userlevel 7
Badge +9

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.”

Making people their best....currently disguised as a CS Ops Architect. How can I contribute to your success?
dayn.johnson
Rank
Userlevel 5
Badge +3

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? 🤔

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide
alizee
Rank
Userlevel 6
Badge +9

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. 

 

 

 

If you don’t want to make mistakes, don’t do anything. If you want to learn, ask questions and make mistakes, except in construction because they’re the most expensive part of building.

Reply


Terms & ConditionsCookie settings