Introducing the Partnering Reference Architecture

Introducing the Partnering Reference Architecture

Brian Hattaway 3 min

What are the key principles involved in the ideal partnering reference architecture?


Over the next few weeks, I will share the principles of good partnership systems design. I’ll show you the guidelines, principles, and standards that are needed to set up a scalable partnering program.


I’ve learned the hard way - through trial and error. Now I want to offer you these learnings so you can assemble the best-of-breed systems to scale your partnership program to the enterprise level quickly.


What are the key principles involved in the ideal partnering reference architecture? Here’s a preview - and we’ll dig into each of these principles in more detail in subsequent posts.



Guiding principle one: Your CRM is the center of your partnering universe (a.k.a The Partnerverse)

Your CRM should be your system of record for all partnering information. Do not manage your partnerships with a tool that operates separately from your CRM. You will never be able to report on partnership performance metrics if you segregate sales activity (managed in the CRM) from partnering activity (managed on a separate platform).



Guiding principle two: You have to modify your CRM and/or your procedures to effectively manage partnerships

The native (direct sales model) CRM functionality that comes "out of the box" is not sufficient to manage partnerships well. We’ll explore the theory of how a CRM works, and highlight what changes need to be made to a standard CRM to allow it to work for Partnering.



Guiding principle three: Data is the currency of power in partnerships

There should be no tool in your arsenal that cannot share data with your CRM.

Your best options for managing and reporting on the success of your partnership program rely on your ability to capture the data from 3rd party tools in your CRM so that all your critical metrics can be reported alongside all of your critical sales data (which is already in your CRM).


We’ll look at aspects of connectivity that include API capability and data compatibility (a critical, but often overlooked aspect of connectivity).



Guiding principle four: Quality reporting should be automatic

One of the hallmarks of good system design is that reports are automatically available, and they are structured in ways that are meaningful and relevant to the business. One of the diagnostics we use to define the health of a system is the ease of reporting.


Many partnering professionals spend hours (days?) creating Partner Business Reviews (“PBRs”). This is usually because of poor system design (they are cobbling together data on different platforms, or trying to deconstruct data that has been collected in non-standard ways). Good reporting comes from good system design, and we’ll explore ways to ensure that a PBR (and other reporting) is automatic.



Guiding principle five: Scalability is a critical design feature

Setting up a partnership is only part of the battle. True results come from continuing to manage the partnership - encouraging bigger and better results. This means that the partnering platform needs to have the automation capability to support ongoing measurement, management, and performance of partnerships.


This ensures the efficient use of partnering professional resources.


Stay tuned as we explore these principles in more detail in the next blog posts.


I’m excited to take you on a journey through the universe of partnerships a.k.a, the Partnerverse. I’ll create the right answers for you as we travel the partnering path together.


Prefer to listen? Subscribe to our nearbound.com Audio Articles Podcast. Text-to-speech provided by our partner Voicemaker.in.

Brian Hattaway 3 min

Introducing the Partnering Reference Architecture


What are the key principles involved in the ideal partnering reference architecture? Learn them here.


You Might Also Like