Launching a tech ecosystem involves a ton of moving parts. It’s more than just developing the integrations that improve your customers’ workflows and bottom line. You also need to consider how to get your entire team bought in, how you’re going to present your marketplace to potential users and partners (the marketplace UI), and getting a solid group of partners to team up with you (before you’ve even got the results to prove it’s worth it). 

The idea of managing all this and more can be daunting, especially when there’s not an all-inclusive resource to help guide you. Ahem, we’re changing that. 

In May 2021, we launched our first tech ecosystem — and we want to help you learn from our successes and our mistakes. 

When our VP of Partnerships, Chris Samila, joined Crossbeam in November of 2020, he quickly got to work building his Ecosystems Team — an internal team consisting of members from Product, Engineering, and Product Marketing — to bring our new tech ecosystem to life. 

Now, just six months later, we’ve launched more than 30 integrations with 24 partners, all part of the Crossbeam Partner Cloud. 

It wasn’t easy, and Samila says he knows exactly what he’d change if he could go back just six months in time. 

“There’s just a lot of nuance, especially on the integration infrastructure side and making sure that everything’s going to work the right way,” says Samila. “Everything cascades.”

Below, you’ll get an inside look at how Samila and the Ecosystems Team launched our tech ecosystem — plus, everything they wish they knew ahead of time. Let’s get started.

What to expect: 

#1 Get Buy-In (At Least Six Months Before Launch)
#2 Establish Your Ecosystems Team (Six Months Before Launch)
#3 Determine The State of Your API Infrastructure (At least Five Months Before Launch) 
#4 Decide How You’re Going to Build and Manage Your Integration Infrastructure (At Least Five Months Before Launch)
#5 Determine Who Will Build the Integrations (At Least Four Months Before Launch) 
#6 Decide How You’re Going to Build and Manage Your Marketplace UI (At Least Five Months Before Launch) 
#7 Identify Tech Partner Categories and Use Cases to Pursue (At Least Four Months Before Launch)
#8 Get Your Potential Partners On Board (Six Months Before Launch and Onwards)
#9 Keep Your Entire Team Informed (Six Months Before Launch and Onwards) 
#10 Prepare Your Partners and Internal Teams for Launch (Two Months Before Launch) 
#11 Prepare Your GTM Teams for Launch (Two Months Before Launch)
#12 Build Partner Attribution Model and Tracking in CRM (Two Months Before Launch) 
#13 Initiate a Soft Launch (One Week Prior to Launch)
#14 Launch
#15 Map Accounts to Drive Integration Adoption
#16 Measure the Results (Weeks, Months, and Years After Launch) 
#17 Keep the Momentum Going (All Day, Every Day) 

Get the “Integration Marketplace Launch Command Center” Form.
Get the “Tech Integrations by Partner” Form.
Get the “Tech Integrations by Category” Form.
Get the “Launch Tech Program” Form.
Get the “Co-Marketing Activities” Form.
Get the “Integration Marketplace One-Pager” Template.

Something to keep in mind: Each component of the checklist that follows requires varying levels of effort in the months leading up to launch. We’ve mapped these efforts from high to low in the table below so you can plan accordingly.

Let’s get started.

#1 Get Buy-in (At least six months before launch) 

As soon as he joined Crossbeam, Samila was in a unique position. He was tasked with developing a tech ecosystem for a company that lives and breathes partnerships. (That’s the dream!). As a partner ecosystem platform (PEP) that makes account mapping easy and secure, partnerships are in our DNA — but we know that’s not the case for everyone. 

To ensure your tech ecosystem launch gets the internal support it needs, you’ll need to build the value story for each internal team that will need to contribute to your integration roadmap and go-to-market (GTM) strategy. 

“Get your CEO on board,” says Samila. “Build that value story of how each team is impacted by a strong ecosystem of integrations — sales, customer success, product. You can help expand the breadth of what’s possible if integrations are in place.” 

Integrations benefit a company in four ways:

