Using Service Desk Day to Day

[HH]

Hi, 

I'm hoping you can offer me some advice. I'm currently on the 30 day trial of the IT service desk. I work within a university and we'd like to use the Service Desk to replace our current software. 

I've set it up, and it all looks good, but my question is around the day to day functionality. Could be that I'm just missing it in the docs that I've read - or that what we're trying to do is overly complex. 

Having looked at the demo I've been assuming that each team within our IT department will have their own queue. So Databases, Web, eLearning etc. Then a group of users will be assigned to that queue. 

Scenario: 

User raises a ticket

Ticket goes into the correct queue in the back end. 

Service Desk staff assigns that ticket out to the correct queue. 

What I can't seem to see is how on an incoming ticket it would be marked with a ticket field to indicate to the service desk to which department it would go. I was expecting to see hidden ticket fields where when passed through they would be marked with "email" or "web" so that it would be obvious to the service desk that this was a certain category of request/change/incident etc. 

Would my approach be correct for a large organisation? Any advice as to how you've done it would be greatly received!

Could be that I've got completely the wrong end of the stick, so if someone could point me in the right direction that would be great! 

Thanks!

[Jack Brickey]

Hi Hollie, welcome to the forum. I think you will find JSD to be very flexible and there are different ways to address your needs depending on what works best for you. Invariably, I have found that this flexibility coupled with my experience level to result in setting things up one way only to change that in time as we learn how we really use the system.

That intro aside let me see if I can add some input building on Henri's.

General Input:

My first 'best practice'  advice is this - Try to get your customers to use the Portal to open and monitor issues as this will give you much more control over how tickets are opened and initially allocated. If emails are going to be used then you will want to put a "triage" process in place whereby your agents will inspect incoming issues and update the necessary fields to move the ticket along its way. The more tickets that come in thru the email channel the more your agents will have to triage.

Allocating issues to various queues (Database, Web, eLearning, etc)

There are two ways I would look at doing this:

1. Component Field (work group = queue = Component)
   1. if the Portal will primarily be used then you can expose the Component field and make it required. Granted the requestor may get it wrong so your agents will have to be educated so that they can quickly change the component, redirecting to the proper queue.
   2. if email will be used in any capacity to open tickets then you will not be able to expose the Component to the customer.
   3. Define your queues based upon component
2. Request Type
   1. If you don't have a lot of queues then you can simply define a request type for each.
   2. Again this does not work for email channel as there is a 1:1 relationship between an email channel and request type. TIP: if you use email channel you may want to dedicate a request type to it alone and hide it from the portal.
   3. Define your queues based upon request type

For my purposes I use a combination of these methods. On the surface it seems that you might benefit for #2.

One last comment on the "triage" process, I have all my groups own triaging the incoming issues. I have a Triage queue that basically looks for Assignee is Empty. My agents collectively monitor this queue and keep it empty. They ensure the important fields are accurate and assign the issue to the proper person/group.

Hope this helps or at least doesn't confuse your further. 

cheers,

j

[HH]

Hi Jack,

Thanks for your answer!

We are going to have incoming tickets via email. We have pre-existing forms that can't be moved that will need to be emailed in when they are completed. We'll also have users who'll need to raise tickets via email rather than through the portal in the first instance. From your reply I'm given to understand that we won't be able to add in the correct component field needed in order to pre sort these?

You mentioned pre-defining a request type for email channel and hiding it from the portal - that sounds like a good solution as if I understand correctly we could specify that all of those request types would be funnelled into our General SD queue and they could be assigned out from there? I've turned those on so they can be seen in the queues and they look good - can they be changed and re-assigned manually? Presuming so, just can't see it in the admin side of things!

We're going to need about thirty queues as we have that number of teams - but we'll likely have multiple request types for multiple teams. E.g. the DB team might have a server request form as well as a server access form. Is it supposed to be one request type to one queue?

