‍

The Partnering Reference Architecture: Managing Your CRM

Last week, I wrote about how your CRM must be the central hub of your partner reference architecture.

This week, I’ll explore some of the principles of CRM and of Partnering. I’ll highlight how these two concepts are not quite aligned. Even though the CRM should be the centerpiece of your partner universe (aka the Partnerverse), there are still some changes that you need to make in your CRM to handle the differences that partnering brings to the business operation.

The basics of CRM design

First, let’s explore some CRM basics. These standard objects make up the components of traditional or direct business sales. The standard objects of Lead, which converts to Account, Contact and Opportunity, are the foundations of basic CRM theory.

This is the model for managing direct (inside) sales, and your CRM is built to handle this functionality straight out of the box.

Changing the data model in your CRM

As a partnering professional, this simple data model will not be sufficient, and 3 key things need to be added to support partner sales:

• Data Design Consideration one: How do you identify a Partner?
• Data Design Consideration two: How do you identify a Partnership?
• Data Design Consideration three: How do you handle Attribution?

Design consideration one

How do you identify a Partner? In the model shown in Fig. 1, the Account record represents the Firmographic details related to the End Customer.

But, there needs to be another type of Account record that identifies the Firmographic details related to the Partner. This can be handled either via Option 1: changes to the data structure, or, Option 2: by creating “tags” in the data (not recommended).

Samples of option one: data structure changes are as follows:

• Create a Record Type on the Account record so that there are fields for “regular customer” Accounts, and a separate layout for “partner” Accounts.
• Add a picklist field on the Account record to enable users to select the type of account (Partner, Customer) from a dropdown.

Sample of option two: data tags:

• Name the Account with the word Partner in it (e.g. Acme Widgets - Partner)

Note: Option two is extremely difficult to use in reporting, and is strongly discouraged.

Design consideration two

Identifying a Partnership vs. a Partner. This nuance in the data structure is vital to some organizations and will be of little interest to others (depending on the structure of your partnering programs). This nuance ensures that there are ways to allow a Partner (Account) to have multiple Partnering Programs (called Partnerships) they can be a part of.

As a simple example: Acme Widgets could partner with our company via a Reseller program (in which they are compensated at 20% of product value). Acme Widgets could also engage in a Referral program (in which they are compensated at $1000 for a successfully converted Lead). 

In this example - it is not sufficient to say that a deal belongs to a Partner - Acme Widgets - we need to specifically identify the Partnership program that a deal was brought to us with.

Some companies only have one partnering relationship with each account (e.g. everyone is a reseller), and in this scenario, the Partner and the Partnership are the same. However, companies with a sophisticated relationship model will need to track both Partner and Partnership details as they connect their deals.

Design consideration three

How do you handle Attribution? One of the most fundamental and important characteristics of a partnering program is the ability to attribute a particular deal to a partnership. However, there are a few nuances to this discussion that require consideration.

First–for most partnership models: there is the possibility of multiple partners being involved in a deal (e.g. it was referred by Acme Widgets, but Ajax Corporation is the technical partner who will deliver the deal).

Secondly: if there are Partnerships that are distinct from Partners, the Attribution needs to identify the Partnership (not just the Partner). Both of these factors need to be considered when performing Attribution - so that the correct metrics (and the correct financial results) can be achieved.

These three design considerations make the data model for Partnering different from the data model for standard CRM and Sales. This new model - shown in Fig. 3 is the Reference Architecture for Partnering.

What’s different here is that the standard CRM model has been updated to include changes for adding a specific Partner Account, the ability to specify multiple Partner Account Partnerships, and then enabling Attribution for multiple Partnerships.

We’re still in the early days of partner-tech

If you work in partner operations - you might have questions like:

• Why does it take so long for me to put reports together?–or–
• Why does it take so long to assemble Partner Business Review documentation?–or–
• Why are the other systems in our Partnerverse (e.g. PRMs) not giving me the right data?

Here’s why: The data model isn’t tuned for these new relationships that partnering needs, so manual intervention is almost always required.

So, review your current systems–see if you can make the changes you need to enable your reports and metrics to reflect the many-to-one relationships you, as a partnering professional, need. We’ll wait to see if any of the first-generation partnering tools in the marketplace today can adjust.

Partnering professionals are going to be pursuing ever-changing, and always more complex deal structures, and so the systems that manage partnerships are going to need to evolve just as rapidly. Right now, we’re in the early days of Partnering - and the tools in the marketplace aren’t quite ready for prime time.

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