In today’s business climate, the need for companies to be agile, innovative and able to scale is greater than ever. APIs are drivers for these needs. But before an organization can reap the benefits of APIs, it must set up an API strategy.
Developing an API strategy can be broken down into four stages: establishing your strategy, aligning your organization and culture, building the technology needed to support the strategy and engaging with your ecosystem. This series of articles examines the fourth stage.
All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build vibrant ecosystems of developers and partners who, in turn, can extend the reach and success of those API strategies. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on Aircall, a cloud-based telephony Platform. We spoke with Raphael Assaraf, the company’s manager of App Ecosystem.
When the topic of engaging developers is brought up, a lot of the focus is given to independent developers. There’s a good reason for that: their sheer numbers make for an enticing market. Another set of developers worthy of attention are those with technology partners. In Aircall’s case, its partners are building applications for the company’s application marketplace, a component to Aircall’s strategy that Assaraf considers a key to the company’s success. According to Assaraf, the difference when marketing to partners is that “you're not really selling a product, you're aligning on a common strategy to go to market.” He goes on to say that the key with partnerships is “the support you’re bringing. I'm talking about how well the API is documented, how clear it is, how well it shows what developers can and cannot do, not to mention how available you are to answer the questions.”
Going beyond clear references, Assaraf discusses how his team focuses on nailing down use cases and offering in-depth tutorials that partner developers can turn to before they have to turn to live support. It’s all about over-delivering according to him.
To find out more about how Aircall approaches developer engagement, read the transcript of the interview below. This interview has been edited for clarity and length.
ProgrammableWeb: Hi this is Wendell Santos, editor of ProgrammableWeb and today I’m speaking with Raphael Assaraf, Manager of App Ecosystem at Aircall. Raphael, thank you for taking some time out to chat with me. Could you tell our readers a little bit about yourself and your background, and also a little bit about Aircall?
Raphael Assaraf: Yeah, for sure. I'm Raphael and I manage the app ecosystem team at Aircall. This is a team in charge of growing our app marketplace. So as a SaaS product, we integrate with a lot of other solutions. Some of these solutions, like HubSpot or Salesforce or Segment, we built the integrations ourselves, but most actually have integrated onto us.
Aircall is a fast growing company. In five years we have gone from zero to more than 7,000 customers across the globe. Our team has scaled to 400 people, and it's still growing. As we have gone through that journey and that growth, we have had a lot of interest from other companies to partner with us through a technology partnership. This means using each-other's public APIs to build new products for our joint prospects and customers. That's what I manage, I help other companies build integrations with us. That means helping developers. They are not the only point of contact for me, but they're key.
As for my background. I actually started my career working for a mobile payment app based out of France. My job there was a mix of customer success and sales, but also partnerships that included API integrations. So from very early on I was exposed to APIs. I got to see the process of developers wanting to use your API, the hoops they have to jump through, and how you can make the experience better for them. It's been a silver lining for me as I've built up my career.
At Aircall, we have between 10-20 SaaS companies reaching out to build integrations with Aircall each quarter. Generally, it works one of two ways. Either the business team has needs related to the product, but doesn’t quite know the specifics of how to implement the solution. Or, the Integration will be stemming directly from the CTO or the developer themselves, who are already looking at our Documentation and really want to get the implementation done. In both cases, you'll always land at the point where you say “okay, to get this integration out as a developer, I need to code and I need to understand Aircall's API. So, I'm going to reach out to the team at Aircall for help or guidance.”
What comes out of it, and what is really interesting is that, when you do technology partnerships in SaaS, the result is a product that customers are going to use. So you have all the incentives to help developers understand your API and to make sure that your API is good. You want to make sure that we can really release the best version of the product together. So that's the overview of my role.
PW: Let me ask you, the developers that you work with and that you are trying to engage with, do they tend to be embedded with your partners, or are they independent developers that you're trying to bring into your ecosystem?
Assaraf: If we were to break down all the developers, there's three big audiences. One, is our customers and they tend to do a lot of custom development. I think when we build our documentation, we really have to have them in mind.
Second, would be our service partners. These are integrators and people doing implementation. Generally, the resources we have for customers can also help these partners build stuff with our API.
Lastly, there is a unique audience for us, which is the one I'm in charge of, technology partners that are building applications for our marketplace. These partners, they're generally developers, CTOs and product managers at other SaaS companies at our stage. But, as we grow we’re seeing that there's an opportunity for any developer to build solutions. We actually have a company that was built on top of Aircall, already. They're called Postcall.io. What they do is help Aircall customers send surveys after a call and they do that really, really well. So, that's where we want to go. But right now, a lot of the interactions I have are with developers at existing companies, or CTOs.
PW: Okay. Let's focus on the developers that are with those technology partners. Can you discuss at a high level, what some of the strategies are, as far as going after those developers and making sure that they feel a real sense of engagement with Aircall?
Assaraf: Yes. From when we started out to now, I think the marketplace has gone from 10 to a hundred plus apps. That journey was less than a two year journey. At first it was very much a manual process where we tried to identify who in the marketplace would make a good partner and then who would be the person to talk to within those companies. That's what we tried to do from the top, make sure that the conversation we had with these companies was both a business and a product conversation. So really early on, we were mapping, let's say, all the CRM software that could be relevant partners, and then getting in touch with the CEO, the CTO, maybe a product manager, maybe a developer in the team, to really check all the boxes.
So, it's a bit like sales. The main difference is that you're not really selling a product, you're aligning on a common strategy to go to market. That's how we started. But even back then we had interest from people coming to us and saying, "Hey, I want to integrate with Aircall." So regardless of whether you're trying to manually source partners and work with their developers, or you have developers coming to you to build stuff, the common denominator is that you have to market activities that are relevant to them. But marketing for developers should be about what you can do, and the products you can build. The common denominator is really the support you're bringing. I'm talking about how well the API is documented, how clear it is, how well it shows what developers can and cannot do, not to mention how available you are to answer the questions.
Every time I work with external developers, it feels like joining a new team where you really want to be someone who's over-delivering in that team. You want to go beyond the bare minimum of only giving a canned answer. Sometimes you have to do that, but it’s better to point out, in a kind way, "Hey, have you really read through the documentation, because I think you've missed some key elements.” Or, on the other end, you have the developers that know what they are doing and are really challenging you. So, when they bring up an issue or when they highlight a flaw, you really want to go deep and try to understand if it is true. You want to find out if they missed something or if we missed something, and provide a real detailed, not detailed in terms of length, but detailed in terms of understanding, answer to them.
So, I think support is super important. I'd go further and say it's more of a collaboration than support with these teams. That's worked really well for us. When you're building an integration with Aircall, if you're in touch with the right contacts, we're going to answer you as fast as we can. We're not going to slow down your development time through hurdles and bureaucracies if we can avoid it.
PW: You talk about how important it is for your team to be available to offer help. What does your team look like, as far as those that are available to help?
Assaraf: Well, we have tech support. We have level one, level two. We have solutions engineers. We have a team dedicated to integration on the product side. We have engineers that can interact with customers on Slack or other channels. They can jump in when the problem is really complex. But, in the case of Aircall's app ecosystem, the volume is not so high because you're not going to release a hundred integrations every month. You're not working on a hundred projects at the same time. So, for a while, the team has just been me, with the support of all the teams I just mentioned, especially our product team, and our internal developers.
As we grow, we're going to scale a developer experience track where we are going to hire developer support people specifically for partners. So far though, we haven't really felt the need. Actually, it's been helpful to have a very agile team where we are working on both the business side and on the tech side with our partners. Our partners have a single point of contact and we can explain to them how this tech implementation is going to impact the product and impact the way we are going to do product marketing when we release the solution.
We really want to provide a VIP type of experience for these partners and then, as we scale, we layer typical support resources. Then, it's more about our own support processes, where we want it to be seamless and fast so that our partners have good expectations. It's a very basic principle where it's about shorter answer times, providing good answers, making sure you understand the issue. But, to apply that at scale becomes harder.
PW: The other part that you talked about was developers wanting that documentation to be top-notch and for it to answer the questions that they have. Plus there is the added benefit where if your documentation answers their questions up front, then they're not having to come to you to ask those questions. What are some of the things you do to make sure that your documentation is on point?
Assaraf: We were lucky to have a great first version of our first API references. I did not work on those and they came out in 2016 or so. At some point we shifted the focus to accelerate both the ecosystem and developer relations, and the first thing we did was rebuild the API side. There were a lot of different elements there. First, we had to make the documentation clear, in terms of being actionable and letting developers know what they can and cannot do. We made it clear which endpoints were available, the scope each one covers and explained if certain endpoints were only available to a subset of users. For example if there was a limitation on a plan, and a feature was only available on higher plans, that needed to be highlighted in the documentation.
We’ve also focused on our tutorials, trying to be very proactive on identifying use cases that are popular for both our customers and our partners. We take those and templatize them to include an explanation of the business logic driving the use case as well as the process behind it and how to code it. We also include some best practices. For instance, we are a telephony product, sometimes a user will want to do phone number matching. So we provide a useful phone Library. We try to highlight packages or things that people can use.
We love using that part of our company to experiment. Recently, we built an Aircall app that shows you the weather of the person you are calling. We open-sourced the code. One reason for building this was to delight our customers.
The second reason was to leverage the value of open-source. If someone wants to build the exact same app, they can do it. They just need to follow the steps. We have a huge block of code next to the documentation, that explains step by step, how we did it. It's really helpful, because if someone wants to develop a totally different app that leverages the same Endpoint, we can say, "Look at this implementation." If they want to do things really, really well, they have the resources to do it.
Aircall's documentation includes blocks of Sample Code to help developers better understand how to implement the application
Real life use cases are very useful, because sometimes [in the reference docs], you're being very generic with the endpoints and what they do, and people don't see your [API as a] product. It’s important to let users know how it’s going to impact the customer experience. So you want to be visual when you document the API. You want to have clear use cases, straight to the point documentation, and then tutorials that showcase real life examples.
PW: When you talk about real life use cases do you ever leverage your partners? Do they ever get brought in, to say, "Hey. We work with XYZ company, and this is what we did, or do you ever need to do that?
Assaraf: Not yet. We don't have a developer forum yet, but we'll definitely get there in the future. Right now, if I talk to partners and I know they don't care about me sharing their implementation of something, then yeah, we can point to that and use that info.
We also use our internal team quite a bit. So for tutorials, we leveraged our solutions engineering team who helps customers build use cases. The solution engineering team had a library of use cases that customers have implemented, and how best to help those customers. When we decided to build more tutorials, we went straight to the solution engineers and asked, "Okay, what have you built, and what can we turn into a tutorial?" At the end of the day, they may be inside Aircall, but they're a developer audience as well, because they are building stuff for our customers. So yeah, we definitely do that.
PW: I’d like to ask about KPIs. We’ve discussed your documentation and you’ve explained your goals there. You want them to be very actionable. You want to make sure the scope is covered for any of the resources on the API. You mentioned you want really good use cases. You mentioned tutorials that cover real life scenarios. So, that's great. You have all of those pieces in there. Do you have ways of measuring how well these things are resonating with your developers?
Assaraf: We're not ultra quantified yet but I can point out a few things. One is when something does not happen anymore. We support two Authentication methods and we want partners to use the OAuth method. In the past, because we had bad documentation around which authentication method to use, we were testing a lot of partner apps that didn't have the right authentication method. They have already finished their sprint and we’re telling them, “change your authentication method,” and that’s not a good look. Since then, we improved the documentation for when to use each authentication style and I see fewer companies using the wrong authentication. That's a good indicator that the doc is working. Similar to that, sometimes there's a specific implementation that we think is best but when we test the app of our partners at the end of the process, we see that they haven't done it. That makes us ask ourselves, "how can we make the documentation clearer, so that this doesn't happen?" We had few successful runs of this.
Second, we share a lot over email. So, when partners tell us, "the doc is great or useful or helpful", sometimes we’ll follow up and ask what about the documentation was relevant. Those are some of the things we pay attention to. We don't measure logs or stuff around activity on endpoints.
One measurement that we do have, that's our North Star, is growth of the ecosystem, how many partners built an app and how fast do they go? The second is customer adoption of partner applications. So, my North Star is, how many customers have used applications that are built by our partners. That's where you assess the quality and the interest, for what the community has built.
PW: How many apps are currently in the marketplace?
Assaraf: Publicly on the marketplace, there should be around 70 apps, I think, if we add one every other week or two. We have around, I think, 80 applications built on top of Aircall, that we know of. Some of the ones on our marketplace, we built off of those.
PW: That's great. Any goals for the next year that you can talk about? Perhaps where you're trying to go and who you're trying to reach, moving forward here?
Assaraf: In terms of targets, we still think the number of integrations is not really important. But, we still want to grow that because we want the ecosystem to keep thriving. So first is growth of the number of partners on our marketplace.
Second is adoption of apps by our customers, whether that is double, triple, the best we can do. We really want to focus on improving the discovery of our partner applications, product marketing, also just working with the customer facing teams. Everything we can do to promote developer applications, because they're bringing value to our customers. And then third, continuing to extend our developer relations effort. Being a bit more vocal and public about our ecosystem, about the success developers have achieved and about extending outside of that. Now Aircall is becoming bigger and we have more customers. So, there is more opportunity for developers or makers to grab a bit of the market share and build a cool solution that's simple to use and that can help us kick off their growth. It's really focused on the technology partnerships, at this stage.
I’d like to thank Raphael Assaraf for taking the time to speak with me and share Aircall’s approach to developer engagement. This is part of a series of interviews with developer relations experts such as Ryan Boyd of Databricks and Lisa-Marie Namphy at Cockroach Labs. Be sure to keep an eye out for future interviews coming soon.