I work in customer success in the enterprise technology space and have written several posts on the activities required for the role – find them under the customer-success tag. This one is about the use case which I see as the currency of customer success management.
A use case is a set of interactions between a user and a system to attain a particular result or function and is often represented by a process or work flow. Use cases should ultimately be geared towards delivering a business solution.
A solution is designed to integrate multiple facets of a company’s business through interchange of info and processes and should produce outcomes that achieve business goals.
The use case is the input, and the solution is the output.
Use cases / solutions can be captured to show the value a platform is providing to the business. It can also be used to share amongst users to support further use and value creation across different parts of the business. See more on this at the end of the post.
Each use case should have its own measure of success and can be broken down into 4 parts which could easily be captured in a single page or slide document template:
- Challenges and objectives / expected outcomes.
- Workflow and/or functions breakdown to focus on.
- Success criteria (KPI’s).
- Additional factors for success (change management, training, etc.).
Managing use cases
As far as possible have a method that is simple, quantifiable and results should be taken as representative. You could start with a simple spreadsheet for collecting and managing a use case pipeline. Apply a selection criteria that will allow for quick shortlisting. From a shortlist you could (but don’t have to) use an online survey to get feedback on priority and demonstrable value.
Example criteria for shortlisting use cases
Criteria used for selection (score 2/3 to be progressed or selected)
- How important is this for internal stakeholders. Case studies that touch core business operations carry more value.
- Financial: How does it impact on the bottom line
- Customer: How does it impact on how our customers perceive us
- Internal Process: How does it improve productivity
- Learning & Development: How do we improve and create value
- Key KPI’s / metrics can be identified
- These can be measured through survey’s or analytics and tied to the use cases
- Delivery of business value can be quantified in some way.
- Resources to manage are available (people, budget, time)
- Key stakeholders identified and involved
- They suit the organisations level of maturity in use of the specific technology
There are two types of use case that generally need managing:
- Pre-existing. Function / activity already being used or carried out to good effect (good outcomes) and can be captured for purpose of sharing good practice and perpetuate further use.
- Planned. Function / activity that the organisation would like to see being used or carried out. Idea would be to propose a workflow or process, train users on it and then monitor to see if intended outcomes are achieved. Share if it worked well or iterate further if needed.
In the case of a new platform launch, ask the vendor if they have any from other customers that can be used as a baseline. When a platform has been around for a while but you are only starting the work of managing use cases at a late stage, ideally you are able to identify as many pre-existing use cases as possible.
Pre-existing use cases (I call them serendipitous use cases :) have come about spontaneously and hopefully reflect a natural use of the platform. They are unforced or not mandated and as such they are the purest form of a use case. These type of use case are like gold. When I manage business value workshops with customers in which identifying uses cases is big part (see diagram), I dedicate a separate session for these.
Readying planned use cases for execution
Analyse responses from surveys if you have used them or manually evaluate each use case and select the ones that have scored highest in terms of priority. Next identify a person who will help drive their development. Progress with the development of the top 3 or 4 use cases. Finalise the use case format/template mentioned at the beginning, ready for distribution and work closely with use case leaders and users. On this last point, the more complex the technology, use case or organisation, the more you will likely need an owner and team of people supporting it.
Executing the use case
This should be done over a short period of time but that also depends on the complexity of the organisation, technology and/or use case. I suggest roughly a three month period. In this time users should be trained on the use case and supported in getting up and running where needed. Progress should be followed pretty closely and ongoing support provided where possible. At the end, determine where the goals for the use case have been achieved. If it does perfectly then you could adopt this in future uses as is. If not you may need to tweak and iterate further on the use case in a second, quarterly cycle. You may, at worst, need to discard it. If the former case, you can then go on to share it.
Sharing successful use cases – perpetuating the success
A critical aspect of achieving success (and ultimately in my business that means driving adoption of a technology platform) is capturing the essence of the value it delivered in an easy to understand, simple and ideally visual way and then sharing or communicating it. This is also fundamentally important for those responsible for the platform in the business and who have paid for it and must ultimately justify its value and ROI.
It is by capturing successes through use cases and sharing them that you perpetuate success. Users in the organisation not using the system yet see how others who are using it and are inspired to use it in similar or even better ways. It becomes a self fulfilling and virtuous circle of success.
The diagram you see here could be a simple way of capturing the outcomes of a successful use case delivered over a period of time. It is fairly self explanatory. The key thing about it is that the easier you make it to share the better. An image file is likely to be the best way to do that. You could even go so far as to share a template with use case owners or the general population of users so they can capture their own unplanned or serendipitous use cases and then go on to share them.