Edge of Chaos | Agile Development Blog

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.

We are working hard to improve our support. Sometimes it is very good, sometimes not. We are receiving about 20-40 requests each day via emails and Help Desk Portal, also we have several chats and phone calls. I want to share our experience and problems we are facing with, maybe it will help other companies to provide good support faster.

Manage Support using Email Client

Initially, as may other companies, we just use email client to handle incoming issues and requests. It worked fine for 2 years. There was a single inbox for all support requests and there was a single person who handled it. You may flag important requests and track them. For example, if important issue submitted, you may ask for additional info, submit a bug into TargetProcess and notify customer about new build when the bug is fixed. Usual questions are even simpler, you just answer them and forget till customer asks for more info.

However, support management via email client has several important problems and constraints.

1. It is really hard to track many requests with it. The good thing is that you have requests queue and may handle new requests nicely, but what about old requests that are not resolved so far? For example, bug created from request and it is still not fixed due to various reasons. Also we may ask for some additional information, but customer did not replied. It is likely that we want to re-ask again, but it is quite easy to forget that.

2. The other problem is when you have several people working on requests. It is not clear what request already answered and what request still waiting for the answer. 37signals uses gmail client for that and it seems it works fine for them. However it is not true for usual email clients like outlook.

3. Third, if you have several channels (live chat, phone, email) it is hard to manage them. For example, you have discussed the problem in the live chat and now want to create a bug. You add a bug, but forget to notify customer about new build when it is ready, since there is no such email in support inbox at all.

As you see, email client does not scale. It can be used if you have low volume of requests, but at some point you need something more efficient.

Interesting question. No, we don’t want to create bloatware with thousands features, complex UI and 100MB installation package. We have clear goal – help agile teams to complete projects in the most efficient way. In fact I think Help Desk/Customers Area is one of the most important modules, it helps to manage customers feedback. And customers’ feedback is the MOST useful thing you can get to improve your product, to make it really useful.

So it is all about Feedback Loop in software development. Help Desk module will provide the complete feedback loop. Check the picture below. In fact it is very clear and simple picture of any software development business (replace Help Desk Module with requests stack for example).

1. You get feedback from customers (end users if you do product development).
2. You handle the feedback somehow (Excel, cards, custom database application, office walls and floor, product manager’s long-term memory).
3. You create features and bugs based on provided feedback and own vision.
4. You implement features and bugs and deliver software to customers (expecting that they will be happier and they satisfaction will increase).

That is how almost any software development process works. Almost all Project management tools focus on Implementation (TargetProcess as well till TP 2.5 release). The tools do not care how requirements put in, the tools just manage defined requirements (user stories, epics, features). There are several problems with that approach:

1. You should manage initial requests and ideas outside PM tool. This complicates things. You need integration and this will take additional effort and time and likely end result will be not the best you can get.
2. Relations between initial request and resulted features often lost in space. You don’t remember who requested what, how many customers requested the same feature (and this information is very substantial, likely the request is important).
3. Customers can’t check progress. All they may see is that “request XYZ accepted”. In the best case you may spend a lot of time and drop them emails with confirmation that request accepted and planned for release #12.8.

What is the conclusion? The conclusion is that you may do way better with integrated Help Desk on board. Many, many things will be automated. You will not spend hours writing emails and do status reporting. You will always have clear relations between initial request and final implementation. Support will be simplified and customers’ attitude will be improved. You will receive more testimonials with “excellent support!” words and you will have more new customers.

There are no reasons to not include Help Desk into TargetProcess. The only reason is more complex UI, but TargetProcess has Process/Practices concept and it will be possible to turn off Help Desk practice and stick with simple UI if you don’t need Help Desk. We use TargetProcess for TargetProcess development. We NEED that module ourselves! We receive 20-50 requests each day. We spent a lot of time on these requests and still we don’t have clear process in place. We’ll benefit from Help Desk and it means other companies will benefit as well (we’ve already have many requests for that module to be honest :)

Next release of TargetProcess will include Help Desk. It will close the loop between development team and customers (however if you don’t have good interaction with customers then TargetProcess will not help, it just saves time and automate several things).