We covered the essential bones of a ticketing system, now we'll look at some of the features that make up a succesful solution. All ticketing systems should have the following qualities:
Accessibility
A ticketing system should be simple to access from wherever you are going to access it. Programmers and programs will want a CLI (Command Line Interface), and users will want a GUI (Graphical User Interface). An example of a good choice for a GUI would be a thin client using the HTTP protocol across an Intranet or the Internet. This ensures that anyone with a web browser can use the system, and it doesn't require vendor-dependent client software with software upgrades and rollouts to handle.
Using the web as a front-end also ensures the client is platform-agnostic and works on Unix machines, Windows desktops, VMS hardware, Mac OS laptops, mobile phones, and all the many other variants around the world which support a web interface.
Besides a GUI, users will probably also want an email interface, so that they can receive alerts about system activity, like when a ticket they submitted is resolved.
Ease of use
The system should be easy to use. This means it should be intuitive to enter data, update the status, add interested parties, and assign scripts to certain events to modify the flow of a ticket to suit your particular requirements.
Multiuser
The application needs to be able to handle more than one user at a time, both at the user level and at the administrator level. Any number of people in an organization must be able to enter data of people in an organization to enter data and open tickets at the same time. Equally, multiple administrators must be able to modify things like scripts and status flags at the same time, and not be needlessly restricted by waiting for someone else to complete their changes or logout before they can do any work. A help desk team, for example, may find themselves quite busy receiving, triaging, and resolving customer requests.
Ability to track history
As previously mentioned, the system needs to be able to track not just the current state of an object but its entire modification history: who changed the status from pending to resolved, the original headers from the email (if the ticket came in an email), the IP address that created the ticket (if the ticket came from a web form), and so on.
Handling these things takes a lot of time and effort in the background. We use computers to make light work of tedious and repetitive tasks. Tracking the history of a ticket as it moves through the system is one of the many things that the system does for you. What part of the history is most relevant depends on your requirements, but the first step is to have the data.
Immutable history
Although tracking ticket history is essential, having a history of changes is not a lot of good to anyone if the history vanishes once a ticket is closed or finished in some manner. History must always be available and cannot be deleted erroneously.
Flexible views
The system should offer a means for viewing subsets of tickets: only the highest priority tickets, for instance. A user should be able to easily switch from viewing the open tickets for the last week, tickets that belong to a particular owner or user, tickets with a specific status, or those open for more than a minimum period of time, for example.
In addition, either the user or an administrator needs the ability to configure these views add custom fields or alter the templates for different user's needs.
Access control
It must be possible to control access, perhaps via an ACL (Access Control List) mechanism. Levels of access include who can view and alter the tickets, who can modify ticket status and priority, and who can assign interested parties. When the application includes the ability to write scripts or mini-programs to extend the functionality of the delivered system, the permissions to create and modify these and what they can do must be closely monitored and controlled. Perhaps different groups or queues need to have different access rights depending on their involvement in the task in question.
A ticketing system without an access control mechanism is a disaster waiting to happen.
Dependency management
The system needs a way to link tickets to one another and define dependencies. This makes it possible to set up linked lists or trees of events or status and prevent anyone from closing a particular ticket unitl all its dependencies are satisfied.
This is an important aspect of any true ticketing system. Without the ability to assign and follow dependencies and/or links to other tickets, there is no way to create meaningful workflow structures. In a naive system, it would be easy to miss relevant links and bypass entire tasks. With the ability to assign parent-child relationships to tasks, simple or complex dependencies can reflect the steps involved in a real process within a particular group or team.
Notifications
A ticketing system needs to be able to inform all parties of the current state of the tickets relevant to them. This sort of notification rule set centers around assigning users to groups, and users or groups to tickets.
Whenever the status of a ticket changes or some other defined event takes place, this is immediately reflected in the database for viewing via the thin client. Equally useful is the ability to send notification emails to any and all interested parties, or perhaps to execute a script which might notify people or programs in different ways. The possibilities are endless and simply need to be defined, based on the particular requirements of the people involved.
Customizable workflow
The system needs to be customizable to suit the requirements of the group using it. The company shouldn't have to change its procedures to accomodate a piece of inflexible software.
Deciphering the precise requirements of a client can be a difficult job. Specifications may be vague, misleading, or even downright wrong. One way around this is to allow the client to change the source code directly to accomodate their own requirements. This brings the power of a fully developed system to the hands of the people who actually use it and gives them the freedom to use it as they will.
Software is called soft for good reason it should be flexible.
