TLC - How do you manage communications?

Brian O'Keeffe · 2024-05-14T16:37:20+00:00

There was an error rendering this rich post.

I am looking for advice and experience on how to manage the following types of communications:

Uptime/downtime notifications for routine planned maintenance
Uptime/downtime notifications for unplanned maintenance/events

Product update information (service pack updates and new releases both major and minor)

Informational updates that include webinars, on-line training, and other events led by the CS team.

I am thinking of using a Trust site and subscriptions for the first two and possibly routine updates. I think major releases need more and a combination of subscriptions, email campaigns and in-application updates. Informational updates might be subscription based with an opt out option.

What do you do? Advice/experience appreciated.

Find more posts tagged with

Thought Leadership Corner

Comments

Brian O'Keeffe

https://gaingrowretain.com/discussion/comment/12055#Comment_12055

It was easy to do with the two being integrated. We did a lot of things that raised eyebrows and blurred CS with support, a giant no-no for some. For example, going into tickets to link to community, link to a case in the community to move an issue to support (closing the thread at the same time) and lifting from a support ticket to create a thread on a customer's behalf to move an issue to community from support.

I focused on #1 how we give the customer the best experience possible #2 focus on the right behavior. There was some fighting going on as we did this. Support was not comfortable going into community, some support team members and CS reps refused to go into community (it's not my job, I don't have time etc.). If we sat around trying to create and enforce the rules of community engagement first (as some wanted to do and as is commonly done) we would never have gotten anywhere. It created some friction. In the end we had a thriving community, a lower number of support tickets, customers who could more easily self-serve and a less blurred line between support and CS. It never vanished totally and never will.

FYI: Those that refused to go into community often got linked to threads with the answer they needed. That broke down some of the resistance!

PiperWilson

The more we had in the community, the more the ticket queue shrank. This is the real win.

That IS the win! It's fantastic that you were able to establish that metric.

Brian O'Keeffe

https://gaingrowretain.com/discussion/comment/12050#Comment_12050

Thank you for sharing.

I have used two strategies for Community membership. The first was to invite every administrator or potential member to join. Some did, some didn't. Not having access created problems. How do we share a thread with them? Or introduce them to another member? Having a Community allowed us to point to threads that had the answer of frequently asked questions, to introduce contacts to champions with similar struggles, and to move questions following an announcement or update into the community, all very powerful ways to seed self-service. We often went right into support cases and linked the customer to the community thread where the answer or relevant discussion lived too. (They were fully integrated.) By automatically adding everyone we were always able to point to the community directly whenever needed and not risk a NOT AUTHORIZED message. I even used the proxy feature to post questions that customers asked on his or her behalf as the user. (I asked first and only did it if they were ok with it. No one ever said no.) This was a great way to move serial emailers and ticket generators into the community without ever having to tell them to please go there directly.

You are correct that it hurts the engagement rate. A small percentage engaged in the community on any regular basis. Many more came only when needed. We reported on member growth in the community over time (obviously adding them automatically turbo charged this) and number of tickets opened over time. The more we had in the community, the more the ticket queue shrank. This is the real win. The added bonus was identifying and adding advocates we found in the community who we rewarded for community engagement.

PiperWilson

@Brian O'Keeffe

How did you roll alert groups into onboarding or new administrator creation? I am thinking of a default option where we manually subscribe the user to the right alerts (I used a proxy feature) and then introduce it to them and at that point they can adjust subscription options

Agreed. Some platforms allow you to subscribe members to categories or groups automatically, so you don't have to go back and proxy or do anything for existing members.

Same thing for community membership. I folded it into onboarding and join everyone automatically. Lots of pushback on this one too but it worked and we had 100% membership VS 60% with an invite and wait approach.

I invite you to reconsider automatically putting all new customers in your community. Having 100% of your customers in the community does not necessarily mean that they will engage with other members. That can mess with your metrics and make it seem like the community is not doing well enough to prove ROI.

Since part of the reason you want members in the community seems to be the ability to send notifications to customers, maybe there's a way to send community announcements to customers who aren't members. That would obviously take some sort of integration.

Brian O'Keeffe

https://gaingrowretain.com/discussion/comment/12047#Comment_12047

Thank you @PiperWilson ! I am looking at a status page to manage planned and unplanned maintenance. Possibly an alerts group too. For all product updates it will be strictly an alerts group by product. The struggle is for a customer to know what products they have. Right now I do not have a simple way for them to look and know. (There are legacy, current and acquired products and a customer can have any combination that look like a single product from the user perspective.)

How did you roll alert groups into onboarding or new administrator creation? I am thinking of a default option where we manually subscribe the user to the right alerts (I used a proxy feature) and then introduce it to them and at that point they can adjust subscription options. I found doing the reverse failed too often. Showing them and expecting them to have a motivation to subscribe is not realistic. Subscribing them (and I got lots of pushback internally on this idea) then allowing them to adjust subscriptions was a lot more successful. Same thing for community membership. I folded it into onboarding and join everyone automatically. Lots of pushback on this one too but it worked and we had 100% membership VS 60% with an invite and wait approach.

PiperWilson

@Brian O'Keeffe We do that in one of the communities I serve on the Vanilla platform, and I'm sure it can be done on other platforms as well.

For the most part, I find that most members don't reply to the update discussions. That doesn't mean they aren't consuming the information, though!

Personally, I would rather control when I look at the information I want than be pelted with blanket emails. Don't misunderstand; members can follow update threads if they want to be notified via email, but they aren't being sent so many emails that they're tempted to unsubscribe.

I recommend against using threads like this for unscheduled things. The type of thread I'm talking about is most useful for regular updates.

Brian O'Keeffe

Has anyone here tried using groups and alerts? For example a community group PRODUCT A with a subscription option for alerts about that product, including unscheduled maintenance and release updates. Posting is limited to a select few, comments to all members. I am trying to move away from all email, all the time and introduce more customer friendly and self-service options. It also solves the issue of walling off updates that might be fodder for competitors in a more public solution.

Brian O'Keeffe

Hi Kevin, thank you for sharing. I like the webinar idea that covers release information and other updates. I am a big fan of subscription based alerts that allow each contact to determine what to subscribe to and end the giant blast announcement that is so common.

I am getting some push back about a status page. Some see it exposing too much and possibly allowing competitors to identify weaknesses. I do not agree. If that is a concern, then we have bigger problems to solve.

kwilliams0

@Brian O'Keeffe , great question, and this can be surprisingly difficult to solve. What I've done in the past:

For unplanned downtime:
1. Have a status site so the customer can check if something is down. If there is unplanned downtime, we update there directly and will post the RCA there as well.

For planned/scheduled downtime:

1. Try to make this a consistent time window, and during non-critical hours. Saturday nights/Sunday mornings for example.

2. A status page should reflect this.

3. In-product notifications (I like the pop-up when logging in) preferably with 1 week of advance notice. If the maintenance is for new features, link to a blog post with the new features that will become available. After release, have a wizard in-product to introduce the customer to the new feature.

4. Customer email list specifically about maintenance notifications. Make sure to keep this list separate for opt-out/opt-in preferences. This can either link to the blog with the new features or contain the contents of the new features directly.

5. I also recommend a quarterly newsletter and customer webinar where you share new features already released, and upcoming features that are about to be released.

At this point, you have provided a site where they can check whether something is happening, two ways for communication, a reserved time window they already know about, and a quarterly summary sharing results and what's coming next. With this solution, customers shouldn't be able to say "You didn't tell us!"

Hope this helps!