In the previous article, we looked at the possible ways to reach our customers at a personalized level with news on product launches and improvements. We realized that while at it, we also needed a customer communication checklist to streamline the process.
In this article, we will use a retrospective lens to look at other available solutions that would have helped increase our understanding of customer behavior and hence boost the customer experience. If you’ve missed the earlier parts - here is the introductory article.
Thumbnail credits to Freepik.
What Else Would I Have Liked to Do?
There’s no doubt that we had made improvements in our customer’s experience. In retrospect, we had managed to reduce the number of support tickets significantly and we learnt how our customers interact with our pdf reports, emails, and features.
Keeping in mind we could not implement some of the solutions due to external or internal constraints; what else could be done to better understand customer behavior?
Feature launch benefit on support tickets
Problem: It was very hard to measure the incremental impact of feature launches because feature launches target only a subset of tickets. Tagging at the feature level isn’t possible by agents since the tagging options would change over time and tagging takes extra time from support agents.
Auto-Tagging Support Tickets: To be able to get the actual impact of a feature launch, the tagging of tickets needs to be done per feature or customer problem. With an auto-tagging capability, the tagging of tickets can be done for hundreds of features.
The auto-tagging would need to be coupled with auto dashboards based on new keywords defined by the PM during a feature launch. This way, it would be easy to see the number of customer queries that result from a particular feature launch and be able to react in good time.
Announce Updates to Customers
Problem: There is no channel to announce feature updates to customers.
Broadcast Feature Updates: Along with publishing an online changelog and support articles, We could broadcast a series of messages to keep the customers aware of feature updates. The broadcast messages would also include links to the relevant self-service FAQ for further assistance. Since customers are not necessarily looking forward to the broadcast updates, it is important to be targeted and avoid spamming their inboxes. Here’s a quick checklist of what to do to keep the information relevant:
Prioritize the important updates to communicate to the customers
Customize the updates based on the stage of each customer’s lifecycle.
Focus on making the updates actionable for the customer.
A possible solution for sending broadcast messages is Mailchimp. We would also want to have notifications within the product’s web portal. Examples of such software include Appcues and AnnounceKit.
Awareness of infrequently used features
Problem: customers do not have any hand-holding to learn some of the less used features of the product.
Feature Walkthrough: To avert this problem, we could have identified the most relevant point in the sign-up funnel to explain some of the less-used functionalities to the customer. Some viable options would include doing a site walk-through on a functionality, email blast, popup, or web portal banner. We riffed on this idea in an earlier article (part 6).
In this blog from Appcues, they discuss some good examples of a site and product walkthrough.
Infrequent web portal login
Problem: A lot of users do not use the web portal and rely on connecting with our company offline.
Restrict Feature Usage: First of all, we need to identify how many users access our web portal. Since we already know that most customers would rather connect with our company offline rather than through the web portal, how then can we increase the number of users on our web portal?
To incentify users to move to the web portal, we would need to make it impossible for users without login details to create support tickets. Using a web form on the web portal to submit a ticket would also enable us to serve pre-written answers to users and have cleaner ticket metadata. We riffed on this idea in an earlier article (part 5).
Also, a single sign-on (SSO) capability would simplify the process for users to create an account. This way, users would be more likely to get login credentials in a large enterprise company and in turn, use the web portal.
We would also need to include the link to the web portal in every customer touchpoint with our product, and especially the pdf report. This makes it easy for the customer to access the web portal whenever they think of it.
Copy-paste support
Problem: Customers should not need to create tickets to get answers via support shortcuts.
Auto-Suggest Solutions: The main aim of creating shortcuts is to cut down the number of support tickets coming in and save support agents’ time in having to deal with the backlog. Hence, an interface that auto-suggests relevant solutions to customers would work magic. Customers would easily get the help they need through relevant FAQs or how-to articles and support agents will be less stressed. We riffed on this idea in an earlier article (part 5).
An example software that does this is Servicenow.
Let-me-google-that-for-you support
Problem: Customers are asking questions that are already answered in articles.
Knowledge Base: There are always chances that customers will keep asking the same questions. If support agents keep repeating the solutions, it becomes repetitive, boring, and tedious. Hence, it would be of immense help if customers could have a go-to place on the portal for all such problems. The solution could be a universal search bar within the web portal where customers can search anything, ranging from a page, a field, to a how-to.
An example software that does this are Search365, ElasticSearch, Happeo, and Google custom search.
Correlation vs Causation
Problem: Not aware of the precise increase in how-to article page views due to my contribution vs external factors.
Tracking Page Views: An important aspect of understanding customer behavior as we’ve learned from these retrospective scenarios is tracking and analytics. Now, if we cannot tell the sources of the page views, then it would be hard to tell if adding a new article or editing an article is creating an impact. To do this, one should record every action taken and track the page view numbers before and after an event. An event in this case refers to publishing articles, article edits, or a feature launch.
An example software to use (more in-depth than we did) would be Google Analytics.
Slow, gradual adoption
Problem: Customer adoption took many months which meant for all those months the support team and customers had sub-optimal experiences although the feature existed.
Communication Checklist: Here, a customer communication checklist would provide a playbook to facilitate future product launches and enhance early adoption. The checklist would include identifying the customers who benefit from certain metrics, queries, or insights. Then, build upcoming launch information within different parts of the products and communicate with account managers, to share with their customers. Enable support by creating shortcuts and a policy on the escalation of issues. Finally, make announcements about feature launches through regular modes of communication like emails. We can cover the detailed customer communication list in a future article.
Examples of software to enable this would be Quadient Inspire and Front. Neither of these seem to be purpose-built for this, so there is a gap.
Noisy recurring metric alerts
Problem: As a Product Manager, receiving recurring emails on a weekly or monthly basis from dashboards is not always useful because you never know when to pay attention to the alerts.
Anomaly detection: Another aspect of metrics is identifying and monitoring product metrics so that we can understand customer behavior and notice new patterns. Three ways to do this include building reports of metrics, collating a dashboard of such reports, and scheduling emails of such dashboards. However, this presents each PM with way too much information and is not actionable. Instead, if the software could detect anomalies in the metrics and alert just based on that, it would make information more concise for PMs and hence increase the likelihood of acting on changes.
It seems a lot of known companies also offer such features. Examples of software to detect anomalies are Datadog, Servicenow, GitLab Prometheus, Splunk, and Zebrium.
Next up…
We’ve discussed what I would have liked to do differently. In the next article, we will discuss one new technique to visualize the customer behavior so that we can identify the right opportunities for beneficial interventions. The next article would be the last one in this nine part series.
Originally published at https://harshalpatil.substack.com on Feb 8, 2022