So I think I might have a better grip on things now, and this would be how I would see it working now: 1.Portal requests are all different request types. 2.Each request type when set up is assigned to a specific queue (do you know where I specify that in the set up? I can't seem to find it!) 3. All request types that come in via email would have to go to the SD general queue to be sorted.

Sorry for such a long reply and picking your brains!

Thanks!

Hollie

[Jack Brickey]

Hollie,

i have included answers to questions you posed to both Henri and I here. ultimately, i simply had to stop typing here as this has become more of an initial design discussion than answering a question and I fear I may be confusing you. As such, I'm happy to have a phone call and even screen share if you would like. JLMK

As Henri mentioned in the beginning, "queues" are really nothing more than a view or more appropriately a filtered list of your issues for a given project. You can have multiple queues for a project and depending on how they are defined there can be overlap. Here are some examples of what I do but your needs may be different:

• Triage - all incoming tasks that the collective team of agents is directed to monitor hourly to redirect to the appropriate team that will work the issue to closure (JQL basically equates to assignee=unassigned)
• Agent A or Team A - all issues to be addressed by that person or team. I have a very small team of agents (3) so I simply have a queue per person but this can be a group of agents. (JQL assignee = fred or....assignee in membersOf("group") where group is a pre-defined list of users)
• All Open - a queue that allows you to see all open issues across all agents/groups
• Recently Closed - use is obvious
• Assigned to me - use is obvious

Some of the above are setup by default when you create a project.

The difference between queues and project:

• Queues are filtered lists within a Project
• Projects - this depends on your scenario and can be defined however best fits your needs. A project might have a beginning and an end (I want to build a raised garden in my back yard) or it might have no foreseeable end (iPhone Support).

Without better understanding your situation it is hard for me to decide on the best path but will offer the following.

In my use of JSD I have three current Projects: IT, Facilities, Staffing. While these could be all under one project they are really unrelated and the organization structure is such that it makes sense to have them in separate project. There are lots of other reasons but won't go into them here. In your situation where you speak of 30 teams/queues, while it may be useful to break into a handful of projects it is highly unlikely that you would create 30 queues. Think about how management wants to monitor and report on issues. If they want to roll everything up into a singular view (dashboard, reports, etc) then maybe a single project is best. Hard for me to say for sure w/o speaking w/ you and having a Q&A (open to that if it would help).

Custom fields don't require plugin. they just get created and then you can add them to the portal.

Forms topic - If you cannot simply replace the need for these forms by integrating the required fields into JSD then that means you will need to handle via an attachment. The user would need to complete the form in whatever application then attach to the email or w/in the portal. Note that JSD is not going to be able to parse the form and take any action so it will be left to the agent to deal w/ as necessary.

Email topic - in fact i misspoke earlier and you may be able to accomplish what you want by parsing the text in the email. I happened to run across this under the Automation feature (project>project setting>automation>Triage request sent by email). I have not used so can't speak to this in detail but worth a try.

Pre-defining request type for email topic - Yes this is a good method for triaging email requests and you will be able to reassign as desired. Also, test out the automation stuff i mentioned above.

Request Type in portal - regarding whether the request type aligns w/ your queues, to be honest I would need to discuss w/ you to give you an opinion. I can say that having 30 different request types on the portal seems excessive. While you can group things in the portal and this will help it still seems excessive.

[Henri Volk _amily_]

Hi Hollie, new to Service Desk as well, but let me try to help

If you say: >> "each team within our IT department will have their own queue. So Databases, Web, eLearning etc. Then a group of users will be assigned to that queue. "

Do you mean queue or Service Desk project? For a queue AFAIK you cannot assign users through the application.

>> User raised a ticket...

How will they do that? You can enable my email or by creating a ticket through the portal. Or directly if they are JIRA users with a license. If you go through the portal, you can of course by the type of ticket / fields you present  make a categorizaion that sends it to the correct queue (btw, a queue is more or less like a view). I don't think you can have a ticket field if a request is sent via email.

You also may stat if you plkan to use the cloud version or the server version since there slight differences (we are using server).

Best

Henri

[HH]

Hi Henri,

Thanks for your reply - just wondering if you could tell me the difference between a queue and a project! I don't think I've seen this in the docs anywhere - tho I'm probably just missing it!

Can you have multiple projects set up per instance of the SD? So we'll have around 30 queues - can we have 30 projects set up? 

We'll probably use the server version.

We're also going to need some custom fields in the portal, which I haven't seen documented anywhere and seems to require an additional plugin. Have you used that?

Also just wondering if you could tell me how forms/views are filled in if they aren't viewable on the portal? I can't seem to locate them in the admin side of things, so was unsure how these ever get filled in!

Sorry if these are really obvious questions!

Thanks, Hollie