.jpg)
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.
Cube is a software for finance teams that is designed to work from within Google Sheets and Microsoft Excel. As a result, its teams is well familiar with how to integrate with other systems. Cube's CTO Josh Holat shared his advice for startups who are looking to build integrations to other systems.
Cube is aimed at CFOs and finance teams who do the majority of their work with spreadsheets. Our product is a Google Sheets and Microsoft Excel add-on alongside a separate web UI where the user sets up their company within Cube.
We have our own API that we built to power our add-ons. Our API is only used internally right now, but customers will be able to use it to build their own integrations.
We support many integrations for our customers where we pull in source data. These include products like QuickBooks and Salesforce. From software like QuickBooks we pull in transactional actuals data. From software like Salesforce we pull in driver/operational data which helps financial analysts predict future growth and outlook.
We use REST design for now. It was the simplest to get up and running in the beginning so we could focus on solving our customer’s core problems. We may look at something like GraphQL in the future if it supports our needs, but the tried and true REST design has been working well for us so far.
The approach we’re taking is that when a large percentage of our customer base are using a system, we’ll build and support those integrations internally. This is to ensure those integrations are solid and reliable. For us, those are systems like QuickBooks, Salesforce and Xero.
There are various other systems, like Sage Intacct and Microsoft Dynamics, that we might build next depending on customer demand. One reason we built an API is that if we have a customer with an obscure system, they are able to build an integration themselves or hire a consultant to do it.
A big part of the process is learning the nuances across the different APIs. We are generally pulling the same data from different systems, but depending on the system it can be quite easy to pull that data in a structure we need or rather difficult. This also applies to rate limits. Whereas bulk importing may work from one API, another may have strict enough limits that this becomes harder.
For some of the enterprise systems we integrate with another issue is access to sandbox accounts and data. Typically these aren’t offered at all which makes building and testing the integration more complicated. Simpler SaaS products like QuickBooks make this very easy by offering one click sandbox set ups.
Supporting integrations long term also becomes a significant time investment. After you build a basic version of an integration, you still have to maintain it. As you onboard more customers, they’ll often be using different data from the source system which requires expanding the support for that integration.
Also, APIs change and deprecate endpoints over time, so you also need to keep on top of those updates. Luckily, finance APIs are more careful about changing so this is not as big of an issue for us as it may be for people working in other industries.
In terms of process, adding in the first integration of a particular type of system is typically a longer process. You most likely need to make decisions around where that data is going to live in your database and what spots in the UI your user will be able to interact with that data. Then when you move from one system of a type to the second system of a type, you can then determine what pieces can be shared vs how your normalized storage of that data needs to be altered to be more flexible.
Normalize the data that makes sense in your system and then translate that to the other systems of that same type. The more you can share business logic across systems, the better.
We have created a normalized transactional data table, for example. We work off that code to integrate with all the systems where we are pulling transactional data. The goal is to find the most generic terms in those types of systems.
First, be extra attentive to security. The way in which secrets and tokens are stored and dealt with should be very secure. If people get into your system and then they find the tokens for access to your customer’s connected products, you have expanded the breach. Furthermore, anywhere you move or store your data needs to be as secure and compliant as you are.
My second piece of advice is to make sure that you have good demo accounts for the external systems. If you have someone at your organization who is familiar with that particular system, say an accountant or finance person who knows how to use Quickbooks, then you can populate that account with dummy data and then test the integration.
We have general logs and monitoring around when third party systems return unexpected responses. Depending on the severity of the event, it gets logged to various places (Sentry, Slack, etc). We then handle it from there. Generally, the more logging the better. You just have to be careful that you aren’t logging unnecessary customer information.
My general advice is every API has weird behavior or edge cases that aren’t documented. If you’re using an API for a rather large/complex integration, the chances of coming across these increase. Creating workarounds for these edge cases is typically what takes the most time when building the integration.
You also might run into issues only with certain customers because they have a use case or data within their usage of that system that other customers do not.
Generally you are never done with integrations because you have to keep updating them for new customers or if the API changes. It becomes an ongoing project that takes a fair amount of resources over time.
Larger companies tend not to be very responsive to support for their API. Typically as long as the API is working for the majority of their customers they aren’t very interested in resolving any issues. In these cases it’s often just to assume the API isn’t going to change or be updated, so you need to head down the path of building your own workaround. Then if the API does get adjusted later, you can simplify your code at that point in time.
Generally, API documentation has gotten better. Companies have realized that docs are important to get developers to build on top of their systems.
I am a big believer in the bus factor. Generally knowledge should be shared amongst various individuals to avoid issues if any one person were to no longer be at the company. We typically might have one engineer who builds the initial integration but then other team members will understand how it works as well. This happens via code review or having other engineers built on top of the initial integration. Integrations are integral to what we do, so it would be hard to isolate that knowledge to a particular team.
