Feb 17, 2009 / Organizing Support in Agile Product Development Company

1 comments

In 2007 we released TargetProcess v.2.5 with Help Desk on board. It was a quite powerful help desk with email integration and Help Desk Portal application. It opened new ways to provide support. We merged all support sources into one place: Help Desk. Customers send emails and they are converted to requests, sometimes customers post requests directly via Help Desk Portal. Also we have a support forum, but currently it is disconnected from Help Desk and should be monitored separately. So we had almost all the requests in one place, it looked like a good start.

Unfortunately it did not work as expected. We missed requests, we missed some communication threads and overall support quality was unstable. There were several reasons for that:

• When someone adds a comment to request, we did not receive notification. If a comment was added on Friday's evening there was a good chance to miss it.
• Sometimes we closed request thinking that the problem was resolved, but it was not. Customer would get back with comments and receive no feedback.
• There was no single person in charge of all incoming requests.
• Bugs created from requests live in backlog for quite long (several bugs have been living in the backlog for about 2 years, well, they have Small and Normal severity, but still too long).

Over the last two months we focused on support process improvement. We discovered the roots of our support problems and formalized the support process in just several simple rules.

1. Single Queue Manager. Queue Manager is responsible for all the incoming Issues and Questions. She handles requests Queue. It is a very important job and a good queue handling is a key to the great support.
• There should be no requests with reaction > 24 hrs.
• All simple requests are to be processed first (if the request can be answered right away we just answer it to shorten reaction time).
• Complex issues get prioritized and sended to QA team (QA team decides who will reproduce the issue):
• QA is responsible for the issue and communicates with customer directly.
• A bug is created from the issue and then assigned to Support Release. Support Developer takes bugs from this release and works on them.
• Product Owner is responsible for bugs prioritization in the Support Release.
• Scrum Master is responsible for new builds releases with bug fixes.
• Follow-up. If there's no reaction from customer during 2 days, we should send a follow-up.
• Clearance. Each week all issues and ideas with last comment from our side and no reaction from customer during 7 days are closed by Queue Manager (customer does not want to help and we're unable to reproduce it, so the request is closed).
2. Support Developer. One developer is allocated to support full-time each day (developers rotate during the week).
1. He provides technical help to Queue Manager and resolves complex issues.
2. He fixes bugs created from requests.
3. All ideas are handled by Product Owner.

This process has been working over the last month and I should say it works fine. Reaction times improved significantly and no requests are missed. Maybe this simple process will help other product development companies. In fact there is quite a few articles and discussions around support organization. Hope this one will be helpful and you will make less mistakes than we did.

One thing to add. Requests Queue Manager is a highly responsible job. This position demand extraordinary responsibility and the person should REALLY CARE about customers. That is the key.

Labels: help desk, support

posted by Michael Dubakov @ 6:57 AM