Development teams at Stack Overflow share the responsibility of addressing bugs through a rotation known as "bug duty." On the Jobs team, the four or five developers each take two weeks in alphabetical order by first name. I am between my first and second weeks of bug duty for the current rotation.
I don't mind bug duty. It provides a chance to work on some small and not-so-small problems as they come up. Here are some things I try to do when on bug duty to help the development team and the quality of the Jobs offering.
Go Looking for Trouble
Don't wait for bugs to be reported. Use whatever system status tools are available. At Stack Overflow, we have our own status system that I'm sure someone will tell me is open-sourced somewhere. The Talent team — that is, the employer-facing side of the Jobs product — also has TrackJS available to catch client-side problems. If your team doesn't have tools, or they aren't accessible to you, lobby for change. Your products will be better for it.
Job applicants sometimes report issues on Meta. When such a user tags their meta issue with "bug" and "jobs," our team is notified through our internal chat system, and the bug-duty person is expected to handle the issue. I will admit that Meta is not an ideal bug-tracking system; it is clumsy to acknowledge that a problem is being addressed, which means we aren't necessarily as responsive as I would normally like to see. But, I try to get back to the user in some manner as soon as I can. Besides, as a user, wouldn't you like to see that your issue is being addressed as soon as possible?
Other times, Stack Overflow personnel report the bugs. Such bugs end up on our Trello "bug board," and everyone in the company can see the status of such bugs if they want. I still try to acknowledge these bugs as soon as I can. Communication is key.
Fix It Twice
Sometimes, the "ideal" fix for a bug will take too long for customer comfort, or we need some architectural change, etc. We have a theme of "fix it twice," meaning that a second task to eliminate the conditions that permitted the bug should be added to our task tracker (again, Trello), then actually addressed. The second fix may be part of bug duty if there are few bugs, but sometimes the second fix actually needs to be a project on its own, with a specification and estimate.
Whatever the situation is for software support in an organization, the people handling issues could benefit from these approaches.