Episode #67: DCFTS 9, How to Build a Unified System of Engagement

Now that you understand the Digital Customer-First Transformation System, it’s time to put it all together. The Reference Architecture Model helps you look at your entire martech stack, enabling you to build an integrated system that will create that all-important, 360-degree customer view. And, with that, we’ll call it a wrap on our nine-part DCFTS series.

Click here to view the Digital Customer-First Transformation System Reference Architecture Model (pdf, 317KB)

See all CXM Experience podcasts
The CXM Experience on Apple Podcasts

PODCAST TRANSCRIPT

We’re back. It’s the CXM Experience. I’m Grad Conn, CXO, chief experience officer at Sprinklr. And this is our final episode — not the final time we talked about it — but our final episode on the DCFTS, the Digital Customer-First Transformation system. And today, what we’re gonna do is we’re going to talk a little bit about how you use a reference architecture to fit new technology into your existing martech stack. It’s going to be a pretty interesting discussion. But before we get into it, I’m going to spend just a second on what DCFTS is already. You’ve been listening, you probably know. I’ll do this reasonably economically. But I’m gonna go through these five steps on your journey to becoming digital customer first.

This is something that we do with customers all the time. We can do it as a series of workshops, half-day, one-day, two-day, as many days as you want. Senior leaders from inside Sprinklr, also our SI partners all can execute these, and they’re a fantastic way to align your stakeholders, get your thinking straight,… making sure everyone is on the same page. And you can also download these and get copies of these from our blog, and from my blog, etc.

So, let me talk a little bit about the five steps. So step one is to see what’s possible. That’s a value model, hey, what can we really get out of this? What kind of value do I want to deliver to the organization? Step two is identify what you need. So that leads to a capabilities model. What are the capabilities we need to build as an organization. That was a two episode, or maybe even three-episode, discussion as I went through that in detail. It’s a very rich model. Step three is to define where you are, and what’s next. So that leads to the maturity model. The maturity model is one of my favorite steps because gets everyone to agree, this is where we are today as an organization, and more importantly, where we want to be. And then you’ve got to validate the investment. What is the ROI that we’re expecting from this? How do we want to make this thing payback? It what’s our payback timeframe. And what are we gonna look at there? And how do we think about ROI? Very important, because a lot of digital customer-first transformations tend to take on almost a religious aspect of “what’s the right thing to do”? And it is the right thing to do, don’t get me wrong. But the result is, people end up driving something that people aren’t clear what the value is, don’t know why we’re doing it. And it can get kind of confused and maybe frustrated.

And then step five actually has got three parts. It’s deciding what to do. So, once you’re at this stage, you can build functional use cases, and they’re very particular to the organization. You can build an operations model. And we went through that in detail in the last show. And I think you can see the operations model, a great way to get everyone aligned on all the things you need to do. And then today, we are going to end with the reference architecture model.

This is a pretty visual slide. So, I’ll describe that and talk about that a little bit. But also, I’ll talk a little bit about martech stacks and some of my thoughts on that, some experiences that I’ve had with martech stacks, and a little bit of perspective on what I see people who are doing the best job on it doing. So that is DCFTS. So here we go.

Let’s talk about the reference architecture model. I do have a bias here. So, I’ll just expose that bias, because I think… I probably have multiple biases, but this is a particular bias around architecture, which is we work with very large organizations of Sprinklr. So, when we go into an organization, they typically have a lot of systems already. Multiple SAS systems. The average marketing department overall has more than 70 different martech systems. Only HR has almost as many. But many have many more than that. I was actually at a large global manufacturer and technology company, and I used that 70 number as an average. And the COO was in the engagement with me, he started laughing. I said, what’s so funny. And he goes 70, he says, we aspire to get down to 70. We’re in the 100s. And that’s pretty typical. So, I do say that I have a bias in a nuanced perspective that we’re working with large organizations that have a lot of systems.

