In part 1 of this article, we started our retrospective journey of understanding customer behavior that eventually helped halve the normalized number of support questions raised by customers for my business unit’s (BU’s) product suite. In the previous part of this article, we looked at communicating to cross-functional teams about a significant change to improve the overall customer experience. We then built a dashboard to provide visibility into metrics for 4 user segments and used a software log analytics tool to get intermediate metrics of product adoption.
Based on feedback from part 1 and part 2, I’ve reduced the size of each part, which would lead to more overall parts but fewer (missteps and) takeaways per part, which would make it easier for you to skim the takeaways to find the ones of your interest.
In this part of the article, we will look at communicating with customers about the self-service portal in 2 ways. We will attempt to communicate in non-intrusive ways which is often the case for platform enhancements as they do not get a press release or a launch event.
Thumbnail credits to mungang kim from the Noun Project, People vector created by pch.vector, and Abstract vector created by starline.
Announcing via Web Banner
The team owning the self-service pages in the web portal added a banner to announce the feature. This banner was on one landing page in the web portal and it announced the availability of the self-service feature to customers. See a mockup of the banner below. But, we were not sure whether the banner was being read. Were customers even logging in to the web portal? Were customers reaching this landing page? Were they reading this banner?
So, the team built a feature for a customer to close the banner, which is the cross mark at the top right. Any customer who closed the banner would trigger a data record in the system to save the customer’s preference to not be shown the banner again. We could review this data record to see the number of customers who’ve closed the banner, which could serve as a proxy for customers who’ve read the banner, which could serve as a proxy for customers who are aware of the new feature. Unfortunately, these proxies didn’t work well - perhaps not a surprise in hindsight?
Around the same time, I had scheduled some customer interviews related to a different problem statement; I asked these customers about their web portal login behavior. We also dogfooded the changes. Through dogfooding and the customer interviews, we realized that the banner was neither prominent nor did it have a CTA (call to action). Since there was no CTA, we were not driving the customer behavior that would benefit customers. Since the banner was not prominent, customers were not paying attention to the banner and were not closing it off. This resulted in a lack of data about customers who’ve closed the banner. So, we had no proxy data for customers who’ve read the banner or customers who are aware of the feature.
Although some customers probably learnt about the feature via the banner, we had no idea how many. We could see a gradual increase in the usage of the self-service feature (as seen in part 2). But, since we did not A/B test the banner, we did not know whether the banner led to any of this increase in feature adoption (Correlation vs Causation). It was safe to assume it led to some increase, so we went ahead with that assumption and investigated other approaches to communicate with customers.
Problem — How do we inform customers about the launch of the feature and measure it?
How-to Articles
I had a few hypotheses after the customer interviews and reviewing the progress of customer ticket data:
Customers in the segment who created support tickets weren’t opening the web portal.
Customers were not sure about how to use the feature in the web portal.
Customers were not aware of the feature.
I recollect a company executive joking about this as, “So, you are offering an ice cream to your customer but they are not taking it?” whereas a better analogy here might be, “We have an ice cream for the customer but the customer does not know about it.” But the crux remained that customers were not using a feature that they needed.
If we need to provide information about a web portal feature to customer segments who do not open the web portal, we need to provide the information in other mediums. Not all such mediums have sufficient leeway to allow for detailed prose of the feature being offered and nuances on it. So, I thought of writing a detailed how-to article, but use simpler phrases in other mediums which summarize it in a few words and point back to the article for more details.
I worked with the product designer to generate sanitized mocks of the feature and a team of writers to write an article on how to use the self-service feature with relevant FAQs and disclaimers. Now, any customer with questions could refer to this article and we could use this write-up to notify customers about the feature addition. We could now notify customers with short phrases in various mediums and refer them back to the write-up for more information.
Examples of software you could use to publish how-to articles for customers are Zendesk, Service Now, Joomla, WordPress, HubSpot, Contentful, Duda, Webflow, Salesforce, Document360, LiveAgent, and Helpjuice.
Problem — although I have the article, how do I inform customers of the article?
Hierarchy of Needs for Customer Problems
Indulge a tangent on my thesis of solving customer problems. Although I think how-to articles are not ideal, sometimes you need how-to articles as a backup. Ideally, customers have an intuitive experience and are not confused. Not just “customers” but every type of customer” across 100,000 customers have an intuitive experience ideally. I would rank ideal outcomes in this descending priority:
Intuitive feature for every type of customers
Intuitive feature for the majority of customers (majority by customer count or ticket count or revenue; think Pareto)
Not completely intuitive feature but detailed/simple/easy how-to instructions to use the feature
Not an intuitive feature and a lack of instructions but a quick and responsive support team
Not an intuitive feature, no instructions, and a burdened (so slow) support team
No (e.g. self-service) feature and a burdened (so slow) or non-existent support team
This illustrates a hierarchy of needs for customer experience.
Takeaways
We saw the challenges in using a web banner announcement - although a very common tool used by Product Managers across companies - you want to use it when you can drive the customer behavior you want, and measure the customer behavior. Further, you may build a great feature, but also you need to think holistically about announcing the feature the right way. You also need to explain the workings of the feature with the assumption that there will always be some customers who would need explanations for a well-built feature. Lastly, sometimes in the absence of a press release or a blog post, you can use your how-to article as a source of information for your customers.
Next Up…
In part 4, we will identify more non-intrusive ways of announcing this feature. We will then look at metrics! How to understand the engagement level of our customers with the how-to article? How to understand the sources from where customers find the information?
Originally published at https://harshalpatil.substack.com on Apr 29, 2021