It depends on what sort of software you are supporting and where it is in its lifecycle. Providing support for the software that controls a nuclear reactor, a network of ATMs, an online game company and a DTP package will all be very different
Pro-active support is good but you will inevitably spend a lot of time doing reactive support work.
I would definitely prioritise faults
something along the lines of
Crashes/wrong results in live realtime systems
Crashes/wrong results in UAT realtime systems
crashes/wrong results in live systems that aren't time critical
crashes/wrong results in UAT systems that aren't time critical
crashes/wrong results in non-critical software
crashes/wrong results in that can be worked around
Bugs that irritate the user
Problems that would go away if only users would read the manual
The last two will probably be the most common
Bugs that irritate the user will be much higher profile when you are trying to sell software to a client
I would also document all the reported problems and their solutions. Then use the information to build up a knowledge base.
That will allow you to do several things
Check for similar problems in the past which will save you going over the same ground several times and give a quick resolution to your clients
Identify clients that have lots simple problems so that you can maybe sell extra training to them
Build a list of frequently asked questions that you can publicise which will save support staff time on replying to the same questions from different users over and over again.
It is important to keep clients informed at each step and give them regular updates. You also need to chase clients to find out where the data is that they promised you or whether the solution you suggested has resolved their problem.
Hope that helps
Snuv
"If it could have gone wrong earlier and it didn't, it ultimately would have been beneficial for it to have." : Murphy's Ultimate Corollary