/build/static/layout/Breadcrumb_cap_w.png

Service Desk queue view by submitter's department or location?

Is there a way to create a custom queue view that uses submitter information? We have a large group of desktop support staff who are assigned to specific buildings. They share a single queue. They would like to be able to sort by (or at least see) the submitter's location displayed in a column of the view. It looks like you can display the submitter or submitter username without any trouble, but not their location or department even though our LDAP import captures that information and adds it to their KACE user account. I suppose one approach might be to create labels for the different locations and group the users that way? Or perhaps a rule can be used to populate a ticket filed called "Location" ? While it is possible for the Service Desk to select a location from a drop-down list, I suppose that is a manual workaround that would provide a field that is available in the queue view. Another solution, the one that management favors, is to create a separate queue for each location and leave it up to the Service Desk staff to assign the ticket to the correct queue. I don't like this approach because I'm the Service Desk Manager and I thinks it's a better practice to have a single shared queue for them, so someone who is available can take a ticket even if it isn't in their location. That way the customer gets prompt service by the next available consultant instead of having to wait for the one assigned to them to be available. I would appreciate any thoughts or suggestions.Sean

1 Comment   [ + ] Show comment
  • If you are familiar with writing mysql you can write a ticket rule to try the following to automate it but you would need a custom field called location created

    1. Using LDAP Labels you can create USER LABEL and assign them to people as they log into the KBOX USER PORTAL. (LDAP current isn't working due to a bug that KACE is aware of)
    2. Create a ticket rule that looks at the label the USER has and then auto populates that in the location field so your techs don't have to do that.

    Another is you could create one queue that all users see and then someone moves the tickets to the correct queue for the building behind the scenes.

    I will be honest, your statement about having a single queue and anyone who is available can take the ticket seems to negates what you are trying to accomplish.

    ORGS are another way but you don't need to create completely separate KBOX instances for each building. - nshah 9 years ago
    • Thank you for the suggestions. Our old system had separate queues for each of the teams, but these are only two person teams. It was extremely burdensome for the Help Desk staff (who deal in much higher ticket volume) to keep track of which team does what in Desktop Support (it changes frequently). It also resulted in tickets being routed to teams and sitting for days because both team-members were unavailable. So I would rather just have one queue for them and then let their staff sort it out. A couple of their staff are not fond of this approach, so I told them I would do what I could to make it easy for each team to recognize their own tickets. Their teams are supposed to help each other out, so I think it will help even out their workload in the long run... and it will help avoid tickets sitting around when the staff for that team are not available.

      I like the idea of creating a user label, but most of our users will never login to KACE... at least not initially. The majority of tickets are entered by student-staff answering the telephone. If I could assign the label upon LDAP import that would work, but that is the part you say KACE is working on.

      The compromise we may go with for now is to require that the Help Desk staff who enter the tickets use a standard format for ticket Title that includes a brief description of the ticket, the submitter's department, and the submitter's location. That way the department and location information will be visible (as part of the title) in the queue's list view, along with fields like Submitter name, category, etc.This approach is a little cumbersome for my staff, but not nearly as cumbersome as trying to figure out what to do with a ticket when both members of a two-person team are on vacation.

      Sean - anonymous_110381 9 years ago

Answers (1)

Posted by: Chris.Burgess 9 years ago
Orange Belt
1
One of the things you can do is create an SOP where the tech changes the TITLE to include the location.  Then you can use the Custom View.



For example, if one of your locations is BUILDING1, then your techs would include that somewhere in the Title of the ticket (beginning or end) and set the custom view so that "Title Contains BUILDING1"   

I believe you can also use the "ADD GROUP" button to make multiple custom views, one for each location, and then have the system group them together for you.


Comments:
  • Thank you Chris. We did decide to include the building information in the title field, so it shows up in the queue's ticket list view. The custom view idea is a very good one as well. Personally I think it will be better for the customer if all of the desktop techs see all the tickets. That way they can take a BUILDING1 ticket even if that's not their area, but they know that one BUILDING1 tech is out sick and they other is busy with an office move.

    However, if they really prefer to filter things down to just their buildings, they can do that as long as it's okay with their manager. At least he will be able to see all tickets in the queue. He likes this approach as well, because it's only one queue for him to monitor.

    Sean - anonymous_110381 9 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