If your organization is anything like any of ours, there’s always a lot of stuff to do. Vendors need to get paid. Customers need to get invoiced. Staff need to do work for customers. Sales inquiries need to be answered. Bugs in hard- or software need to be fixed, and everyone needs to know that they have been fixed. Somebody needs to take out the garbage. And at the end of the day, you’ve got to know who wanted what, who did it, when it got done, and most importantly what remains undone.
That’s where a ticketing system comes in.
The convention is to call each request or piece of work a Ticket. When a new thing comes into the system, we give it a virtual slip of paper with a number, much like the ticket for checking your coat at the coat room or leaving your car in valet parking. This is the ticket we track.
Before we get into typical applications, let’s dissect a generic ticketing system into its component parts, by building a list of the things a typical ticketing system will do. You can use this list to decide whether or not you need a ticketing system.
These are the bones of a true ticketing system:
Register an event or a ticket
Assign an owner, or person responsible, to the ticket
Assign additional interested parties to the ticket
Track changes to the ticket
Inform interested parties of these changes
Launch activity based on ticket status and/or priority
Report on status of one or more ticket(s)—an overview
Finish with, or close, the ticket
Note the list doesn’t include a “Delete this Ticket” mechanism, even when it is finished, or closed. This is because it is essential for any professional ticketing solution to show the status of a Thing once it’s entered into the system and the entire history of how it is handled. You should be able to close a Thing, but not remove knowledge of it, or what happened to it, from the system. On the other hand, it is possible and sometimes even desirable to remove erroneous entries from the system—such as duplicates or plain wrong entries. Deletion may be primarily a manual process, so that people will use it rarely. The prime intention here is to maintain a history of events and the current status, and never to lose it.
While your to do list, sticky notes on the refrigerator, or PDA may be a great personal ticketing system for simple lists of things to do, these tools are mediocre at best as a ticketing system for larger projects. Taking a numbered ticket at the supermarket before you can buy meat and cheese at the deli counter is another instance of a short-term but effective system. The same applies to the systems installed at railway stations and doctors’ offices.
The concern here is not the short-term view, but the fully-functional system leveraging the power of a database to identify a Thing and follow the course of this Thing through a distinct process to an expected conclusion.
Although ticketing systems come in several flavors, most are designed for a single application. Typical applications, and some of the ways in which a ticketing system can explicitly help, are explained next.
Running operations support in a production environment can be very confusing. For example, if a bank financial trading system goes down, the online replacement (hotswap) system needs to step in and take over. Even if this works smoothly, there will be lots of people running around screaming like headless chickens. Under these circumstances it is very easy to see how a fix to a less critical application could be missed or delayed.
You can use a ticketing system to assign tasks as they come in to the next available operative. Tasks which have a higher priority or are critical in nature get fixed first. Simply fixing the current emergency is not enough, though. There needs to be a system in place which tracks the outstanding tasks—the ones temporarily on the back-burner—and identifies which are the most important to solve next. This is what the banks do and for good reason—they work in a permanent state of paranoia. The need for a priority list like this is not limited to banks. It applies to whatever is critical in your environment.
A representative of the company is informed of a potential sales lead. This information might come in many forms: a note, an email, a telephone call request, person who hears of a requirement that needs fulfilling, a personal recommendation. What form the lead takes doesn’t really matter. The important thing is to not miss the opportunity to close the sale.
If you have a sales lead tracking system in place, you can see which leads are still open and need more work. You also can see which salesperson brings in the most leads, and perhaps most important, which salesperson successfully closes the most leads. This information is immediately available at all times via a number of configurable report options.
Without having this information handy, it is very easy to lose promising leads, or to leave half-finished responses unfinished, neither of which improves customer confidence. If a buyer is unable to buy from you, they will buy from someone else.
A customer contacts the company with a query. In this case we are not talking about a purchase but a service request. The request should still be tracked, even if the contact person can immediately solve the query.
Tracking the request ensures the company has a record of what types of queries are most common. This also can give the company instant feedback on whether or not their users find the published documentation or processes hard to understand, merely sufficient, or easy to follow.
A ticketing system can track the items in a project management plan. You can see who is responsible for a task and, when he has finished the task, you will know about it when the status changes. In a project management plan, it is critical to have an overview of the dependencies between separate tasks or work flows.
Imagine that you are in charge of developing a new space station or vehicle. You are particularly interested in the exciting new space telescope which will allow astronomers to peer into the beginning of time. It might be easy to miss the importance of an incidental task, such as installing a reliable, bombproof, redundant air supply for the personnel. The safety team, in this case the interested party, needs to know that the oxygen supply team, the owner of the task, has completed and tested the installation of the air supplies and backups.
This example may seem obvious, but smaller things have caused immense failures. We only have to remember the tragic Challenger Space Shuttle disaster, where the extremely small O-ring seal failed in part because of the extreme temperatures and in part because of bad management pressure and decisions. You can’t ignore essential information or equipment—no matter how small it is.
A complicated and redundant project like the space shuttle has so many checks and counter-checks that a ticketing system might seem irrelevant—yet it needs some way to track all the outstanding tasks and who should work on them.
If a system is compromised by a security breach, this event can be entered and tracked as a ticket, and an alert can be sent to the appropriate parties. People responsible for the hardware, the software, the administration, the firewall, the proxy, or the Internet access can be assigned as interested parties to the ticket.
If the documentation team continually gets alerts from network attacks, or if the sales team receives endless notes regarding the current status of a particular firewall configuration, they will start filtering incoming notifications to /dev/null or the dustbin. Being able to assign the appropriate people from different interest groups to a particular ticket is critical to the smooth running of an efficient ticketing system.
Everyone who needs to know can follow the status of the new security breach: what can be done to fix it, what has been done, and whether the problem has been succesfully fixed and the hole plugged. If you don’t track this information, there is a high probability that the same attack will break through your defenses again after you’ve forgotten when and how the original attack broke through.
Many open source projects have a public bugs database where users can check if a problem they have is related to a known bug. The database is essential for tracking the history of bugs over time, for example, to determine if developers already tried a proposed change and rejected it for a valid reason. People can find out if the bug they are trying to report has already been reported and not flood the database with duplicate bug reports.
Bug tracking software has been around a long time. The success or failure of any bug tracking solution often depends on how people use the system. It is not enough to simply enter bugs in a database or tracking tool, and then to fix the bugs. The next step—an essential one—is to close the ticket. Often the QA (Quality Assurance) department will ensure this takes place. A good ticketing system makes this task simple by letting you view the status of all known tickets at once.
The preceding list of potential uses is not exhaustive, but it should give you an idea of the breadth of applications a ticket tracking tool has.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ticketing systems are good for multiple purposes and for many different people in different circumstances. Let’s step back from the company or group perspective and look at how a ticket system benefits individuals.
From a personal perspective, a ticketing system enables you to collect tasks in a list, assign a priority or status to it so the system can automatically order the list, and more or less forget about it until it’s time to work on it. Deciding what to do next is simply a matter of looking up the most critical item and doing that task. The system decides on your behalf what is the most urgent task based on attributes you set.
A ticketing system also helps you manage your time more efficiently and avoid working on three or four things at once and not getting any of them done. You simply do the current task, mark it closed, and move on down the list. This is a bit like a shopping list: you can go to the checkout when everything on the list—the prerequisites for this shop—is in the basket. Once the checkout phase is complete, you move on to the next shop. Millions of people do this everyday, all around the world. They are using an unsophisticated ticketing system, the shopping list, which is ideal for a simple and solitary activity.
However, if you are involved in a large organization, you may work with a number of people from separate departments, and your job may involve multiple different tools and interrelated tasks. A ticketing system can simplify your complex and interrelated tasks to behave like a shopping list for your environment. Select an open ticket, work through the involved tasks, if there are any unfinished dependencies close them first, then close the parent ticket.
Divide and conquer, simplify and close.
Perhaps you manage a team of people, all working on vaguely related tasks. Each time a new task arrives for your department, you assign it to one or more people based on their apparent availability and skill set. The task may be a customer request, a production change, a system failure bug report or whatever it is that your department handles.
If you are using an effective ticketing system, you can easily find helpful information like the number of outstanding tasks, the status of all the submitted work this week, who is not overloaded, and who has more work than they can reasonably handle. You can locate essential tasks that are still open, and assign the merely nice-to-have tasks to the back-burner by simply changing the status of a ticket on a web page.
Members of your team can cross-assign tasks to other members when they’re overworked, or find another team member who is more of an expert on a particular task. They can assign the expert to the ticket as an interested party or may even transfer ownership altogether.
This kind of system ensures high visibility. The entire team will always know the overall state of the tasks at hand—what needs doing and who should be doing it. Everyone will know who needs to pull their weight more and who is doing too much. There is always a balance to be found. This information will bring in, all by itself, peer pressure to get your list of tickets closed. Everyone will probably want to have closed the most tickets this week, particularly if this is tied to a bonus scheme. The bonus scheme may be targeted to the team, not necessarily to the individual, but the incentive and result remains the same—your team will become a more effective self-managing unit.
The accountants, or whoever watches the company profits, are essentially concerned with getting something for nothing or less.
A ticketing system will allow accountants to keep track of all the tasks requested from your group—a series of support requests, for example—and which tasks you’ve completed. They may be able to charge for each opened ticket, but they may only be able to charge a substantial sum or bonus for closed tickets, or for tickets closed within a specified period of time.
An automated tracking system enables accountants to make economic decisions based on real throughput of work, as well as to charge immediately for completed work, rather than waiting for this information to filter through an inefficient manual system. If the work is ticket-based, they could even automatically generate profit and loss forecasts based entirely on the contents of the ticketing system itself.
All of this makes a ticketing system a must for any bean-counter worth her salt.
Your boss is not only responsible for giving work out to you and other employees. She must track the entire workforce, the work it is doing, and the outstanding work. She feeds reports back to her management in turn. Most bosses are only bosses relatively speaking, and report to higher management, shareholders, or their partners.
The boss provides summaries of the current state of progress, which go all the way up the food chain. The best way she can satisfy continual requests for status updates is to use the predefined views in the ticketing system to generate a suitable report. If these views are not sufficient, then the system needs to be able to produce flexible reports tailored to the relevant purpose.
Keeping your boss happy is an important part of a good ticketing system.
Although you may want a ticketing system because it will make handling and tracking tasks so much easier, the first step is to persuade the right people. You need enthusiasm for the solution across the organization.
The people who pay for it come first—management has to have an interest. They need to see the benefits for their business, their customers, and their bottom line.
Any of the points described in the section “Ticketing Helps Everybody” might help convince a manager that his workforce could be more productive with less resources. A ticketing system can help handle multiple requirements to ensure a smooth operation, save time, avoid missing tasks, prevent less critical work from impeding the important work, and make the entire workflow more efficient.
Last, implementing a ticketing system is an inexpensive solution with many rewards throughout an organization. It enables managers to track activity in a complex environment—knowledge is power.
An enthusiastic manager is not enough, an excited staff is essential to the new process, too. One of the many reasons for individual members of a team to be keen on having a ticketing system in place is that they no longer need to inform a whole tree of people of the status of a particular chunk of work.
The familiar cries of: “Let me know when you’ve finished,” “Don’t interrupt me now, can’t you see I’m busy, . . ., and “When you’ve done X, I’ll tell you what to do next” need never be heard again. Once a ticketing system is in place, anyone in the team can pick up an outstanding piece of work with the highest priority and deal with it. They know no one else is going to start work on the task at the same time, because they are the owner of the task. No one needs to ask about progress, because everyone knows it is finished when the status is changed on the team web site. There may even be a customizable email to all interested parties. No more treading on each other’s toes.
A ticketing system empowers the members of a team to handle discrete tasks with much less overhead and enables them to manage their own time more effieciently. Higher efficiency means less stress, less stress means happier staff, happy staff means a job well done, and we all go home early.
Having a ticketing system is not enough—you need to use it! There are many ways to motivate people. Many implementors may think that the only choices are the carrot and the stick. An example of the carrot might be: “If you close more than 10 tickets a day, you can go home early.” An example of the stick might be: “Unless you close more than 10 tickets a day, you’re fired!”
Neither approach is ideal—both involve some authority figure who will either punish or reward performance. The carrot may even be an appropriate solution in some environments, but the danger is that it may promote unproductive competition between your team members. They may pick the easy-to-close tickets rather than the highest priority ones.
An alternative approach might be to educate the users of the ticketing system to appreciate the benefits of the improved workflow. This information does not need to focus solely on immediate improvements to the process, but it also might demonstrate how it will positively effect the provision of service, improve the confidence of the customer, and expand the bottom line of the firm. These lead to future expansion, more and better jobs, and perhaps world peace.
All of this depends on the nature of your work and your business model. You need to implement whatever solution works best for you. Each group may have to decide how to use the new tool to it’s best advantage. Each situation will have its own best practice solution for local problems.
RT is designed not only to handle all the scenarios explored above, but it also is flexible enough to accomodate almost any variation with little or no specialized knowledge.
RT runs on a number of different mainstream platforms, including various flavors of Unix, Linux, Windows and Mac OS. RT supports several popular database backends: MySQL, PostgreSQL, and Oracle. Finally, RT uses Perl—a language familiar to many programmers and systems administrators—to make local customization easy.
RT also has a great user and developer community, with active email lists and a handy wiki (http://wiki.bestpractical.com/). And because RT is open source software, you are free to extend and change the core product to suit your needs.
This chapter has described what a succesful ticketing system needs to support a satisfied user base, without focusing on any particular tool or solution. The rest of this book gets down to the nitty-gritty and describes how to use RT itself, from typical installation scenarios to detailed configuration files, and from the commandline to the web-based GUI interface.