A lot of customer's I've dealt with are using the Change Templates and to make it easier to navigate use different categories as you say.
I've always taken the approach with standard changes, because they can be considered 'Pre-Approved', they must first be raised as a Major change and go through the full change process including approvals. Once approved they could be flagged as a 'Standard Change' and from there you could simply clone the change, which then allows you have a relationship been the 'master' approved change and any subsequent standard change that are logged. This also gives you a history then of how many times that change has been implemented.
we have a bit of another way.
We do change management for Enterprise Apps and so called Infrastrcuture Platforms. This platform could be "Windows Server" or "Unix Servers". We have a created a new object which is linked to the Apps and Plattform Objects. This is called Standard change templates. The object contains all the fields from the change mask. In the documentation for every platform and every app, the owner of this have to define their standard change templates. The documentation is then approved from the QA. All the standard changes they designed in their documentation are then put into the standard change object and linked to the platform or app.
In the change module the user first has to select either the app or the platform which should been changed. If the classification standard is selected, the subject field becomes a drop down and the user can select the standard change from the list out of standard change object which are linked to the selected platform or app. Those changes are pre approved and does not need to have an approval workflow.
This works very good for us. Good a good feedback from the community.