Hi guys,
I've been reading a lot about departments and teams and how these would need to be used to reflect the helpdesk usecase we're trying to set up via OST. I've hoped to solve this one by myself but can't seem to nail it down...

So I've decided to turn to the community for input and advice 😁 Perhaps someone out there could show me the light!

Our NGO has various operations around the world with various technical areas that require HQ support (.ie Telecom, Biomed, Energy). Each operation is managed locally by a coordinator.
When a ticket is created we would like to have a first level of support that is taken care by the local coordinator. This first level of support can either directly solve the ticket or "forward" it to a second level of support which is essentially the relevant group of technical expert located at HQ. Then someone from this group claims the ticket and solves it.

I thought that by having a transfer of department this could be the right setup (ie. Department Local Coordinator --> Department Energy Support), but our issue is that the local coordinator should remain in the loop and be able to jump in at anytime (write a public/private note, close the ticket) while the ticket is being worked on by the Energy expert(s)...

The element that makes it a little complicated is the ticket access rule we want to have:

  • the local coordinator should able to keep track of any tickets that are being sent from his operation, but they cannot see anything that is sent from other operations...
  • (once the ticket is forwarded to them) the experts should be to see all tickets that concern their technical domains, and they should not be able to see tickets that are concerning other domains...

So essentially, one type of agents should be able to see cross-operations, while the other type should be able to see cross technical domains...

How can I reflect this is OST? You feel my pain? :-/

Thanks in advance to anyone who even bother reading this long individual issue!

:-)
Julien

So Departments.

If I am reading your description correctly you have a bunch of locations/departments. We do also.

So taking that you have HQ support, Biomed, Energy we would make two departments for each.
You can name these whatever you want, but I feel like giving you names makes the explanation make a little more sense.

Departments:
HQ Support - Tier 1. This department has any tier 1 support folks (ie your local coordinator)
HQ Support - Tier 2.

