Does anyone receive or write product requirements that come from the support org?
I'm working on creating a set of requirements for product that include supportability (smart error messages, logging for debugging) customer experience (does the product do what it says, do the docs make sense and usable) and other criteria.
I'd love to know if anyone has a set of requirements they already use or suggestions of what to include. Thank you so much and I'm happy to share what we create if anyone is interested.
Best Answers
-
Don't forget to look for product enhancement that allow customers to resolve their own issues such as smart help within the product, integration with your KB, etc.. You can improve case deflection significantly that way and, depending on your targeted market, it might be critical to the success of your org.
1 -
Hi Clarie,
From a new product perspective here are some thoughts in no particular order - I don't have a framework I can share, but this might aid you:
1 - Make sure that Error messages can be captured by the user, ie, not in a dialogue where the text can't be copied. Text is more searchable via google, knowledge base. Integrated contextual Knowledge and Docs even better.
2 - Ensure that the user experience can be easily replicated by support agents. (Rather than just a screen recording/screenshot), allow the customer to export project/example and share it with support in a simple way.
3 - Ensure that power-users have the tools at their fingertips to dig deeper into the issues they might face to debug them (more important for more technical products. It aids self-service, people might blog about the solutions they find.)
4 - Expose error messages and suggestions at healthy rates/levels. Don't inundate the customer - ie your project/environment contains 1,999,999 problems isn't helpful. Tips that lead to an engaging experience.
5 - Analytics that shows when an error message or user "warning" is shown, so that product can review and address the use-cases.
6 - Wizards that align with your customer experience, in-app tutorial availability.
7 - Support provided technical training to allow deep diagnostics into product issues, support team enabled to dive into the product at a low level.
From a maintenance and sustaining perspective:
1 - Regular catchup and review of the product's top ten issues - Bugs, Enhancement Requests, Fugs, etc. What's generating customer frustration and load for support.
2 - Reviews of most accessed Knowledge Articles in the area, why do customers need to access these articles. Weak product experiences, poor documentation, etc.
3 - Review of analytics on Error message rates/encounters - why are they running into these errors, how can product avoid them. Do you have coverage of the error experiences in Knowledge Base?
4 - New features demonstrated to Senior Support, reviewed for ideas similar to what has been listed above.
5 - Deprecation/breaking changes and migration changes tested against customer example and use-cases to ensure successful experiences. (A Beta program, a self service community around the public betas also useful.)
6 - Tooling for the Support team to automate tasks involved in replication of technical issues, seeing what the customer sees so that customer issues can be resolved easily.
2 -
Our customer success leader generates some of our best requirements as he is closest to how the platform is actually used. I hope product/solutions teams are in constant conversation around how the solution is actually being used and how it is delivering value. At our shop I would say that strategy gets 30 points, sales 30 points and customer success 40 points! But I will ask customer success to see if they agree with this or if I am fooling myself!
0
