Using Service Desk Day to Day

Question

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 · Answer

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.

HH_brlcp1 · Answer

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

HH_brlcp1 · Answer

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