Exception codes (or reason codes, call them what you will) have previously been the most useful tool I've had available in preventing problems, rather than just having numbers to prove that there is a problem.
Currently, if we fail to meet the SLA, all we can see is that we failed. An exception code can be as simple as a, possibly required, dropdown with reasons why. The tech themselves, or a manager, needs to set the exception code before the ticket can be closed. The numbers produced by exception codes have been an amazingly powerful tool for me before. At the end of the year, rather than just being able to say that we succeeded so-and-so many percent of the time, I've been able to give specific numbers on what needs to be improved. Had a situation where executives wanted extended hours for IT, because they felt that we were failing due to not being available. Exception codes let me prove that less than three percent of SLA failures were due to no techs being available, whereas over 50% were due to things related to vendor provided parts (wrong part in box, wrong part picked, DOA). Ended up putting into place some procedures testing parts in advance rather than when needed, and didn't have to extend any hours. Also popular with the techs, as it gives them a tool to show that not all failed SLAs are the fault of the techs.
