Whose Lead Is This?
A sales team is a sometimes-splendid, sometimes-frightening example of “coopetition.” As in The Hunger Games, there are shifting alliances and rivalries. It usually doesn’t go to extremes… usually. But, be they within the same organization or several different ones, sales people will team up for one pitch and be adversaries in another.
Such groups need to share information in one situation, and be guarded and territorial about information in another. Since several deals can be in play at the same time, some cooperative and other competitive, possibly involving the same groups of people, the question of “who can access what, when?” quickly becomes rather complicated.
In the rapid-pace, cloud-based, SaaS-driven sharing economy, access control for Customer Relationship Management (CRM) applications poses particular challenges. This post describes access-control use cases for CRMs that would benefit from being rethought. For simplicity’s sake, I will assume a Web-based application (mobile-specific issues are left out) provided via SaaS (on-premise app issues are left out).
CRM is like any other SaaS App… not!
Before we get mesmerized by the more complex use cases, a reminder: in many respects a CRM is a multi-user information-management application like any other. It manages structured information (contacts, deals) and unstructured or less-structured information (attached files, communications, workflows) among a group of users with differentiated access to features and data.
Even if we look only at the aspects of CRMs that are like any other shared application, there’s a significant “access-control gap” between CRMs and other apps. There are cultural and historical reasons for this: sales, as a business activity, has remained largely zero-sum in its mentality and methodology, and sales teams have been slower to adopt sharing-economy / “make the pie bigger” approaches to their job than, say, the IT or Marketing departments. The implementation of access control in CRMs reflect this: information and feature access is largely partitioned along org-chart lines, and there are few (if any) mechanisms to manage access outside of the organization.
Compare this to Google G Suite, a SaaS collection of office-productivity applications. Access Control in G Suite has its problems, but there’s a well-articulated set of features that satisfy many typical use cases. Let’s just look at GDrive, essentially G Suite’s file system. It includes the following features:
- Policy-based rules like “Anyone in organization can comment” at the file and folder level
- The ability to override the default / containing-folder for a specific file
- An option for a recipient of a file link to request access if it has not (yet) been granted
- The ability to share a file or folder with people outside the organization
There are a few things GDrive doesn’t handle well, such as auditing. There are third-party add-on solutions like WhoCanAccess that facilitate a manual review of granted permissions, but the best of these are band-aids, and none offer “permissions monitoring” as an ongoing background task or any sort of automation.
Most popular CRM apps are in the gutter when it comes to this stuff:
- they lack the basic policy-plus-exceptions permissions management of “vanilla” SaaS apps like GDrive, and
- they also suffer from a lack of auditing or “Permissions Lifecycle Management” features that are absent from nearly all SaaS apps.
Use Cases unique to CRM
CRM thus starts at a disadvantage when it comes to access control; but things get worse when we look at CRM-specific access control use cases. Here are some things that happen in the real world of sales:
- Salesperson A “lends” a bunch of leads to Salesperson B (same company)
- Salesperson A from Company A (as Lead) and Salesperson C from Company C team up on a deal, but fail to close a sale
- A fast-growing company may start with a small-business oriented CRM like Hubspot, then add or migrate to a more “muscular” CRM like SalesForce.
Here is what must happen in a typical CRM to address those situations:
- Salesperson A must permanently reassign leads to Salesperson B, somehow save that list, and permanently reassign them back when the “loan” ends — minus any leads Salesperson B managed to convert
- Salesperson A had to export Company A’s leads to “share” them with Salesperson C at Company C, who then imported them into their own CRM — when the short-term alliance ends, there is no way to un-share those records with Company C
- The folks in IT can easily export/import lists of: users, leads, companies, contact history etc. But in nearly all cases they will need to manually recreate access-control policies when adding or migrating to a new system. This is labor-intensive, tedious and error-prone.
Of course, Hubrix is working hard to solve these problems. But this post is not to brag about our access-control technology. It is just to make this point:
Access Control is not just a security concern. It is also a usability concern, especially for CRM applications.
Why does this matter ?
Owing to their history as the very first app category to go SaaS, and their particular evolution as the enabling tool for the most territorial business activity there is, CRMs are a step behind in functionality vs. apps in other SaaS categories. It is a very unusual thing in 21st-century business for technology to be a drag on methodological innovation; usually, nearly always, it’s been the other way around.
If CRM developers focus on updating access-control features to facilitate “coopetition,” sharing-economy scenarios, and the 21st-century reality of more fluid employer-employee, vendor-customer relationships, they may well break out of their conceptual pigeonhole and discover a whole new market for relationship-management software.
At the very least, it will delight existing users of those CRMs. Of all software categories, shouldn’t CRMs be especially focused on Customer Delight?
Photo Credit: Alec Baldwin in the “Angry Sales Speech” scene from Glengarry Glenn Ross.