

Ask HN: Where do you draw the line in supporting your customers? - mholt

I&#x27;m mainly asking about small tech companies that provide APIs as a service. How far do you bend over backward to support the customer?<p>According to some of our customers, we break their production systems when we make what we define to be non-breaking changes. Some changes include:<p>- Replacing SSL certs after Heartbleed. Apparently some of our customers hard-coded the certs in their Java apps (?) and they lost connectivity.<p>- Rotating cloud servers. We do this regularly without downtime, but some customers hard-code IP addresses instead of using DNS. We have enterprise options available for those with firewall restrictions or who need static IPs, yet customers who can&#x27;t connect to the old IPs are upset with us.<p>- Changing our JSON library without changing the API contract. Our old one was lenient with integer&#x2F;string types, but the docs were clear about types and had examples. But when we switched JSON libraries to one that&#x27;s strict, it broke a bunch of customers who relied on requests that were not correct.<p>These problems are preventable just by using DNS, not hard-coding certs, and following the docs. Too much to ask?<p>We also get lots of requests for help with implementing our API into customers&#x27; systems to the point where they share their screen, give us control, and ask us to make it work. Why are we doing that kind of help for free? Aren&#x27;t there liabilities? Don&#x27;t businesses charge thousands of dollars for that kind of support&#x2F;freelance programming work?<p>We&#x27;re torn. Our customer support wants to help the customers and answer their questions. They don&#x27;t feel satisfied just sending them to our documentation or Stack Overflow. From the dev perspective, some customer questions are simply a matter of them not knowing how to code. We want to help, but it derails our progress on other, more important domain things.<p>Is it possible to do too much for customers, and where do you draw that line? Do other API providers have this issue?
======
KohgnaK
Being a HPC sysadmin, I was in a similar kind of situation. More often than
not I get crazy requests for implementation + dev + debug support. This
started to severely interfere with my other attributions so I decided to
change things.

1/ Set a strict line in the support provided: I'm happy to give a hand as long
as it is mail support and whenever I have the time to reply. No direct
interaction with the user code whatsoever. Otherwise we agree on a number of
hours I would spend on this and they would be charged for it.

2/ Use the liberated time to set up a knowledge base: Currently I've set up a
wiki, a FAQ and I'm giving free courses (101 + good practices). I try to keep
everything up-to-date by adding the questions/answers I get to it.

It was not easy especially at first (convince someone non tech-savvy that
their model was at fault when the error logs displays 1 error coming from the
model and 80 coming from MPI processes was quite hard) but now in about 80% of
the requests you could see they've started looking for stuff by themselves
before contacting me. Which is really pleasant!

In your particular case I would involve the customer support in the
documentation writing (at least a FAQ) so that they actually see how painful
and time consuming it is to write those things. On the dev side, the technical
documentation should have some good practices nuggets here and there, for
example in the part where you explain server cnnection by showing the actual
command line to use you could add a comment like "#connection using hostname
to keep it IP independent". Which might lead a couple of newbies and junior
dev to the right path. On API level ideally it should enforce good practices
by enforcing more strict rules (connection only possible using hostname f.e.).

But as soon as you actually touch the system or machine of the client you
should at least be legally covered. And given the set of skills involved and
how the time spent here won't be available somewhere else they also should be
charged for it.

~~~
mholt
Thanks for sharing your experience, that's definitely helpful.

I do look forward to our team coming to an agreement about precisely what we
support and how we handle customer requests or complaints that are outside our
scope. I imagine it'll look something like what you've described, at least in
part.

We already have our support team helping with FAQ and articles about our
product, so now it's just a matter of defining our scope more precisely and
coaxing our customers to take care of their own internal systems.

------
entreprenewb
>Why are we doing that kind of help for free? Aren't there liabilities? Don't
businesses charge thousands of dollars for that kind of support/freelance
programming work?

Yes, many companies have large lines of business just providing support. At
the end of the day it's all about the value it provides your company and your
clients. If you're able to retain and attract users/clients then some free
support could be worth it as a sign of cooperation and goodwill. If they're
already paying customers you may need to better define what's covered by your
SLA and various support agreements. However, if they are asking for advanced
help outside of those agreements then you can just say you don't provide
additional support. Or if your company has the resources you can always charge
them for engineer support (for example, MS charges $259/h for advanced support
during business hours).

------
MalcolmDiggs
Well...there's rarely a downside in the extra mile... as long as it's the
right folks doing it (customer service reps, account managers, etc). Spending
a core-dev's time on a customer's code seems kinda backwards.

As a rule of thumb: I'd say if one customer makes those kind of complaints, it
doesn't necessarily mean anything... but if two customers have the same exact
problem then you should look into changing how you present your
guidelines/docs to the users. They might need to be modified to make the
warnings more aggressive and apparent. If you've done everything you can in
that area, then all you can do is equip your customer-facing-teammembers with
all the firepower they need to handle those kind of complaints themselves.

------
seekingcharlie
It is not your responsibility to touch their code in any way.

The POS that we integrate with makes changes all the time. Sometimes, these
affect our product & we have to fix them. It not a single circumstance have we
ever asked them to fix the errors, nor would we.

I would stop doing any maintenance work for your customers immediately. I
don't know if the examples you mentioned are just edge-cases, but to help
them, you can just communicate what you have changed, why etc, so at least
they are aware before their issues begin.

~~~
mholt
Logically that makes a lot of sense, and I believe is 100% correct. It's more
challenging when emotions run high and our customers call in irate. But the
idea to communicate internal changes isn't a bad idea; I think we're starting
to do that.

------
canterburry
I think you responsibility could maybe include giving them a heads up about
changes you are about to make and that if they are using your recommended
approach there should be no interruption in service. This will let them at
least review their code.

For SSL certs, this is a common practice and frequently needs to be
coordinated between close integration partners so that nothing breaks.

~~~
boz_x
As canterburry says above, good communication can go a long way towards
improving customer experience and avoiding problems.

If you can provide clients with ample warning about any upcoming changes, and
preferably provide them with a staging/dev instance they can test their code
against, it might help avoid similar problems in future.

In my experience, clients get frustrated when their business-critical
processes suddenly break with no warning and they have to engage in fire-
fighting. From their perspective, they had something working one day, then you
"made a change" and "all their stuff broke". That might not be a fair
assessment, and it might well be due to shoddy practices on their end, but the
end result is the same: the client is frustrated and has a bad experience of
using your product.

~~~
jonathanoliver
It becomes especially tricky when any given customer can hard code an SSL cert
into the Websphere or Tomcat server without the service provider knowing
anything about it. Then, when the service provider needs to rotate the
certificate because it's about to expire and is renewed or perhaps it's
suddenly rotated (because of Heartbleed, for example), it breaks the customer.

What kind of communication channels have you guys seen or used for that kind
of scenario? A separate Twitter feed? A blog? Sending an email to all customer
every time the SSL certificate changes in any way?

~~~
boz_x
More or less any communication channel will work, provided clients are aware
of it and checking it regularly. Personally I would recommend a mailing list
that your clients can subscribe to in order to be notified of any upcoming
changes.

------
petervandijck
Put in a more expensive plan and say they get increased support with the more
expensive plan.

Also, make it harder to use improperly. Can you block direct calls to the IP
address? Etc.

------
sansavarous
How are you responsible for your customer's bad code?

