Do, Doc, Done captures a way of working that is popular among support engineers and which often works well. For example : a case comes my way in the issue tracking system. I fix it (Do), send an email or write a comment when I close the case (Doc) and move on to something else (Done).
There’s nothing wrong with this reactive process, but it can be even more powerful when a touch of proactivity is added, in the form of a Double-check.
A recent conversation with Alex Growcoot crystalized my thoughts on this. Alex, for his sins, runs customer-focus workshops for ARM support. He’s done a lot of work to understand how customer support could be improved, mainly using feedback from ARM’s issue tracking system. In spite of the considerable data available from the system, it’s been surprisingly difficult to work out what could (systematically) be done better.
Engineers analysed dozens of cases where customers had said they were ‘extremely satisfied’. They found a number of common themes and, unsurprisingly, quality and speed of response were the most common contributors to satisfaction.
It seems that many customers are easily satisfied (bless their souls :-). If an ARM engineer makes their pain go away, then they’re happy. Even if that engineer breaks multiple support guidelines – fails to ask basic questions, writes undecipherable emails, makes it hard to upload their testcase, etc. – then an easy-going customer may not care too much, provided the fix works.
However, we learnt more from the #2 satisfaction factor, which was that the support engineer had followed up to confirm that an issue was completely resolved. Hence, as shown by factor #1, Do, Doc, Done (D3) generally works, but Do, Doc, Double-check, Done(D4) would be even better.
This is good news, since it’s challenging to systematically improve the quality or speed of support responses. On the other hand, it’s relatively easy to have support cases systematically closed with a Double-check that, for the customer, the issue is fully resolved.
Notice that this work did not take the obvious approach of looking at negative feedback in order to understand and correct the support process. This had been tried in the past, but it was found that lessons on how to improve processes are hard to spot in most « angry customer» cases. Many are caused by events beyond the support engineer’s control – earthquakes and email inadvertently going to into the Junk folder, for example. Most others are related to fiendishly difficult technical issues and a few are caused by, let’s say, psychological glitches on the part of one of the parties. Either way, it’s hard to imagine any process that could completely eliminate such problems.
So, Alex’s data clearly shows that going a little beyond D3 makes an important difference. An email or call to check that information and data has been received and understood is greatly appreciated. What’s more, there are other advantages for the support organisation, since the exchanges which result from this type of follow up may unearth information on customer preferences, projects and future needs.
Of course, implementing a D4 process has to take account of certain obstacles:
- Time pressure: If support engineers feel that they are being measured only on the number of cases that they close each week, then D3 is the most logical way for them to go. Team leaders must therefore avoid such simplistic performance metrics.
- Perfectionism linked to blame avoidance: Even if team leaders fully support Double-checking, many engineers have in-built ‘be perfect’ and ‘hurry-up’ drivers. This may be compounded, in some cases, by the wish to avoid blame – i.e. negative feedback from the issue tracking system. These factors may cause engineers to keep their heads down and execute the D3 process as quickly and perfectly as possible, even if they are encouraged to do otherwise!
- A preference for solving clean, isolated problems: As explained in a previous article, the natural inclinations of most engineers, reinforced by their scientific training, is for solving isolated problems using analytical methods. This is easier to achieve with a D3 approach, since things often get more complex once extra customer feedback is obtained.
Once these obstacles are overcome, Alex and I believe that D4 takes significantly more time than D3 only in cases where there is a good reason for investing the extra time. And if there isn’t, then the most likely customer response is, “yes, it’s working great – thanks” … which is well worth the extra few seconds it took to make the Double-check!
