If I’m being totally honest with you - and I generally strive to be uncomfortably so - it’s been a busy week. On top of the three kids, spouse, and full-time job, Partnership news also blew up.

First, PartnerHacker announces a merger with Reveal to launch Nearbound the same day I went deep on the value of Salesforce list-views. Seriously team... next time let’s coordinate. Really hate that for you...

Then, Crossbeam announces a new partnership with Pavilion to accelerate learning around ’Ecosystem Led Growth.’ Clearly, they’ve not paid attention to the weekly office hours I host exclusively for members of Partnership Leaders. Oh well... more people learning about the value of the Ecosystem is a good thing, right?

Finally, I had a conversation that inspired a litany of ideas and research that I anticipate leading up to additional announcements of my own that start here today. The first announcement?

CRMs are the Worst (for Partnerships)

I did some digging this past weekend and confirmed some suspicions I’ve had for quite a while. Namely - there’s no "cheap" path to Partnerships within core CRM functionality.

Every CRM I checked - Salesforce, HubSpot, Dynamics, and even Zoho - fails to include ’out of the box’ functionality for Partnership management. This means any company looking for native functionality has to upgrade licensing for the entire organization to get access to the customization capabilities they need. This can add significant cost - we’re talking thousands of dollars in most cases - and then they still have to build it!

Building is the secondary challenge behind price because the need is urgent, creating pressure to deliver something yesterday. Literally, every ops professional out there knows this pain - it’s not unique to Partnerships. What is unique, however, is the lack of experience and resources that goes into the solution effort. The general priority is ’Don’t mess with Direct’s toys’ and we’re off to the races building a poor foundation. Little to no consideration for the Partner Experience felt by Partners, Customers or colleagues.

Don’t Skip the Ice Machine

This past weekend I hit up a local burger joint with my wife and couldn’t resist snapping this photo in the midday rush. If you’ve ever worked in a restaurant that faced this problem you’re already grinning from ear to ear because you know exactly what I’m going to say next. If you’ve never worked in a restaurant or experienced working in one with a cheap owner, let me explain.

The ladder is there so that the employee can fill the machine with ice.

I grew up working in restaurants. This is where I first learned concepts like ’front of house’ and ’back of house.’ It’s where I first saw pecking orders and hierarchies really come to life. It’s the world that exposed me to customer satisfaction, upsells, and learning how to get things done with speed and efficacy.

In this world where every second matters, the worst job you can have is filling up the ice machine. It’s a never-convenient but always shared job that irritates everyone from the customer to the line chef trying to get food out the door. Why you ask? Oh, fortunate you that never felt this pain... let me expand.

• That latter stayed in the way for 10 minutes while the employee made 5 trips to the back of the restaurant, through the front desk, prep areas, and cook lines.
• Customers had to work around it in a very limited space this entire time. One couple had to stop their kid from climbing on it to get a drink.
• The employee had to haul a 5-gallon bucket of ice up that ladder 5 times, I saw (hello Slip/Trip/Fall claim!).
• The line lost a cook in the middle of the lunch rush (my onion rings were a bit crunchy).
• A spill can send ice all over the counter and floors, creating more hazards and time lost.
• It’s generally needed at peak hours, pressuring employees to rush the job and increasing the risk.

What drives me nuts is that virtually every time I see this I know, with 100% certainty, that a solution exists. Ice machines can be installed on top of the machine to keep the ice flowing and avoid every single delay, hassle and liability mentioned above. So why don’t they do it?

In this case, I can see two likely reasons that have the same core issue: cost.

1. Not enough space (resources). They may have been told the space was too short and they’d need additional work to accommodate the bulk of the ice machine. Given they could get or had a standing ice machine for a fraction of the total cost it ’made sense’ to just go have someone do the fills instead of trying to build a solution.
2. Legacy Setup. This is an older, established joint, and they may also be working with a legacy setup. The option may not have existed when they started, and they’re not prompted to make a change when what they have ’works well enough’ as it is. They’ve got front-end bussers (ops teams) they can assign to relieve the burden from the wait (sales) staff.