1. Help your sales team tell “better-together” stories that help potential customers solve a wider range of challenges. The integrations expand the breadth of capabilities for our product and provide our sales team with allies through our tech partners for co-selling. 
2. Help your customer success team drive retention (e.g. RollWorks has observed that customers who use partner integrations renew at a rate 30% higher than those who don’t). 
3. Help your product and engineering teams build a “stickier” product while filling gaps your product can’t or shouldn’t solve alone. Additionally, you’re creating building blocks (APIs, integration infrastructure) that partners can use to extend the value of Crossbeam with less of a lift from your internal product team. Keep in mind: Selling your product and engineering team on launching a tech ecosystem involves getting their investment in API and integration infrastructure development. This means a reprioritization of your existing product roadmap. The importance needs to be understood deeply by your product and engineering teams so that it feels like an exciting pivot for everyone. 
4. Provide your marketing team with new avenues of competitive differentiation as a main talk track for their strategy while simultaneously gaining marketing allies through your new tech partners. Your marketing team will have more partners to collaborate with on co-hosted events and content — meaning more opportunities to gain ecosystem qualified leads (EQLs) through your partners’ audiences. 

Determine how your tech ecosystem would benefit your internal teams by figuring out each team’s pain points and how your tech partners can help solve them. Then, be clear about each team’s involvement in bringing your tech ecosystem to life. 

“There’s a reason why NASA operates more than 100 facilities across eight different states,” says Samila. “It’s because you want a bunch of different stakeholders invested in the success of that program.” 

(If you need more firepower for buy-in conversations, bookmark these 13 articles that prove the value of partnerships.)

#2 Establish your Ecosystems Team (six months before launch)

Building an integration marketplace is a long journey with many paths. Before you set out, you must make sure each of your internal and external stakeholders knows their responsibilities and temporary or ongoing roles.

Think of your partnerships lead as the director guiding the actors and production crew to make the best performance possible. 

To bring our tech ecosystem to life, our “director” worked with our Solutions Engineers, Ecosystem Product Managers (Ecosystem PMs), development agency, the engineering team, product marketing (and 24 partners!).

Introducing our internal Ecosystems Team:

A brief overview of the Ecosystem PM and Solutions Engineer roles:

Ecosystem PMs interface between the partner manager, product team, and engineering team to ensure everything is running smoothly (e.g. with your APIs and integration infrastructure) and that the team is meeting the integration marketplace launch deadline.

Solutions Engineers are the technical experts gathering customer feedback on which integrations are desired, liaising with partners around technical questions and capabilities, and developing solutions when things don’t go as planned. 

Since we don’t have an Ecosystem PM at Crossbeam just yet, we ended up splitting the role between a few internal team members. From November 2020 to mid-March 2021, Lindsey O’Niell, Director of Product at Crossbeam, filled in as a temporary Ecosystem PM. Then in March, Eric Nograles, Director of Engineering, and Dan Singer, Engineering Manager, took over as dual Ecosystem PMs. Ideally, you’ll want one dedicated Ecosystem PM.

The Ecosystem PM (in this case, O’Neill, Nograles, and Singer) is instrumental in: 

