One of the things that our team has struggled with the most is providing our development teams with quantifiable data for user feature requests and annoyances (e.g. UI/UX issues).
We noted that this was something that the problem/incident flow did really well when we were presenting a case for bug fixing. We were able to say we had 47 incidents etc. However, there was no obvious way to duplicate this flow. With a bit of assistance we've managed to succesfully replicate this system and it's really quite simple.
1. You'll start by adding a custom field to your tickets (we used a drop down menu labelled "Issue type") that includes any category you'd like to track using this method. As noted we've used "feature request" and "annoyance".
2. We then created two additional views for our team, one for each respective category.
The views themselves are specifically designed to show problem tickets with the custom categories and exclude the traditional problem ticket.
We achieved this by setting up the following under the "meets all conditions" sections in our view:
- Ticket: Status is less than solved
- Ticket:Type is problem
- TIcket: Issue type (our custom field) is "annoyance".
3. We adjusted our original "problem" view by ensuring that the "meets all conditions" section includes
-Ticket: Issue type (our custom field) is not annoyance
- Ticket: Issue type (our custom field) is not feature request
It's as simple as that, you can now duplicate the problem/incident flow for any number of categories and therefore, get good quantitative data for feature requests that enable you to put more weight behind requests to your development teams.
Note: The only potential downside of this is tagging incidents as all of your problem tickets will be included in the problem list when looking to pair an incident to a problem ticket. As these come with a search feature this wasn't considered a big deal for us however, if you're accustomed to a fairly small list of problems it's something to be aware of.
Hope this helps!
Thanks for the detailed explanation Giovanni!
I can't think of anything off the top of my head that would remove this from your backlog other than setting the tickets to on-hold and tagging them as they're created.
You could then set up your main working views to filter out any tickets that do contain that tag as well as filter out any tickets containing that tag within your Insights reports.
Maybe some other community members will jump in here and offer up some alternatives for you :)
As for the isolated incidents, what exactly would you like to do with these tickets? Do they still have the appropriate fields selected upon creation?
Just want to make sure we're both on the same page here.
Thanks!