6 ms·

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a

by ibash 2y ago

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you get a response at all.

swiftcoder 2y ago
In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored
- __MatrixMan__ 2y ago
  A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.
Viliam1234 2y ago
In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that. If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step. For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done. One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout. The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation. The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.
- dspillett 2y ago
  > In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. Yes. But also HELL NO. Back when we were a small company and I did a bit of everything, from infrastructure management to support, on top of actually doing dev work, taking to them was the bit I dreaded most at times! I do occasionally interact with our customers' technology/security teams as part of my remit is dealing with ingesting this party data and pushing information (or making it available to be pulled) the other way. That can be irritating enough, you would not believe the amount of people working in that area that don't properly understand SFTP and, for instance, get thoroughly confused by key based auth.
Vegenoid 2y ago
I worked as a sysadmin in a large physical services company. We had in-house software that integrated with almost all levels of our operations, most employees were using this software throughout their day. The whole IT staff, including the team of ~10 devs who built and maintained this software, worked in-person on the same floor. L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something. We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly). Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all. You can probably guess how user-friendly that software was, and how much the users liked it.
playingalong 2y ago
Yeah. In some rare cases there's a direct feedback button in the product itself. Then usually you don't get the response, but at least your remarks are read by someone. Or at least that's the impression I get. As a positive example - check out the new commit view page in GitHub which they are currently rolling out. There's a Feedback button which goes to a *public* discussion page with voting and comments. One can tell they are really into listening the feedback. And that's something. At least one of the miracles for free.

by ibash 2y ago

swiftcoder 2y ago

In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored

__MatrixMan__ 2y ago
A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.

Viliam1234 2y ago

In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that. If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step. For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done. One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout. The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation. The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.

dspillett 2y ago
> In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. Yes. But also HELL NO. Back when we were a small company and I did a bit of everything, from infrastructure management to support, on top of actually doing dev work, taking to them was the bit I dreaded most at times! I do occasionally interact with our customers' technology/security teams as part of my remit is dealing with ingesting this party data and pushing information (or making it available to be pulled) the other way. That can be irritating enough, you would not believe the amount of people working in that area that don't properly understand SFTP and, for instance, get thoroughly confused by key based auth.

Vegenoid 2y ago

I worked as a sysadmin in a large physical services company. We had in-house software that integrated with almost all levels of our operations, most employees were using this software throughout their day. The whole IT staff, including the team of ~10 devs who built and maintained this software, worked in-person on the same floor. L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something. We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly). Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all. You can probably guess how user-friendly that software was, and how much the users liked it.

playingalong 2y ago

Yeah. In some rare cases there's a direct feedback button in the product itself. Then usually you don't get the response, but at least your remarks are read by someone. Or at least that's the impression I get. As a positive example - check out the new commit view page in GitHub which they are currently rolling out. There's a Feedback button which goes to a *public* discussion page with voting and comments. One can tell they are really into listening the feedback. And that's something. At least one of the miracles for free.