• Helping to decide the integration infrastructure path
• Ensuring the APIs worked as intended
• Guiding the engineering team in collaborating with Left Hook to deploy Frigg (read about Left Hook and Frigg in #4)

David Evans and Graham Young filled in as Solutions Engineers and helped augment the speed at which we needed to go to market and launch our tech ecosystem. Evans and Young managed aspects of the technical scoping and served as a technical resource for partners who had questions related to the integration roadmap. Additionally, they collaborated with Amanda Groves, Director of Product Marketing at Crossbeam, to develop the joint solution messaging for each integration and relevant co-selling collateral.

Meanwhile, Groves handled the co-marketing and product marketing side of things while collaborating with our tech partners and internal team members. 

The Ecosystems Team kept in sync through a variety of methods in the months leading up to launch. They operated according to an Integration Marketplace Launch Command Center in Notion, which featured an extensive table-checklist that slowly turned from red (not done) to green (done). Then approximately one month before launch, the Ecosystems Team met daily for 30 minutes to discuss the status of integrations, product updates, marketplace listings, and co-marketing materials. 

Get the “Integration Marketplace Launch Command Center” form.

#3 Determine the state of your API infrastructure (At least five months before launch) 

Determine the capabilities of your API infrastructure (if your company has one). After all, if your APIs aren’t ready, nothing will be ready. Determining your API infrastructure is a major piece of determining your overall integration infrastructure.

A slide from our recent webinar “The 4 Levels of Tech Ecosystem Maturity”

With the help of an Ecosystem PM, determine the answers to questions like: 

• Do we have APIs?
• Do we have the infrastructure in place to support partners building integrations on top of our API? 
• Does our current API endpoints return all of the data our partners will need, in a format that is easy to consume?
• Do we need to add API endpoints to satisfy specific integration use cases?
• Which APIs can we use with each tech partner?
• Which partners are interested in building integrations on top of our existing APIs?
• Are there APIs that, if created, would interest a large number of prospective partners?

Knowing these answers will help you articulate to the rest of the business what you’re focusing on and how it plays into your team’s abilities and priorities. This is also the map to figuring out who your first handful of tech partners should include. 

Samila used Notion to notate: 

• Categories of potential partners
• The use cases for each partner
• The customer story we’d tell with each partner
• Do we have APIs to support this story?

Keep in mind: even if your APIs generally seem like they do what you need them to do, small details and unexpected hiccups in how the data flows can have a major impact on your integration roadmap. Everything up until the actual development of the integrations is hypothetical. You’ve got some data and reason to believe the APIs will function as you expect them to. However, you’re only seeing one side. You may not know the exact approach your technology partners are taking to utilize your APIs — and you may need to quickly adjust the APIs late in the game to make certain use cases work (Spoiler: We ran into this issue!). 

#4 Decide how you’re going to build and manage your integration infrastructure (At least five months before launch) 

There are two main components of developing an integration marketplace that you need to consider before building the actual integrations themselves:

1. The integration infrastructure (e.g. the APIs your company has available, the framework and philosophy you are embracing when building the integrations, scalability, and how you move data between your product and other products)
2. The integration marketplace user interface (UI) (e.g. how you visualize and present the integrations to the end-users through your website). Refer to #6 on how to build and manage your marketplace UI.

These two sides require different skills, people, and tools to make them successful. You’ve got to nail the user experience and the actual integration development. 

To note: The solutions you choose for building and managing the marketplace UI and integration infrastructure go hand in hand. In some cases, one solution can satisfy both needs, and in others, you’ll need a second solution to fill the need for your marketplace UI or integration development. Mix and match the solutions from #4 and #6 that work best for your integration roadmap and business needs. 

Let’s go over the integration infrastructure first. 

“Anybody who utilizes integrations as a core part of their go-to-market strategy probably wants to think carefully about which approach to the integration infrastructure aligns to their business model today and into the future,” says Samila.

Samila analyzed three options for managing the integration infrastructure: 

Option #1: Build the integrations in house. 

The downside: Your team needs to dedicate their time and resources towards developing the integrations (in addition to or instead of their typical responsibilities). They also need to fully understand the ins and outs of every external tool you are integrating with. You may need to bring in another company (like an agency or contractor) to help out. 

Option #2: Utilize an integration platform as a service (iPaaS) vendor.

An iPaaS vendor can manage some or all of your integration development (and in some cases, your marketplace UI, too). The scale and speed at which you develop integrations and go to market can be much greater since the iPaaS vendor has an extensive, existing library of connections to common SaaS solutions and an entire platform available to efficiently building more. The iPaaS vendors are like legos: they provide you with the building blocks (connections, recipes, templates) that will enable your partners and developers to quickly build integrations.

The downside: It can be costly to both you and/or your end user when the iPaaS owns your integration code and thus the pricing and packaging of your integrations. In some cases, the iPaaS vendor builds the integrations in-house, and in others the iPaaS vendor has an agency that builds the integrations for you or allows you to build them directly. Your team might also need to invest some time in writing additional code. Each iPaaS vendor functions a bit differently than the next, so you’ll need to weigh the pros and cons of each. 

Option #3: Utilize a universal integration framework provider. 

Samila looked into Left Hook’s solution Frigg (in beta), a product that provides a universal integration framework for building integrations at scale (more on Frigg in a bit!). He also looked into Open Integration Hub.

The downside: You need to invest your engineering team’s time towards getting the universal integration framework up and running within your product’s infrastructure — a lift, but not as big a lift as your engineers developing all of the integrations themselves. Additionally, the concept of universal integration frameworks is still relatively new in the market, so there aren’t established best practices just yet. 

Our Solution:

We first considered building the infrastructure for integrations in-house. For us, it proved to be too resource intensive and would have affected our product roadmap. We then considered iPaaS, but we were looking for more flexibility around the code ownership and pricing/packaging to accommodate our long-term ambitions for the Partner Cloud. 

We chose option #3: Utilizing a universal integration framework provider provided us with a wide breadth of integration development expertise and the comfort and ability to work closely with our internal engineering team. 

Samila adopted a software framework called Frigg, by Left Hook, to accelerate the development of some key integrations.Samila chose Frigg for three reasons:

1. Frigg allowed our team flexibility in having the integrations run on the back-end of Crossbeam’s software infrastructure while also enabling simultaneous co-development of the integrations by both Crossbeam engineers and external developers at Left Hook. 
2. Frigg’s architecture utilizes reusable logic blocks so that after building the first integration within a specific category, they can reuse these chunks of code to build the next, similar integration use case faster and cheaper. 
3. We “own” a copy of the code and can price and package access to the integrations for users however we wish. 

“There’s a certain workflow for integration use cases that may function in a similar fashion to one another,” says Samila. “With Frigg, we get the benefit of using the existing technical efforts for the first integration to make additional integrations in the same category, or even potentially other categories, faster to build. We’re building a library of these reusable technical components.” 

Even though we utilized Option #3 for our integration infrastructure, we still believe there’s a powerful benefit to partnering with leading iPaaS providers. We partnered with and built integrations into iPaaS vendors like Workato, Tray, and Zapier. We even invested our own engineering resources to build iPaaS powered integrations into various highly requested SaaS tools.

#5 Determine who will build the integrations (At least four months before launch) 

Now that you’ve decided the right integration infrastructure, it’s time to choose who actually builds the integrations themselves. 

“Who builds the integrations is probably the most difficult decision that the partner executive is going to have to face as they navigate these new tech partnerships and evaluate available resources,” says Samila.

A partnership is a two-way street — and the same goes for your tech ecosystem. While many of your tech partners will be the ones building integrations on top of your APIs, that’s not always the case. You’re also going to be responsible for developing many of the integrations and will need to invest in a solution that will enable ownership of the development work.

Samila and the ecosystems team considered three options for building the integrations:

Option #1: Split our team’s capacity between our product roadmap and integration roadmap

The downside: In this case, your integration roadmap will compete heavily with your product roadmap. You’ll need to be clear early on about the time and resources your team should spend on your integration roadmap and product roadmap to make sure your team isn’t overworked while meeting expectations for both. 

Option #2: Have a dedicated team in-house building the integrations

The downside: You’ll either need to transition specific roles that already exist to be dedicated to integration development and offload their responsibilities to others on your team or allocate budget and resources towards hiring a new integration team. 

Option #3: Hire a development agency/contractor to develop the integrations

The downside:

• You’re spending budget on outsourcing work rather than having your team manage the work internally.
• You’re spending time finding and hiring the right development agency for the job.
• In some cases, you’re spending time getting the development agency up to speed on your technical infrastructure, your brand, your partners, and other knowledge only you or your team would know.
• Once the initial launch work is done, you may need to invest in billable time with the development agency for ad hoc projects.

Our Solution: 

You guessed it: we went with #3. Having Left Hook’s developers build the integrations directly gave our engineering team flexibility and control over the integration infrastructure while alleviating some of the actual integration development lift. 

The integration marketplace launch benefited from the product and development process our teams at Crossbeam already had in place, with various members of our team filling in as temporary Ecosystem PMs. 

Inherently, your integration marketplace launch will compete with other projects on the roadmap — a huge reason getting buy-in early on from your entire organization is incredibly important.

“You need to treat this as a project that has all of the internal structure around it that other projects have from a product and development perspective,” says Lindsey O’Niell, Director of Product at Crossbeam. “We broke the work into features that different teams owned, and they were inserted into our roadmap with a team of engineers managing them.”

This option still requires internal engineering resources and a reprioritization of our roadmap to guide the integration development process and complete development work where needed. 

For instance: Our engineering team invested time standing Frigg up inside our infrastructure, refining our APIs (creating new and updating existing), writing API documentation, building recipes for the iPaaS platforms, and preparing our software systems for Left Hook to deploy Frigg into software environments.

“We probably should have given ourselves more time on this because we didn’t have our ducks in a row with all the APIs,” says Samila. “It’s only when we got into building the integrations that we realized the way those APIs operated actually didn’t always solve for the use cases we needed. Then there was a maniacal racing around trying to quickly update the APIs because we were on a timeline.” 

For example, with marketing automation tools, we wanted to pull data on specific accounts rather than a whole report. The API that existed did not satisfy this need, so our engineering team had to build an entirely new API midway through the process. 

Keep an eye out for roadblocks during the development phase so that your whole integration roadmap and ecosystem launch doesn’t get delayed. 

#6 Decide how you’re going to build and manage your marketplace UI (At least five months before launch) 

Now that we had our integration infrastructure plan ready to go, we needed to determine how we would manage the marketplace UI component.

Samila considered two options for building and managing our marketplace UI: 

Option #1: Utilize an iPaaS vendor that has marketplace capabilities

This would enable us to leverage an iPaaS vendor’s existing marketplace UI (In some cases, your iPaaS vendor could manage the integration infrastructure as well, as previously mentioned).A solution like Pandium, for example, can accelerate the launch of your marketplace and provide rich analytics data on the marketplace and integrations.

The downside: In some cases, you’re locked into a single vendor for your marketplace UI and integration infrastructure. You may also run into pricing and packaging challenges depending on your unique business needs.

Option #2: Work with an integration marketplace as a service platform like OpenChannel, which can build and deploy the marketplace UI

OpenChannel does the UI development work with guidance from your internal team from a design perspective. Meanwhile, your developers can submit each integration directly to the platform, and you have flexibility over which integrations you present through your marketplace — integrations built by partners, in-house, through external developers, and even iPaaS-powered integrations.

The downside: You’re incurring an annual cost to utilize a marketplace as a service platform.

Option #3: Build your marketplace in-house

The downside: Like building anything in house, you’d get complete control over the marketplace in exchange for taking some developer resources away from other parts of your business. The timeline to bring your own custom designed, engineered and hosted marketplace can be lengthy, especially if partners need to be able to update their own profiles.

Our Solution: 

Samila decided to adopt OpenChannel, because it allowed us to launch a professional marketplace quickly that both our internal team and partners could easily update going forward. As an API-first approach to an integration marketplace, we had the choice of designing and building the marketplace ourselves or utilizing OpenChannel to build the marketplace based on our designs. OpenChannel’s ready-to-use marketplace design templates accelerated how quickly we could get a baseline in place and then allowed us to tweak the design to match our branding and functionality needs. 

Keep in mind: While the design process becomes simpler by using OpenChannel’s design templates, we still needed to prioritize time in our design roadmap to ensure the marketplace reflected our branding. Don’t underestimate the time needed to do this.

#7 Identify Tech Partner Categories and Use Cases to Pursue (At least four months before launch)

With your APIs’ capabilities in mind, it’s time to decide the kinds of integrations you’d like to include in your tech ecosystem along with the specific companies you’d like to include. 

Samila identified potential integrations in two main ways: 

1. Customer and prospect feedback — What are they asking for in terms of actual integrations and categories they’d like to see partner data flow into?
   
   
2. Determining how our business and product wants to expand as a solution and which integrations could help with that expansion — In addition to chatting with the leadership team about where partner data should exist in the future, Samila browsed G2 to map out which categories he could visualize partner data going into and relevant companies that fit into those categories.

“It’s an interesting dance between, ‘Where is our product direction going?’ and ‘Does that align to certain tech categories or partners?’” says Samila.

#8 Get your potential partners on board (starting six months before launch and onwards) 

Samila turned to Crossbeam to validate potential integrations by identifying how many overlapping customers Crossbeam has with each potential partner (in Crossbeam, we know, meta). With this partner data in hand, Samila and our prospective partner would be able to build a strong case to invest in an integration. 

For example, if you have five customers who have requested an integration with sales engagement platform SalesLoft, and an account mapping tool like Crossbeam shows you that you have an additional 100 overlapping customers — that’s more than 100 customers that would potentially adopt the integration and find more value in your product and your partner’s product. You can also determine how many prospects your partner has overlapping with your customers. Those are the accounts you can help your partner close by pitching your joint solution. 

Before meeting with your partner, prepare a quick “better-together” story to help them understand how you would position and co-sell your joint solution. 

“You can say, ‘Hey, we have a mutual customer. They really want this integration. Let’s use Crossbeam and identify a bunch of other customers that also want this,’” says Samila. “It helps with the alignment side of making it very real as to why they should partner with you.”

“We’re going to look at market presence,” says Samila. “We’re going to look at alignment on who their target customers are. ‘In their category, are they the market leader? If they aren’t the market leader, are they rapidly catching up?”

One more thing: don’t forget to make sure your partner is a culture fit. 

“Is the partner team at this company going to respond quickly as we dig into the work together?” says Samila. “Will they help us be creative in building the most impactful and innovative integration together? Will they rally their GTM teams around this new integration and make the biggest splash possible on launch day and beyond.”

Additionally, you’ll need to create partner program legal documentation for your partners to sign off on. Samila worked with Amy Rose, Crossbeam Head of Legal, to build a technology partner program legal framework to help articulate how we wanted to work together with partners and make sure both parties were protected — especially since we would be sharing data back and forth with our APIs. 

Samila and Rose devised three documents: 

1. A Partnership Agreement (which includes a mutual non-disclosure agreement). This will describe how you and your partner might each use the other’s trademarks and logos, how you might co-sell together, and how you might share certain information about your customers and prospects with each other. This will protect the confidential information that you and your partner share with each other. 
2. Developer Terms. These will describe how partners can develop on your APIs, and how you might market or list the apps they build so that your customers can find them.

#9 Keep your entire team informed (Six months before launch and onwards) 

Since every role in your organization will benefit from your tech ecosystem, you’ll want to ensure the entire organization is kept up to date on the status of the official launch. 

Samila and the Ecosystem Team maintained transparency to our fully-distributed team throughout our tech ecosystem’s development by:

• Creating documents in Notion that listed each partner that was participating in the launch, each partner’s status (e.g. still in the development phase or launch-ready), use cases relevant to each integration category, timeline updates, and more. 
• Recapping every tech partner in a dedicated #partnerships Slack channel. This helped align the partnerships, content, and sales teams (among others). Just picture it: Your sales rep is in conversations with your potential partner, and your content team is planning an interview with the partner for your blog. All of these stakeholders need to know about the other’s relationship with the partner to keep the partner informed and provide the most valuable information to the partner in each circumstance. 
• Keeping the people closest to the launch aligned through a dedicated #partnerships-tech-program-launch Slack channel, where our marketing team, product and engineering teams, and leadership discussed activities surrounding the launch’s execution.
• Establishing a #technology-integrations-infrastructure Slack channel to keep our engineering and product teams aligned on the integration roadmap, any challenges with APIs, and launch progress. 
• Spending 10 minutes during our weekly company-wide standups informing everyone about timeline updates, new partners, or use case changes. 
• Presenting the progress thus far and any significant changes to the tech ecosystem in the making during our monthly All Hands meeting.
• Ensuring all co-marketing collateral is kept in one place accessible to the entire team (we used Google Drive and Notion).

A tech partner workflow slide that Samila shared with the entire organization to give everyone a sense of the timeline, resources, and people involved in bringing a prospective technology partner and integration to life: 

The partnerships tab in Notion, accessible to all internal team members: 

In Notion, Samila sorted all of our tech ecosystem partners by: 

• Category 

• And by Partner 

Get the “Tech Integrations by Partner” form. 

Get the “Tech Integrations by Category” form.

#10 Prepare your partners for launch (Two months before launch) 

To get the marketplace collateral ready, Samila introduced Amanda Groves, Director of Product Marketing, to each partner and/or each partner’s marketing team. Groves liaised with each external stakeholder to gather branding collateral from them and make sure their joint solution messaging was lock-tight before producing the final materials.

“It’s rare you have an ecosystem this size,” says Groves. “Going to market with over 20 integration partners and delivering each partner’s go-to-market package is a very exciting and impactful launch moment.”

Groves worked with more than 20 tech partners to create integration marketplace listings, which included: 

• The partner’s logo
• An overview of the integration and the challenge it solves
• A list of key benefits
• Videos and/or images describing the technology partner’s solution 
• In-app screenshots of the integration
• An FAQ section
• A description of how to adopt the integration and how it works
• Badges 

Groves and the Solutions Engineers also built an integration marketplace template one-pager for partners to fill out with their own messaging and information.

Page 1 of 9 in the Integration Marketplace one-pager. Get the template below.

Page 2 of 9 in the Integration Marketplace one-pager. Get the template below.

Page 3 of 9 in the Integration Marketplace one-pager. Get the template below.

Get the “Launch Tech Program” form. 

Get the “Co-Marketing Activities” form.

Get the “Integration Marketplace one-pager” template.

#11 Prepare Your GTM teams for launch (Two months before launch)

Launching an integration marketplace opens the doors to co-selling and co-marketing opportunities. Be prepared to maximize the effects of both by planning ahead at least two months before launch. 

It’s around this time that you’ll need heavier involvement from your product marketing, content marketing, and sales team. Amanda Groves and the Solution Engineers prepped our GTM teams with the integrations and tech partners involved in the launch.

To prepare for co-selling, Groves and the Solutions Engineers developed sales enablement materials and trainings by integration and by integration category to roll out over a six-month timeframe post-launch. This includes: 

• A resource page in Notion with details about integration pricing, screenshots, FAQs, enablement slide decks, and more.
• Live enablement sessions and recordings of all sessions so our team can easily reference them when needed
• Launch dates for integrations coming soon 
• A visual representation of the pricing for each integration, outlining whether they’re paid of free
• One-pagers for each integration 
• Snippets for the sales and customer success teams to easily reference our tech integrations in their correspondence with prospects and customers 
• Updating our sales deck with information about the integration marketplace launch
• A sequence of enablement sessions each month for our sales and customer success teams
  
  

Meanwhile, Groves collaborated with the content marketing team to produce GTM co-marketing collateral including: 

• An integration marketplace announcement blog post, written by Director of Content, Sean Blanda

• This blog post written by Staff Writer, Olivia Ramirez

• A webinar — No More Silos: 4 New Ways to Use Your Partner Data on June 16th at 1PM ET — which required work from Content Marketing Manager Jasmine Jenkins and Sean Blanda
• Social media copy and creative for announcing the integration marketplace and upcoming webinar, developed by Jenkins and Graphic Designer Nick Beaulieu
• A newsletter integration marketplace announcement and email marketing promoting the webinar 

#12 Build Partner Tracking and Attribution (Two Months Before Launch) 

Once your integrations are live, you’ll need to track their adoption, usage, and influence on opportunities and retention. 

Samila implemented four tactics for tracking attribution:

1. Create a new account record type in Salesforce called “Partner Account” which contains key details about the partner. We created a separate record type to make reporting easier long-term.
2. Created a custom object in Salesforce called a “Partner Relationship Object” (PRO), which provided a link between the partner accounts and the sales opportunities managed by our AEs. This PRO was designed to sit alongside each opportunity, rather than having the data on the opportunity record itself. This provides the benefit of allowing us to have an unlimited number of partners associated with one opportunity and keeps all the relevant data about the partner for that opportunity contained and easily reportable. We built this before launching our integration marketplace so that we can effectively scale our partner attribution model. Through this method, we can see all the ways that partners are associated with each customer account.
3. Set up tracking for every API call made using Segment, with specific tags for each unique integration, and then pushed this into our Redshift database. This allows us to monitor which integrations are getting used, when, and by who — and this data leads to all the other analyses that go along with that, like which integrations lead to paying customers most frequently, for example.
4. In the future, we anticipate adding tracking and reporting on the influence these integrations have on the retention of our customers.

#13 Initiate a soft launch (One week prior to launch)

One week before our official launch on May 26th, we launched softly to invite customers who expressed interest in beta testing the integration marketplace to give it a test run and provide us with early feedback. Samila and Groves also noted which integration categories were most popular to help prepare their GTM launch.

During the soft launch, our team continued to finish up outstanding items — like gathering final pieces of co-marketing collateral and ironing out last minute technical issues. Unlike for a normal feature launch, a soft launch for an integration marketplace requires proactive help from multiple external stakeholders. In our case, we had more than 20 partners contributing content, discussing revisions, and coordinating with their internal teams to meet our launch deadline. The Ecosystem Team has to be all-hands-on-deck — especially in the month leading up to the soft launch. 

#14 Launch

For the launch of your tech ecosystem, you’ve got one major factor on your side: all of your partners are working to meet the same deadline. 

A big first tech ecosystem can make a big splash. Own it! All of your partners have agreed that they want to align their brand with yours (and vice versa) — that’s huge. 

“This is just the beginning. The launch of a marketplace is signalling to the market that you not only have new partnerships and integrations available but that your company is investing in the success of the ecosystem around your technology,” says Samila.

Now’s the time to push your integration marketplace live, for your partners to hit “publish” on their dedicated partnership pages, and put your co-marketing and co-selling motions to work. 

The Crossbeam Partner Cloud (Browse our entire integration marketplace here)

HubSpot’s listing

Launch announcement in our newsletter

Refer back to Groves’s “Co-Marketing Activities” form for a full list of all the co-marketing materials that went live for our tech ecosystem launch. 

Meanwhile, each of your partners should publish your partner profile on their websites to spread awareness about the partnership and create access points for others to discover your integration marketplace. 

Crossbeam in Medallia’s partner directory 

Crossbeam in RollWorks’s partner directory 

#15 Map Accounts to Drive Integration Adoption

Look to the partners you’ve brought into your tech ecosystem to amplify the reach of your new integration marketplace among your shared audiences. 

If you’re using a PEP like Crossbeam for account mapping, make sure you and your partners are sharing data to surface overlaps between your prospects and your partner’s customers (and vice versa). This will help you identify co-selling opportunities and overlaps between your customer lists (to drive integration adoption).

Meanwhile, you should empower your sales and customer success teams to gather feedback from prospects and customers about how your ecosystem is stacking up. For instance, your sales reps can get insight about the use cases your prospects wish a particular integration solve, and your customer success reps can learn how customers want to dive deeper into your platform with more complex use cases. 

Keep the dialogue going. Samila has created go-to-market (GTM) Slack channels with each partner and their respective sales and customer success teams so they can initiate co-selling motions on an ongoing basis.

If you’re launching more than 30 integrations like we did, you’re going to need to dedicate time over the next six months to make sure everyone involved on both sides of each partnership knows what the integration does, the use cases it solves, the joint solution pitch, and how customers can adopt it. 

#16 Measure the results (Weeks, months, and years after launch) 

Once your tech ecosystem goes live, you’ll need to start measuring results. Start with metrics like: 

• Number of customers who have adopted a particular integration and whether the integration is active or not. For instance: A user may activate the integration, but their long-term integration usage is critical to measure adoption effectively. At Crossbeam, we have a Slackbot that shows API utilization among our customers and partners as a leading indicator of integration adoption, sent to our #general channel daily, and integration usage metrics on an individual level visible in Redash.
• Number of deals where a technology partner sourced an opportunity or influenced a sales cycle. 
• The percentage faster sales cycle with a partner
• Renewal rates for customers who have adopted specific integrations compared to those who haven’t

Some of these metrics will require months and years of data. Start small, and develop sources of truth as your ecosystem grows and you have more data to compare. 

#17 Keep the momentum going (All day, every day) 

In addition to driving sales and retention, your integration marketplace is making an impression with all of your future partners. Other potential partners within a particular category will see their competitors front and center on your integration marketplace, and they’ll want to get in on the action. 

Crossbeam hired its first Senior Product Manager of Ecosystems to help manage the integration roadmap between the engineering and partnerships team in the years to come. 

“In June we will have a full time Ecosystem PM. This whole project illuminated how essential that role was to hire. Too much for a PM to do in their spare time, which is what Lindsey was doing,” says Samila.

Check out our upcoming Partner Cloud releases here.

—