When someone submits a problem via support@smartthings.com, I’d suggest that you don’t mark the ticket as “SOLVED” until the problem is actually solved. I currently have several tickets in your support system that were marked “solved” with no resolution AND THEY ARE STILL PROBLEMS.
The message conveyed to the user when their unsolved problems are marked as being solved is “Screw you, customer, we’re not going to do anything more for this issue.”
(In my case, that might actually be the case - considering how abrasive I am and how so many of my tickets are marked as “solved” and no fix was ever made for the issues.)
@Tyler , I know you aren’t support@ anymore, but I’m hoping you can get suggestion to the proper people. I’ll put a few more tags on as I really have no idea who reads the forums who works with support@: @April, @Ben, @alex
Especially for ones that are bugs. I realize behind the scenes is probably another system for tracking bugs. But don’t mark my ticket solved, create a new category called bug submitted.
Then attach a bug ticket number and when that bug is marked resolved, follow up with us and tell us it should be fixed in next version, etc.
I’ve put a few tickets in only to get a form letter back saying “We fixed this on Friday”.
That’s great, but I submitted my ticket AFTER the “fix”. So I have to reply (via e-mail) to tell them it’s still an issue. This seems to put me at the back of the queue, since it’s at least another 24 hours minimum before a reply. Then it’s “What’s your e-mail address?”
Really? Back to the end of the line we go!
2 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
4
I discussed this at length with Tech Support Management @RyanH and @tyler1, and I give respect and appreciate the time they took to acknowledge my concern and disappointment in this choice of work flow convention, but I could not convince or impose a change of heart.
I could post the exact communication, but best to have the participants’ authorization.
In a nutshell, I suggested that it seems they are letting the limitations of the tool (ZenDesk and related progess / quality metrics reporting) drive the department’s processes and goals, instead of having the business goal of true Customer satisfaction be accurately measured and reported. @tyler1 also expressed a commitment that “a process” was now in place to actually follow-up with Customers of “Resolved” tickets when the real fix has been implemented or is available. Sounded awfully manual and thus labor intensive and error prone…
The communication was triggered from me receiving an automated ZenDesk “resolved” support ticket satisfaction survey that only offered two choices: Good (fully satisfied?) or Bad. Since my problem had not been resolved, even though the support technician had been polite and attempted to be helpful, the only accurate answer to the survey was “Bad - Unsatisfied”. We’ve been told Tech Support has a 98% “Satisfaction Rating” (totally anomalous in the industry…), but now you know how that was achieved…
Where do you see your tickets marked as “solved”? Mine just go into the great unknown and I have to come back to the community to figure out if they were fixed.
I went back to my open tickets and i have 1 still open from June 14, 2015 when i reported scheduler death issues that are still unresolved. I could be completely wrong, but maybe they are just closing out the duplicates and keeping the original open.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
8
But that doesn’t help inform and followup with the Customer’s who have reported a personal experience with a problem, to confirm that the Customer is Satisfied with the resolution…