Luke, I can tell you some of these answers from my experience but which reports are useful depends on your policies and what you are trying to measure and/or improve.
1. Most help desks have a published service level policy that would cover this. Policies generally cover things like how long users should expect to wait for help with certain issues as well as items like this. Some help desks leave them open forever, some have a stated policy that after a certain number of failed attempts at reaching them, like 3, or after a certain period of elapsed time after the last attempt, 2 days or 2 weeks, then the work order is closed and the user notified that its being closed and to contact the help desk if they need more help.
2. Most help desks allow users to generate their own and also enter tickets for work they are performing. This keeps a measure of all work done by the IT staff.
3. This depends on your goals. There are quite a few useful reports included with Track-It! and with Crystal you can do about anything so the sky is the limit.
4. Most help desks have a policy that they create a ticket for every call, email, walk in, etc.
5. Projects can be kept in Track-It! no matter how long they take. If you assign seperate assignment work orders for each task for each person who needs to do work, you get a good record of all the work that each user performed for the project as well as the overall work the project required.
Hope this is helpful. I am sure others may do things differently and will comment. No 2 help desks are exactly alike.
We are preparing to deploy Track-It! so these answers are based on our previous tool, but should relate for the most part.
1. Our policy is to make two attempts to contact the customer for information, followed by a third notice to the customer, copying the supervisor of the customer notifying them that they have x days to respond or we will 'Archive' the support ticket which subjects it to 'bottom of the queue' prioritization if it is re-opened. We typically wait 4 days between contact attempts to allow for shift cycles. Of course metrics are a problem because looking strictly at the length of time the ticket was open is skewed when this happens. We have toyed with the idea of tracking hours actually worked and logging them, but that puts additional burden on the staff, so we're stumpted.
2. We also use tickets to track our own work. The rule of thumb is that if it requires IT time/resources, it has to have a ticket so that we have a documented trail and proof of our true workload. This is used annually to assist in budgeting and determining needed staffing levels. I have actually told my staff that "If there isn't a ticket for it, then it never happened." a safer version of "Tix or it didn't happen."
3. I have a Crystal Reports Guru on staff and our old HD tool uses Crystal as well so I had him build me a custom report for just about everything I needed, whenever I needed it. None are out-of-the-box reports though.
4. Yes, I require my staff to enter a ticket for every call, request, cellular call, walk-up, hey-you, or anything else they request from us. See #2 above. Even though some calls may only take a minute or two, that is still 'billable time' as an attorney would put it and that affects our budget.
5. I want to track projects in Track-It! I'm just looking for examples and ideas for how others do so in order to setup Track-It! to best do so. I have an open question in the discussion asking for this very information. So far, it seems like many use the 'Priority' field to identify a ticket as a project. Personally, I would like something more robust. Something I will eventually enter as an 'idea' once I have everything up and running and get a feel for what we can and can't do.
Hope this helps.
Does your staff complain of using too much time to enter tickets for calls, walkins, quick questions, etc? Our helpdesk line easily receieves 50+ calls a day (10 hour period), so asking our technicians to always enter a ticket for each call can be cumbersome, especially when also requiring walkins, 'hey you's', projects, normal tickets, and to-dos, on-call pages, etc. It may be something they will just need to suck it up and do, but it would be great to know if you have an efficient/streamlined process for this.
Also, we are a non-profit hospital, so we don't get paid by the ticket, there our SLA only holds half the weight. And the hospital may be shifting to a compensation by performance model, so our manager needs better metrics from TrackIt to identify who is performing above level or just average. Right now he just doesn't feel we can get fair information out until we identify a more meaningful way to handle tickets.
If you are switching to a performance based compensation then I would definitely say enter a work order for everything you do. It may take some time but I think if you took full advantage of templates, solutions (limited as it may be), Track-it web, etc., the time to enter data into work orders can be drastically reduced. We have done this over the past year or so and it has yielded fantastic results.
As far as reports, we typically use the Total work orders by month, Completed work orders by month & Technician. In your situation, the Work Orders closed within 1 Hour would be really useful in your performance based environment.
The success (both with techniciasn and users) of the implementation of a HD system like Track-It! depends largely on three elements:
- How much care has been placed on planning Types, Subtypes and Categories: their choice should be intuitive for users, meaningful and useful for technicians, and not so long and complex that to much time is spent in making the right selection.
- Leveraging the built-it automation and time-saving tools: templates, skill-routing and event policies, mail event policies, and the knowledge base (solutions). All those "FAQ's" and "quickies" should be documented in the solutions module. There can even be "self-closing" templates for those pesky, frequent quickies, where the technician simply applies the right, ready-asnwered template, and the user gets the required answer without further intervention.
- Educating the user base (possibly the greatest challenge all IT departments face when implementing a HD solution for the first time). The fact is, by far the greatest amount of time in an IT department is wasted in answering all those "quick" corridor questions, "this-will-only-take-a-second" telephone calls, and "I need you to come see this" visits.
Once the system is correctly implemented, it really takes a lot less time for the user to check the Knowledge Base, or get an auto-reply; or for the technician to apply a template, than to put something important on hold because we're dealing with a parachute visitor.
Additionally, by insisting that everyone uses the system, we protect the uses because their requests are registered in writing, so a technician can't simply forget it, and we protect the technicians because everything they did or responded (ideally) gets recorded.
It all takes some time, but it is really well worth the effort.
We don't let users choose type, priority, etc. Those are assigned by the technician when he receives the ticket so we have consisentcy. Also, for that reason we don't implement skill routing. I assign tickets based on who can most efficiently complete them, workloads, learning opportunities, etc. If I am out the other techs take over to the best of their ability.
I am not sure if we could design templates to save us time or not. We service over 100 applications, 700 users, over 1000 devices across 15 sites so tickets are often very unique in their priority, type/subtype/category and assigned tech.
I understand the difficulties that you may perceive in designing templates, skill routing policies and event policies. Nevertheless, I invite you to give detailed consideration to these tools, particularly if you do not permit your users to assign type, subtype and category.
If the users do not have access to the order classification, then the classification tree only needs to be practical and make sense to the Service team. In that case, having ready-made templates can save a great deal of repeat work. Even in the most unpredictable environments, you always have common, predictable requests, and also people who are more skilled at certain tasks than others.
Common requests point at templates. Specialized (or higher level) skills point to skill routing policies. Once you have those two elements identified, then event policies help you make the most of your skill routing policies and templates.
For example, why should a tecnician have to create a work order from scratch every time a user requests a password change, a software update, or diagnostics of a recalcitrant printer? Every IT department has cases like that (the "oh, not again!" factor), and it makes everyone's life so much easier to be able just to click on a pull down menu and have most of the required information already filled up!
The idea is not to make absolutely everything automatic, so you don't need a ticket coordinator at all (sometimes, in some places, you can do that - but that's rare). Rather, the idea is to automate anything that is routine, at least to a point, so that the manual operations can be dedicated to those truly unique cases where the ticket must be carefully composed.
I want to pose another question here. Let's say you have a ticket to replace a broken printer. The actual work required only takes 30 minutes, but since you have no spare printers available, you must order a new one, which takes two weeks to arrive. How do you handle this ticket? How do you get meaningful data/reporting out of this ticket?
The issue here is the ticket will stay open for 2 weeks, but the amount of work that was required only took 30 minutes, thus this ticket will skew that technicians average time to complete a ticket. If you stack a handful of these type of issues a technicians queue could appear very large, when in fact his workload is miniscule as he is waiting for parts, vendors, approval, etc. We have ourselves created a 'Hold' status for tickets, indicating we are awaiting for some out of control event to happen (an item to arrive, a paper to be signed, etc), but I don't think reporting can be intelligent enough to excluse days a ticket was in this status.
I agree with Diverst that using the "Hours" field seems to be the best way to handle these sorts of tickets. Ideally it should be possible to have some "stop the clock" status that behaves as a pause, differently from the "close" status... but while this is not implemented, the best workaround is to manually insert the time spent in the Hours field.
1. 1) If a user is failing to respond: the technician will make 2 attempts to contact the user, then contact their supervisor. The 2nd attempt will be by both phone and email. If no reply after 24 hours, the tech will close the ticket with a note and a resolution code of : “Closed – No response”.
2. 2) Technicians also create work orders. Our policy is that a WO is created for anything a technician does. We use it the same way Dennis does in his comment on July 10, 2012.
3. 3) We create custom reports as the canned reports do not meet our need. but we do use them as a starting point.
4. 4) Yes, technicians create “Trouble Tickets” even for phone calls, or walk-ins, where users have not created one.
5. 5) Yes we keep projects and activity in Track-IT work orders. We have changed the Look-Up 1 label to “WO Type” and made it a required field. (We changed the “Work Order Type” field label to “Functional Area” or you might call it “Classification Type” ). The drop-down selection is
a. Asset Request
b. IT Task
c. Informational /Other
e. Trouble Ticket
We classify duplicate trouble tickets as “Informational /Other”.
We have our reports based on the WO Type.
We create a "master ticket" then have assignments under that ticket. For your printer example, the tech will have spent 30 mins diagnosing the printer situation, The person doing the order spends 20 mins ordering the part, then the final ticket for installation of the part. The master ticket stays open for as long as it takes to resolve the issue, and it's recording the "real" time actually spent on the issue.
You could create a new Work Order Status, called "Waiting for parts" or something similar. This status would be a subset of "closed" (all Statuses are either a subset of Open or Closed). When "closed" or a subset under it, all timers stop, and no additional notifications are sent out. You'd probably want to build a custom grid view to show these, or incorporate this status into your current grid views, so these don't fall through the cracks.
When the parts arrive, you change the status back to a normal "open" status, and timers resume.
It's not the most graceful solution, but should accomplish what you're after. On a related note, our Dev Team is working on a "stop the clock" feature that will allow you to leave a work order "open" but stop the clock so that reports show actual time spent working the issue, vs. time spent waiting on users. parts, etc.