
Everyone should read support emails - stuffhq
https://medium.com/@simonschultzdk/why-everyone-should-read-support-emails-42ca2172e23e
======
superice
This is why we regularly take developers to customers. It is eye-opening to
see on-site that your mobile app with tiny but well-designed buttons doesn't
work for registering container positions when the user is in a shaky 90 metric
tons weighing machine, handling 30 metric ton containers.

We write software for container terminal and other logistical actors, and
seeing the software being used by real users is so incredibly important when
designing new screens and workflows, it's baffling to me that developers
aren't taken on-site more often.

~~~
duxup
I think that's valuable, but depends on the organization. At a company I
worked at engineering used to go on customer visits, but the "customers" were
the executives and managers who make buying decisions and put forth
requirements. However, these were not the folks who actually used the product.
Their opinion was important (gotta sell it) but it was NOTHING like what we
saw in support.

The the few times end users were there, they clearly did not give their honest
opinion in front of their bosses. And really even folks giving feedback who
use a product are poor at doing son.

But support is where the rubber hits the road and folks actually encounter
real issues that they can't solve on their own and create real pain points
that will come up.

In my example there were still a lot of issues we'd take back to engineering
and they'd say something that amounted to "but they said they don't use it
that way" and it was a real chore to get engineering to understand the
difference between what an executive asks for / some of the requirements they
were given, and what the real user does / needs / asks for. Understandably
engineering resources were sometimes irked by this, and support often took the
hit politically because of it. It was one of the reasons I got out of support
despite getting along with the engineering teams really well.

~~~
hobs
At the last company I worked at they brought glad handers to take care of the
execs while I the "low level tech" went around to people's cubes and spent 2-3
days talking to them, understanding their requirements (usually with NO
meetings, just 1-1 after talking with their managers and leads.)

This got me the best feedback I have ever gotten, and I regularly implemented
fixes and changes that made the C-levels rave about the product (because their
entire staff was so surprised at someone giving a shit.)

I was quite impressed by my head of product's subterfuge, she was incredibly
talented.

~~~
WorldMaker
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 unhappy with me though for breaking
protocol.

That job taught me a lot about what to avoid in a corporate culture, because
of how dysfunctional that was that the more actual work I did the worse my
reviews got and the more my managers seemed to hate/resent me being on the
project. It was a situation I hope never to repeat in my career.

~~~
Aeolun
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 look at
what they actually do.

~~~
froindt
I love finding those high impact, straightforward changes! I support dozens of
spreadsheets at work and am the person people call when one breaks.

* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.

* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.

* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.

~~~
BostonEnginerd
Every company needs one person who can make simple changes to inefficient
business processes and save a ton of time.

~~~
Ntrails
I feel like there are a couple of obvious problems that exist:

\- Knowing that such a person exists \- Knowing that the fix is simple \-
Knowing that they will have time to look at a thing quickly

I'm a person who will answer any question on any topic if asked, and help
anyone with anything if I have the ability to do so. That's because I enjoy
doing stuff in general and my long projects aren't meaningfully going to
suffer. Counterpoint, the only people pestering me on this are friends / close
colleagues and it wouldn't scale.

I reckon that the net benefit of being willing to do that to the company is
positive, but honestly I'd do it anyway because sometimes 2 hours hacking on a
powershell script is a welcome distraction!

------
lbotos
Hi, Support Engineering Manager here, who has forgone Dev for a career in
Support.

In a small company (<10), yes, do this, everyone will level up, and you'll get
extreme customer focus.

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 messages wrong, etc, etc), and then funnel harder
or product-changing bugs to product. For every 10 devs, I think you should
have 1 Support Engineer.

\- LISTENING to your support team. I always see companies and people doing the
"uhm, oh yeah, we should totally all jump in and do support to better
understand it" but really, it's like, trust and LISTEN to your support team,
ask them what the most important thing to them is, and actually prioritize it.

It was extremely demoralizing when "holier than thou" devs came to do support
and kicked and screamed for their week rotation. Sure, thats indicative of bad
culture, but I promise you there are at least a few devs on your team who are
this way right now. Let them be devs, instill a culture of trust and teamwork
in different areas, and your company can scale and move fast.

~~~
trynewideas
Some caveats and related advice, having been on the product side and two
different customer-facing sides:

Integrate support engineers at least part-time into the product engineering
teams. Support engineers who don't know what product is doing can duplicate or
complicate product work.

Invest in paying and training the support engineers. Don't pay them well and
they'll either transfer to product engineering once they get competent or jump
ship to someone else. Poorly trained support engineers who "have commit access
and can write fixes" will invariably introduce new bugs that will block
product work.

