Introduction
It's not a secret to anyone that, for obvious and multiple reasons, our world has changed in the past years in ways we couldn't have imagined, and that change spills over every aspect of our lives, and yes, it also affects your MarTech architecture.
As a Marketing Technology architect, I spend much time figuring out the Next Best Architecture to help organizations adjust their marketing technology strategy to accommodate change, but this time feels different.
Our industry is a world built on top of change, so that's not surprising to anyone; in fact, I wrote a paper a couple of years ago to describe a framework to architect for change starting with an understanding of the customer, but there is more in that approach. Let's explore the MarTech of Tomorrow.
We are at the very beginning of an exponential change coming to our industry, and no matter your MarTech maturity level, what we will face next is not something we can manage only with tools or frameworks built one or two decades ago and probably not even five years ago for that matter.
With access to vast amounts of content, assets, customer data, analytics and all the specialized technology platforms that underpin them, what needs to be added in the current state of MarTech?
Most mature marketing technology architectures have tremendous capabilities. The problem is not around the capabilities but around the goal of your architecture; what's your MarTech architecture for?
While architecting for CX or being CX-Led is excellent, as I said at the start, we can't stop there in an exponentially changing environment.
All this led me to the following question: From a marketing technology standpoint, what's the thing that will be consistent in a world of ever-growing interactions between brands and customers? And, what would matter the most for both brands and customers?
This might seem too complex of a question, but the simple answer is Engagement. The meaningful interactions between brands and customers are what will exist tomorrow, exist today and exist in the past, regardless of the number of channels our touchpoints. In other words, the MarTech architecture of tomorrow is an architecture for Engagement, as it should have always been.
But before I continue, let's review the definition of Customer Engagement.
"Customer Engagement is the ongoing interactions between company and customer, offered by the company, chosen by the customer."
- Paul Greenberg, circa 2014
As you can see, the main characteristic of customer engagement is that it's driven by human behaviour. And there's nothing more complicated than trying to cater to many humans' needs and wants individually.
Now, the genuine question is: How do we architect for Engagement?
Architecting For Engagement
The Engagement layer
One of the best ways to describe systems is to use layers. Using layers allows us to explain different levels of complexity and various interactions that occur inside and between the systems.
Most architectures, or marketing architectures to be more specific, have at least seven high-level layers: Customer, Channels, Experiences, Processes, People, Technology and Data.
I have used these over the years to describe and implement many enterprise architectures for marketing. However, one layer exists between your Channels and the Experiences that have been generally overlooked or even missed for many years—The Engagement Layer.
I call this the "invisible" layer, mainly because there aren't specific or tangible components that you could put in it, or should I say, the elements that compose the Engagement layer are highly dynamic and almost impossible to predict in a static definition of the system.
The reality is that the Engagement layer is what gives any MarTech architecture a reason to exist because, ultimately, meaningful interactions are what every brand should seek with their customers.
In a review of what I earlier described as a CX-Led Architecture, I'm comfortable with the fact that we could and should add an Engagement layer to the stack and redefine the approach to modern MarTech as an Engagement-Led Architecture, so we now have eight high-level layers. Customers, Channels, Engagement, Experiences, Processes, People, Technology and Data
Key concepts
The elements belonging to the Engagement layer are hard to describe, given that they're not static. However, we can achieve this goal by using an agnostic approach and defining components that allow us to model Engagement.
First, we can understand that Engagement in this context is a series of interrelated interactions that can happen at any time and touchpoint.
Our second definition is that these interactions are always under the customer's control and can not be dictated by the brand.
And finally, every interaction happens under specific conditions that can change over time. In simpler words, every interaction has a particular context.
In summary, our Engagement layer comprises Interactions and the ever-changing context where they happen.
Beyond the concepts
Now, using the Interactions as a base for the Engagement layer, we need to understand that the value of defining this layer in our architecture is to be able to drive those interactions meaningfully for the customer's benefit.
For that, we need to be able to:
- Coordinate interactions.
- Make sure the proper context informs every interaction.
- Ensure that any action required after every interaction is shareable with the rest of the ecosystem.
Implement the above pattern so the system can perform that task in real time. Real-time should be the default way to execute the above, leaving asynchronous or delayed coordination as optional.
What about scale?
When architecting for enterprise marketing, the first consideration is scale, which comes in complexity or volume, but we should be ready for both. The temptation could be in trying to model every possible interaction or Engagement within this layer, which would be virtually impossible, given that, as I mentioned earlier, Engagement can't be dictated.
Describing Engagement using Interactions is a highly scalable way to architect, given that the complexity of what's possible is broken down into what's defined and available. The volume is reduced to the individual.
We can cater for large data volumes or complex calculations. Still, these responsibilities are delegated to the Technology or Data layers in good architecture.
This leaves us with a clean and agnostic definition of the Interactions that's easy to scale and manage. More importantly, it enables your MarTech architecture to perform 1:1 conversations with your customers.
Systems in play
In short, every system is part of the engagement layer. However, there are key capabilities that we need to provide so this can happen in such a way that is maintainable and can evolve. In any case, I explain the high-level capabilities required rather than dictating which systems should take care of this function.
- Event capture: The system should be able to capture events and data associated with them consistently and in real-time. Events should be mapped to Interactions and persisted for further analysis.
- Context definition and enrichment: Every interaction should be able to read from a context or customer context where all the relevant information is held with the latest version or value. The context should be updated after every interaction if required. This context should be persisted.
- Rules management: The ability to coordinate interactions requires a place where the rules that make the coordination possible are managed. These rules or conditions inform decisions that can be used to trigger actions.
- Recommendations and Content: The system needs the capability to associate content with a business hierarchy that can be used in different Interaction coordinations.
- Arbitration: The system needs to decide amongst rules and actions that are agnostic to the Interactions and can leverage existing data, context and rules.
- Orchestration: To chain interactions, the system should be able to trigger actions that start other interactions or communicate with other systems.
- Analytics: The system needs the ability to interrogate and analyze interactions to provide insights into the different sequences of interactions that customers as a whole take and, at the same time, enrich customer context for future interactions.
Is this possible with the current tech stack?
As you can see, these high-level capabilities definitions are easy to describe but are non-trivial challenges when implementing in any traditional MarTech stack.
You could think of three to five different systems, and some additional development might be required within your current stack to provide such capabilities.
The reality is that this seems a bit of a stretch for most systems because, as I mentioned at the start of the document, this layer has been mostly "invisible", and trying to retrofit the capabilities of other platforms doesn't seem to be an easy task as much as we as architects aim for reusability of components.
However, acknowledge this layer in your architecture and try to align some of your platforms with these capabilities. You can close the gap and move towards an Engagement-led architecture.
What about the MarTech stack of tomorrow?
The answer is to include the Engagement layer in your architecture and add a platform that can take care of the engagement capabilities in such a way that it can elevate the value of your current architecture and even help optimize it.
In summary, the critical considerations for such a platform are:
- Allows you to define and map Interactions that are channel agnostic
- Allows to maintain a customer context to inform every interaction
- Can enrich customer context on-demand and in real-time
- Can analyze interactions at scale
- Can execute actions that will enable interactions coordinations (real-time and asynchronous)
- Is securely open to other systems (APIs)
Lastly, the one principle to always keep in mind: Your best architecture of today is not your best architecture of tomorrow, architect for change.
.png)
.png)
