Incidents can be related to servers and equipment, workstations, printers or software. They should be related to a vendor as well. This is not a helpdesk ticketing system rather then a bridge in between. It is designed to help you keep track of open vendor tickets and actually being able to look at a certain asset and see what was going on with it like repairs on a workstation.

The thought was, enter basic problem / issue information and once it is resolved mention basically what was done – keep it simple and link a ticket if you have one in your ticketing system.

With time the incidents proved to be more then a simple I called the vendor system. You now can automatically create folders to collect additional evidence, in case you have a need to collect additional files. Further can you add notes and most important related TAGs to incidents.

The TAGs started to be important for recurring issues. Lets say you have a specific workstation model – it starts with one user having weird issues like blue screens and you find that this happens more and more and it seems to be related to a specific model. What you do is, you create a specific TAG and instruct everyone to create an incident and relate it to the TAG when this happens – you later can look at the TAG and see how many incidents have been assigned to it. It does not need to be a blue screen of course, this could be related to the motherboard having issues etc. – this certainly helps to find out if this is related to a specific model or not.

Of course, it is not to recommend to overdo this – only if the team reports increasing issues with certain models of devices. The above is a sheer example on of how to engage TAGs most efficiently.

Data field and reference overview