Hi,
There are a number of ways you could do this (you could create and add application CIs to the ticket along with the hardware CI for example) but I would say that the generlaly accepted way would be....
Define Catagories for the different issues that the users have. A category has up to 4 levels of notation such as Hardware.Printer.Drum Failure or Application.COTS.Visio or Application. Messaging.Exchange . When the incident is raised you should set a category for it. As the incident progresses you might change the category to reflect the new things you learn about the real issue. For example the issue may start out as a Hardware.Laptop error but on investigation it turns out that its actually an issue with MS Outlook on the laptop and so it would be re-categoriesed to Application.COTS.Office.Outlook or sonething like that. Its a function of the Investigate and Diagnose phase of the ITIL incident management process to try and determine the right information here to ensure it goes to the right people to fix it. Good first line scripts help with this.
A key KPI for Incident managers to look at is to look for incidents that have a classification at the point of resolution that is different from the classification that it had when it was logged. This might show a lack of knowledge at the first line or some other issue that you could improve on.
A key thing for problem managers to look for is trends in the data from reporting. Starting with the category of issue and then deep diving to lower levels of data to inform them further. For example, they might start with noticing that there are a large number of issues with SAP, they might then look at the lower levels under that and see that 80% of the SAP issues are password resets. They can then build a business case to implement single sign on to reduce that volume of workload completely.
I hope that helps, happy to discuss further.
cheers
Carey