So, here's a scenario if you are supporting users of (your) software or systems. An urgent issue is reported, and you get to work on addressing it. After a while, a workaround is discovered and for now, the problem has gone away. Or, what also happens frequently, the problem goes away by itself.
As a diligent supporting organization, you might 'ping' the user once to figure out of they are happy, and perhaps you still have some outstanding questions for them (log files, packet traces, versions installed etc). But otherwise, both user and vendor move on to more pressing issues, and we don't get to the bottom of it. It is not in most organizations' nature to focus on things that are not broken.
Time passes, and maybe a few months later, the customer is fuming, the issue is back, "and we reported this MONTHS ago, we have a 2 hour SLA, and it STILL isn't solved!" The blame is put squarely on the vendor, because the individual corporate employee most certainly isn't going to blame himself. It is just not done, and this is to be understood.
Meanwhile, you or your people dig out the old email exchange and note that "well yeah, but you didn't get back to us on X!", or the weaker variant "the workaround worked, and you went silent on it".
Escalation ensues, and it is noted that a more professional support organization would've kept nagging about the open question, or working on (what appeared to be) the low-priority remaining issue.
By now everybody is seriously pissed off at each other.
This anti-pattern is well known, and occurs everywhere. A common first-order approach to prevent it is for supporting organizations to attempt to proactively close issues that aren't progressing.
This sometimes works, but most often it makes the customer feel that their vendor is trying to artificially "solve" the issue, and not actually help.
Additionally, it doesn't feel good for people to have to agree to non-solved issues to be 'closed', or even 'solved'. In corporate environments, such things might come back to haunt the employee ('why did you sign off on that?!').
So, often a low-level stalemate develops where the customer is unwilling to spend time with the vendor to get to the bottom of the issue, but also not agreeing to close it. And a few months down the road, BOOM, "this problem STILL isn't solved, and we've been at it for MONTHS!".
Neither side wants this, but it keeps on happening, and it keeps on pissing people off. It is human nature and corporate realities working against us.
So - what is the solution? Clearly we need some indication that is acceptable to all sides, but saves a lot of shouting later on. One suggested way to achieve this is to add another status flag to an issue: 'Paused'. This does not in any way imply the issue is solved, or unimportant, or that anyone has agreed the fault is on their side.
It means what it says - this issue is paused. And if later on the problem becomes urgent again, it can be unpaused. Of course, the people that now shoulder more of the blame won't be too happy about it, but at least there is a reflection of the fact that *nobody* was working on it.
Supporting organizations meanwhile should remind supported users to respond to outstanding questions, and note that it is perfectly fine to agree to 'pause' the issue. This might even happen automatically after a few reminders.
So summarizing, by not angering people by closing issues the user is not actively working on, but by adding a 'Paused' status, when the problem resurfaces, we can all get to work faster because the mutual screaming about issues being left unresolved for months 'while we have a 4 hour SLA with you!'
As a diligent supporting organization, you might 'ping' the user once to figure out of they are happy, and perhaps you still have some outstanding questions for them (log files, packet traces, versions installed etc). But otherwise, both user and vendor move on to more pressing issues, and we don't get to the bottom of it. It is not in most organizations' nature to focus on things that are not broken.
Time passes, and maybe a few months later, the customer is fuming, the issue is back, "and we reported this MONTHS ago, we have a 2 hour SLA, and it STILL isn't solved!" The blame is put squarely on the vendor, because the individual corporate employee most certainly isn't going to blame himself. It is just not done, and this is to be understood.
Meanwhile, you or your people dig out the old email exchange and note that "well yeah, but you didn't get back to us on X!", or the weaker variant "the workaround worked, and you went silent on it".
Escalation ensues, and it is noted that a more professional support organization would've kept nagging about the open question, or working on (what appeared to be) the low-priority remaining issue.
By now everybody is seriously pissed off at each other.
This anti-pattern is well known, and occurs everywhere. A common first-order approach to prevent it is for supporting organizations to attempt to proactively close issues that aren't progressing.
This sometimes works, but most often it makes the customer feel that their vendor is trying to artificially "solve" the issue, and not actually help.
Additionally, it doesn't feel good for people to have to agree to non-solved issues to be 'closed', or even 'solved'. In corporate environments, such things might come back to haunt the employee ('why did you sign off on that?!').
So, often a low-level stalemate develops where the customer is unwilling to spend time with the vendor to get to the bottom of the issue, but also not agreeing to close it. And a few months down the road, BOOM, "this problem STILL isn't solved, and we've been at it for MONTHS!".
Neither side wants this, but it keeps on happening, and it keeps on pissing people off. It is human nature and corporate realities working against us.
So - what is the solution? Clearly we need some indication that is acceptable to all sides, but saves a lot of shouting later on. One suggested way to achieve this is to add another status flag to an issue: 'Paused'. This does not in any way imply the issue is solved, or unimportant, or that anyone has agreed the fault is on their side.
It means what it says - this issue is paused. And if later on the problem becomes urgent again, it can be unpaused. Of course, the people that now shoulder more of the blame won't be too happy about it, but at least there is a reflection of the fact that *nobody* was working on it.
Supporting organizations meanwhile should remind supported users to respond to outstanding questions, and note that it is perfectly fine to agree to 'pause' the issue. This might even happen automatically after a few reminders.
So summarizing, by not angering people by closing issues the user is not actively working on, but by adding a 'Paused' status, when the problem resurfaces, we can all get to work faster because the mutual screaming about issues being left unresolved for months 'while we have a 4 hour SLA with you!'
PS: And yes, if you really think this post is about you.. it might well be ;-)
No comments:
Post a Comment