One of the reasons for this is that a lot of empowerment has gone to different groups, like marketing teams, who will buy these systems on their own without involving IT. I think that’s a mistake. I actually loved working with… had a great IT partner, and loved working with IT. And it was a really important part of how we were successful at Microsoft doing this. But that doesn’t happen everywhere.

The second thing is that I actually observed that a lot of vendors take advantage of the complexity of large organizations. I’ve got a point of view on this as well. I think this is the wrong thing to do. But classically you’ll go into a large organization and ask them how many, say CRM systems they have. And they’ll all be from one vendor. But they’ll have like 16, 17, 20, 25 different versions that cannot be combined, in either different countries, different departments, or different businesses. And so, the challenge is you end up with data about the customer in a bunch of different systems, and that can never be aggregated.

So, we do have a philosophy at Sprinklr, which we hold to very strongly, which is we only do single instance deployments. And this has been a Sprinklr principle from day one. And it has proven to be a fantastic operating model. We work with some companies in 140 different countries. And even if a country asked us to have their own version of Sprinklr, we wouldn’t do that. We always make sure that everyone’s on that company’s instance of Sprinklr. So that global collaboration can occur, business unit to business unit collaboration can occur, and individuals can work with each other no matter where they are. And that has proven to be prescient, people weren’t as worried about it, say a decade ago when that principle was created. But today, it’s become a real problem where people are trying to figure out how to get a 360 degree customer view, and they can’t do it.

I also have a point of view on martech stacks in general. I’ll expose this bias as well. If you go to Chiefmartech.com, which is… I love what Scott’s been doing there. I think that’s a great site. If you don’t read chiefmartech.com at least once a week, you should. It’s really great. He does it for free, and lots of interesting perspective in there. But he runs something called the Stackie Awards. And the Stackie Awards are: show us your martech stack. And we’ll judge who the best stack is. And there is some pride, I think in people having complex stacks. The problem is that in order to get all these different SaaS applications to work together, they’ve all got to connect via an API. And the challenge is that any good SaaS application is constantly evolving. We’ll do 700 to 800 features a quarter, that’s at Sprinklr. And everyone’s doing that. And so, you’ve got all these different SaaS applications all evolving very quickly. And those API’s tend to be quite fragile. So, systems have a hard time working and connecting to each other.

I had a team when I was at Microsoft, whose goal was just to find the broken leads that fell to the floor between the API, the broken API connections between our different SaaS applications, for perspective. But that’s the reality. And it’s changing. What we do see, increasingly, is that people will use Sprinklr to eliminate a lot of individual points solutions. Sprinklr, can replace up to 17 different point solutions with its functionality, or even more if you got duplicates. That’s pretty cool. I’m not gonna pitch that today, that’s where we’re going. But when I was building my martech stack at Microsoft, my perspective was, I don’t want to have a bunch of point solutions. What I really want is I want a bunch of suites. And not even a bunch… a few suites, right?

And that perspective came from healthcare. Healthcare is classically a little bit ahead of the curve on IT. Which maybe not everyone thinks about, especially when you’re sitting in doctor’s offices filling out forms over and over again on paper. But actually, IT is very sophisticated… IT in healthcare is very sophisticated, because they’re always on the bleeding edge of trying to figure out how to make sure that patient outcomes are optimized. And so hospitals got to a point about 10 years ago, where they had so many point solutions it was hard for them to operate the hospital. Even just provisioning a new user was extremely complicated. The Palo Alto Medical Center, for example, in Palo Alto, California, had 400 beds in their hospital, kind of mid-size hospital. And they had 400 different SaaS solutions running. Some were desktops as well, I think. And so that poor CIO is on the edge all the time. Just to provision a new nurse was extremely complicated.

