[API as a Product] Supporting Customers

This is a Chapter 29 of my free e-book dedicated to APIs.

First of all, an important remark: when we talk about supporting API customers, we mean supporting developers and to some extent business partners. End users seldom interact with APIs directly, with an exception of several non-standard cases.

1. If you can’t reach partners that are using the API incorrectly, you might have to display errors that end users can see. This might happen if the API was provided for free and with minimum partner identification requirements while in the growth phase, and then the conditions changed (a popular API version is no longer supported or became paid).
2. If the API vendor cannot reproduce some problem and have to reach out end users to get additional diagnostics.
3. If the API is used to gather UGC content.

The first two cases are actually consequences of product-wise or technical flaws in the API development, and they should be avoided. The third case differs little from supporting end users of the UGC service itself.

If we talk about supporting partners, it’s revolving around two major topics:

• legal and administrative support with regards to the terms of service and the SLA (and that’s usually about responding to business owners’ inquiries);
• helping developers with technical issues.

The former is of course extremely important for any healthy service (including APIs) but again bears little API-related specifics. In the context of this book, we are much more interested in the latter.

As an API is a program product, developers will be in fact asking how this specific piece of code that they have written works. This fact raises the level of required customer support staff members’ expertise quite high as you need a software engineer to read the code and understand the problem. But this is but half of the problem; another half is, as we have mentioned in the previous chapters, that most of these questions will be asked by inexperienced or amateur developers. In a case of a popular API, it means that 9 out of 10 inquiries will not be about the API. Less skilled developers lack language knowledge, their experience with the platform is fragmented, and they can’t properly formulate their problem (and therefore search for an answer on the Internet before contacting support; though, let us be honest, they usually don’t even try).

There are several options for tackling these issues.

1. The most user-friendly scenario is hiring people with basic technical skills as the first line of support. This employees must possess enough expertise in understanding how the API works to be able to identify those unrelated questions and respond to them according to some FAQ, point out to the relevant external resource (let’s say, the support service of the platform or the community forum of the programming language), or redirect relevant issues to the API developers.
2. The inverse scenario: partners must pay for technical support, and it’s the API developers who answer the questions. It doesn’t actually make a significant difference in terms of the quality of the issues (it’s still inexperienced developers who use the API and asks questions; you will just cut off those who can’t afford paid support) but at least you won’t have a hiring problem as you might allow yourself the luxury of hiring engineers in the first line of support.
3. Partly (or, sometimes, fully) the developer community might help with solving the amateur problems (see the corresponding chapter). Usually, community members are pretty capable of answering those questions, especially if moderators help them.

Importantly, whatever options you choose, it’s still the API developers in the second line of support simply because only they can fully understand the problem and the partners’ code. That implies two important consequences.

1. You must consider this time need to investigate inquiries while planning the API development team time. Reading unfamiliar code and remote debugging are very hard and exhausting tasks. The more functionality you expose and the more platforms you support, the more load is put on the team in terms of dealing with support tickets.
2. As a rule, developers are totally not happy with a perspective of sorting the incoming requests and answering them. The first line of support will still let through a lot of dilettante or badly formulated questions, and that will annoy on-duty API developers. There are several approaches to mitigate the problem:
   — try to find people with a customer-oriented mindset, who like this activity, and encourage them (including financial stimulus) to deal with support; it might be someone on the team (and not necessarily a developer) or some active community member;
   — the remaining load must be distributed among the developers equally and fairly, up to introducing the duty calendar.

And of course, analyzing the questions is a useful exercise to populate FAQs and improve the documentation and the first-line support scripts.

External platforms

Sooner or later, you will find that customers ask their questions not only through the official channels, but also on numerous Internet-based forums, starting from those specifically created for this, like StackOverflow, and ending with social networks and personal blogs. It’s up to you whether to spend time searching for such inquiries; we would rather recommend providing support through those sites that have convenient tools for that (like subscribing to specific tags).