Issue tracking for hardware support?

Question

I'm looking into using Jira for tracking how often customers report issues with their products and to help collect data for later root cause analysis. Customer reported symptoms (such as "this part isn't moving correctly") have a lot of overlap and it can be difficult to tease out what the actual problem is. We use Zendesk for customer communication but I'd like to build a Jira project that can:

- have individual incidents associated with a single product's serial number (eg customer reported problems with X unit)

- multiple separate 'symptoms' can be associated with each incident (eg on X unit, the customer is seeing something not moving correctly AND odd noises AND a firmware update failed, etc)

- photos, etc can be attached for each symptom

- have workflows and resolutions based on those symptoms (eg the firmware update was resolved by the support team but the odd noises meant we had to bring the unit back for repairs)

- have certain fields required for certain symptoms (eg require the current firmware version for failed update symptom)

There are 20 primary symptom types we've categorized, each with 2-6 subtypes. We receive about 1000 customer incidents per month, across thousands of different users and serial numbers. It's very common for a single serial number to display 2-6 symptoms per incident.

I've been a Jira user for a while but I've never configured anything and I'm not sure where to start or what add-ons I might need to make the above a reality. I tried using subtasks for the symptoms but in the new UI it doesn't do what I need out of the box. I'm pretty sure we're on Cloud, if that makes a difference.

Thanks!

Daniel Ebers · Answer

Reading you requirements there are several ways to implement it. The more feedbacks you get the more different ways to will be told - based on everybody's experience, this is basically good.

There are many open questions and in the end you would have to decide with your team if you want to start small and grow the solution (which can provide instant possibilities) or make a big solution out of it which might require lots of planning and maybe also coding.

I feel the most interesting part to you is the categorization for symptoms and sub-symptoms.
Also, for this there are several approaches. One might be the use of components. This seems to me a too small implementation for you needs right from the start.

On Jira server there are Apps to implement whole structures for such categorizations. On cloud there are probably alternative Apps (I only implemented things like your requirement on server so the mentioned Cloud App would have to be investigated further by you or your team if it is suitable).
Other things are just not there which could have been of interest to you in that matter.

I read you thought of creating a sub-task as per symptom. This sounds good but also on this other users might have chosen a different implementation why they will recommend something else.
From my point of view you could choose that way. High-level plan: to implement an automation that creates a sub-task as per the chosen symptom.
Attachments can be made to a sub-task as well so also this requirement is met.
The "serial number" is just a custom field in my opinion. It also goes well along with other criteria like symptom or time ranges the defect(s) occurred. You can easily do nice overviews on this using JQL queries.

For the part of having some fields required when choosing a specific symptom you can use "Field Configuration". On the other hand this would probably mean a lot of needed configuration upfront (own screens, likely this also requires creating several Issue Types).

For the workflows it is the same. I understood by a first look into your description the workflows should be differ as per symptom. Whilst this is possible (connection here would be a Workflow Scheme as they allow you to separate different Issue Types along to a defined Workflow) it might also mean a lot of work upfront - further complicated Workflows are not very popular with users (please see chapter "2)" of the linked article).

There is so much more that could be said about but I will press pause here :)
In case you have a non-production environment/copy of your cloud site it would be probably best to try a few things, show them to the team and discuss which approach works best.

Cheers,
Daniel

Roxanne Gordon · Answer

Hi Jack! Thanks for your response. The idea would actually be to use JSW since, as you said, customers aren't great at categorizing things correctly. We have a highly technical product geared at non technical users so this would be for tech support employees to "translate" customer observations back to the engineering teams. This isn't one of them for us, but as an example one of the symptoms with sub-symptoms might be:

Product not moving correctly

-- stuck at bottom/top of range

-- inconsistent movement

-- loose/moving too much

Right now our customers can self select some broad categories but we're seeing the need to dig in on this granular level to figure out root causes for common issues, and tagging whole conversations in Zendesk isn't giving us the insights we need.

Jack Brickey · Answer

Hi Roxanne, welcome to the Community. I’m going to assume that you would actually use JSM and not JSW for this since you are working with external customers.

Reading thru your post one thing strikes me as making this challenging - associating symptoms to workflows. Now maybe this isn’t really a requirement. It isn’t that you couldn’t create the workflows but rather getting the customer to reliably choose the right Request type when opening a ticket. Experience show is that if you make it too complex for the customer to be able to find and pick the proper request type then they will simply pick one. When this happens it makes leveraging the RT for metrics unreliable. 
I think what I would do is try to minimize the RTs making choosing the right one straightforward and then have the customer prompted to answer questions vis the RT underlying form so that you end up with data that can later be interrogated.