Incident and Request Logging against organisations

[Damon Johnson]

Hello.

This is a question to ensure JSM is capable of supporting our customer base.
Its probably easier to explain a use case and see if there is any input if this is achievable or if we need to revaluate how we will use JSM.

We support many Organisations (Such as Umbrella company 1, 2 and 3).

From these Organisations, they have many sites (Such as Company 1, has site A, B, C)

If a customer logs the incident, we want this incident to go against a specific Organisation and Customer level for service reporting.

All of these Umbrella companies have the same email domain, so no distinguishing what site they come from, so this will have to be picked up from the email text.  Any staff member can report the issue via email, so they will not be able to access our JSM platform.

We want these tickets to fall into an open queue, and then we can assign these incidents to that customer (or do it automatically)

Current Flow not using JSM

Customer emails generic support inbox

Details are taken and a incident created against the relevant customer AND site

Ideal flow would be

Incident reported

Assign incident to Customer and Site

Resolve

Close

Report incidents at a site level.

Is this achievable with JSM and is there any documentation for setting up this type of helpdesk?  Or would we have to use a custom field containing all organisations and sites and use these custom fields for reporting purposes?

Kind Regards

[Jovin · Accepted solution]

Hi @Damon Johnson 

A great challenging question to say the least, so I'll summarise the scenario first before going into possible solutions for you to explore.

Scenario:

• Support is offered to multiple companies/sites under a single Umbrella
• All companies/sites use the same domain
• All support queries are directed through email only, no portal access

Desired Outcomes:

• All tickets will be assigned to the correct company/site
• This should be "automatic" allowing:
  • correct allocation to resources
  • correct service management reporting

Okay, some possible solutions in terms of difficulty, starting with easiest: 

Allow portal access and require customers to fill in the information

In it's simplest form, force customers to use the Portal and fill in those details from dropdowns. 

Leverage multiple service projects inside JSM with multiple service email addresses

Meanwhile this one is "messier" in terms of the backend, it is the easiest way to split out the different companies and sites.

• JSM just like normal Jira leverages "projects" to group work. This also dictates the structure of the ticket numbers, for example, in ServiceNow you may be used to having INC1234 for incidents and CHG1234 for changes. In JSM it's project based, so "Company A Site 1" might have tickets like CASO-1234 while "Company B Site 2" might have tickets like CBST-1234. You can decide what the letters are - it's not prescribed.
  • For this, you'd have 1 project per "Company" inside UmbrellaCorp (e.g. Company 1 = ACME-1234, Company 2 = HALO-1234 etc.)
• Within each JSM project you can have up to 10 "support emails" that people can contact on. In it's simplest form this would just be support@company.atlassian.net (or link your own mailbox) and all tickets would be the same type. Alternatively, you could split this into requests@company.atlassian.net and incidents@company.atlassian.net to have differentiation between requests & incidents. You could further split these emails into the "sites" within the company, e.g. acme-site1@company.atlassian.net, acme-site2@company.atlassian.net

Use a single service project and have your agents identify the correct company & site

This requires more manual work by your agents, and would instead only allocate them to the correct company after someone has raised an issue.

• Option 1 for this: Organisations (Warning: Has Sharing Implied)
  • Inside your "Customers" you can have something called "Organisations". Think of this as a way of grouping your customers. You can normally assign a domain to these so customers are auto-added, but this won't work for you.
  • Instead, your agents can manually assign the customer to an organisation, and then assign the ticket to the organisation as well.
    • NOTE: This means everyone in the Organisation can see the ticket and it may be undesirable.
• Option 2 for this: Custom fields
  • You can configure custom fields to denote the Company & Site, such as a cascading select list.
  • This would allow you to configure Company A has Site 1, 2, 3; while Company B has Site X, Y, Z.
  • This would need to be manually assigned to issues, unless you have "Customer Details" enabled in the features, and your agents manually assign the customer. From there an automation could automatically retrieve this and update the ticket details accordingly.

Use Automations & Regex/NLP APIs to determine Company & Site

This one is complex and potentially error prone but could automate the allocation of company & site.

• On issue creation you can look for certain regex values in their signature or text to infer the company & site, if it misses it, you can then leave the values blank.
• You could further extend this to have the automation send a request to a natural language processing API and infer what the company and site are, this would need to consider the implications of public interfaces etc.

[Damon Johnson]

Hi Jovin,

Thank you so much for the comprehensive reply.

I will take this away and see what the best fit is for our set up.

Kind Regards