Best practice for customer issues from different sources: projects or issue types?

Amedee Van Gasse November 25, 2014

Hello,

I am in the process of reviewing our current JIRA setup, and I would like to get some feedback.

Currently we have one main product and 3 projects around it:

  • Development - new features, bugs, and other development tasks go here. The usual stuff. Internal only.
  • Support: technical support for our customers, they use the JIRA web interface or a dedicated email address to enter issues directly. Customers can only see their own issues. Issues are handled by support and development teams. These issues may be cloned/linked to development issues (for bugs, improvements, new features).
  • Technical sales: technical support for prospective customers. Questions like "can we do X or Y with your product". These issues are entered by our sales team and handled by the dev team. So currently sales is sitting between the customer and the developers, but we are considering to open this up, so these to-be customers can follow up their own questions directly. Occasionally we also get issues there that lead to bugs, improvements, new features in the dev project.

I read this question, where the suggestion is to use only one project with one workflow that does it all:
Best practice for setting up an 'customer issues' project within an existing Jira installation that is configured around tracking 'internal' issues

I don't want to go that far (yet). However, I have 2 projects, Support and Technical Sales, that are very similar. The only two differences are:

 

  • Who reports the issue (support: customer; technical sales: sales team).
  • Who closes the issue (support: customer or developer; technical sales: sales team).

I have two possible solutions regarding the 2 current projects with issues incoming from external sources:

  • 2 projects, each with 1 issue type and 1 workflow. Sales team doesn't have any noise from regular support. (current situation)
  • 1 project with 2 issue types, each issue type has a different (but mostly similar) workflow. Simpler for support&development, but more noise for sales.


What are the pros and cons of either solution?

Are there any other solutions that I haven't thought about?

 

1 answer

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 25, 2014

Your second solution is not really going to work.  Users will be asked which issue types to create, they'll be able to see other stuff in the project that should be internal only, unless you do a lot of config work and use post-functions to set things for them.

The question you've found is a good guide, but ONLY where you don't have the desire to hide things from your customers, and you do.  

By far the best solution is for one project per group of people who need to see stuff.

Amedee Van Gasse November 25, 2014

I am sorry but I disagree. If I understand you correctly then we would have to create thousands of projects. Currently our customers can only browse and edit their own issues. They have no access to issues created by other customers. I don't know how the person before me configured it exactly, but it works already. I agree with you on the issue types, but I am looking into JIRA Servicedesk. Once that becomes a mature product, I will be able to create a customer portal where I only offer a limited set of issue types to the customer. I already evaluated JIRA Servicedesk and it does not yet fit our needs because of other reasons, but at least for this aspect it does what we want.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 25, 2014

Sorry, you've misunderstood - I mean you should have a project for the internal stuff and another for the external, because you can't restrict users by issue type. Service Desk doesn't actually do the different issue types, it hides JIRA complexity from the customers and makes you map issue types internally.

Amedee Van Gasse November 26, 2014

OK I see what you mean. Now I have 1 project for internal stuff and 2 for external stuff, I was thinking about 1 for internal stuff and 1 for external stuff. Concerning JIRA SD, I am ok with hiding complexity from the customers.

Suggest an answer

Log in or Sign up to answer