There are better ways to understanding your customer than encouraging your entire team to give attention to inbound support.
Care to elaborate?
You have your folks on the CS frontline knowledge share their experiences with the company
Everyone should read support emails
211–214 of 214 posts
Re: Everyone should read support emails
#212Earlier quoted context omitted.
At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so un…
Yeah, going directly to the end user is almost certainly best. The amount of times you find people spend 2 hours of their days on what would be literally a 5 minute fix (my favourite being the select with a thousand options that wasn’t alphabetically sorted) is mind blowing. And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and lo…
Similar to the "users request crazy stuff", managers of users request crazy stuff based on what they think their users need. Stuff that goes up and down two very different reporting chains (up the users' then back down yours) is almost always going to be some weird telephone game crazily divorced from reality.
"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.
Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)
Re: Everyone should read support emails
#213Hi, Support Engineering Manager here, who has forgone Dev for a career in Support. In a small company ( As companies grow 2 things that I think are really more valuable: - Support Engineers, These are folks that have commit access and can write fixes, who are focused directly on customers. Don't distract product from new features, Support Engineers can fix low hanging bugs, (button states weird/form is weird, error m…
[deleted]
Re: Everyone should read support emails
#214The flip side of this, of course, is that not everyone wants to be involved in support and that sharing around the support burden can lead to a loss of focus within the organization. Often everybody doing everything is indistinguishable from everybody doing nothing. At my last job the support team was a thin abstraction layer that seemed to pass almost everything directly through to my dev team. For a while I enjoyed…
So much this. I'm working for a company that used to have Support Engineers and now does not, and I now get bombarded directly with requests from customers, and I haven't been able to make any effective new development happen for months as a result.
Those Support Engineers are invaluable. They can investigate those requests, decide which ones are legitimate (we get a lot of either one-off minor freak things happening due to network glitches or customers just interacting with the software in really crazy ways and we don't have time to baby proof the software -- I should note that this is internal software, so we only have a couple hundred users), and for the things that do happen from time to time, like a customer accidentally closed something out and needs to reopen it but we don't normally allow that to happen so it doesn't get abused, we provide tools so the support engineer can fix those things without involving the rest of the dev team.
Once those things are taken care of, everything that's left, assuming the support engineer thinks it's important enough, can then be passed along to us. We used to only get a handful of those a month.
Now that there's no Support Engineer I get these requests all the time, and I'm getting burnt out, as I'm effectively working two jobs now instead of one (actually four, as I'm also an Architect now and the director of the phone systems, without the promotion, and basically have four bosses now, who don't communicate with each other and each have their own high priority requests I'm expected to do for each of them in addition to dev and support work, but that's another story....we lost a lot of people and there's almost no efforts being made to replace them).