Best practice for a multi-tier customer support team

[Patrick Wacher]

Hi,

I've been out of the Jira loop for many years and would like to ask for feedback on how best to structure a JSM project. I'm sure this support structure isn't unique, but just trying to get my head around it.

For context,

• there are two support teams, Tier 1 & Tier 2.
• Our internal customers escalate to Tier 1, this is the only team that interacts direct with the customer.
• Tier 1 will escalate an issue to Tier 2 for additional help. Updates should only be between 1 & 2. Customers should not see this interaction.

What would be the best setup here? Separate project for Tier 1 and for Tier 2 or can this be accomplished within a single project?

Thanks in advance!

[Kai Krause · Accepted solution]

Hi,

When deciding how to structure Jira Service Management (JSM) for a two-tier support model, there are a few considerations to keep in mind:

1. Visibility and Communication Flow:
   • Tier 1 is the only team that communicates directly with customers. Tier 2 is a backend support team that offers expertise and further troubleshooting, but their interactions should remain internal.
   • If you opt for a single project, you need to ensure your request types, issue types, workflows, and permissions are configured in a way that separates internal communication (Tier 1 ↔ Tier 2) from customer-facing updates. This often involves leveraging internal comments vs. public comments or creating custom fields/automation to ensure the right details remain hidden from the customer.
   • If you choose multiple projects (one for Tier 1, one for Tier 2), you can keep customer-facing support limited to the first project while using a linked issue in the Tier 2 project. However, you need a process to keep them in sync and ensure that updates flow smoothly.

2. Workflow and Automation:
   • Within a single project, you can use issue security levels or comment restrictions to hide certain fields. You can automate transitions, so that when Tier 1 escalates to Tier 2, the issue transitions to a status and notifies Tier 2. Just be sure to handle comment visibility (internal vs. external) carefully.
   • With two projects, you might automate the creation of a linked issue in the Tier 2 project for deeper investigation. Tier 1 remains the “owner” of customer-facing communication, while Tier 2 is resolving the separate ticket behind the scenes. You lose a bit of simplicity this way, because you now have two tickets to track, but you also gain stricter data compartmentalization.

3. Permission Schemes and Roles:
   • If you keep everything in one project, you will need a well-designed project permission scheme to ensure that Tier 2 can access everything they need internally, while allowing Tier 1 to continue customer communication. You must also restrict customers’ ability to see internal comments.
   • If you create separate projects, you’ll maintain separate permission schemes. Tier 1’s project would allow customer sharing, while Tier 2’s project would be strictly internal, reducing the chance of accidental customer exposure. However, it adds complexity with cross-project links and possibly dual administrative overhead.

4. Reporting and Metrics:
   • A single project may offer a simpler “one stop” for reporting. You can track escalations and resolution times from one project’s perspective, though you’ll need to carefully design your workflows to capture the escalation events.
   • Two projects can make it easier to measure Tier 2’s performance independently, but you’ll need to merge data if you want an all-up view of the entire support cycle.

5. Scalability and Maintenance:
   • If the organization is small or new to JSM, a single project with properly set up issue types and permission/comment restrictions can be simpler to manage.
   • If the organization is large or expects frequent expansions, separate projects might offer a clearer separation of duties, easier administration for each team, and more robust scaling options (e.g., different SLAs for Tier 2).

Overall, you can achieve the desired setup with either option. For many teams, a single JSM project with well-designed workflows, internal comment restrictions, and correct permission settings can keep the process simpler and still ensure privacy for internal escalations. If your organizational requirements or compliance rules demand that Tier 2’s work be completely separate, or if you need advanced and independent analysis of Tier 2 performance, then two separate projects would be more appropriate. It ultimately comes down to balancing administrative complexity with the need for secure, efficient collaboration between Tier 1 and Tier 2 teams.

It depends, as always on your Requirement. Hope it helps to come to a decision 

BR
Kai

[Patrick Wacher]

Thanks Kai, very much appreciated the detailed response. This gives me a lot of good context for my next steps.

Regards,

Patrick