1. Turning Feedback
Into Action
A method for scoping support issues
Presented by Brian Levine

2. Before we begin...

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
fields.

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...

11. The friendly bump

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 affected
For feature requests:
● Who wants the feature
● Why they want the feature

14. Details help, but
are not enough for
prioritization

15. Prioritization
Matrix

16. Two dimensions
Impact Severity

17. Two dimensions
Impact
How many people are affected?
Think in terms of end users and
individual people.
Severity

18. Two dimensions
Impact
How many people are affected?
Think in terms of end users and
individual people.
Severity
How is your product/service
affected?
How does that affect the people
using your product/service?

19. Support priority matrix

20. Support priority matrix
AllLargeMedSmall

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 definitions
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 definitions
SP4: This is no big deal
SP3: We should work on this soon
SP2: Let’s do this next month
SP1: This is our next project
SP0: Stop everything to do this

27. Your team doesn’t
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

29. Prioritization
Matrix
Part Two

30. Two more dimensions for B2B companies
Customer Value
How important is the customer to
your business?
This is specifically for customers
whose value does not scale in
proportion to their user base
Customer Severity
How does the problem affect the
customer’s product/service?
This may differ from the affect 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 definitions
Low:
● Proportional to the size of
the customer’s 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 definitions
Low:
● Cosmetic effect on end user
Medium:
● Affects non-core customer
product/service
High:
● Affects core customer
product/service
Critical:
● Shuts down customer’s
product/service; causes
security or privacy bug
Low
Medium
High
Critical

34. Setting Priority
Customer Priority (CP)
Example definitions
CP4: This is no big deal
CP3: We should work on this soon
CP2: Let’s 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
Define 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 define 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-specific decisions

39. Get in touch
SD
balevine@bottlecaptechnology.com
brian@balevine.com
@Brian_A_Levine
@balevine

40. Questions?