I have posted in the past about my efforts to write a user facing bug tracking interface for TFS to integrate with our SharePoint based customer portal. I have had some mixed success, but the end point is that I am just not happy with what I have written.
Historically we have used our own home grown call tracking system (started as an Access DB, went via VB6 to ASP then ASP.NET, now is web service based) which our clients know (and love?). This give a far richer audit trail for the actions performed on a support call than is possible with a work item in TFS. In the end this simple fact is what has forced me to conclude that TFS work items are not the thing to expose to end user/help desk staff for bug tracking.
My new plan is to add a new feature to our existing call tracking system (oh and of course port it into a SharePoint webpart based UI) that allows a call to be escalated into TFS when it becomes change request or requires a code bug fix. This means all the initial triage can be handed by the support desk in a their call tracking system and TFS only gains a work item when it is a task for the development team, a product backlog item in Scrum terminology.
This seems a more sensible approach, much like the Snagit add-in for TFS, I will report back as to how it goes.