There are a lot of reasons why CRM Implementations fail. Long before I ever found a niche in Partnerships, I actually wrote about this myself but of course, I recently deleted all the proof from my older LinkedIn articles because of “branding” or whatever.

The good news is that loads of other, more qualified organizations have written loads of other, more technical articles that you can easily find on a Google search. They also back-link to one another kind of like I’m doing here so it’s easy to find more sources (sorry, Issac, I know it’s up to us to end algo simping).

This matters today because of my current campaign to make Salesforce more relevant for Partnerships. If the overwhelming data suggests that CRM implementations are going to fail due to a repetitive list of reasons, how much more effort will be required to support a team that doesn’t even get core architectural support?!

More simply put… if the Sales team has a hard time adopting a solution literally built for them, what hope does a Partnership team have?

If you’ve been reading along the past few weeks, you might agree with that it’s more than you think.

The power of list views

Salesforce has a lot of native features that often go unused or get adopted without any strategy. Big features like activity monitoring and email integrations become the focus, while things like basic platform navigation tools fall by the wayside.

Teams will know how to flag an email from their inbox to ensure it gets added to the right Lead or Opportunity, for example, but not understand the basic value derived from using the ‘Favorites’ menu.

‘Views’, in my opinion, fall into this bucket of ‘poorly’ and/or ‘underutilized’ native features. There are several reasons I think ‘Views’ offer clear value for any organization and team.

• ‘Views’ can be limited to roles, profiles, or groups independently, giving you lots of flexibility in who can see what and in what way.
• ‘Views’ can be strategically named to drive processes when built correctly.
• ‘Views’ can be set up for data editing on certain field types, helping drive quick updates.
• ‘Views’ can be set up as lists or Kanban.
• ‘View’ can incorporate graphs - cool, but I’m honestly still working on the long tail value here.
• ‘Views’ can show whatever fields are important for a specific workflow.
• ‘Views’ can be locked down, forcing people into the workflow.
• Favorited views appear in the drop-down for each tab in the traditional Sales app, where most organizations tend to work.
• ‘Views’ can help users find data more quickly than loading reports.

The typical user experience, however, looks more like this:

• Everyone can create global views that show up on everyone else’s list - this is perhaps the number one challenge to strategic adoption as I see it.
• ‘View’ lists end up growing to unreasonably high counts that make ‘View’ use difficult to navigate.
• ‘Views’ aren’t tied to the process and thus lose value over time
• Changes in data architecture/process don’t include ‘View’ review and updates to keep them in sync with current efforts
• Overall, all of these issues roll into a lack of strategic planning and adoption for the use of ‘Views’
• Users ultimately learn not to trust existing views and instead build their own, making support and alignment challenging over time.

Failing to look at ‘Views’ as a strategic tool in system utilization early means you’ll either end up abandoning their use or investing a significant amount of time reclaiming them down the road. Anyone with experience managing operations will see this pattern as a common occurrence in the world of system adoption, the ever growing mound of technical debt that never gets paid.

Partner specific views

Built correctly, ‘Views’ can be used to help drive visibility and process on active data across every data point in Salesforce. Almost anything you might want to move through a process can likely benefit from a few well-constructed and intentionally deployed views. This makes the features a great way to add quick value when leveraging Salesforce for Partnerships, especially in early to mid-stage companies that don’t have other tools and systems in place.

Here are some examples of ‘Views’ that might be useful for Partnerships:

Partner Recruitment Views (on Accounts or Leads based on setup):

1. P: New Partner Applications - Unreviewed

2. P: Active Recruitment Accounts

3. P: Recruitment in Contracting

4. P: Signed Partners - Last 30 Days

Partner Sourced Lead Views:

1. P: Partner Sourced - New Leads/Deals to Approve
2. P: Partner Sourced - Open Partner Leads/Deals to Review
3. P: Partner Sourced - Partner Leads/Deals Closing in 30 days

Leads for Distribution to Partners:

1. P: Distributed Leads - New Leads to Assign
2. P: Distributed Leads - Assigned and Unaccepted Leads
3. P: Distributed Leads - Accepted and Open Leads
4. P: Distributed Leads - Leads Ready for Conversion

Inbound Partner Referrals:

1. P: New Referrals to Assign
2. P: Working Referrals
3. P: Referrals Pending Payment

Hopefully, these examples are enough to get you going but there are a few things worth noting on setup.

• Define all Partnership views with a ’P:’ (or maybe an ’E:’ for Ecosystem if you’re there) at the start to make finding them easier. Inform RevOps, etc. that these are intentionally managed and should only be updated through Partner/Channel ops.
• Make sure the views are assigned to the right users, profiles, or groups, with groups being one of the easier methods for new people as there’s less security concern or risk if you need to have it created.
• Use Views in processes that help drive daily activity and, if possible, order them sequentially to help drive operational order. The idea is that people can check these views for outstanding work and move things forward into other views, i.e. some views like ’New Leads for Partners’ should be cleared daily. Keep in mind ‘Views’ have a character limit so you may need to adjust to standard abbreviations and educate the team (i.e. Ptr = Partner).

General tips to improve view use

Aside from the partner-specific ideas above, there are a few things to consider as ‘Views’ are a global element within Salesforce. Literally, everyone has access to use global public views and without intentional effort, the feature can get bogged down.

• Attempt to get global list view creation locked down for everyone. You might be way too late for this, but if you can get it you increase the value of the feature for everyone and make your life a little easier.
• Include ‘List View Review’ as a component of every SFDC project to ensure they are maintained. At the very least, bookmark your key views and remember to check them on your own for your projects.
• Remember that views can be user-specific. If the view is filtered to ‘My Records’ you’ll need to log in as users reporting issues to check on what’s happening. Also, advise your team to refer to ‘core views’ if they are cloning for adjustments.
• Train your teams to use their initials on any Personal views (i.e. AH: Lead View) as this helps distinguish clones.

I know.. so few images this week... whaaaaat? 

The downsides

I try to be as agnostic as possible around the tech I’m working with. This is largely because Operations doesn’t normally have much actual say in what’s being adopted (another travesty to work on over time) but also because virtually all tech comes with opportunity costs that are often overlooked by the vendor and absorbed by the customer. To that end, there are some downsides to using ‘Views’ so that you can make a fair decision.

• If not a global strategy, list views get cluttered with views for other teams or individual views deployed to global visibility. This makes adoption even for one team more difficult.
• Views can’t currently be grouped. You have to use numbering and naming techniques to help drive the process instead of creating a ‘Partner Lead Management’ group of views and you’re then limited by character count on the View title.
• Views aren’t reports - you can’t download data sets, and results are often limited to the first 50 records without scrolling. If you’re using ‘Views’ for process management, however, I question how often a data set of actively working data should be as large as 50 records.
• List views do not easily display Global v. Personal views in search, hence the earlier tip on use of initials for any personal views.

The wrap-up

The key to success in partner ops for early to mid-stage companies is often how well we use the tools we have. Yeah… okay… even late-stage land legacy companies. We just don’t often get the budget to solve all of the problems we face and running a successful partnership is often described as ‘running a startup within a startup.’ Experience continually pushes me toward simpler solutions and I find myself saying, “Less is more”... well… more. The key to solving any problem, however, is still clearly understanding the needs of your stakeholder group. ‘Views’ may not get what they need to be delivered or you may find you simply hate the effort to develop and manage them. 

At the end of the day, the software that works for your team is whatever software they are willing to use.

Salesforce Views for Partnerships (Making what you have work for you) by Behind the SaaS

Listen to a discussion of this topic on the podcast, less than 12 minutes this week!