Ask HN: Where do you draw the line in supporting your customers? | Hacker News Reader

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

5 pointsmholt12 comments

I'm mainly asking about small tech companies that provide APIs as a service. How far do you bend over backward to support the customer?

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:

- Replacing SSL certs after Heartbleed. Apparently some of our customers hard-coded the certs in their Java apps (?) and they lost connectivity.

- 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't connect to the old IPs are upset with us.

- Changing our JSON library without changing the API contract. Our old one was lenient with integer/string types, but the docs were clear about types and had examples. But when we switched JSON libraries to one that's strict, it broke a bunch of customers who relied on requests that were not correct.

These problems are preventable just by using DNS, not hard-coding certs, and following the docs. Too much to ask?

We also get lots of requests for help with implementing our API into customers' 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't there liabilities? Don't businesses charge thousands of dollars for that kind of support/freelance programming work?

We're torn. Our customer support wants to help the customers and answer their questions. They don'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.

Is it possible to do too much for customers, and where do you draw that line? Do other API providers have this issue?

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.

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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

Reply on news.ycombinator.com