Ironic email accounts and their subject lines.pic.twitter.com/DGasBlp8jd
Chief Marketing Technologist
The phrase “system of record” has been bandied about in martech for years. In the absence of any other context, it’s usually assumed to mean the software that holds the authoritative (or “golden”) customer record. Most often in practice, this is a CRM.
This is why illustrations of martech stacks often have a CRM product such as Salesforce, HubSpot, or Microsoft Dynamics visually placed at their center. (Speaking of which, the 2021 MarTech Stackies are now open for entries — and we’re donating up to $10,000 to COOP Careers on behalf of those who contribute.)
But this assumption often belies that fact that there are many different kinds of data in the modern marketing organization — not to mention the broader domain of rev ops. Each may have its own system of record. And, as with core customer data in CRM, it’s important to identify which system is the “source of truth” for what it provides, so as to minimize data fragmentation, contention, and decay.
It’s okay to have multiple systems of record in your martech stack. But it’s not okay to have multiple systems of record vying for ownership of the same data.
To help think through different kinds of systems of record in a stack, I came up with the 2×2 at the top of this post. It organizes systems along two axes:
Customer Data — customers and engagements/interactions with them
Operations Data — production and operation of the business and its digital experiences
Objects & Assets — relatively “permanent” data and digital entities
Flows & Events — more fluid and transitory data (often much larger in volume)
A CRM is the quintessential Customer Data system of record that stores relatively permanent objects about customers: contacts, companies, deals, purchases, etc. A DAM, which stores the official versions of content assets such as logos, images, videos, etc., is an example of an Operations Data system of record.
But in digital business, we increasingly deal with more “streaming” data too, what I bucket as Flows & Events. For instance, if you’re tracking website and app interactions customers have with you, you may be using a CDP as a system of record to aggregate that data. From more of the operations side, such data might be feeding into a product analytics platform, such as Amplitude or Pendo.
I know, I know, it’s acronym salad city in that 2×2, so here’s the cheat sheet:
CRM = customer relationship management
PRM = partner relationship management
MAP = marketing automation platform
CDP = customer data platform
MRM = marketing resource management
MDM = master data management
DAM = digital asset management
CMS = content management system
Now, can you have one platform that serves as the system of record across these quadrants? Absolutely. For example, the suite of products that are part of HubSpot’s CRM platform could be mapped into all four quadrants:
Disclaimer: I work at HubSpot. However, this is not an official HubSpot product diagram — just my personal take on how I’d map our products into this systems of record 2×2.
There are advantages to having a common platform foundation across all of these domains. However, when you do see different systems of record within martech stacks, the boundary lines tend to be at the different quadrants. Which makes sense.
We could also debate the placement of different products within quadrants. Should a CDP be in the more permanent Objects & Assets quadrant or Flows & Events? Or span both?
Well, it depends on the CDP and how you’re using it.
I was thinking of how CDPs such as Segment and mParticle are well-suited for managing streaming event/flow data around customer interactions — often integrating with and complementing a CRM — which is why I put them in the upper left corner. But if you have a CDP that is almost more of a B2C CRM, as some are, then it’s probably more in the lower left corner or spanning the left side.
I leave it as an exercise for the reader to place individual logos where you wish.
One more related thought. As it’s been said that salestech is the new martech, it’s interesting to see how different categories of sales technologies fit into this 2×2 map as well:
The Great App Explosion can’t be stopped. But it can be harnessed.
A couple of years ago, I proposed a model of 4 layers of app integrations with SaaS platforms. Advocating for better integration, for marketing apps in particular, I pointed out that not all integrations are equal. They vary significantly in how deeply they’re integrated.
The 4 layers of integration that I described:
Data — sharing data between apps, which is the most common kind of integration
Workflow — automating activities across apps, most commonly triggers and actions
UI/UX — embedding elements of one app in the user interface of another
Governance — establishing and enforcing rules and standards in an app ecosystem
I still believe this is a useful model for individual SaaS platforms and their app ecosystems to strive for deeper integrations.
But as tech stacks continue to grow — not just in marketing, but in all departments and across them — I’ve been fascinated by the emergence of more and more products that span multiple, heterogeneous apps and create a kind of virtual platform layer across them.
The lightbulb turned on over my head when I attempted to map those app-spanning products into the 4 layers of my platform integration model, resulting in the illustration at the top of this post.
Virtual Data Layer
Companies with dozens or hundreds of apps are now aggregating data from all of them into data warehouse/data lake products such as Snowflake. They are using CDPs like Segment to share customer behaviors across different apps. And Excel and Google Sheets are universally used to work with small data sets, pulling and pushing data from many different apps too.
Virtual Workflow Layer
iPaaS and workflow automation tools, such as Workato and Zapier, have been widely adopted to automatically sequence activities across apps. A “trigger” occurs in one app — such as a new customer signing up on your website — and then your iPaaS/workflow automation tool can execute a series of “actions” across other tools in your stack. Any webhook can be a trigger; any API can be an action.
Most of these workflow automation tools are packaged as no-code solutions, which enable anyone in marketing ops — or even individual marketers — to create and modify automations in their work.
Virtual UI/UX Layer
Slack and Microsoft Teams have become ubiquitous. Whatever other apps you have open in your day-to-day work, it’s very likely that you have one of those open too. Both products are open platforms that let other apps embed features in their conversational UIs. Integrations range from simple notifications to pop-up modal dialogs, as well as adding new commands that can take actions in those other connected apps.
The result: disparate kinds of apps all share a common UI/UX within Slack and Teams.
Virtual Governance Layer
Finally, at a layer above, there is now a rich collection of tools that help govern all these different SaaS apps. Tools like Okta provide identity management and access control. SaaS management platforms (SMP) such as Blissfully and Torii keep track of all your different software subscriptions, manage onboarding and offboarding for users across a toolset of multiple apps, optimize SaaS spending and usage, and more.
Tools such as Dynatrace monitor the performance of your apps and cloud infrastructure. And tools such as OneTrust manage privacy, security, and data governance across apps.
Essentially, the tools at these different layers tame the chaos of large, diverse tech stacks.
Instead of trying to dramatically reduce the size of your stack, these tools make sure that your data can be aggregated, your cross-app processes can be automated, the number of UIs that an individual user has to jump between on a daily basis can be consolidated, and that good governance can be enforced — without having to converge on a single vendor platform.
There’s complexity — many different apps, delivering their own special capabilities to the different users who need them. But it’s manageable complexity, not chaos.
I expanded the model to include a bunch of other apps at each of these layers, as I think there are now many products enabling this stack-as-a-virtual-platform environment. But they tend to all share three characteristics:
They are the canonical service for a particular capability in your stack, e.g., your data warehouse (Snowflake), your workflow automation platform (Workato), your messaging/collaboration app (Slack), your data governance tool (OneTrust), etc.
They have open APIs and integrate with almost everything else in your stack.
They’re agnostic about the other apps and platforms in your stack. For instance, they don’t care if you prefer HubSpot or Salesforce for your CRM.
There’s still enormous value to domain-specific platforms that incorporate these 4 layers of integration across their own ecosystem. A lot of this comes down to the platform where given roles in an organization spend most of their day. For marketing and sales, that is likely a CRM platform such as HubSpot or Salesforce. For IT service managers, it might be a platform such as ServiceNow or Zendesk.
But those platforms are increasingly citizens in a larger and more heterogeneous “virtual” platform of an organization’s entire tech stack.