Tracking Feature Requests and Annoyances using Problem/Incident Flow
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 sharing your tip, Matt!
-
Hey Matt,
Super tutorial ! We're also using this workflow on our side (I just found your topic to see if someone had the same idea haha.)
Still, I have an issue on my side regarding this process. Indeed, all those feature requests are increasing my ticket backlog, and now we've an important ticket backlog composed on features ideas.
I would like to isolate the incidents tickets and create a view where only the incidents that are not linked to a Problem tickets are listed.Unfortunately I didn't find a smart way to do it for the moment (no trigger or view filter possibility on this specific ticket metric.)
Would you have a solution?
Cheers,Giovanni
-
Hi Giovanni,
Have you considered using a macro/trigger to tag any non-feedback incidents tickets or tag feedback tickets? If you tag your incidents tickets you can then create a view to show all incident tickets that contain that tag or filter out the tickets that contain the tag.
Let me know your thoughts!
-
Hey Giovanni,
I think I'm not quite understanding which is the issue. If I understand you correctly, you'd like to create a view that displays only tickets labelled "incidents" but not those that are tied to a problem ticket.
If that's the case, I think it would be best to determine how exactly you're categorizing your feature requests at this stage as you are correct, there is no way to isolate only incident tickets not tied to problems. You'd have to find a different way to do it.
Can you give me an example of how you would categorize one of your feature requests? This will help me to point you towards the best way to isolate them.
For example, as I mentioned in my first post, I used a drop down menu to determine if an issue was a feature request or not. If you're using that method, then any drop down menu can additionally include a tag automatically, so you could use the method Brett mentioned above and use the tag that is included to isolate your feature requests.
It really depends on what fields you chose to use and how you categorized your tickets. Do you mind me asking why you chose to use "incidents" and not attach them to a problem ticket?
-
Hi,
Thanks for your reply Matt & Brett.
We may not have the same process in fact :D.
Here is what I do:Every ticket is categorized with a custom field « kind of request » with 4 possibilities : Feedback / feature idea / product question / technical issue. It allow me to know how many tickets we receive every month for each « theme ».
We combine this custom field with the « type » field (Question, Task, Incident, Problem) to create workflows ( ex : If a Problem ticket with kind of request : Feature idea is created -> Send an email to the support team)
Once a Problem ticket with the category « feature idea » has been created, we will then link all the incoming support requests similar to the original requests received (to stack them, we use the Problem ticket as a folder).
Today those new linked tickets are set as « on hold » and we get back to our users when the feature requests has been released (So we directly reply to them when we close the Problem ticket with a public reply, on their original request).
The problem with this flow is that you stack a lot of incidents tickets in onhold and it add noise on your backlog. It’s even worst if you can’t discuss those features requests on a regular basis with the product team, as you can start to stack a lot of tickets.
We kee the ticket on hold today because otherwise you would not be able to easily get back to your users when the feature is released (Closed status won’t allow to reply easily to those users and let them know about the good news)
What I am trying to achieve:
- Find a way to manage this backlog (best option would be to close those tickets and find a way to get back to my users even if the tickets are « closed »)
- Find a way to target isolated incidents (= incidents that are not linked to a Technical issue or Product feature or Feedback problem ticket and touch only a specific account or order for example)
Thank you for your time,
Giovanni -
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!
Please sign in to leave a comment.
6 Comments