What is a recommended support technician to developer ratio for an enterprise web application?

Question

We have been dealing with a lot of headaches in development and support. Tickets pile up and while we are busy hacking away at the problem we neglect to spend enough time actually communication with the customer on the issue. Currently we have 2 main developers available to work on the web app, one of which is also pretty much the only support guy in charge of handling communication and juggling support tickets. We also have a third guy that works part time dabbling in both support and development realms. Do you have any good tips for managing support tickets and juggling both communicating with customers and actually fixing bugs?

Answer 1

It's really a function of the economic cost of bugs for a user, the cost of developers, and the cost of support staff.

If the business suffers little when bugs occur, then allowing the bug tickets to pile up is an OK business decision.

If support staff are cheap, then having a busy operations/support team can be cheaper than fixing bugs. For example, say a user has to make a phone call in order to change her password. Now, consider, it would take a developer ten hours to code a feature which would allow the user to change her own password. You basically have these costs:

x = Cost of support time * number of requests * average time to service one request
y = Cost of developer time * number of requests reduced * average time saved

Simply find the intersection of those two parameters. That's not so easy, as one needs to factor in the expected life of the software in order to determine the cost savings. You can rewrite the function in terms of how soon would fixing a problem pay for itself. You can then rank what problems would be best solved by developer hours, and what problems are best handled by support.

Another example, is say your web server freezes up every 2-4 weeks. The support staff get a complaint, and then reboot the server. You can calculate the cost to the customer, the cost of the support staff, and the development cost to troubleshoot and fix the issue. Usually the first two are easier to calculate than the third. It might take a developer an hour to find the issue, or it might be a hardware fault that escapes diagnostic testing, which takes two months for the developer to find.

Economics aside, my preference is to have a rotating schedule for developers to handle support. This gives them a good idea of what are the most time consuming support issues, and they are also the best ones to judge the cost of fixing them. Also, developers tend not to like support tasks, and will figure out economic fixes to reduce the support burden. Having each developer rotate into support ensures that they are 'eating their own dog food' to some extent.