1 project with multiple customers or multiple projects with 1 customer?

[Rob McBride]

Hi

I am new to JIRA service management, so apologies for a potentially simplistic question.

We are a Cyber Security Managed Service Provider and we are setting up a Security Operation Centre using JIRA service management.

I notice that there is a new Customer feature within JIRA Service Management and I would like people's views on whether it would be better to have:

A. 1 project for each customer; or

B. 1 project with multiple customers assigned to it.

Although there are lots of similarities, each customer will need its own custom portal and each customer will probably need its own inbound support email address (unless we can filter using the sent from domain).  I would also like to be able to track time spent supporting each individual customer.

Given the above requirements, I was thinking that individual projects will be better, but operationally for our team it might be better to have 1 project.

Please can you share your thoughts.

Many thanks

Rob

[Valeriia_Havrylenko_SaaSJet_AbcSite · Accepted solution]

Hi @Rob McBride 

Whether to create separate projects for each customer (Option A) or have a single project with multiple customers (Option B) depends on several factors, including your operational needs, the volume of customers, and the level of customization required. Let's delve into the pros and cons of each option to help you make an informed decision:

Option A: 1 Project per Customer

Pros:

1. Isolation and Customization: Each customer gets their own dedicated space (project) which can be customized according to their specific needs. This includes creating a unique portal, custom workflows, SLAs, and email channels.
2. Enhanced Reporting: You can generate specific reports and metrics for each customer, offering better insights into their support history, issues, and resolution times.
3. Security and Access Control: Customer data is isolated, providing an additional layer of security. You can control access to each project more easily.

Cons:

1. Project Management Overhead: Managing multiple projects might require more administrative effort, especially if you have a large number of customers.
2. Learning Curve: Your team might need to switch between different project contexts, which could lead to a steeper learning curve.

Option B: 1 Project with Multiple Customers

Pros:

1. Simplified Management: One project simplifies administrative tasks as there's only one project to manage, which can be beneficial if your team resources are limited.
2. Easier Cross-Customer Reporting: Overall performance metrics can be gathered and reported across all customers, offering a broader view.
3. Efficient Resource Allocation: Team members can work on issues for multiple customers within the same project, potentially optimizing resource utilization.

Cons:

1. Limited Customization: You might face challenges in providing a highly tailored experience for each customer, as they'll all share the same portal, workflows, and configurations.
2. Security and Data Isolation: You'll need to ensure that customer data remains properly isolated, and access controls are set up meticulously to prevent unauthorized access.
3. Potential Confusion: If not organized well, tracking issues and managing different customers' needs could become confusing.

Based on your requirements, it seems that Option A (separate projects for each customer) might be a better fit. It allows you to provide a more customized experience for each customer, which is crucial in the realm of Cyber Security Managed Services. However, keep in mind that this approach could entail more administrative overhead.

To address some of the operational concerns with Option A, consider implementing a standardized workflow template that can be reused across projects, which could help streamline your team's processes.

Ultimately, your choice should align with your business priorities, resource availability, and the level of customization you're willing to provide to each customer. It's always a good idea to start with a pilot approach and iterate based on your team's experience and feedback.

Remember that every organization's needs are unique, so adapting these options to suit your specific context is key. 

Good luck with your Security Operation Centre setup using JIRA Service Management!

Regards, 
Valeriia

[Marko Schneider]

Hi!

We're currently evaluating JSM for our external customer facing services.

Thank you very much for the pros and cons of these two approaches!

I think we also need "One Customer" - "One Project". One additional aspect though:

We're migrating from a different Service Management solution where it was possible to define services (and the appropriate costs, billing, SLAs etc.) and associate these services with a customer.

How can this be done in JSM? Is it possible to define services (one time) and use them for multiple customers?

Again, thanks for the list of pros and cons!

[Emre Toptancı _OBSS_]

If each customer needs its own portal and inbound e-mail address, the choice is obviously 1 project per customer. However, your choice might also be affected by your team structure. Do you have customer-oriented teams? Or service-oriented teams? maybe location-oriented teams?

Personally, I suggest you go with a structure based on your customer-facing services. One project/portal for each customer-facing service. Your internal teams only have access to projects for services that they contribute to. Your customers see the projects (and portals) only for the services they purchase. Since Jira's customer portal search bar can search for request types across projects/portals, the experience for customer end-user will still be good.

[Mark Segall]

Hi @Rob McBride - While both are possible solutions, I would recommend a single project approach.  Here are the pros/cons of both.

Single Project

• Pros
  • Easier for the agents as they can have one place to manage all work coming in as well as a centralized location for managing request types (If you split projects, every configuration change becomes multiplied as you have to make the change in each project).
  • By design JSM provides a logical split where portal users cannot see each other's tickets.  You can also leverage Organizations to enable customers from the same organization visibility into each other's requests
  • You're on Premium so you can leverage assets to provide even more functionality (e.g. customers from organization 1 are always assigned to agent(s) A
  • You can leverage automation to help populate a custom field with customer affiliation for your reporting requirements
  • Once everything is configured, it's pretty much a set and forget configuration.
• Cons
  • There's more upfront work to get everything configured
  • Your email requirement is more tricky but doable - You could have multiple emails forward to the project email address and then you could set up automation based upon the domain to automatically set the organization. 

Multiple Projects

• Pros
  • No need for additional custom fields - The project key can serve as the delineation needed for reporting.
  • Email configuration is simpler as each JSM project has a unique email address
• Cons
  • More overhead for agents
    • The queue experience would either be overly complex requiring multiple tabs being open or completely ignoring queues in favor of a cross-functional dashboard.
    • Multiple projects means multiple points of entry so client messaging becomes more complex (e.g. If customer 1, send them to link 1, if customer 2 send them to link 2, etc.)
  • More overhead for project admins
    • Every new client would require additional project administration overhead vs empowering agents to update the customer/organization list on a Single proejct
    • The solution will quickly encounter scalability issues as each time request types, help text, etc. changes are required, every project would need to be touched vs a single update