You would make a Help Topic called HQ Support. This Help Topic will assign the ticket (behind the scenes to the HQ Support - Tier 1.

John Doe (local Coordinator) gets a new ticket in their department. They see that ticket needs to be escalated to get fixed so they would transfer the ticket HQ Support - Tier 2. When they do there is a tick box for "Maintain referral access to current department", make sure that they click it. They will be able to see the ticket after they transfer it to HQ Support - Tier 2.

If you have multiple tier 2 groups for each things at each location you could make more departments for those "groups" of Agents who will be answering and solving the tickets.

For example you could have HQ Support - Intranet/Network (T2), and HQ Support - Development (T2), and HQ Support - Marketing (T2). etc.

Does that make sense?

    Hey ntozier , thanks for taking the time to help us with this 😁

    I wanted to add some details and make sure I am understanding your suggestion.

    Originally, I had set my Help Topics to be each type of technical support the field employee might require (.ie Biomed, Energy, Telecom ...). So this guy would select from the dropdown Help Topic menu the technical support he's needing and then it would load the form, which are at the moment are identical (in the future we might have forms that are more specific to each help topic)...

    But what I am understanding from your suggestion,

    • the Help Topic would just be a generic one (.ie HQ Support)? Then the loaded form would have a field where the user would be able to specify the technical domain for the support he's looking for? Correct?
    • this Help Topic will assign the tickets to the local coordinator using the Filters, correct? + I was thinking of adding a country field on the Users' information which would also be used in the Filters to identify which local coordinator the ticket should be sent to, what do you think?

    Thanks again!

    Julien

    Your Help Topics can stay what you have them.

    ie Selecting Biomed Help Topic would assign the ticket to the Biomed - Tier 1 Department. No filters needed. Look at Help Topics, they can assign tickets to a department. Then your Agent in that department can answer and re-assign if needed.

      ntozier yep, I have seen that.

      But I am still not sure I understand the set-up you're suggesting. I am sorry 😅

      May I rephrase with an example?
      If a member of the staff in Congo faces a Biomed issue, he opens a ticket selecting the Biomed help topic. This tickets assigns the ticket to the department in which the Congo coordinator is located. Other coordinators, ie. South Sudan, should not be able to see incoming tickets from other countries, so I believe that our first tier of departments should be categorized at country level. Would this mean I'd need to have my help topics be the countries?

      But then once the coordinator escalates the ticket to the Biomed experts by changing the Department, he should remain in the loop (this would be done via the referral checkbox - though I think this would only give him a read-only access...). This Biomed Department (tier 2), should not be able to see tickets from Congo that concern another technical domain (ie. Telecom), in contrast they should be able to see/receive all ticket escalations that concern Biomed (ie. that come from South Sudan). This would mean that our second tier of departments should be categorized at technical domain level, like you explained in your answer (ntozier).

      Hope I am not asking too much!

      I really appreciate you taking the time to help me out with this!
      Cheers!
      Julien

        JuVDC Hey - lets just say I frequent these forums. I too worked at a NPO (IT Director). Basedo n what your now more detailed request is I'd suggest the following:

        Department: Congo-Biomed Support - Tier 1. This department has any tier 1 support staff (ie your local coordinator in the Congo)
        Department: South Sudan-Biomed Support - Tier 1. This department has any tier 1 support staff (ie your local coordinator in the South Sudan)
        Department: BioMed Support- Tier 2

        It has been a while but I'd need to check the ticket routing by team because the alternative setup to this would be:

        Department:

        • Biomed Support
          -- Team(s):
          ---Tier 1- Congo Bio-Med Support
          ---Tier 1- South Sudan Bio-Med Support
          ---Tier 2- HQ Bio-Med Support

        As per your granular question about access permissions - that is all under the access tab and settings. To simplify this answer - agents are only given access to other departments tickets IF they have permissions to do so. Given that you're dealing with multi-location with multi-departments (deployed osTicket twice with that setup) I really do suggest that you get osTicket installed and then begin to map out (based on org chart AND call flow) your Departments, Teams & Access levels of each.

        Hey @Rich_C !

        Thanks a lot for taking the time to help me out! Really appreciate it.

        This definitely gives me some ideas!

        Just a little clarification on the process based on your 1st suggestion, how would you see an incoming ticket being handled?
        --> A Biomed ticket gets submitted in Congo
        --> It gets automatically assigned to Department: Congo-Biomed Support (where Congo Coordinator is placed)
        --> Congo coordinator needs to escalate, he/she assigns Biomed Support?
        --> How would the Congo Coordinator keep full access to the transferred ticket without being able to see South Sudan tickets? Adding him in the Tier 2- HQ Bio-Med Support would give him access to South Sudan tickets I think..

        For the team set-up, I am curious! Do you think you could expand a little?

        Thanks!

        Julien

        Well typically in most organizations Tier 1 is the "gatekeeper" so as odd as it sounds they usually have access to MORE than tier 2. Especially in your case. So my suggestion would be that the coordinator should be given permission to all of the tier 2 tickets.

        I have a series of meeting to run - I will respond to the teams question once I am done.

        Hey @Rich_C , thanks for your help!

        With a bit of play around with teams and thanks to your suggestion, I think I've managed to lock down a workflow that answers what we're looking for.

        1st Tier:

        • Department Congo
        • Department South Sudan
        • Department Afghanistan
        • etc....

        2nd Tier:

        • Department Energy + Team Energy
        • Department Telecom + Team Telecom
        • Department Bio-med + Team Bio-med

        1/ So basically our first tier of support is handled by departments where each are defined by the country from which tickets are coming from.
        --> so for instance if someone based in Congo submits a ticket (field defined on the user profile), the ticket gets linked to Department Congo (where our local coordinator belongs to).

        2/ There if the ticket needs escalation, the coordinator assigns the relevant Team, while the department remains unchanged.
        --> ex: assigns Team Energy

        Now the ticket is visible both by Energy agents and the local coordinator. according to the roles defined by their primary department. An Energy agent can claim the ticket, while the ticket remains visible for his Team and the local coordinator (as explained here).

        I'll give this some more testing, but I think this might be it.

        😁

        Sounds good to me. I'll leave this thread open for now. Please circle back when you finish testing to let us know.

        Write a Reply...