/w=256,quality=90,fit=scale-down)
Success Metrics
There are two formatting options available. The traditional desired outcome statement is a structure used in the Outcome-Driven Innovation methodology. Since many stakeholders - especially when involved with marketing or UX teams - push back on the awkward nature of desired outcomes statements since people don’t talk like that, the alternative is a natural language structure that gets to the heart of the outcome and tries to avoid tasks and activities where feasible.
This catalog contains 20 potential metrics using each formatting option. You will likely need to reduce this set for a survey. The number of statements that have been generated is arbitrary and can be expanded to accommodate your needs.
Desired Outcome Statements (ODI)
How important is it that you… and How satisfied are you with your ability to…
- Minimize the time it takes to confirm the new solution is fully operational, e.g., all features working, no bugs, etc.
- Minimize the time it takes to ensure all data has been successfully transferred to the new solution, e.g., customer data, transaction history, etc.
- Minimize the time it takes to verify that all users can access and use the new solution, e.g., login credentials, user permissions, etc.
- Minimize the time it takes to confirm the new solution integrates with existing systems, e.g., CRM, ERP, etc.
- Minimize the likelihood of disruption to business operations during the switch, e.g., downtime, data loss, etc.
- Minimize the time it takes to train users on how to use the new solution, e.g., tutorials, user manuals, etc.
- Minimize the time it takes to receive confirmation from stakeholders that the new solution meets their needs, e.g., feedback, user acceptance testing, etc.
- Minimize the likelihood of unexpected costs associated with the switch, e.g., additional licensing fees, data migration costs, etc.
- Minimize the time it takes to decommission the old solution, e.g., data deletion, account closure, etc.
- Minimize the time it takes to resolve any issues or bugs with the new solution, e.g., technical support, patches, etc.
- Minimize the likelihood of users reverting back to the old solution, e.g., resistance to change, lack of training, etc.
- Minimize the time it takes to achieve the desired outcomes with the new solution, e.g., increased productivity, cost savings, etc.
- Minimize the likelihood of non-compliance with regulations due to the switch, e.g., data privacy, industry standards, etc.
- Minimize the time it takes to monitor and evaluate the performance of the new solution, e.g., KPIs, user feedback, etc.
- Minimize the likelihood of security vulnerabilities in the new solution, e.g., data breaches, unauthorized access, etc.
- Minimize the time it takes to establish a support and maintenance plan for the new solution, e.g., service level agreements, support contracts, etc.
- Minimize the likelihood of negative impact on customer experience during the switch, e.g., service disruption, data errors, etc.
- Minimize the time it takes to communicate the switch to all relevant parties, e.g., internal teams, customers, partners, etc.
- Minimize the likelihood of missed opportunities due to the switch, e.g., lost sales, delayed projects, etc.
- Minimize the time it takes to realize the benefits of the new solution, e.g., improved efficiency, cost savings, etc.
Customer Success Statements (PJTBD)
How important is it that you can quickly and accurately… and How difficult is it for you to…
- Confirm the new solution is fully operational, e.g., all features working, no bugs, etc.
- Ensure all data has been successfully transferred to the new solution, e.g., customer data, transaction history, etc.
- Verify that all users can access and use the new solution, e.g., login credentials, user permissions, etc.
- Confirm the new solution integrates with existing systems, e.g., CRM, ERP, etc.
- Avoid disruption to business operations during the switch, e.g., downtime, data loss, etc.
- Train users on how to use the new solution, e.g., tutorials, user manuals, etc.
- Receive confirmation from stakeholders that the new solution meets their needs, e.g., feedback, user acceptance testing, etc.
- Avoid unexpected costs associated with the switch, e.g., additional licensing fees, data migration costs, etc.
- Decommission the old solution, e.g., data deletion, account closure, etc.
- Resolve any issues or bugs with the new solution, e.g., technical support, patches, etc.
- Avoid users reverting back to the old solution, e.g., resistance to change, lack of training, etc.
- Achieve the desired outcomes with the new solution, e.g., increased productivity, cost savings, etc.
- Avoid non-compliance with regulations due to the switch, e.g., data privacy, industry standards, etc.
- Monitor and evaluate the performance of the new solution, e.g., KPIs, user feedback, etc.
- Avoid security vulnerabilities in the new solution, e.g., data breaches, unauthorized access, etc.
- Establish a support and maintenance plan for the new solution, e.g., service level agreements, support contracts, etc.
- Avoid negative impact on customer experience during the switch, e.g., service disruption, data errors, etc.
- Communicate the switch to all relevant parties, e.g., internal teams, customers, partners, etc.
- Avoid missed opportunities due to the switch, e.g., lost sales, delayed projects, etc.
- Realize the benefits of the new solution, e.g., improved efficiency, cost savings, etc.
Test Fit Structure
Apply this to Customer Success Statements only. Everything should fit together nicely. Here’s an article where I introduced the concept. Feel free to devise your own version for Desired Outcome Statements as this does not apply to their format directly.
As a(n) [end user] + who is + [Job] you're trying to [success statement] + "faster and more accurately" so that you can successfully [Job Step]