There is a separate Administrator's Guide describing how to set up the helpdesk and maintain the data.
Every request has a category, which identifies what kind of request it is. The categories can be very detailed and specific, or very vague and general.
Every request also has a priority which defines how urgent it is, and may have a due date, the meaning of which depends on the priority. For example, if the priority is "Critical", then there is no due date since it must be resolved immediately. If the priority is "Deadline" then the due date is the deadline. If the priority is "Objective" then the due date is the date when the objective is to be reviewed.
Certain categories of request might have specific pieces of information that it is usually useful to gather. These properties are attached to a request when it is created, and may be filled in for future reference and reporting.
I am calling the person who is using the helpdesk system the user. A person asking for something to be done is the originator of the request. To avoid confusion, I am not calling them a user although they are probably requesting support as the user of some other system.
A request can be assigned to one user. The owner of a request is the person it is assigned to at the moment, meaning they are the one responsible for its resolution. Users can be grouped into teams for the purposes of grouping users who share one or more skills. Teams can overlap and don't necessarily relate to the departmental structure. The skills that a team has are defined in terms of the categories of request that members of the team can be expected to handle. Each request may also be assigned to a team, but it needn't and it's only used for reporting purposes or to hint at who else should pick up the request if the current owner is unable to continue.
In general, the owners, originators and other people are listed in the database as contacts, associated with a full name, phone number etc. Each has a unique contact ID. It is probably a good idea for this to follow some established convention so that it can be guessed from the name.
Individuals whose names appear in the examples are fictional, although there are probably many thousands of real people with the same name.
The sections are:
The contact search pages matches what you enter against the last name, first name or location (in that order). So typing "S" would match a "John Smith" a "Steve Jones" and everyone in the "Sales" location, but hopefully the one you want is near the top of the list. The search is not case sensitive.
The "search contacts" page also has a row of letter buttons, which are effectively equivalent to entering a single letter as the search string.
Search contact database the person making the request. Preference order is Last Name, First Name, Location.
|petha||Peterfirstname.lastname@example.org||IT Glasgow||Take Call|
|Someone else, maybe not listed in the contact table.||Take Call|
Following the "Take Call" link from one of the search results identifies that contact as the originator of the request, which is yet to be created. You can also continue with the originator unspecified, if they aren't in the contact table yet.
The next stage is diagnosing the request to see what category it should be.
Initially the request would be "Uncategorised". Answering a question provides information that either identifies the request category or leads to a further set of questions (or both).
It is not necessary to ask the caller every question, just use what information you can get from them to determine the nature of the request, using the questions as a guide. The questions are configurable from the "Admin" section of the helpdesk system. They can be tailored carefully to act as an "expert system" to troubleshoot common problems.
When it is possible to create a request, there is a "Raise Request" button at the top of the page, and if there is advice in the knowledge base (e.g. "logging out and back in should fix it") for that category of request, it will be displayed.
Otherwise, there is not enough information to categorise it yet, although you can start again at any time and just raise the request as "Uncategorised" if you have to.
Here the priority and due date (if any) can be selected, and some descriptive text can be typed or pasted in. The originator of the request (the contact ID anyway) will be filled in already if you got to this page via the contact search page. If the contact ID is not known, or there is no contact record for that person, the name can be entered instead.
Some categories of request can expect additional information that is useful in resolving requests of that type. If so, fields will also be provided where that information can be entered.
The appropriate team and specialist to be assigned to the request can be chosen from drop-down lists. By default the person assigned to the request is whoever is logged in. If any of the specialists have set an "away until" date, for example if they have gone on holiday, this will be visible.
If the "send e-mail" box is ticked, then the helpdesk system will attempt to send e-mail to the owner of the request, notifying them that the request has been created and is assigned to them. Whether this works or not depends on them having an e-mail address set up in the contact table, and on whether the e-mail system is working.
|141||Change to Helpdesk||user interface improvements for 1.2 beta||08-01-2001||Peter|
|129||Change to Helpdesk||Add reporting of requests created and closed, by category, team, owner or originator, between 2 dates. Option ...||The Boss|
|156||Write Documentation||Write helpdesk user guide 1.2||Peter|
The link in the first column (the request number) leads to a page where the request can be updated.
If the "Send e-mail" box is ticked, the system will notify the person assigned to the request that it has been updated. By defualt, this box is not ticked when you are looking at your own requests.
If the "Notify originator" box is ticked, the system will notify the originator of the request (assuming their e-mail address is set up in the contact table). By default this box is not ticked.
|06-12-00 10:41||ASSIGN||petha, prog|
There is also a report by property. If a category has a property associated with it (e.g. printer name for category "printer problem") the report "Count requests by property" can give a breakdown of requests by the values entered for that property (e.g. printer problems by printer name). This is designed to be useful in identifying problem areas in more detail than just by category.
To use it, first select a category of requests which has properties associated with it:
The request search allows you to find requests by more complex criteria, including due date, category, priority and so on.
If you choose "Exact Match" beside the category, then only requests of exactly that category are found. If you choose "Match similar", it matches categories whose codes begin with the chosen code. If your category codes are organised into a hierarchy it may be useful. Any category is "similar" to the "Uncategorised" category by this rule.
If you tick one or more priorities, only requests of those priorities will be found. If you leave them all unticked then any priority is included.
The "originator" and "assign to" should be the unique contact ID, not necessarily the same as the person's name.
The request extract is like the request search, but it produces a CSV (comma-separated-values) file which your browser will probably download, and may load into whatever spreadsheet program you use, depending on settings on your computer.
Users can also specify a date until which they are away from work, or at least unavailable for taking helpdesk requests. This makes it easier to avoid people assigning requests to you while you are on holiday!
Both of these are done in the "Your Preferences" screen, which you get to from the "Operator" screen.