"Don't distract product from new features" is a great goal, but recognize that
it's a goal, not a law. There will be fires that product engineering will have
to walk into and put out alongside support engineering, especially if your
product is more than an small-team app, exponentially if the problem comes
about due to systemic design problems on the product side.

It will be tempting to outsource support engineering to save money for in-
housing product. Don't. If anything, outsource low-hanging product work before
any support work. In-region support engineers make everything about
firefighting smoother and customers in every geo will appreciate it.

Incorporate support pain into your dev process. That's not bug metrics—measure
the _pain_ your product causes customers. Feature requests are pain.
Insufficient docs are pain. Licensing issues are pain. You can insulate
product from customers, but don't insulate them from the pain the product
causes customers. Use it to help guide the roadmap and you'll find low-hanging
fruit that product never considers because, chances are, they aren't
interacting with painful parts of the product (otherwise they'd already be
addressing it).

~~~
lbotos
I love this extra perspective to my comment!

The only thing I'd add:

> who "have commit access and can write fixes" will invariably introduce new
> bugs that will block product work.

All fixes by Support Engineers should go through the normal CI pipeline and
Code Review process. This is designed to exactly stave off this kind of
effect. But yes, I still agree with your points! I love HN <3

------
AllegedAlec
I once joined our support team to talk with one of our clients (I'd written a
new bit of functionality and they wanted me there in case they would ask
technical questions). It was one of the most eye-opening experiences ever. Our
client talk about their clients abusing our software in ways that we as a
development team had never even thought about.

EDIT:

On the other hand, I don't think it should be done to create a sense of
urgency for developers. They are not going to work better if they also have to
worry about each and every emotion that's being displayed in support emails
like the example in the article. That's just creating a sense of
responsibility in your company by appealing to emotions and guilt.

~~~
mercer
Could you elaborate on the kinds of abuse you saw?

~~~
AllegedAlec
> Could you elaborate on the kinds of abuse you saw?

In a very broad sense, sure. I don't want this account to be traceable to
where I work now, so some details will be changed or omitted while keeping the
kind of abuse the same.

We make a website where our clients can make timeslots available to the
general public. The length of a timeslot is dependent on how many people the
person booking slot intends to bring, as well as some other factors. Whether a
person can book at a certain time therefore (partially) depends on how many
people they tell our clients they'll bring.

We also made it so that the booker can change how many people will be coming
along (for example because of sickness), or, if they are delayed, by how much,
so our clients can more fully use all of their available resources.

However, how bookers were often using it, is by saying they'd come alone (if
you have a very short timeslot, there's a better chance it's still available),
and then change the number of people to how many were actually coming along.
Or they'd just book a slot at the start of the day, and then delay it until
they were placed on the time they actually intended to come. In both of these
cases, they were abusing features which were genuinely needed for the product
to work to their own advantage. It was slightly naive of us as developers not
to take this sort of behaviour into account.

------
scrollaway
Fully agreed. I'll go a bit further: Everyone, _especially engineers and PMs_
, should once in a while actually reply to support emails. As CTO of my
previous company, I still found time for large amounts of customer support,
and so did one of my cofounders.

It's definitely important IMO for key people to be in contact with the
userbase. Get a better look at what people are asking for, feel more directly
responsible for both CS failures and successes, etc. And it overall increases
the quality of support (rather than put people in CS who have no idea what's
going on aside from the script they follow).

Key quote from the article:

> _My experience with everyone reading support emails is, that everyone feel
> an increased responsibility and a sense of urgency to eliminate whatever
> emails hits your support inbox._

I am always sad when I see people who think doing customer support is beneath
them. It's a red flag, IMO.

~~~
kruczek
While reading the article, I got a feeling that reading support emails is only
one step away from answering support emails - and here you are, suggesting
just that.

I've seen further steps down this road - if there are engineers already
answering support emails, then why do we need support people at all. After
all, engineers have better knowledge of technical details and can make changes
themselves. No need for intermediaries.

I understand the reasons for having engineers read (or maybe even sometimes
answer) support emails, but still I'd be extremely wary of again working for a
company that walks this path.

~~~
anilakar
The reason lower-tier support personnel are employed is because someone
reasoned that the engineers' time is too valuable. If 90 % of incoming support
requests will be escalated to developers, it makes little sense to have extra
people whose main task is to create SAP tickets or press "forward" in Outlook.

Another extra perk of making devs handle the support is that they also have
the chance to fix the underlying problem. Remember that for an engineer,
fixing broken software is always less of a burden than correspondence with
customers.