Regardless of the reason, the excuse is the same - avoiding an ’expensive’ investment because they can’t see the long-term payoff. The ice machine would make things easier, and safer, and everyone happier, but it’s not "necessary" because we can solve the problem with headcount.

Sound familiar?

The partner ops "ice machine"

This ’big payoff’ this week is a list of considerations for your build efforts, the ’Ice Machine’ of your Partnership program if you will. If you won’t, maybe consider it the border pieces of the partnership puzzle that will frame your program tech stack, beginning with your CRM and expanding out into future solutions.

It’s not meant to be prescriptive - there’s no specific guidance or additional prompts for the elements. I’m just highlighting the data and a few questions to drive intentional conversations around your foundation. You’ll have a lot of other decisions to make. It’s only meant to provide a high-level list of considerations for the architecture that will either support or block your future scaling desires.

Sounds really sexy, yeah? I thought so. Anyway... here’s a non-exhaustive list of common elements that are often needed yet not supported natively in any CRM.

• Partner Accounts and Page Layouts
• Partner Contact Management
• Partner Recruitment Efforts
• Partner Programs (Details and Engagement–who’s in what program?)
• Partner Agreements
• Partner Attribution + Influence Model
• Partner Renewals
• Partner Lead Distribution
• Partner Inbound Referrals
• Partner Outbound Referrals
• Partner Deal Registration
• Opportunity Visibility and Tracking
• Partner Quotes + Approvals
• Co-Selling
• Customer Renewals with Partner Support
• Partner Support
• Partner Product Licensing
• Partner to Customer Licensing Ownership and Billing
• Partner Marketplace/Directory listings (In-App, Online, Internal)
• Partner Certifications/Credentialing at Individual & Account levels
• Partner Reporting
• Partner Dashboards
• Partner-related workflows/automation

Questions to ask

The questions presented below are working from the assumption you’ve already decided to have your Partnership teamwork from the core CRM. This is really the first question to answer. If the answer is ’No’ then you’ll want to use the element list above to start vetting vendors focused on building ecosystem platforms and get clarity on how data can be synchronized back to the CRM for Direct visibility.

If the answer is ’Yes’ - we do want our Partnership team in the CRM, at least for now - here are a few questions to help you build something solid to get started.

1. What do we want our program to look like in two years (vision)?
2. Is this element necessary for our current programmatic strategy (prioritization)?
3. What do I want to track about this element (reporting and outcomes)?
4. How does this element contribute to our success (strategy)?
5. Who is managing this data element (ownership)?
6. Who needs access to this data (visibility)?
7. How do I get any of this reflected in our CRM (change management and resourcing)?

Ultimately, your goal is to build the vision for what you want to see at a higher level and then work toward the daily functions.

Go crazy - get your ideal state of mind and write it down. Better yet - make sure your methodology for Partner Management is reflected in your summary for full alignment. You likely won’t get all of it but it’s better to do this kind of brain dump than nitpick over details and blockers you don’t know exist.

All of this information will help you work more efficiently with your Ops teams (IT, RevOps, SalesOps.. who owns the CRM build-out) on the solution, leaning on their technical guidance around how to execute what you’re after. Don’t get too stuck on your own idea for the solution details - checkboxes v. dropdowns, button placement, etc. - as long as they are meeting your business need.

The wrap up

CRMs are the worst (for Partnerships). They can be expensive, they all need customization, and none of them solve the Partnership problem out of the box.

I hope this summary helps you feel more confident in taking on the super-not-fun-or-sexy work of system architecture. No matter what you do from here, if you only take away one piece of advice, make it this...

Don’t skip the ice machine.

(P.S. - If you’re looking for an ice machine for your Salesforce implementation, reach out on LinkedIn or to aaron@partneropspartner.com and let me know.)

Prefer to listen to a summary of this post? Check out Aaron’s podcast here: