We have used SD for several years, but are not taking full advantage of the product. My mgmt team is wanting to evaluate our use of the product and start making the most of SD in our environment. One of the biggest issues over time has been the amount of data entry necessary for service calls. I am interested in what others have done to minimze the amount of typing and entry that the help desk has to do. I know templates and checklists exist. What about forms? What fields do you use and which ones do you not use? If you are able maybe a screen shot of a typical form for a service call could be posted?
automation is a wonderful thing and with e.g. UI rules you can automate the population of the fields. However if you automate too much you may loose accuracy in reporting against the attributes.
Things to automate could be setting the actual finish on closure of a call. But then the question raised is is that value the time the call was closed or the time the issue was resolver which could have been before the call was closed.
Look at all the fields on the form and look at what could be populated by rules. Using impact mapping will populate the priority. Use rules to pass values from problems to changes to service calls.
Above all there is the possibility to use ruels to create a running diary or log which can populate the persons name, time of entry and the actual entry into the 64k text field.
I think the key to which fields you want to use is what management information you want to get out.
We recommend the following approach:
At the time of logging a call, typically you will know the caller and the service but by the time you resolve a call you should know the CI, the "cause" (e.g. user error, no fault found) and the way the call was handled (closure code - typical values include Solved, Work round, used a remote access tool, needed a site visit etc).
So we make these required for any status after Resolved. Then the CI gives yoy infromation as to whether it was a hardware or software fault, the closure code on how much it is costing you in site visits etc.
You can use UI rules and templates to automate some of these settings.
If your principal objective is to reduce the amount of typing to be done, then I cannot help you. We added more custom fields, rather than having reduced the number.
However, if your objective is to provide information to problem management so that you can regularly reduce the impact of incidents and improve the satisfaction of your users, then I would suggest trying to determine what problem management needs in order to make such improvements. That is the information you need to capture.
For me, the key issue is to have information that allows you to prioritize the problems and ensure that your limited problem management resources are working to best effect.
The bottom line of all that is becoming more proactive and thereby reducing the amount of typing, because you will presumably have fewer incidents and service calls.