Useful Ticketing System Tips
As with almost all modern software offerings, a ticketing system is a highly configurable and versatile product. In fact, an IT support organization’s ticketing system as a whole will contain more than just software – it is a balanced blend of people and process as well as the technology. Each selection, implementation, and adoption of a ticketing system is somewhat unique, but there are, nonetheless, some useful generic tips and hints worth considering for your IT support organization and invoking appropriately.
When selecting a suitable ticketing system, it doesn’t necessarily help to ask for everything possible. The more complex and sophisticated a ticketing system is, the more expensive it will be – not just the initial purchase but also to implement and to maintain. A sensible first step with ticketing system requirements analysis is to decide upon which aspects and features are truly necessary for your implementation. Unless you can foresee using a feature, and the value it will actually deliver in your situation, then do not consider it as a reason (or one of the reasons) to buy a particular ticketing system. If you do, then you might be choosing the wrong ticketing system because you are asking for the wrong things, and you will most certainly be paying for capabilities that your organization will never use.
While you should not be motivated by features you will not use, do be careful to predict as much as possible what you are likely to use over the life of the ticketing system you are investing in. Of course, seeing into the future can never be 100% certain, but do take note of the clues available to you, such as:
They say that “the customer is king” but the ticketing system is likely to be mostly used by IT support staff. In fact, it will occupy them for a large part of their working day and become a fundamental aspect of their daily job, and their motivation levels. If your staff like using the ticketing system, then that will increase their job satisfaction and productivity. If they do not like it, then the opposite will happen. The easiest way to find out if your staff will like the ticketing system, thereby capturing their support, is to involve them in the selection and assessment of any new ticketing system.
Plus, of course, there is the need to involve end users in the ticketing system capabilities that they use, such as self-service portal and the knowledge base. If end users don’t like using the ticketing system then driving adoption will be an uphill battle at best.
As a new ticketing system is used, staff and end users will become familiar with it and push the ticketing system to new limits. They may well also adapt and improve upon how it is used. Many of the techniques, tricks, knacks, and improvements will be useful to others in similar situations. So establish a mechanism – from a local wiki through to formal user groups to help capture and spread useful ticketing system innovations. Also keep track of the lessons learned for things that do not work, so as to prevent repetition. These can also be incorporated and fed into the organization’s ITIL continual service improvement activities as appropriate.
There are many benefits of using consistency and conformance to establish norms. To help deliver this, set up a group to, initially, build an agreed set of categories to be used within the ticketing system. But also be aware that all things change and that this set of categories and standard terminology will evolve as the organization and its environment change. Your organization will need to steer a careful line between:
If your ticketing system has a significant element of “newness and innovation” in your organization, then it is highly unlikely that it will have been implemented perfectly first time. To do so would require a perfect vision of the future, which most of us don’t have. The truth is that unexpected changes will happen, growth will be different from expected, and some presumptions and assumptions will not be validated by reality. So this element of imperfection, and need for improvement, is to be expected and is not any kind of failure. It does mean though that after, say, 18-24 months the implementation should be revisited and adaptations – or possibly even a re-implementation – put in place.
Start Crushing IT