I’ve been plagued by emails recently from companies with whom I’ve raised support tickets and have failed to see the cases resolved to our mutual satisfaction.  Presumably these cases are festering deep in the guts of their CMS systems, which have been set by management to automatically close any cases that have been inactive for a certain period of time, marking them as “Solved” and emailing the end user.

From a management perspective this seems a great way of reducing the number of “pending” or “unsolved” cases held in their systems, which undoubtedly makes the statistics look good.  As an end-user, my experience
is usually that the case is not at all solved, and the reason for the lack of action is usually due to either the customer or techsupport department being overloaded and treating the case as a low-priority item.  Alternatively the customer gives up all hope of the company either caring about or being able to solve the problem, and goes on to buy another solution.

For those of us working in, designing for or managing technical support roles, this daft situation highlights the need to allow for the fact that some cases are never “solved”. We need our “unresolved” and keep details of why, if only for future reference during either further support or development.  We need to understand that the truth doesn’t always want to be stored in neat little boxes, nor does it always need solving.  Just acknowledging, accepting and archiving by some means.

Meanwhile where I do some across emails in such “unresolved” cases, I’ll simply bounce them back to keep the case open until a human reads the case and deals with it in a more meaningful way.  It takes just a few seconds to send a reply saying “you say it’s solved.  It isn’t”.  It’s not about being awkward, it’s about wanting to make sure that companies can’t say “everything’s great.  We couldn’t be doing better” when the end-customer experience can be rather different.