
How to Deliver Amazing Support at Scale - ianstormtaylor
https://segment.io/academy/how-to-deliver-amazing-support-at-scale/
======
manacit
If you're a small enough startup to have all of your support handled by one
person part-time, I would hardly call it at scale.

They made ticketing systems for this purpose, so you don't need to remember to
switch drip e-mails and juggle things, just log in and start helping.
Ultimately, it's how well the user is helped that matters.

~~~
ianstormtaylor
Very true, I should leave the round-robin'ing out of the "at scale" pitch. But
honestly, I think a single person being the load balancer for support scales
pretty darn far into the future. Seeing as it takes about one hour of my day
right now, it can easily scale to 8x our current growth. (And that's not
counting fixing all of the obvious support issues, so we can grow past 8x.)

If you have a dedicated support load balancer, you don't need to switch up
drip emails. Heck, I bet Customer.io and friends even get the switch emails
part down to a single button at some point anyways.

The problem with ticketing systems is, well, they suck. Your customers don't
want to get "tickets", they just want someone to solve their problem. And when
you're doing it in a really personal way they'll give you tons more feedback,
and they'll share your product with more people. Ticketing systems are
especially despised when you're building developer-focused products.

~~~
manacit
Ticketing systems don't need to suck - you could set one up to work nearly
identically (maybe even better!) to the system they have here. The workflow is
pretty simple

* Customer e-mails the support@ e-mail (or even your personal support e-mail), it's thrown in the ticketing system.

* You read the ticket

* You reply to the ticket, it's sent from support@ or your support e-mail

There's no reason you need to have an obnoxious ticket generation e-mail,
especially if you can get to it in time with a personal reply (generally
because, at this stage, you don't have too many tickets to process
individually).

------
NameNickHN
The first part of the article is missing the point. Sure, how you do support
may become important when you have to scale. More important is improving your
software/app/website in order to reduce the number of support requests.

The most important part of supporting customers for me is motivation. After
thirteen years my motivation is almost zero. It's probably time to pay someone
to do it but I wonder, what about their motivation.

~~~
ianstormtaylor
Seems like you didn't read the second part of the article. But if you really
can't be bothered to offer support, you better be darn good at designing your
product in the first place. And even then you're leaving huge amounts of
potential on the table.

------
iamdave
_Whenever anyone emails iant@segment.io, their question doesn’t actually go to
my personal inbox, it goes into our Help Scout account, so they are guaranteed
a much faster response time!_

Interrogative: What happens when say, a tech is assigned to an internal
project requiring email communication with a vendor? Here's a relevant
example:

In 2011 I was hired as into a role that was half Jr. Project Manager, half
Help Desk team lead (my door read "Support Operations Lead"). While I assisted
when the load got heavy in daily HD work, more often I was working on getting
new solutions into our support flow; implemented a new ticketing system,
rolled out a backup solution, and handled the IT purchasing for the entire
organization (this was a huge commerce firm of about 600 at the time.
Daunting, but it got done).

All of these tasks required constant communication with vendors, who had my
personal email address to send purchase orders and invoices to. Do those need
to go into the support bin? I'd wager not.

How does HelpScout differentiate between the two?

~~~
jcrites
From what I understood of the scheme, HelpScount doesn't differentiate between
them - you do. If you want to communicate with someone on your personal email
address, you can give it to them directly.

