Category Admin
Uncategorised |
A | AS400 | |
|
C | Change to a system | |
 |
E | Error message or fault | |
|
EC | Error - PC crash or hang | |
|
EE | E-MAIL Problem | |
|
H | Hardware | |
| Code | Description | Usual Priority | Team | |
|---|---|---|---|---|
Individuals whose names appear in the examples are fictional, although there are probably many thousands of real people with the same name.
This is where administration tasks are carried out.
To add a new request category (for example) you would go into Category Code Admin. You would probably also add questions and answers the helpdesk operator could use to diagnose a request as being in that category, and go into Team Admin to add the category to the skill set of one or more teams.
To add a new helpdesk operator, specialist, or other person you would use the Contact Admin page. If they are to belong to a team, go into Team Admin also to add them to a team or create a new team for them.
For this reason, the default set of priority codes begins with (in decreasing order of urgency) "Critical", "Deadline", "No Deadline". "Critical" means "do it now", "Deadline" means the date by which it must be done is known, and "No Deadline" means "do it whenever you get round to it".
Other levels that are less urgent are possible. For example "Suspended" for tasks that can't be done yet but should be reviewed at a later date to see what can be done with them. Each priority level is associated with a date name, which defines how the due date is described for each priority level. So "Deadline" tasks have a "Deadline" date, whereas "Suspended" tasks have a "Review" date.
To add a new priority code, enter the code, description and date type in the form at the bottom of the list and click the "Add" button. To edit the description or date type, click the link in the first column (the priority code).
Note that priority codes are sorted in alphabetical order. This is not a coincidence; it's how the system knows which is more urgent. Although the initial letters of the description have been chosen for the priority codes, they needn't be, as long as the codes sort in the right order.
Depending on how your organisation operates, you might want a knowledge base of hundreds of well-defined categories each with advice for its resolution, or you might want a few general categories just for your statistics. You can do either, or mix and match.
The category admin page looks like this:
|
A | AS400 | |
|
C | Change to a system | |
|
E | Error message or fault | |
|
EC | Error - PC crash or hang | |
|
EE | E-MAIL Problem | |
|
H | Hardware | |
| Code | Description | Usual Priority | Team | |
|---|---|---|---|---|
Note: I strongly recommend that you keep one category with an empty category code, for uncategorised requests.
If you have a hierarchy of categories i.e. a general category and a set of more specific ones, it might be a good idea to use category codes that make it clear that they are related. For example, make the general category code be a prefix of the more specific ones. It helps later on when defining the skill sets of teams, as you will be able to match a team to several related categories with a wildcard pattern.
The categories are displayed in a tree, with the assumption that they are arranged in a hierarchy as described above.
To add a new category, enter its code, description and usual priority (see Priority Admin), and choose a team which will have that category as one of its skills.
By following the link on the category code in the first column of the table you get to the "Edit Category" page.
Every category has a descriptive name, and a usual priority. Certain things are inherently crirital, others are usually not urgent at all.
Every category can have some "advice", which is text that will be shown when the request's category is identified. This is a good place to put advice such as "turn it off and back on, that usually fixes it", which might provide immediate resolution of a problem without assigning it to a specialist. There is also space for an advice link - a URL pointing to more information than can be entered in the "Advice" text.
There is an Update button to write back the changes. There is a Delete button to remove the category, unless requests of that category exist, in which case "Requests exist" appears instead.
Certain problems always require information to be gathered before they can be fixed, or you might want to always record machine serial numbers (for example) so that repeated problems with the same machine can be highlighted. Category properties are the way to do this. They are properties or attributes of the request that you expect it will be useful to record. Every category can have as many "properties" as you like. When a request is raised, it gets a copy of the list of properties which can be filled in for later reference.
It is possible to change the code used for a category. Enter the new code in the "Change category code" box and click on the "Change category code" button. All requests of that category will be changed to the new code. Request properties and team skills (see below) will also be changed accordingly. Note that only team skills that match the category exactly will be changed. Note that the questions and answers used to categorise requests are not changed, so any answers leading to the old category code will need to be changed separately.
This can be a single question with a list of the few categories used as answers, or an expert system with many questions and answers that can be used to troubleshoot the problem extensively.
The questions and answers are maintained in a similar way to the eay they are used in diagnosing a problem. Starting at "Uncategorised", the administrator can choose answers to questions to navigate to the point in the question and answer tree where changes are to be made.
Such a question and answer page might look like this:
The "guess state" is shown at the top of the page. If it is a category code, then the category name is also shown. It needn't be, though. The guess state is just a string associated with the last answer that was chosen, so it need only be a category code when the answer chosen provided enough information to identify a category.
Choosing one of the answers changes the "guess state" and presents the next set of questions (if any). Another question can be added by typing in the field at the bottom of the page and clicking the "Add Question" button.
Choosing the link on a question takes you to the "Edit a Question" page.
Possible answers to the question can be added using the form at the bottom of the page. Note that the order in which the answers are specified doesn't matter. Each answer should be associated with a guess state - the best guess at the category of the request if that answer is given, or at least a new state which will have questions to further refine the guess.
Note that there is no built-in consistency checking - the method is as flexible as possible which means that to use it well requires a bit of design effort in choosing useful categories and questions.
Users of the helpdesk wanting to receive e-mail notifications when requests assigned to them are updated must have a corresponding contact record with an e-mail address.
Any contacts that are to be users of the helpdesk can be made so by clicking the "Make Operator" button, which will create a Zope user with the same ID. To give a user Admin permissions, you have to use the zope management interface - users created within f2w are only normal helpdesk operators.
Teams can be added using the form at the bottom of the page. Following the link on the team ID, you get to the "Edit Team" page.
The team name and leader can be changed on this page. If the team has no members and no skills, then it can be deleted (there is then a Delete button on the page).
Members can be added to the team by entering their contact ID and clicking the "Add Member" button. Similarly for skills. It has proved to be useful to have a team called "Anybody" (or whatever), with an empty ID, containing all users. Then common categories like "Uncategorised" can be associated with the "Anybody" team. And don't need to be set up in every team for all users to be able to be assigned requests of that type.
Any other suggestions are welcome.