In the previous article, we looked at linking to how-to articles in the PDF report but found that even after doing it, support teams were still getting too many unnecessary tickets. Hence, the need to find a more personalized way of informing customers about the self-service feature.
In this article, we will look at how to reach out to the customers in a more personalized way and convince them to login into the web portal and use the self-service feature for their issues. If you’ve missed the earlier parts - here is the introductory article.
I originally published this in my newsletter on Substack. You can subscribe there to get new articles straight to your inbox.
Thumbnail credits to Abstract vector created by starline and Designed by Freepik.
Roadshows cum Interviews with Customers
There weren’t many enterprise customers yet a lot of tickets were being created by the enterprise customers. You can think of this distribution like the reflective pyramid from an earlier article or the Pareto principle.
I thought if I could just talk to a few enterprise customers and convince them to use the feature, I would reduce the support tickets significantly and improve their experience via feature adoption. I can also learn along the way why enterprise customers were not using the feature. I decided to conduct roadshows to increase the adoption of the self-service feature among enterprise customers. So, I talked to sales and customer success (CS) teams and requested their help in reaching out to the large-enterprise customers.
Along with sales and CS teams, I tried to understand whether they had such needs. If so, did they use the feature? If not, were they aware of the feature. If yes, how did they find out and why don’t they use it? If they aren’t aware, how do they usually find out about new features in our products?
What did we find out about their needs?
They want to update their account settings
They want to confirm their account settings once every 1-2months.
They have multiple accounts to organize their usage of our product - sometimes even 10+ accounts.
The stakeholders within the company who know what the settings need to be changed to do not have access to the product web portal
Customers want email confirmations of their changes
Customers expect a white-glove treatment in meeting their needs.
Due to these needs and constraints, customers would rather email support than gain login access to the web portal and login to change the settings themselves. The self-service feature would meet needs 1 and 2. We could enhance the feature to update multiple accounts together and send an email confirmation of the changes. However, how do we encourage stakeholders to gain access to the web portal and put in the effort to use it? How do we provide white-glove treatment while freeing up the operational time of frontline employees?
Problem — Many relevant stakeholders in enterprise companies do not have access to the web portal of our product, so they do not have access to the self-service feature.
Enabling Access to Enterprise Stakeholders
Coincidentally around this time, the support team had noticed a trend that tickets coming in from emails were less structured, were harder to connect to an account, and so took longer to resolve the customer queries. So, they wanted to drive customers towards using the submission form in the web portal to submit queries.
Along with some vocal sales and customer success colleagues, I brought in the reverse perspective. I suggested continuing to allow email as a medium to create tickets primarily for niche stakeholders in enterprises, where they need to request updates to the account settings and monthly reports but do not have web portal logins.
We further worked on a joint solution across many departments to build a combination of product and process solutions that would enable user logins for every stakeholder in a customer organization and also not allow non-users to access support etc.
It also made sense to build Single sign-on (SSO) capabilities for our product since that would reduce the friction to create several logins for an account of the customer. The goal was to first enable, simplify, and incentivize users in any role of our enterprise customers to have logins to the web portal. Then combine the web form to submit questions with a capability to search the knowledge base for how-to articles. Then combine the ability to search with the ability to recommend answers based on the question asked. Solving these problems involved cross-department prioritization challenges and I’ll jump over its execution for now.
Problem — as a PM, I cannot scale to talking to every enterprise customer (and SMBs) to educate and persuade them to adopt the new features such as the self-service feature. How do I scale the persuasion?
Post-sales Pitch Deck
I reached out to a few teams - the sales onboarding team, the technical writer, the product marketing manager, the growth team, and the community evangelist team to create content together to answer customers’ FAQs by utilizing the recent feature launches.
You’ll recollect that in our earlier article, we had read through 1,000s of tickets to know the exact distribution of customer problems. So, we knew the most commonly asked questions and answers.
I talked to marketing to build a post-sales pitch deck to highlight the improvements we’ve done in the product for existing customers. Sales reps showed some interest in this kind of pitch deck as they were used to fielding questions on the challenges faced by customers in day-to-day usage of the product.
My hope was this could help reduce customer churn, improve customer satisfaction, reduce customer time on taking action on day-to-day tasks, and reduce support tickets. Also, I hoped it would give opportunities for sales reps to stay in contact with customers.
I’ve added a mock of the initial prototype:
Problem — touchpoint with customers after they’ve been using the product for months is already late. Also, sales reps do not stay in touch with 100,000s of customers, but rather a subset of them. How to reach out to more customers and at the right time?
Marketing Blasts to Customers
I realized that instead of limiting the information to marketing collateral that is used for post-sales, we can instead prepare handouts and blast it out to all customers like a marketing blast. But this is not marketing communication, nor transactional communication, or legal communication.
What is the legality of this communication? Whom can we send it to within a customer’s organization? How does it stand with GDPR and spam opt-out protections such as CAN-SPAM? I needed to figure out or work with the legal team to get a recommendation. I hope this serves as an example for the need for PMs to recognize various angles of a problem.
This also sounded like a problem that the growth team would’ve considered before. We moved forward considering this to be marketing communication since it is neither legal nor necessary in order to use the product, so it is not transactional either.
I also reached out to teams to see if anyone has built such a solution already. Eventually, it turned out this problem statement had not been solved in the company before. Neither the growth team, nor the marketing team, nor the community evangelist teams had a playbook for executing this.
The information to send could be a subset of the post-sales slide deck we saw above. We exclude recent launches and just focus on frequently asked questions e.g. understanding your usage and using the web portal.
This could be in multiple formats: pop-ups or banners in the web portal, how-to walkthrough visually in the web portal, and email blasts.
Example of a product walkthrough from appcues:
We considered the option of email blasts because, as we’d discussed in the previous article, a lot of the users of this part of the product did not login to the web portal. With email blasts, there were multiple factors to choose from.
Content breadth vs depth:
Send all FAQs at once? or
Select only the most relevant ones for the customer or situation and email those?
Timing broadcast vs drip:
Send FAQs relevant to this customer (or all) at once? or
Send the information spread across multiple emails across weeks / parts of the customer lifecycle?
This results in 4 options - a 2x2. I’ve shown this below.
Let’s discuss the 4 options and their complexity.
One-time FAQs Broadcast - easy, not targeted, not specific
One-time setups tips - somewhat complex. Need to know the right info to share with each particular customer and collate all of it at once. A tricky aspect is not knowing what the customer might do in the future. So, we need to have the capability to connect the dots between info available from customers now to predict customers’ likely behavior based on aggregate longitudinal behaviors.
Drip “Marketing” - complex as we need to know the right info to share with each particular customer and at the right time based on how the customer is using the product now and has used it till now. (Drip Marketing wiki)
Broadcast FAQs Repeatedly - easy but noisy. figure out all the FAQs required and blast it once to every customer depending on their lifecycle.
One challenge in all options is timing with respect to the customer lifecycle:
Should we email the customers when they sign-up? Is that the best time to inundate them with details on how to use the web portal or how to understand usage or how to change their settings? They have not even used the product yet and we are inundating them with more information.
Should we email the customers when they upgrade from trial (think freemium) to premium (or paid) pricing? Is this early enough for us to know what the customers would use in the future and tailor our recommendations accordingly? Is it a busy time for the customer where instead we are adding more info onto them?
Should we email the customers when they use the product for a certain number of days or use it until a particular threshold (number of entries made, API calls made, number of logins, etc.)? What would that threshold be?
Should we email the customers when they reach out to the sales team for volume discounts? But will that address a large enough segment of customers or only a sliver?
Should we email the customer when they search our docs or articles for the first time?
Should we email the customer when they file their first support ticket? Is this too late?
So, here we have discussed one angle to the complexity of sending the right information to a customer at the right time. We did not implement this solution back then because the solution was very complex to implement and did not fit in the purview of any team in the organization.
Problem — So, we are not relying on broadcasting FAQs. how can we improve our launch next time to improve customer adoption earlier in the launch cycle?
Next Up…
In the next article, we will look at other approaches like piloting before a feature launch and creating a customer communication checklist. These were some approaches that the team and I used to try and increase customer adoption of the features and future updates early in the launch cycl.
Originally published at https://harshalpatil.substack.com on Dec 14, 2021