Service Management configuration for multiple customers

[Randolph Voorhies]

Overview

I work for a warehouse automation company, and we install hardware and software at many dozens of customer sites around the world.  Each one of our customer sites runs on a completely separate server, typically has a variety of customizations and may be on a different software version from other customers.

I would like to fully embrace Jira Service Management for all of our customer requests, change management, and incident responses.

Question

Has anyone successfully implemented JSM in this kind of environment where you have many completely separate customers?  I'd love to hear about your successes and failures in how you set things up.  For instance, what works better - one big project with a field to indicate which customer a ticket is relevant to, or a separate project for customer (or even per site)?  Have you found any good end-to-end tutorials that were useful to you?

[Fabrice Huart - NSI · Accepted solution]

Hi @Randolph Voorhies ,

Hope you are doing well. Great question that can have different kind of answers.

From my experience :

• In Jira Service Management, you'll need to use the "Asset" features to keep track of a lot of information (customer company information, contacts, related infrastructure, applications, contracts, SLA's, etc... ).
  At the point you can already think to split each customer in their own "Object Schema".
  You don't want to mix information from multiple customers in the same "place".
  Nevertheless, splitting in multiple schema also have some disadvantages in the way you setup assets and fields related to them, reports, automations, etc ...

• Regarding the portal
  • if it's the same "Catalog" that you offer to your customers, one single portal can be an option and you manage forms information through assets or automations based on the connected person.
    Nevertheless, pay attention, is it the same flow, same requests, same SLA's for all customers for example ? If this vary a lot creating dynamic forms can have limits
  • One portal per customer is really more time-consuming to setup.
  • A mix of both can sometimes be an option also :)

• Regarding documentation in Confluence, you can have global, customer specific or internals teams documentation. So you can also there split information between multiple spaces in Confluence and define a structure and governance.

I don't have a "one rule them all" answer, this need a more deeper analysis to define the good governance and structure to setup based on your goals and limitations (compliance rules, legal rules, ...  can also impose some rules that impacts the setup) .

Best regards,
Fabrice

[David Friedrich]

@Randolph Voorhies Welcome to the community!

It depends on the plan you have. If your using JSM premium I absolutely agree with @Fabrice Huart - NSI . Using the asset feature as a CRM database showing your agents all the relevant information about the customer directly in the ticket would be a good help.

If you can not use assets (yet) splitting up your customers into various service projects might be an option, especially if you need different SLAs per customer.

That being said. please keep in mind that unfortunately it isn't possible to have cross project queues out of the box, but there are apps for that.