Turn Feedback Into Action: A Method for Scoping Support Issues by Brian Levine
0 likes171 views
1. The document provides a method for support teams to scope issues by developing a priority matrix with two dimensions: Impact and Severity. 2. Impact refers to how many users are affected, while Severity refers to how the product/service is affected. Different levels such as small, medium, large are defined for each. 3. For business-to-business companies, two additional dimensions are recommended: Customer Value and Customer Severity. Customer Value refers to how important a customer is to the business, while Customer Severity refers to how a problem affects a specific customer's product/service.
More Related Content
Similar to Turn Feedback Into Action: A Method for Scoping Support Issues by Brian Levine (20)
More from Support Driven (20)
Recently uploaded (20)
Turn Feedback Into Action: A Method for Scoping Support Issues by Brian Levine
- 1. Turning Feedback Into Action A method for scoping support issues Presented by Brian Levine
- 3. Currently Founder Bottle Cap Technology Previously Aerospace engineer Department of Defense VP Support GitHub Head of Support Plaid My background
- 4. Caveats We will primarily be discussing software support and how support teams interact with engineering and product teams. The methodologies we talk about are applicable to other teams and other 鍖elds.
- 5. The Problem
- 6. Standard support process 1. Customer contacts support
- 7. Standard support process 1. Customer contacts support 2. Support investigates issue
- 8. Standard support process 1. Customer contacts support 2. Support investigates issue 3. Support opens an internal ticket
- 9. Standard support process 1. Customer contacts support 2. Support investigates issue 3. Support opens an internal ticket 4. And then...
- 10. ...and then...
- 12. From the other side Engineers and product managers need to know how to prioritize feature work, internally reported bugs, and customer-reported bugs. Without more details, teams often default to what they are told to work on what they think is important what seems easy/fast what seems fun
- 13. Add details Support teams often add details to internal tickets to help other teams scope problems. For bug reports: How to replicate How many users are a鍖ected For feature requests: Who wants the feature Why they want the feature
- 14. Details help, but are not enough for prioritization
- 17. Two dimensions Impact How many people are a鍖ected? Think in terms of end users and individual people. Severity
- 18. Two dimensions Impact How many people are a鍖ected? Think in terms of end users and individual people. Severity How is your product/service a鍖ected? How does that a鍖ect the people using your product/service?
- 21. Support priority matrix 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users
- 22. Support priority matrix 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users Critical High Medium Low
- 23. Support priority matrix Severity Example de鍖nitions Low: Cosmetic Medium: Non-core component not functioning High: Core component not functioning Critical: Security or privacy compromise 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users Critical High Medium Low
- 24. Activity time! Create your own priority matrix
- 25. Activity time! Share them if you want
- 26. Setting priority Critical High Medium Low 1 - 100 users 101 - 1,000 users 1,001 - 5,000 users 5,001 - 10,000 users Support Priority (SP) Example de鍖nitions SP4: This is no big deal SP3: We should work on this soon SP2: Lets do this next month SP1: This is our next project SP0: Stop everything to do this
- 27. Your team doesnt work alone
- 28. Getting buy-in Involve other teams early in the process Everyone should agree on what is important to the customers and the business Develop the Severity and Impact scales and the Priority ranking as a group, with support leading Other teams develop a process for assigning work using the Priority scale Who you involve from those teams depends on your company and teams
- 30. Two more dimensions for B2B companies Customer Value How important is the customer to your business? This is speci鍖cally for customers whose value does not scale in proportion to their user base Customer Severity How does the problem a鍖ect the customers product/service? This may di鍖er from the a鍖ect the problem has for a generic end-user.
- 31. Customer priority matrix Crit High Med Low Low Med High Critical
- 32. Customer priority matrix CriticalHighMediumLow Customer Value Example de鍖nitions Low: Proportional to the size of the customers user base Medium: 2x - 5x more valuable than average for their size High: 5x - 10x more valuable than average for their size Critical: More than 10x more valuable than average for their size
- 33. Customer priority matrix CriticalHighMediumLow Customer Severity Example de鍖nitions Low: Cosmetic e鍖ect on end user Medium: A鍖ects non-core customer product/service High: A鍖ects core customer product/service Critical: Shuts down customers product/service; causes security or privacy bug Low Medium High Critical
- 34. Setting Priority Customer Priority (CP) Example de鍖nitions CP4: This is no big deal CP3: We should work on this soon CP2: Lets do this next month CP1: This is our next project CP0: Stop everything to do this
- 35. Activity time! Create a customer priority matrix
- 36. Activity time! Share them if you want
- 37. Summary
- 38. Summary De鍖ne SEVERITY and IMPACT levels for issues and feature requests Use those levels to create a PRIORITY MATRIX Work with other teams (e.g., eng and product) to de鍖ne levels and ranks Assign a PRIORITY rank to every issue/ticket you create internally Track progress on each PRIORITY rank with the other teams Optional: Create CUSTOMER PRIORITY matrix for customer-speci鍖c decisions
- 40. Questions?