Strategy question how to set up Jira Service desk projects for multiple customers.

Paul Neat March 15, 2018

I have multiple customers we provide systems support to.  I receive system alerts into Jira via email, and create tickets.  I have Organizations which each have their own email sending alerts to Jira.  In addition, I plan to have a customer portal for each.  I believe/assume I can leverage Organization to keep my customers and related issues separate.

Two questions.

1) Should I set up one project for multiple customers, or a separate project for each?  The resources working on the tickets are the same either way, at this point.  My thinking is that one project would be easier to maintain; however, what are the things I should consider?

2) Similar question for automation.  I am creating automation rules based on the subject line and in some cases, the body of the email.  The logic applies to all customers, with some slight variations.  Should I set up one big rule with multiple if then's, or separate rules?

Thank you,

Paul

2 comments

Meg Holbrook
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 19, 2018

Hey Paul,

Are the email addresses your customers sending to going to be different or the same? If you have one submittal address, you can get away with one project, but more than one submitting email address will require another desk (or at least some forwarding rules which makes things messy). 

Separate desks are also the only way to get more than one portal.

As for setting up automation rules, I find that it's easier to manage a smaller subset or rules, and you have a cleaner end-result, but separate rules could be easier to troubleshoot out of the gate. 

If you are creating separate projects, you will likely want to separate the rules. 

Paul Neat March 22, 2018

Hi Meg,

Thanks for your response.  The emails are sent to a central Outlook email and then Jira pulls the emails based on who the sender is, each having their own email.  So I receive it in Jira as if it came from the customers server.  So that email is part of the organization.

I am assuming that I can have a shared portal, with the individual contacts associated with their organization.  Thus I should be able to track requests by organization, etc. Let me know if you think that could be problematic.

Thanks!

Paul

Meg Holbrook
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 22, 2018

Hey Paul, 

If you only have one help desk email channel, you can only have one portal. 

If you want more than one portal, you will need a separate email account for each help portal. 

 

If you have users set to specific organizations, I do believe you can find ways to tie together the organizations to default issue types, which would allow you to administer multiple customers from one desk. 

Paul Neat March 22, 2018

Thanks!

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 23, 2018

to add to this. if you create two different projects and use different Organizations/Customers per project then, while you have only one portal, the projects will have their own unique URL, e.g. .....portal/1 and .....portal/2.

Paul Neat March 23, 2018

Meg,

Can you elaborate on how I might tie the organizations together to default issue types?  I am not able to change the issue type with an automation rule.

Thanks,

Paul

Meg Holbrook
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 23, 2018

Hey Paul, I can try to look into out of the box functionality for JIRA sometime next week, but I can recommend Automation for JIRA if you are looking for an addon with lots of highly-configurable automation settings. 

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 23, 2018

@Paul Neat, i don't understand the goal of associating an org to an issue type.

@Meg Holbrook, not trying to butt in here. just trying to help if I can. :-)

Meg Holbrook
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 23, 2018

No problem at all, happy to see what other people might do. 

My interpretation of this was that Paul wanted one single help desk where users from a differnt orgs could submit to one help desk but default those orgs to different 'types' 

Paul Neat March 23, 2018

Thanks all for your comments. Here is what I am trying to do...

I have several customers with systems monitoring events.  Those events are emailed to a central email box.  Jira pulls the emails and I can associate the email with an organization as each organization has a unique email which I see in the From field when I receive the email in Jira.  I am motivated to have one big project to handle the events as the automation rules are largely the same for all customers, and will be lengthy and complex.  For example, if the subject line says x, change the priority to Highest and escalate the issue, or if it says y, transition the issue to canceled, etc...

Meanwhile, I want to have a portal for our customers to make various service requests.  The emails are tagged with one Issue type.  Ideally I want an email associated with an issue type for events and an email associated with an issue type for customer request.  Thus I am thinking I would need to have two projects, one for each.  When a customer logs a request on the portal it is currently tagged as an event issue type.  I am not able to create an automation rule that changes the issue type to a customer request - I receive a message basically saying you cant change issue types. (perhaps I am doing something incorrectly)

I appreciate any perspective and guidance you can provide.  I am open to any ideas as I may be thinking about this the wrong way....

 

Thanks!

Paul

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 23, 2018

Thanks Paul that helps. So first I agree w/ you on a single project as it will be easier for your team since all agents work on all issues. If you had separate teams working events and 'portal issues' then i would like suggest two projects.

Now to be clear let's keep "Issue Types" separate from "Request Types". Issue types are like Task, Bug, Incident, etc. Whereas Request Types are what the customer will see in the Portal. You likely are already aware but just making sure we use the same language.

It sounds like you are using some email parsing which is really good because it will allow you to appropriately set fields on incoming issues reported to keep stuff straight. OOTB this is a bit limited in JSD, at least in Cloud. If you could dedicate the email channel for events from the monitoring system and the portal channel for everything else that would improve things here quite a bit but w/ email parsing you could deal w/ both events from monitoring systems and customers sending in emails for issues. The point here is I think you will want to separate these into different Request Types, e.g. System Events, Question, Bug, Enhancement, etc. I have a Request Type call IT-Email and I hide that from the portal as it is dedicated to the email channel all other Request Types are visible and grouped to make it easy for customers in hopes they 'get it right' when they open a ticket.

Now if you are in fact using Issue Type for things like Events, etc that might be just fine but maybe unnecessary. If you can dedicate the email to these "Events" then certainly having that be an Issue Type makes sense. One possible reason you likely can't change the Issue type as you mentioned is the from/to issue types have different workflows in which case a Move is required. Or it could be a permissions thing. 

Finally, if you really want two emails then you are talking two projects. But if you can parse the incoming and direct events to "Events" and all non-events to "Customer Req" issue type then you can stick w/ one project. The question to ask yourself is whether the workflow for dealing w/ Events needs to be different than "Customer Req". If they can be the same then I would content that using a single issue type and two request types might be better, but that is very objective.

Unsure if any of this helps. There are a number of ways to set JSD up.

Paul Neat March 23, 2018

Thank you Jack - very helpful.  I will hide the email request option from the portal - good idea.  But if I understand it correctly, if a customer emails a request directly to the Jira email, I will still have the issue of 'conflict' with the events and customer requests coming through the same email, which will have the same Issue type and associated workflow.  I anticipate I can use the same workflow for each; however, for reporting purposes I want to be able to distinguish events from customer requests.  Events are internal and only a subset are escalated to the the customer.  Customer requests certainly will involve a back and forth, status reporting, etc.  Both are reported on a monthly summary report.  So my challenge is how to separate the two?  Is there a way to effectively do so without setting up a second project for customer requests?

Thanks

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events