And so a system came out in the 80s. But it took them a long time to build it out, called Epic. And Epic Health Care, based in Madison, Wisconsin, is one of the great companies in the world, fantastic CEO, very unique culture. And their perspective always was that it would be better to have all the patient information in one place, and have a bunch of different systems connecting to it. Sounds familiar, right? In many ways, Sprinklr’s simply the exact same strategy as Epic, but in marketing as opposed to healthcare. And it took Epic a long time to build out all the different functions that were necessary to fully operate a hospital. But by around 2006 to 2010, they got to a point where you could run your hospital on Epic. Today, Epic is 60% of the hospital business. They’re the dominant player. They’ve squashed everyone. Cerner is in huge trouble. And what has been proven is that the model of being able to see a patient’s full view, and for the patient to see their full view too, because there’s an Epic portal, is so incredibly valuable because you can more easily manage outcomes.

I think that same revolution is coming to marketing. At Sprinklr, what we see every day is more and more companies using us to be able to get a 360 degree view of their customer in a CXM profile, using our CXM database. And they’re going to be seeing the advantages of providing better customer experiences through loyalty and revenue. And that’s where we’re headed.

So, in the DCFTS model, what we do here, and this is incredibly useful, because what we do is we take… it’s a big diagram with lots of lines in it. So, neither here nor there. The key thing is to think about all the different systems that you need to connect. And this is where I think sometimes the complexity of the existing martech stack can sometimes be missed, or glossed over, or like, let’s just not think about that because that’s sort of scary. But this basically says, Hey, you’ve got email systems, you’ve got databases, you’ve got CRM systems, you’ve got all sorts of care management, and you’ve got third party management tools. And you’ve got all the different planning tools, and marketing management tools, and content production tools, and a lot of stuff. And so, what this reference architecture does is it shows all those things in one place. And then you can start to think about what is your architecture and how do all your things fit together?

It is, I think, one of the most important things you can do in this process because, classically, people will forget about a system, or they won’t think about a system, or they don’t create clarity around what is the dominant system. Or what is going to be my system of record. Or where do I go and get that 360 degree profile. And you know, people have been creating data lakes for a number of years. A quick perspective on that, a little bias there, I’ve seen data lake projects fail over and over again. People spend a lot of money on them. But because they aren’t really actionable, they’re just storage, they don’t tend to really go anywhere, and people will typically rebuild the data lake. You may be on a version two or three of your data lake project. If that’s the case, then you probably should stop it and try to get something that’s more actionable that you can actually do something with.

So, then all the front office functions have to be thought of in this reference architecture. So marketing, customer care, advertising, commerce, research and analytics, product development, public relations, sales, human resources, legal, and finances. Those are all really important to look at and think about how all of those connect to all the different systems that are touching the customer. And then we’ve grouped the systems into conversations, community, collaboration, campaigns, and content. So, there are different systems doing all those different things right now.

And then sit down and have some fun. We actually do have little pieces, like little wooden pieces that you can actually put on this diagram. Our CEO does this all the time. And it’s super powerful. Because you can see all the different systems you have and create this inventory of: oh my gosh, all that stuff is running right now. And I need to think about how I’m going to do, or manage, or decommission, or recommission, or whatever, all those different systems. And it’s a great exercise to make sure you don’t forget anything and don’t leave anyone out.

So that is DCFTS. If you would like us to do this with you, please reach out. I’m Grad.Conn@Sprinklr.com, and I’d be delighted to do something. You can also hit me on Twitter, DM me @GradConn. Hit me on messenger, I’m Grad Conn on Facebook. If you want to send a friend request, I’ll accept it. And, of course, LinkedIn. I’m Grad Conn on LinkedIn as well. In fact, I’m Grad Conn everywhere. Except for GradConn.com. I was very complacent because I’m the only Grad Conn in the world, and I did not register GradConn.com. So, if you go there, you’ll see it’s a Chinese connector company. That’s not my side hustle. That’s actually a different company who keeps trying to steal my handles. But, you know, they’re not going to get them. And I keep hoping they go out of business, but they seem to be doing great. So, it’s a bit of a stalemate right now. We’ll see what happens. But anywhere but GradConn.com you can reach me. Get a hold of me and set something up. And we’ll have a conversation, we can go through it in detail, and we can set up a workshop, and for the CXM Experience, I am Grad Conn, and I’ll see you next time.