A customer sends an email with a question. The case is an Inquiry.
A support person investigates the question and discovers a bug. Is the case now a Bug?
After fixing the bug, it is realized that there is missing functionality. Should we re-categorize again as a Feature?
And what if after all this, there is yet more work to do. Is the case finally a Schedule Item (or Task)?
|
3
1
|
|
||
|
|
|
4
|
Another potential way to address this is to keep the correspondence with the customer categorized as an "Inquiry" and then spin-off additional, related cases for the underlying bugs and/or features discussed in their email. This can also be useful depending on who you have interacting with the customer (i.e., can keep the customer support communication and underlying technical discussions in separate, but linked cases). There are pros and cons to both approaches though, so personally, I think it's a matter of finding what works best for your team. A customer inquiry creates at least one "unit" of work (i.e., one task that needs doing). For us, the resolution criteria of the inquiry case is that you, the customer, get a timely, knowledgeable response to your inquiry. Any work that we do because of your inquiry needs to be spun off into a separate case. This is not to be bureaucratic, but because we don't want you waiting around while we decide what to do about a given feature request, or fix a certain bug. Added bonus: keeping inquiries in the Inbox keeps the Autosort algorithm happy. |
|||
|
|
|
1
|
I can think of a few reasons to change a case's category, as the nature of the work remaining (or the work next to do) changes:
A few reasons not to change categories:
I'd like to say that a cases's category shouldn't change, but I think exceptions should be made for short and/or simple cases. |
||
|
|