~~~
mike22
For our on-prem enterprise software, we have two levels before a ticket
reaches the dev team. Level one handles RTFM-type answers, and asks for log
files (and then provide RTFM answers or engage a dev). Level two handles
demos, implementation and architecture guidance, and reproducing more complex
bugs. Dev handles the most complex issues that trickle down, and backup when
staffing is short (mainly only around holiday weekends).

------
t3rabytes
At Basecamp, everyone in the company does a workday in support every month or
two. It's a fascinating experience to take part in:
[https://github.com/basecamp/handbook/blob/master/our-
rituals...](https://github.com/basecamp/handbook/blob/master/our-
rituals.md#everyone-on-support-eos)

~~~
pinko
I worked on a software project for 10 years where we did this, with 5-25
developers in the rotation over time (we grew). It was unpopular with many of
them, but I loved it, and found it incredibly valuable. Even the people who
thought it was useful learned valuable context they didn't realize they
learned (e.g., how helpful our own documentation was when they needed it).

~~~
Aeolun
I really like the idea of doing a day of support a month. When I did it every
day of the week it drove me crazy and made me really cynical though.

------
nostrebored
This is one of my favorite things about Amazon's support system. Support has
direct access to PMs, developers, customer facing solutions architects and all
of these orgs have close connections to the customers as a result. While not
everyone has access to the support cases, customer sentiment is conveyed as
part of this process and features or bug fixes are quickly roadmapped as a
result of customer pain.

The fact that there's someone at the other end of the support channel who
actively cares and understands the problem and the customer's voice is being
conveyed company wide creates a better experience for everyone.

~~~
endofcapital
I have reported and watched maybe half a dozen bugs get fixed on Amazon,
starting in 2003 I think. Never even experienced a reply from any other
company when trying to report problems over the years.

I think a handful of companies are getting more proactive with security
reporting, but everyone still treats the quality of their services and front
line support system as an afterthought.

~~~
mgkimsal
The customers _are_ testers, especially in "break early, break often"
scenarios. I wouldn't _call_ them testers to their face, but... operationally,
they're part of the loop. Treat them as such. If you're not going to pay for
much testing up front, at least treat the real testers (customers/endusers) as
part of a process, not as part of a problem.

If, when I reported an issue, _and_ it was determined not to be PEBKAC... loop
me in on updates, or followup with questions. I'm happy to try to reproduce
issues, or give more details, or whatnot. I'm a user/customer - I want the
product/service, and I want it to be better.

------
adwww
"We can't give devs access to support, because [ZenDesk, FreshDesk, etc] costs
9 gazillion dollars per user"

~~~
stuffhq
For that exact reason I've had a weekly "emails and chill" date with a
supporter. Brought coffee for both of us. I flicked through incoming support
emails for 30-40 minutes....

~~~
spiderfarmer
We did the same thing with a small team. Did wonders for our response time and
for refining our support processes.

------
RickJWagner
Support engineer here. For anyone considering a career in support:

\- It's harder than development. Green fields are easier.

\- It's pretty much a thankless job.

\- You are sort of the janitors of the IT world. Not much respect.

\+ The money can be pretty good. Because of the above, management usually
rewards good support engineers.

\+ You are welcomed by those who don't want to do support.

\+ You stay fresh, learning other people's ideas all the time. This
contributes to longevity.

All things considered, it's been a good career move for me. YMMV.

~~~
levi-turner
Very good list, although I'd disagree about pay. I'd add:

\+ it's one of the easier routes to becoming a literal expert in how to deploy
the software.

~~~
jpatokal
Pay for level 1 positions is indeed not great, but the money is pretty good in
companies that value support enough to do it in-house and once you've learned
enough to be senior/backline to a whole crew of juniors.

I do agree that the pay does not necessarily reflect the fact that the job is
often harder than mere software development: you're basically debugging other
people's software in realtime, often while angry people yell at you.

------
Sir_Cmpwn
Since the article author appears to be the submitter: you should quit Medium.
It's not helping your content when a full-page popup obscures it and entices
your users away to a sign-up page, then keeps nagging them with popup nagbars
on either end of the page.

If you need help migrating to another platform, please shoot me an email.

~~~
alanfalcon
Not the OP, and I don’t disagree re: the nightmare Medium has (predictably)
become. But I’d love to know what platform would you suggest?

~~~
Sir_Cmpwn
I self-host my Jekyll-based blog, by compiling each push on builds.sr.ht and
rsync'ing it onto a static web server. Basically roll-your-own GitHub pages. I
also wrote a tool which converts your Medium posts into a Jekyll blog.

[https://git.sr.ht/~sircmpwn/unmediumify](https://git.sr.ht/~sircmpwn/unmediumify)

~~~
gravypod
Have you considered building [https://cdn.sr.ht](https://cdn.sr.ht)? I do a
similar process for some sites and use AWS CloudFront to essentially get
globally deployed static sites.

Since this is a workflow you've encountered might be something that people
would pay for. I definitely like a CloudFront alternative that wasn't as
overpriced.

------
achow
The day Bill Gates answered a support call

[https://blogs.msdn.microsoft.com/oldnewthing/20091123-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20091123-00/?p=15943)

~~~
monsieurbanana
I'm very skeptic that the customer would believe it was actually Bill Gates
that took his call.

I could imagine it if it was a grandma or grandpa (or similar, you get the
idea)... but then she wouldn't know who Bill Gates was anyways.

~~~
gist
Bill could be all nice, calm, and helpful because he is not sitting there
every day taking calls from end users having to actually work according to
some metrics and deal with aggravation.

------
tgtweak
If a user is willing to message you, you can be sure many hundred other users
are thinking/experiencing the same thing.

I remember support commenting that lots of users seemed concerned about
security (messaging to ask if their files are kept after) and we were removing
them, plus it was written in the privacy and terms page.

Finally we put in plain writing that we didn't keep any files, right on the
landing page... 40% lift in conversions.

Support is a better signal than exit surveys.

------
AnIdiotOnTheNet
That would require developers to think of users as people instead of cattle,
and then they might have to accept that the decisions they made because
"developer time is worth more than user time" have an actual real-world cost
on actual real-world people.

~~~
_carl_jung
In my experience, such time pressure comes from management, not the developers
themselves. This is evidenced by the painstaking effort a dev will go to to
make their ultimate experience on a side project.

In other words, users are often sidelined by new feature requests (for other
users) rather than a selfish conservation of time by developers.

The priority game is as yet unsolved, unless you can point me to contrary
evidence (which I would be eternally grateful for).

~~~
AnIdiotOnTheNet
> In my experience, such time pressure comes from management

In my experience, open source developers are just as bad, if not worse, when
it comes to their treatment of users.

~~~
badsectoracula
Yes, but open source developers are in their vast majority unpaid volunteers
gifting their labor to other users, so these users can either accept the gift
as it is or not accept and move on. They are not entitled to other people's
work and time for free.

~~~
arkades
>>> such dev behavior is driven by managers

>> open source people, who don’t answer to managers, act similarly. Therefore,
it seems unlikely to be due to managerial influence.

> well open source is a gift of labor, people shouldn’t look a gift horse in
> the mouth

What you say may be true, but also irrelevant to the discussion being had.

------
jacquesm
Take it one further: everyone should do support, not just read the emails. 1
day per month or so should do the job, it puts everybody in a good position to
appreciate that if they don't do their work properly the support people end up
taking the heat. So do not just read the emails, answer them, make it work for
the end-user and spot the dysfunctional bits in your organization first hand.

~~~
AdmiralAsshat
> Take it one further: everyone should do support, not just read the emails.

That's a really fast way to burn out your entire team.

Devs don't necessarily have good communication or people skills. They haven't
been trained to respond politely when someone sends them a screaming, all-caps
e-mail that their product is garbage. That's my job as the Support Engineer.

~~~
the_gastropod
While that stereotype may be true for _some_ developers, I don't find it holds
for most devs I know and work with. People incapable of dealing with emotion
probably don't make great employees to begin with.

~~~
AdmiralAsshat
The emotional response is probably the most egregious that a developer can do,
but I stand by my assertion that developers _aren 't trained in
communications_. I work with some developers who write amazing code, but if
you read their emails, you'd think they were written by a ten year-old. The
responses are terse, lack proper punctuation, and usually rife with
misspellings. And that's _fine_ : their job is to write code, after all. But
it doesn't look good if that raw response goes out to the customer.

------
magicalhippo
When I started at my current place, I had some great learning experiences
answering the support phone after the regular support staff had gone home for
the day. Officially our support ended at 1600, but sometimes I'd hear the
phone ring 5-6 times in a row, so I figured they probably had an urgent issue
and picked it up.

Since I was still quite new, this introduced me to areas of the program I
didn't know very well yet, as well as learning just how the users used our
program. This knowledge has been invaluable when improving the program.

I also had several instances of me going "wait why did you click there before
going here?" with a reply along the lines of "oh if I don't do that I'll get
an error message, let me show you", bugs that had never been reported yet
being present for years.

------
jurassic
The 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
it -- it is satisfying to see how my efforts could directly help customers,
undertand how they were using the product, etc. The type of software I was
working on meant that technical configuration problems were showstoppers and
people hailed me as a hero whenever I stepped in and resolved their issues.

The downsides were insidious and slow to show themselves: lack of time to
invest in fixing problems in a systematic way rather than helping customers
one-by-one because of time consumed by support, inability to focus on feature
work due to support-related interruptions up to 2-3 times per day, the
sentiment from leadership that we weren't delivering new features fast enough
because of our invisible support labor, the feeling of being "always on"
because we had customers with high-urgency tickets around the globe, etc.

After two years of that, I was staring burnout in the face. I told my
leadership I didn't want to work this way but nothing changed. When a month
went by where I only made 3 commits to source despite feeling overwhelmingly
busy I knew something had to change, if not in the org then in myself. I told
my manager I simply would not participate in support any more and was deleting
Slack from my phone, that if they wanted a good customer experience they
needed to make the necessary investments. In my mind this ultimatum was the
first step toward quitting my job. But an amazing thing happened once I
started putting boundaries in place: leadership started talking about the need
for better systems, better documentation, the need to prioritize work that
would make the product easier to use and support. My productivity on feature
work skyrocketed and my product managers were happy because we were over-
delivering for their bosses after under-delivering for so long. I was given a
large raise a few months later, the kind people normally have to change jobs
to get.

For myself, I learned it's important not to enable dysfunctional process just
because I can excel, for a while, in that process. I learned it's important to
set boundaries in my work. I learned that focus is sacred and should be
protected. If you are a leader in your company thinking about diffusing the
support burden, carefully consider the productivity cost to your most
expensive/valuable employees that comes with repeated direct exposure to
customers.

~~~
cableshaft
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).

------
robbiemitchell
Agree 100%. The trouble is, you can't ask everyone to read everything, and
it's not always affordable or even possible to give everyone access to the
data. Our goal at frame.ai is to help you understand and act on your chats and
emails -- everywhere they happen -- by drawing your attention to the
conversations that warrant it.

Data are normalized and unified from sources including Zendesk, Intercom,
Slack, and Service Cloud. Destinations include manual export, with triggered
alert and warehouse sync under development.

In the middle is a layer of enrichment and search-based dashboard prototyping.
Enrichment includes "sentiment moments" (wins, issues, risks), conversation
cleanup via elastic tagging, and auto-tagging. You can see a peek at some of
our research in this area at this blog post: [https://blog.frame.ai/learning-
more-with-less-1e618a5aa160](https://blog.frame.ai/learning-more-with-
less-1e618a5aa160)

Importantly, there's no per-seat charge. We think everyone in the company who
can have access should be able to explore customer conversations, visualize
them, and export for further analysis and presentation.

------
nkrisc
One great thing my company does is put a prominent link on the intranet
homepage where anyone in the company can schedule a 1 hour shadowing session
with customer support. You don't need a reason and within a few hours you've
got time scheduled within the next few days. I think the whole process was
actually driven by support as they wanted the rest of company to know what
they do and see what they see.

~~~
the_duke
So, does anyone actually do it?

------
bonestamp2
We have a policy that if a bug generates more than 20 support calls in a day,
the developer who introduced the bug has to spend the next day in the call
center answering support calls. It's not designed as a punishment. It's
designed as an eye opener to the effect it has when we don't write proper
tests or don't take proper care in making changes.

~~~
stevekemp
Does it "work"?, because it really does sound like punishment.

I'm an advocate for developers reading/handling support things, but at the
same time the skills that make a good developer are not necessarily the same
as those that make a good support person. Having some rota/schedule makes
sense, but it seems like a full day of doing support isn't going to make a
developer happy, primarily because they want to be a developer - not a
support-person.

------
jdorfman
I started my career in technical support and looking back it was one of the
greatest learning experiences.

The Support Team knows the product better than anyone in the company which is
extremely valuable if/when you get promoted to another position within the
company.

~~~
duxup
I did the same. Worked in support, moved on to web development. It teaches you
so much about understanding and communicating with customers.

I had some conversations recently where I offered my opinion.

"I think this might be a bit complex for the given users who are using this."

"But they want all this information, we're doing it."

A few weeks later end customers are all confused and they're up in arms
because they can't figure out how things work because the product threw the
kitchen sink at them on one or two pages...

------
ape4
Now its impossible to email many companies I find. You click on "Contact" and
get Twitter, Instagram, Facebook... but not email :(

~~~
AllegedAlec
A few weeks ago I tried to make a complaint to the national mail service,
because they decided the pickup point closest to me was about half an hour
from my house, rather than the pickup point that was literally around the
corner.

They had an online complaint form, but you were only able to use it on
workdays between 0900 and 1600.

~~~
SketchySeaBeast
> They had an online complaint form, but you were only able to use it on
> workdays between 0900 and 1600.

Was it an interactive form with immediate feedback? I'm trying to figure out a
way to justify hours on a feedback form.

~~~
AllegedAlec
They promised feedback within a couple of hours. Even so, I see no reason to
limit it in this manner, just tell them you'll to to get back the same day or
the first workday...

~~~
SketchySeaBeast
Oh yeah, that's ridiculous (they won't be getting back to you in a couple of
hours after 4 pm). I'm sure it's a result of a institutional momentum, and
nothing to do with actually capabilities.

------
joeblau
At Amazon, our team did a day of shadowing tech support calls and it was
extremely illuminating. You think you've designed your product to work a
certain way, but your message may not be communicated very well to your
customers. If it's possible, I would try to get on a support call or support a
customer to gain that empathy to really understand what challenges people
using your products are having.

------
hw
At Re:amaze, we don't hire for customer support personnel. Our culture is that
everyone that we currently have on staff, be it engineers, co-founders,
marketing - all work on customer support. Granted, we're a small team right
now that makes it quite possible to do so, but it really keeps things super
lean. We're also a chat and helpdesk platform, so it helps to have everyone
use and understand the product.

There's also plenty that can be learned from answering support - from
discovering bugs to fixing them to understanding feature requests to
satisfying customers (and the joy that you get from a happy customer), that
it's our main onboarding tool for our hires across all departments. Sometimes
support can take up a couple hours for a team member, but it's totally worth
it. Not to mention our customers absolutely love our helpfulness and
responsiveness in support and is one of the main reasons we've had plenty of
businesses switch over from our competitors.

~~~
behringer
That doesn't work at scale. Imagine your marketing team fielding password
reset failures all day.

For a small company though, sounds like a fine way of doing things as long as
people don't get bitter about the ones who actively avoid doing the support.

------
barrkel
By all means make e.g. Zendesk tickets available on a Slack channel, so people
can dip their toes in and see how things are looking.

Don't spam everyone with every support email. You need a ticketing system at
least to coordinate work, and prioritization and assignment to get workflow.
Don't spam everyone with new tickets in the ticketing system either.

Having a rota of developers who either work directly with support, or on
diagnosing and addressing issues that have come from support, is also a good
idea I think. Problem areas will filter through from this.

Having all developers always interruptible by support will just slow things
down. Interruptions from support often blow away half a day or more worth of
development time, from context switching, checking out specific branches etc.

------
mlthoughts2018
How do you prevent this from becoming another stream of continuous disruptions
that prevent knowledge workers from having enough sustained, concentrated time
to develop big picture solutions?

Obviously you want to prioritize work to address what adds value for the
customer. But can you really do that if everyone has to be constantly
disrupting their work to scan incoming streams of idiosyncratic support
requests? That doesn’t make sense to me.

I’m all for cultivating empathy for the customer and keeping people informed,
but why does that need to be based on a constant inflowing stream of requests,
as opposed to a monthly customer-focused all-hands meeting or something?

~~~
linuxftw
This is literally what the 'management' types should be doing, and then
prioritizing this work along with feature work.

The support org should have enough staffing to be able to 'train up' and start
tackling more and more issues themselves. Even if they're not writing the
software, they can often work to get reproducables or get you most of the way
there "null pointer deref of x caused this bug" etc.

------
ljm
One of my proudest moments in my career was when I took this to the next level
and set myself up as the go-between between support and dev. We were building
internal productivity tools so we could help the support folks clear things up
more quickly, and give them the administrative resources they needed to do so.
It was all about empathy with the user: the end user, and the support user on
the admin side.

It was not a glamorous job at all but it had a meaningful impact, one that
many people gloss over, and I feel the same when reading this. The best thing
you can do is care about your users and the people who deal with your users.

------
jansen
We did this at Loom (W12) and it was one of the most powerful things we could
have done as a team. Internal comms became much more streamlined as a result
and it was usually apparent to everyone what we needed to work on next.

------
edw519
This works both ways. Once I took a job with a large software house who put me
in support for my first 3 months (to learn the system :-) It was the worst
software I had ever seen. Customers were calling in with problems that had
been solved by everyone else 10 years prior. We had over 5,000 open bug
tickets. And most of the programmers who had written them were still there,
spewing out technical debt faster than ever (now that they were agile lol).

I couldn't even make it the 3 months. They didn't either. Their customers'
lawyers were more agile than they were.

------
mb_72
I often listen in to support calls when I'm on Skype with my business partner
(I'm the dev, he's the sales / support / biz owner); this isn't planned, but
happens because he's the only one who can take the calls. There isn't a single
call I haven't learned something from, or (more positively) haven't had an
idea on how to improve the product from. I've also learned a lot of respect
for him as someone who not only keeps his cool with a (admittedly!) sometimes
grumpy dev, but oftentimes grumpy customers.

------
taf2
I built my whole company around this idea. For years, I was the front line
support - IMO, its the best thing you can do to improve not only your product
but your approach to life. That and having kids.

~~~
mrhappyunhappy
How did having kids improve your approach to life? (This is for my own
comparisons sake since having a kid also changed my life and how I think)

~~~
taf2
One thing I always liked to do now is imagine the person who's angry or
annoying me is just a 2 or 3 year old. It's much more fun and takes the edge
off the situation whatever it might be...

------
ianamartin
When simple (the internet bank) was first getting started, I was in their
public beta. Support was handled by the developers. All the engineers had to
do rotations on support.

As an engineer, I think I would hate that being a required part of the job.
But also as an engineer who works in the banking/transaction processing
industry, the support was damn amazing.

A ton of things about the company went downhill as they grew and especially
after they were acquired, but the support turning completely crappy was the
worst by far.

------
throwaway456321
This is a great idea. Read a few customer emails and you will never again have
a dispute over whether a GUI is simple enough to understand. Whatever you do,
it won't be.

------
gumby
Excellent policy. A couple of other operational "eye openers" that have worked
for me:

\- If you run a business targeting the enterprise, have everyone on the
management team go on a sales call once a quarter. Often the CFO will not
actually understand what the product is, much less how customers think of it.

\- If you have sales people making cold calls have management listen in on a
few. Again, you'll see how people think of your message.

------
josh_carterPDX
I loved my time at Twilio partly because Jeff made it a point to make sure
everyone, no matter their role, understood what was happening in support. Many
engineers, product managers, and even sales people would take support tickets
to get a better understanding about what the customers were struggling with.

Every company needs to do more to understand what the customers are struggling
with and the easiest way to do that is to get on the front lines.

------
evrydayhustling
Once upon a time, most growth came from creating supply chains for things
people already knew they needed. Then, it was about creating products that
made people's lives better in ways they didn't expect. Now, increasingly, it's
about getting an audience together and adapting to what they need as it
changes over time. Staying close to the customer is getting more and more
important.

------
ThomPete
When I was at Square the design team would shadow support staff to learn about
the kind of problems people are facing and more importantly how people talk
about your products, i.e. what they call things, how they try to explain
what's gone wrong, what they did to solve it or how they ended up with the
problem to begin with.

It's the closest thing you can come to true realistic user-testing.

~~~
penagwin
That's not just the closest thing to realistic user-testing, production IS the
user testing phase :P

~~~
ThomPete
Yup although the sucessful interections with your product is as important for
context of where it goes bad.

------
blaze33
Actual reports from actual users are priceless to build what provides value
actually worth paying for.

I've met devs considering good code and well engineered systems as their
ultimate work goals. While myself, only ever saw software as tools towards any
actual value keeping the business afloat.

Does that make me a weird software engineer? Or one that should look for some
better suited role? Still wondering...

~~~
mey
It doesn't make you weird, but unfortunately may put you in the minority of
developers. There is a balance to be struck. Business can drive really bad
technical decisions (debt) due to time/people constraints that take decades to
remove. This may be needed simply to get the company going or stay going (see
most startup MVPs). Those decisions need to be intentional and strategic,
otherwise it becomes the norm, and your entire company gets bogged down in
supporting "legacy" systems. On the other extreme, a "perfect" solution can
never be delivered so it's kind of hard to sell.

My anecdotal experience is that these trade offs are rarely consciously made,
instead made by who ever has political power at the time.

~~~
blaze33
Good point. I may add I constantly try to learn and understand best software
or engineering practice while working hard to also stay aware of whats most
useful for the business. As you say " There is a balance to be struck"!

Like trying to know enough to deliver value while avoiding shooting yourself
in the foot and also not wasting time on what's only seen as a black box by
outsiders?

------
jniedrauer
Starting out in tech support 100% made me a better developer. I've seen the
user vs developer tension from the side of the user who deals with broken
things every day, hoping that the dev team will eventually fix them. I know
how to talk to users now and find out what they really need. And I know how to
talk to developers and managers about prioritizing issues.

------
Animats
Bill Gates used to take Microsoft support phone calls once in a while, to get
a sense of what was really bothering the customers.

------
mrhappyunhappy
As a user experience designer the first thing I ask for is access to any and
all data available, including support chat system and access to support folks
so I can quickly gauge the general level of issues being experienced. It’s
just one way to identify possible issues, far in advance of jumping to make
any UI changes.

~~~
iagovar
> and access to support folks

This is key. Support people is the ones that talk with customers, and know
what's going on. Their experience is key.

In most companies this people is low-pay look-down people, gets tired quickly
etc.

------
the8472
> Unless you are a soulless robot, the above statement will probably trigger
> more emotions and requirements for actions than:

Is that not an appeal to emotion and thus incentivizes customers to embellish
their issues with emotional stories to get expedited treatment?

------
mparr4
I created a tool for smaller companies/individual developers that allows users
to submit feedback that gets pushed directly into Github issues:
[https://bugbucket.io/](https://bugbucket.io/)

------
iloveluce
I agree so much that I built an entire company around it.

The insight and nuance that comes from reading support conversations is second
to none but more importantly emphasizing with your user enables you to focus
more on building intuitive products.

------
AlexTWithBeard
Where I work dev team also does the L3 support: we have L1 who can change the
password, reboot the computer, we have L2, who know the basics of our app and
its surroundings, but if an issue is not obvious to them - here we come!

~~~
kbar13
why does l1 even exist

~~~
_red
Who says the ability to "reboot the computer" is avail to the user? (ie.
remote RDC connection or a locked down retail POS terminal).

Also, the "real purpose" of L1 tech is to categorize and prioritize incoming
calls for further L2 / L3 processing. Knowing "who" needs to handle the call
next, and its priority, is usually critical to getting real problems resolved
timely.

------
throwaway-1283
Interesting SaaS idea...a company that plugs into whatever CRM you use
(Zendesk, Freshdesk, Salesforce, etc.) and automatically compiles a summary of
tickets that is sent to certain people or teams within the company.

------
habosa
We do this at Firebase! Actually right now I am about to start my week as
"Support Sheriff" which means that I am the escalation point for support
cases. Everyone on my team does this about once a quarter.

------
forgotmypw7
Great job on your site design. I have not looked at the source, but it loads
quickly, works without JS, and all the elements are accessible with keyboard
hints.

------
deanalevitt
I think support needs a communication channel with development too. Both teams
need to grasp the challenges of the other.

------
xhruso00
Most of the support emails are really dumb. Instead of reading product
description or help they simply write you email and ask you. 98% of users get
through intuitive design. Example1: Customer didn't know how to switch camera
back/front and the product used the same icon and approach as Apple. Example2:
Customer denied access to camera and asked at support why camera doesn't work.

~~~
ColdBrewSea
These sound like legitimate user experience problems. I have fallen into the
trap of example 2 at least once, not because I didn't know why the camera
didn't work, but I didn't know how to resolve it at the time.

~~~
xhruso00
One can't design for 100%. Designing for those 2% simply isn't worth and
doesn't bring any cash. PS: user did not read camera access usage description,
clicked deny and then asked why it doesn't work. This is pure stupidity.

------
rammy1234
more we are closer to customers in any way possible, we will have a great
future as we get to know what we our customers want not what they need.

We need to understand customers the way we understand our program. deep dive
and debug their issues and come out with a solution that is win-win.

------
freediver
Great idea if a product of a culture.

Terrible idea if people are 'forced' to do it.

------
supergilbert
Be careful, it can be demoralizing for engineers working on the product as you
can get the feeling that nothing works.

~~~
ahaferburg
I would presume most competent engineers have a pretty good grasp of what is
or isn't working. If something doesn't, they probably knew about it already,
or at least aren't surprised.

~~~
SketchySeaBeast
And if they are surprised that's the entire point.

------
antidaily
All 3 employees.

------
Thermolabile
In companies people must share support emails to improve their product, that's
real.

------
theaccordance
There are better ways to understanding your customer than encouraging your
entire team to give attention to inbound support.

~~~
maxxxxx
Care to elaborate?

~~~
theaccordance
You have your folks on the CS frontline knowledge share their experiences with
the company

------
uasm
Everyone should also get paid more then. Also, if 33% of your job is answering
support emails, should we still call it a "Software Engineer" position? How
about being very clear about these expectations as-part of the job interview
process?

