The problem with submitting a log is there is never any feedback from Wyze. Calling support is a joke since you only get front-line staff working off of scripts. If the scripts don’t work the typical answer is to send replacement hardware, which probably has the same issue as the current one. There also is no obvious way to get a problem escalated when the CS agent doesn’t know what to do, let alone wasting potentially hours on the phone only to receive inadequate responses.
Turns out neither are democracies.
Seriously, though, I was just thinking (to myself) Mike’s thought over in the Dark Theme Wishlist item yesterday.
I always submit a log, and when I speak to customer service/support I give them the pertinent log numbers and they escalate and I usually get a response directly tied to the log and issue.
In this case, in 2018, I found the process satisfying enough, a reasonable effort. I haven’t used phone or email support since 2019, using this forum and submitting logs when requested by staff on occasion instead. I don’t expect much but am sometimes pleasantly surprised.
It sounds like the experience these days is… not as good? Or varies widely?
Back in the day, if you demonstrated that you had some skill and were documenting things in detail, you got transferred to ‘better’ agents, I think. I remember hearing others back then claim similar, @gemniii comes to mind…
I will echo this sentiment. I am grateful to have access to this Software/Firmware Known Issues list but it means if an issue I see that looks like a bug isn’t on that list I get to live in bug-purgatory. I reported it, submitted a log, contacted customer support but… silence.
This is a bad customer experience.
Customers can deal with disappointment (“We’re not going to fix that, add that, modify that, etc”) but uncertainty is a negative experience.
I wish Wyze did a better job with this. The two it’s clearly a bug issues resulted in a lot of customer service chat time for me and it was clear the CS agent didn’t understand the issue well enough to recognize it wasn’t a hardware failure, it was a software bug. That was also really frustrating.
You’d think Wyze, with its very savvy tech-product leadership team, would understand that there are tech experts out there using their products and, while they sometimes get it wrong, they can be a real asset for the development and debugging process. Just got to use them effectively.
That is such a good idea! I wish I would have suggested that!.. Oh wait… I did!
(I’m just emphatically agreeing with someone who obviously gets it! )
IMO, the Wyze approach to dealing with bugs and issues with their software is akin to driving in India. There are no rules. Anyone can drive anywhere at any time in any direction and if you get there safely you have succeeded. Take your chances again tomorrow. With no rules, no clear direction, no order: chaos ensues.
Right now, logs submitted are useless unless a DEVELOPER looks at them, The CS ‘Wizards’ cannot look at them and wouldn’t know what they are looking at if they did.
There are multiple platforms used (Discord, Facebook, Reddit) wherein Wyze actually solicits the reporting of these bugs and problems yet has no central status reporting feature as discussed above nor a way to track that in real time and publish it to update all users with specifics.
This is chaos, and disorganized chaos at that because there is no critical information data gathering on the front end that would identify hardware specifics, OS, App and FW versions when the bug or issue is initially reported. A simple web input form with data fields would capture all the data needed that would answer the many questions that get asked back and forth over and over… what OS are you using, what is the version number, what is the firmware number, which cam was that for, what version of the app are you using.
And lastly, there should be NO NEED for reporting or discussion of these bugs in any forum anywhere. (Alpha and Beta Testers should be on a private login credential forum with direct access and contact with specific WyzeTeam developers). Wyze needs to seriously tighten up the QA and get it right BEFORE IT IS RELEASED! The release of buggy software just shows a lack of stringent policy and procedures in the Wyze organization and a clear disregard for Quality Assurance. Platform stability is critical.
You’re confident they don’t have an organized process all this chaos sorts into? I assumed they must have.
With Segment and Braze, they have software/services that aggregate data and unify their efforts to work with it. I figured they must have comparable stuff to bug track, project manage, etc.
I have no background in any of this, just making what seems to me a reasonable guess.
(Also figure they must like on some level customers getting all up in their business (the digital exhaust from which is aggregated and unified into something AI alchemical. ))
You do know what happens when you assume.
I would predict they do have something internally for their workflow tracking and management. What is missing in this situation is the front loading of highly specified data points from the user reporting side and a detailed and organized bug publication report that can then be viewed and tracked by affected users.
Digital exhaust! ROFL!
I do know about assuming, but proceed advisedly
Think I heard it from Shoshana Zuboff though I don’t know if she coined it. She has the hair of twenty women and the confidence of twenty more!
I sleep now…
I’m fairly confident and the reason is in your own sentence. Having an “organized process all this chaos sorts into” is an oxymoron.
It’s a game of playing whack-a-mole in a field full or rabbit holes!
People also assume that logs are like cockpit recorders in aircraft. For the most part they are not though some server logs are close. Logs only record the events they are programmed to record. It’s not unusual to see the “symptom” recorded as the event with no idea as to the cause. With the amount of logs they’ve received on this, I doubt they’ve been of much use.
What we do know is there was a firmware version for the hardware that didn’t have a problem. In plain English, you start there and then figure out what you broke. It’s a painful process, side by side, step by step with full bit logging as you go. For many devs, we’d rather go to the dentist
You mean there isn’t some kind of heuristic habba-babba that swirls it into happy glop?
Yep, it’s found somewhere between somebody’s left and right ear, in most cases
Towel K’s like, “It’s a cinch, folks, follow my lead…”
After escalation does it proceed via email? That’s what I prefer…
Normally everything is done via email from that point forward, but I have had the occasional phone call as well.
Mind you, it’s been over a year since my last need to do that, so I can’t speak for how well that works now… But I’ll be finding out shortly as I have a bricked base station from the faulty firmware update.
I wish you’d compose a poll to test this. I want to believe it but I’m not sure I do.
(The mods’ll be like, ‘Sure most people will say they can, but we’ve got the digital exhaust to prove otherwise’ )
Implementation matters! You walk into the DMV and they say the wait is 2hrs, have a seat and be patient – yeah, everyone is going to complain but overall that’s much better than you walk into the DMV they say, “We have no idea how long the wait is going to be,” and you end up waiting 2hrs and that whole time you are saying, “How long is this going to take!?” With all your ire building up.
Setting expectations matter. People will still whinge but they can be given context and usually chill out.
Secrecy, uncertainty, and no expectations being set. Tantrum time.
I love my dentist! !
She gives me happy pills !
I’ve had good luck calling CS when I’m in a laugh-y mood. I’m cereal. They get super sad and one’s good nature helps them out.