As a graduate of Y-Combinator, PartnerStack has been rooted in helping some of the world’s fastest growing SaaS companies scale. Companies like Asana, Monday.com, Unbounce, Intercom, and Intuit all use PartnerStack to manage and scale their partner programs, and onboard thousands of partners into our platform.
There are a few unique aspects to PartnerStack, which has led us to becoming the #1 platform on G2.
PartnerStack is the only solution that has both the PRM and a B2B focused marketplace that connects vendors with partners. On average, our marketplace drives a 30%+ lift in revenue for customers.
We are extremely focused on partner experience, which is a big distinction for us. Most PRMs are focused solely on the vendor experience. But if both sides of this equation are not having a good experience, then it becomes a problem.
And with PartnerStack, all of your channels can be managed from a single platform - affiliate, referral, reseller and ambassador. We see a lot of companies, agencies, and resellers choosing our platform to help them consolidate their channels into a single view.
How is your partnership team structured at PartnerStack?
Our team is still relatively young, as we launched it in April. The majority of this year has been building relationships and working with both agencies and resellers.
I lead the team, and we have an incredible Account Manager that works closely with our partners, as well as a partner marketing manager that works on any co-marketing efforts we run with partners.
Our partnership team is currently focused on two core areas:
We often work with sales when one of their SaaS prospects wants to launch PartnerStack right away but doesn’t have the internal bandwidth. In those cases, we connect them with an agency partner who we know can do it right away and do it well.
Technology partnerships are also on our radar. We have recently built a number of integrations. One of our goals in 2021 and going into 2022 will be to further build out our technology partner program and our own integration marketplace.
We also plan to enter the app marketplaces of other SaaS vendors, especially CRMs like SugarCRM or Hubspot. CRMs are good partners for us because, with the exception of Salesforce, no CRM has a PRM as part of their product offering. So our software is complementary rather than competitive. And it benefits our customers to have those systems integrated.
“If you’re planning to scale your partnerships at all, you need the infrastructure in place to do this.”
<center>- Nikita Zhitkevich<center></center></center>
What advice would you give for organizations trying to think through who their ideal partners are?
Ultimately, everything has to come down to revenue. Whether you’re pursuing referral, reseller, or technology partnerships, you have to tie them back to driving revenue.
Especially since you need the support of other departments in your organization, whether it is collaboration with the sales team or the product team to help build integrations, the benefit to the business needs to be very clear.
For agency and reseller partners, I would advise looking to see if they power similar products to yours. I’d also think about whether the partner will continue to evolve over time in the direction you are going and whether they truly understand your product and space.
Marketing and sales software require a number of product integrations to be useful to their customers.
Prasanna Venkatesan is the Founder and CTO of Insent, a conversational platform that helps businesses identify and engage their prospects. Early on its development, Insent integrated with all the major marketing platforms.
Prasanna shared Insent's approach to integrations, and his detailed advice for other startups on what to consider when planning out product integrations.
Our product is a conversational layer that can be used for a number of different things, but right now, we are focusing on the marketing use case. We have built integrations into the major marketing platforms, like Salesforce, Hubspot, Marketo, and Microsoft. We have a team dedicated solely to building integrations.
When we started, I looked around for help, and to try to see if there is an easier way to build. I know Zapier exists and there are a few similar tools. But Zapier is designed for lightweight jobs. If you want to push some limited amount of data from one system to another, it can work. But if you are dealing in volume, it is too expensive.
Our use cases are too heavy for a tool like Zapier. One of our key features, for example, is that we provide our customers with the ability to create very detailed audiences on our platform, based on their data from their other platforms. As a result, we need to keep in sync with those platforms, and have API calls back and forth every few hours.
Integrations are core to our product and we decided to build them ourselves.
We started with an external API. Our product does not really exist without an external API. A key part of our product is to identify visitors on our customers’ websites, and we use a bunch of integrations to figure out who the person is and how you should message them. Our customers have a wealth of data in their sales and marketing platforms that we need to track visitors and analyze how they should be addressed.
To build that layer, we needed an external API.
First, I would advise not to start building integrations until you are very clear about the use case. Every platform has their own API and system that takes time to learn. Salesforce, for example, has a concept where they give you an access token, and it can expire at any time, and you just have to refresh the token whenever it expires. Marketo gives you an access token and it says it will expire in one hour. Slack gives you one that doesn’t ever expire.
APIs are all different and you have to take the time to figure each one out. So you should always be sure what the use case is before investing all that time.
Second, most of these platforms have good resources and support systems. Marketo has weekly dev office hours. For us, we got in touch with Marketo very late in the process. We tried to figure it out on our own, and we would have saved a lot of time if we had reached out for guidance in the beginning. I would recommend someone starting out look at the Marketo API and then run your plans by the Marketo team before you actually build.
Hubspot has a very good Slack community for developers, and that’s very helpful.
Each one of these large platforms has good support, and you should avail yourself. If you’re coding deep integrations, you will need help.
Another thing to realize is that often these companies have APIs that are so extensive that you can accomplish the same objective in three different ways. For example, with Marketo, contacts can be synced three different ways, and the Marketo team flagged for us that if we do it through the bulk option, we can dramatically reduce the number of calls we are making.
Third, when building integrations, keep the limiting factors in mind. Platforms limit how much data you can download at once, and how many calls you can make.
Look at these limiting factors, and factor them in your planning phase. You never want to cause your customer to not be able to make calls when they need to.
Given their complexity, planning your integrations is at least as important as building them.
If you are going to be working with a lot of systems that are similar, you should plan your codebase around that. For example, if you are working with a lot of customer support systems, they have different concepts but many similarities.
You should avoid making your codebase system-specific. If Zendesk is the first integration you build, do not make your codebase Zendesk-specific. Build with objects that will make further integrations much easier.
When we first built we had a different codebase for each system, but we are now seeing there are a lot of commonalities amongst systems, and code that can be used across systems. If we had done that in the early days, it would have been easier for us now.
In terms of authentication, it is different with each platform. There are two main components to authentication - first, how do you get access to a token?
Salesforce and Hubspot, for example, both use OAuth, a very common approach that allows customers to come to the platform and say they want to connect, and then get access. With Marketo, on the other hand, you have to go in and click a bunch of buttons, get an API key and secret, which you have to then share in your application.
The second key part of authentication is does the access token expire and if so, what is the process to get a new token? In Salesforce, for example, the token expires but you have no idea when, so you have to build that logic into your codebase. Every function call has to include it. Marketo, on the other hand, typically tells you when the token will expire.
I’d also advise startups to gather information on the demands of different APIs at the start of the process. In my opinion, Microsoft has the most complicated APIs out there with very poor documentation, for example. You have to be super extra careful when you build with Microsoft APIs and plan for backups wherever possible.
Slack, on the other hand, in my experience, has the best set of APIs. They are very well documented, and they have a dedicated portal for developers where you can test your APIs.
Our current integrations are all native, the customer can access them from inside our app. We have established default configurations for each integration based on common needs, and the customer can change the configurations if they want to.
Part of our roadmap is to offer an external API for third parties to build with but not yet. We are still focused on building integrations to larger systems. This has to be a business decision, and we look to what our customers are using. Our customers are medium to large companies, and they are all using these large systems.
Moving forward, we will roll out integrations to more systems, as well as build deeper integrations into Microsoft and Slack.
It is a significant investment to plan and build your integration. These systems provide more than one way to accomplish the same thing, and you need to devote the resources to make sure you are building correctly.
For very good engineers, with lots of experience working on APIs, it takes 2-3 months to build a deep integration.
For very simple stuff, you might be able to do it in a week. But for a deep integration, I would advise 3 weeks of planning before you start the building phase.
You also have to consider other costs. Most systems do not charge you to get access, but Marketo, for example, charges 10k USD just to get access to a developer instance. Salesforce has a 2k security review.
The question you have to ask yourself is, “How am I going to get this money back?” If they have a marketplace for apps, for example, can you use that to further push your business? Are you going to have to expend additional marketing resources to drive leads through the marketplaces?
We have not listed our integrations on these marketplace yet. All our customers are using at least one integration, but our sales team has enough leads right now. It is on our roadmap to list in the marketplaces.
We have certain tools built in, every time we call an external API for our customer, we track those numbers internally. I can pull up the numbers. I would definitely advise startups to build tracking into their integration infrastructure.
Integrations are running in the background so it is easy to miss what is happening with integrations. Build tracking and alerting into your system. That is a must have.
For example, if something fails more than 5 times, it is a red flag. It could be a mistake with the customer, but if you have a tracking and alerting system, you can go see what happened. We have the tracking integrated with our analytics tools so our business users, like a sales or CS person, can understand what is happening. You can use external systems like Kissmetrics to visualize alerts.
Currently, we do not alert the customer, we alert ourselves and fix any problems. Giving a dashboard to the customer is on our roadmap. Customers should be able to see integration usage and errors as well.
I am open to talk to any startups who are looking for help or advice on building integrations.