Structure of first level support and 3 departments

[Linda B_]

Hi,

I'm working on implementing a structure in JSM for our three departments and need some assistance with choosing the right approach. We aim to make our new helpdesk (currently on the free plan, moving to the standard plan later) resemble the functionality of our old system in OTRS. We have three departments plus students handling first-level support.

Our workflow was as follows:

1. First-level support (FLS) received emails in the RECEIVED MESSAGES queue.
2. If FLS could resolve an issue, they would move it to the L1 SOMETHING queue and work on it, changing agents as shifts changed (thus changing ticket ownership).
3. If the ticket needed to be escalated to L2 or L3, FLS would move it to the appropriate department-specific queue.
4. Departments are divided into multiple parts (e.g., systems, network).
5. If a department queue agent identified a misassigned ticket, they could return it to RECEIVED MESSAGES for re-sorting by FLS.

The challenge is that the L1 SOMETHING queue (e.g., L1 Network) was part of the department, allowing the supervisor to track issues within their domain.

I'm considering creating one project for FLS where they can sort incoming tickets and then possibly label them. The label could correspond to our old queues, like L3 Network. The FLS agent would label the ticket and then move it to another project, such as DPT 1. I need to know if the label would persist (is there a global label feature?) and if it's possible to create labels via the customer portal (based on the problem they select) to bypass FLS.

The supervisor role should be able to make statistics from multiple projects based on the ticket label. For example L1 network (FLS project) + L2 and L3 Network(DPT1 project)...is that possible?

We also have an option for automation but are concerned about the 5000 operations/month limit. With 650-1200 tickets per month, I'd prefer a maximum of three non-system operations per ticket. I'm worried that if FLS mislabels a ticket multiple times, it could result in excessive operations (e.g., ->|<-|->|<-|->). Is it possible for automation to be portal only?

What approach would you recommend? It's possible that I'm thinking about this incorrectly due to our old system and my inexperience with attlasian products...

Thank you very much for answer!

[Christopher Yen · Accepted solution]

Hi Linda, the automation limit is quite unfortunate but I'm wondering if the labels/automation could be reduced by having the teams live within one service project but use a team field to define ownership that can be used to escalate without automation rules moving the issue between projects. 

So after L1 troubleshoots and needs to escalate they can simply change the team to L2 and remove themselves as an assignee to escalate the ticket. 

We use a services/system field on our customer portal to help with auto routing to the correct team and then once received any escalation or rerouting we handle with a team field and our queues/reports are driven by that field. 

[Linda B_]

Thank you, that sounds like an interesting solution. We can try that!