The Core Tenets of Building Unified Customer Experiences

Welcome to another Prime TSR podcast. I have two very special guests. We have Jack Marchetti, a Cloud Solutions Architect, and John Bennett, a Software Architect. And today, we're discussing the customer experience, and I have many questions for both of you. Let me just start this with, what is a great use case for creating a unified customer experience? And I'd like for you to start with what a unified customer experience really means, and maybe if there are a few examples which are out there that others can relate to.

So, to me, I guess a unified customer experience would be where no matter which device or platform I'm on, I'm able to see the app or website in the exact same way. It's easy to use and pick up, and I don't have to think about the user experience; I don't have to think about where anything is, and I can just use it. To me, some good experiences around that are Ticketmaster, where the app, the website, and the iPad app all feel and look exactly the same, down to the coloring and font sizes. Everything is very unified and effortless to follow, and very easy to navigate, and for someone like me, who's visually impaired, that's extremely important because the last thing I want to do is be able to pick... I typically use a computer or desktop because it's typically easier for me to use than a smaller device. But if I'm able to use the desktop and then pick up the mobile app and it's as seamless and easy to navigate, it's very helpful for me. The way that you're able to purchase tickets, get tickets on your phone, transfer tickets via the phone or the app, or the website, it's all a seamless experience that makes me not have to think while using the application, which is something that Apple does incredibly well. They've put in an enormous amount of time and energy and resources into making sure that if I pick up an iPhone, an iPad, or switch using something like, handoff, to my iMac or whatever, it all looks and feels exactly the same, and that comes partly with Apple being completely in charge or in control of all of their hardware, which allows them to make their software as good as it is. And something like Ticketmaster, where the front end can feel the same across all aspects, is likely due to the way they've built their backend, where it's completely decoupled, and therefore, the front end can take on its own changes and modifications without worrying about how it manages the data since the data is uniform. So that's my 2 cents.

Yeah. I'll echo what you're saying. It doesn't just have to be companies or applications that are purely digital; Ticketmaster is a good example. Everybody's doing all of the home improvement projects with the lockdown. One of my favorite stores that I probably spent way too much money on this year is Home Depot, and I think they're a great example of a unified customer experience. To tackle what Jack was saying, the branding and stuff like that. But not even just that, if you've ever been to a Home Depot store, they have a very specific experience that you're going to go through in terms of just how you find things. They all have the aisles and the bays and stuff like that, and you've become... You can go to any Home Depot store, from one to another, and they're all built the same way. The customer service is always going to be at the front; the… is always going to be on one or the other side, and you can almost figure your way out from one store to another, which is pretty impressive. But then it extends to their digital presence. You go to the website, again, whether it's on a computer or your phone, it's kind of the same search, and they're all built the same way at this point. And then they even have a mobile app that goes into it. So that is a unified customer experience, both from the look and feel and where things are and stuff like that, and the process you're going to undergo, whether it's buying something, whether it's returning something, whatever it might be. So, it's the same thing that you're going to experience regardless of the platform that you're on.

Yeah, I like that example, especially the physical to digital; how they organize their aisles is very similar to how they organize the app. and that experience shouldn't be too different, and that leads me to the next question, is this all sounds great. It sounds like every company should do this, and there's no reason not to do it, and I suspect that's the case for many of these companies that are trying to do this. But what are the challenges of companies who are trying to build these digital experiences? Why is it harder than it should be? Or what should they be doing to create a unified experience outside of just creating that process? What are the technology process challenges in place to make something like that happen?

Sure, I'll jump in on this one. I like my opinion on this one. Depending on the size of the company, many companies have been built with disparate systems. So, you've got an inventory ordering system, and they might be tied into an old ERP system or even a new ERP system. Or their customer service system's an entirely different system, whatever it is. They're just different systems, and they're not very well integrated. So that's number one. Interestingly enough, with today's cloud solutions out there, it's becoming easier and easier to do this. So that number one is probably the biggest hurdle. An order in one system versus an order in another system or the inventory and stuff like that, those are big ones. I think the other one, and I've seen this with my own experience, is the different sales channels that ultimately result in different customers when they may not be different customers. And you've seen this before; you can see this in human life or whatever. When one sales rep leaves a company, and a new guy comes in, there's that transition that has to occur, and so, they do that. There's a conscious effort to do that. Still, if Amazon had a brick and mortar store, I have a pretty good relationship with Amazon at this point. They've got my order history, all of that other stuff. I should be able to go into that store and meet a sales rep, and they should be able to pull all that same stuff up. So, I think those are some of the bigger challenges between different business processes, among different departments, and among different systems. Those are some of the bigger ones that I think companies have a challenge getting over.

I like that.

And I would just add to that, John was alluding to this as well, but when you have tightly coupled systems that are older and haven't been updated in a long time, it makes updating the UI or the front end that much more difficult, and unless you're actively doing that in what we call loosely coupling or decoupling, it makes changing the look and feel and things along those lines quite difficult to achieve. And some of this can just come from the fact that some tech companies are filled with engineers. They don't give the proper time, energy, and resources to their actual application’s look, feel, and user experience.

And that's really good, and there's actually one little follow up question that I have to this question regarding the technology. So, if you're a company and want to create these unified digital experiences, you get the front end stuff: the branding, the color, the ease of use, et cetera. But you have disparate data systems. At a high level, what process would you take to get those technical systems in place so that you can create this unified CX? At a high level, how would you look at that process of getting your technical data systems in place to create that?

Yeah, I'll jump on this one. This is something that’s becoming more and more… So, short of five years ago, putting a message bus or eventing type of technology in a company was cost-prohibitive. It was hard. It has become so easy to do now, which is one of the first things you can do. You don't have to worry about tying system A to system B. What you do is you publish it out into a message and then let your other systems consume it as you need, and then, that allows multiple things. Obviously, you have the communication that's occurring within the different systems in your company. Still, you then also have, from an experience standpoint, I've mentioned this several times now if I'm interacting with one system and if it's not a cohesive system, I shouldn't have to worry about whether or not I've created a relationship with one part of the company versus another. It's there. So those are not able to be synced up and stuff like that. So, the short answer is, the very first thing that I would do is find a way to get these things to talk. But the way we can do that is with some of these emerging technologies in the cloud that are now readily available. That puts the organic data from these individual systems onto a messaging system for all of these consumers to access.

Yeah, and some of those technologies, if you're using AWS, you would use there, which is their oldest service. The first service that AWS, Amazon Web Services, ever created was their SQS, Simple Queue Services, which is where you publish something into a queue and then have your other systems react to events within that queue. And one of the benefits of that is, one; you've now decoupled your application, two; you can now auto-scale your other systems based upon the queue size, and since this is all being done by a managed service in AWS, you don't have to worry about it in your on-prem environment. You don't have to worry about the underlying hardware. You don't have to worry about scaling that yourself. You can trigger, let's say, your order system or your inventory system or whatever, to look at the queue length. "It's black Friday, so our order queue length is getting high. So, scale-out to increase capacity." Another thing now is with serverless technologies, such as lambda functions, the worry about auto-scaling is somewhat reduced because they can all run in parallel, and you can have the Lambda functions simply react to, "An order was placed within a queue, I've subscribed to this notification or this event, and now run this thing", and they just run independently of everything else, and so not only have you decoupled your application, but you've also potentially built in what's called fanning out architecture, where you place something in a queue or notification system, and now, these ten other things happen. And those can then also put things into queues, and you just have an entirely decoupled, very elastic, scalable solution that ideally won't crash for you when traffic and orders and things along those lines increase. So, I get really excited when I start talking about cloud stuff, just because it's kind of like playing Lego when I was a kid; you just keep piling on different pieces, and for everything you can think of, there's a service for it, and there's a managed service for, and managed services are something where the cloud manages the underlying hardware and operating systems and things like that for you. You don't have to worry about servers or configurations or anything like that, and I'm not really an infrastructure guy. So anytime I can do anything managed, I'm a big fan of it. I don't know if you are as well, John, but I definitely am.

Yeah, and to… I think probably the big thing with this is that I want to point out, just from a business standpoint, if you've got technology professionals, developers, DBAs, that are working in your company, by having this, what Jack's talking about here is, you know I'm going to have a DBA babysitting a database server. Now, they're out doing stuff to make a better customer experience. You don't have developers that are babysitting hardware or an infrastructure guy worrying about whether or not he's got enough memory to sit there and support black Friday. These people can now focus on better business processes, making a better customer experience. That's really the benefit to these.

Yeah. What it sounds like is times have changed. Before, doing something like this would require a big data effort in place or a long-term two to three-year project before a company could even begin. But now, with cloud technologies, as I said, the serverless and these event buses, et cetera, you're able to decouple a lot of these events and still enable these customer experiences without a three-year project, where that's just the foundation of it.

It's almost too fast in some cases on how quickly it is and how quickly you can get up and running, it's almost too fast, which is a different and better problem to manage, in my opinion.

Right, exactly.

One of the first major projects I worked on, where I actually had to dig into actual servers and things along those lines, the amount of time it took to, "I need these servers, I need three of them", and then to get them racked and all setup and things along those lines, and by the time I have three, well, maybe I need five. So, taking the guesswork out of figuring out your capacity limits and things along those lines is now pretty much trivial because you have almost an unlimited capacity. I can go on AWS right now, create a free account, and immediately spin up twenty servers. No questions asked. They're all up and running within about five minutes, and I can be global within five minutes, and then if I send a support request because they put limits on you initially, you can reduce them. And now I can have 1,000, and I can have them on the East coast, or I can have on the West coast, or I can have them in Canada, or I can have them anywhere in the world. And the fact that you can do that from the command line is... To say it was a paradigm shift in computing when the cloud started to take off is an understatement.

Yeah, and that's a good segue into... What's very clear is that, from a customer experience perspective, the technology is there. There's no longer a limitation; now it's more of, "What technology do we choose, and do we have the team and resources to do that"? And it's not always a technology issue. It's more of which technology we choose. Still, there are many other considerations when making what we're calling an Omnichannel experience that is not just technology. So, help me to understand, outside of the technology, what are some of the considerations when I'm trying to build an experience that works on mobile and desktop and tablet, or maybe even voice or chatbots and things like that? What are some of the considerations to use that'd help create a unified customer experience?

So, going back to my Ticketmaster example of ensuring the look and feel is consistent throughout. Obviously, Apple does this incredibly well. So the branding, the coloring, and layout, where the search button is, if it's in the top right on the website, it should be in the top right on my app. Where's the hamburger menu? It's typically on the left-hand side of mobile apps, and if it's on the right-hand side, that can be off-putting to some people, although I've seen it, and different apps do it differently sometimes. I think Uber, sometimes it's on the left, but sometimes it's on the right. Anyway, so, keeping a uniform design brand look and feel. An example I gave once was a car; if the door colors were different or backward, it would just look very strange, and you wouldn't get in the car. Therefore, if your website looks like it was just thrown together with crayons and no one gave any thought, rhyme, or reason to it, I'm probably not going to enter my credit card and give you money. Another thing is someone who's visually impaired, something I like to think about is accessibility. It's not something that's often thought of. Many companies have recently been sued because they don't adhere to the WCAG, the Web Content Accessibility Guidelines, and if you don't adhere to, I think it's up to their AA level, you can potentially be sued, and plenty of companies have been. Not necessarily for damages, but just because a blind person wanted to use their website, and they couldn't. They sued that company to force them to do it. Another thing to keep in mind as well is if you're a global company and you have users in different parts of the world where they read from right to left as opposed to left to right; your UI and layout should adhere to those people, to those cultures, those languages. John, if you want to jump in.

Yeah. Well, you hit on a couple of them. So, consistent brand colors, most of the time, your marketing people will control that anyway, in terms of if you've got the brand’s positioning and stuff like that, and that's fairly easy, assuming you have styling standards for the site. But I mentioned this before about my Home Depot experience in terms of, it's the same experience, whether I'm buying something online or if I go into the store, it's really the same thing. Some of the things, I guess, that I would recommend getting a little bit into the technical side of it. But for mobile stuff, for example, iOS and Android, and even Windows, have three different layouts out there. And I've seen some companies, including the account we're working on right now, they have three different applications, and it's three very different experiences for their mobile experience. One way to get around that in terms of another factor as a champion or sponsor for customer experience is to make sure that that experience is the same across the platforms, and there's technologies out there or frameworks out there, Xamarin, I can think of. So, that'll build one app; there are maintenance costs. Obviously, they're reduced for it, but now you can have the same experience regardless of the platform that the user is sitting on. The drawback to this is now you're limited to the least common denominator. Still, in my opinion, I don't know if it's that’s limiting. So, there are things like that. Not that they should be worried about the technology upfront, but that should be front of mind, in my opinion, that says, "I want to make sure that we have the same experience, so that way, the people that are responsible for the technical decisions know that non-functional requirement."

And that's a great segue to the next question, which is: How do you prioritize your non-functional requirements when building these experiences? And a follow-up to that question or to clarify that question is: What has to be in place for these things to work properly? And these are the things that are under the hood that a normal person wouldn't have any idea even exists or has to exist. Help me to understand; What are the things that have to be in there? I guess what we're calling the non-functional requirements or the technical foundation that has to be in there when building these experiences, knowing that these experiences will probably change as they evolve. So, what are your recommendations on that part?

So, the first one, right off the get-go, is security. Jack already alluded to this earlier that it cannot be an afterthought. I worked at a company one time, that because the technology was old or whatever because either it wasn't there or they didn't know how to do it, they were storing credit cards in open text in their ERP system. So, it was just wrong. Nobody liked it, and by the time it was there, it was too much to undo at this point. You hear about it every other day; there's some kind of massive data breach or whatever. So, security is first and foremost, especially for your customers; this is the brand extension; there's a big trust there. I would look at some of the requirements in terms of the host nation. Is GDPR, if you're going to be operating in Europe, one of those things that we have to think about? New York, they have the New York Code 500 that has to be applicable. So, I don't know if these are there, but that has to be first and foremost, and you have to have that answer upfront on how you're going to authenticate people, and two, how are you going to protect their private data in there, and then the experience needs to be baked into the customer experience. We've seen this through two-factor authentications and stuff like that. I've never met anybody that says, "Oh, your application's too secure". Now, the experience might be a little annoying. Still, in today's day and age, if I were logging into my bank, I'm a Chase customer, and they didn't have some of the protocols that were in place, I'd be a little nervous about it. So that's number one. I would say number two is; we already alluded to this a little bit, the user’s experience is going to change. At this point, I've seen three different major paradigms over the years I've been working as a developer and stuff like that. We had server type technology. Then client-side technology became popular again; Bootstrap was on the scene for a long time. Angular, when it showed up, really shook things up in terms of single-page applications, and it's continuing to evolve. The mobile obviously, evolution, is ongoing. So, there's a fault in assuming that your UI will, once I invest in it, it's done, it's changed. So, I would make sure that we put some effort into your core business logic, your core experience, separated from the engaging part of your customer experience. We might have a whole new technology and not mobile applications five years from now. But at the end of the day, you're still selling widgets.

Yeah. I like that, which is you're expecting things to change. How you architect it is expecting it to change, knowing that there might be something on top that you don't even know exists yet because it changes so fast.

Definitely, that's a perfect way of putting it. And again, you put that from a non-functional upfront and say that, then the people responsible for designing the systems will at least think about that upfront. Now, the converse of that is don't get stuck into such an analysis; you will never get anything done, right? There are specific trade-offs that have to happen. You're not going to be able to solve and keep yourself extensible for every single problem that's ever going to exist. But there's the right balance that you can find between the two.

And the last thing I want to talk about here, we've spoken about Ticketmaster and Apple and some of these other well-known companies. However, there are many companies that exist, which are still trying to catch up, and you might have some experience with helping these companies catch in creating unified experiences. Do you have any examples or case studies that are worth talking about, whether you're creating the customer experience for them or creating the foundation for them? Perhaps the path you take as far as creating these experiences? Anything worthy of sharing?

One thing I would say is that I was working on the SC Johnson account at my previous job... I was under an ad agency prior to this, and we were tasked with revamping their entire digital ecosystem. They had these very old, very... It looked like the developers had designed their website kind of thing, and we had come in and do these huge facelifts to match the product and their commercials and give, in that regard, a unified experience throughout. And one of the things we had to take them through was getting them to understand how the look and feel would change, giving them examples of how wireframes worked, walking them through wireframes, and explaining that the wireframes aren't actually what the website looks like. It's a wireframe; it's a blueprint, and then introducing things like, I think it's called InDesign, which is an app where you can take the PSDs from Photoshop and then create, through clickable areas, the experience of going through the application, which was really beneficial because you're actually in the browser, you're clicking around. It gave people the idea of, "Okay, this is how it's going to look and feel". I don't know if that exactly answers the question, but it's the only thing I can think of.

It’s kind of a good example of everything we've talked about here. In a previous employer, there was a company that we were engaged with to build them a new customer portal. So, they work in the waste industry. When I say waste, I'm not talking like garbage. I mean that heavy, nasty stuff, heavily regulated type of waste. Police and fire departments with chemical waste or even biological waste that must be disposed of in a very regulated way. So, they had a portal, which was tied in some kind of way into their SAP system. It's a transactional company. There was Spain; I think the UK, and then obviously they had a presence here in the United States, and the approach, the design, and the engagement that we put into them, and I left before I got a chance to build it. Still, the first thing I did was recommend putting in a message bus – putting many of these disparate systems into it. Then, we separated the presentation logic from the core business systems by just using simple, and Jack alluded to some of these serverless technologies upfront. So, that way, they could deal with their high demand volume, which would occur on a seasonal basis because there are many reporting requirements that they have to report to the Federal Government. So, their reporting server would come under massive duress for two weeks every year, but then the rest of the time, it sat idle. So, the customer experience, this is exactly what we were talking about here, in terms of some of these things that we were going to put in, and then to make it that much more to tie this all together, this was going to be the same portal that people would log into whether or not you were a customer in Spain, a customer in the United States, or a customer in the UK. The only difference that we had to deal with there was obviously localization in the currencies. So, it was a classic case study in terms of them revamping their digital world presence.

And yeah, no, that's really good, and I guess one other question I have is... And help me to understand this, so, the type of work you do now, how much of that is this data work? And we can edit this part out because I want to talk more about... Because these examples are good, but… at least we're building these data platforms to help them build these digital experiences, even if we're not building those digital experiences. Do you have anything like that you think we can share?

You say data platforms, as in terms of storing customer data, or...

Yeah, I guess more of decoupling that data and building those message buses initially now, not knowing if they can help build those

Well, this is what's interesting about this, is by having these venting technologies, again, a message bus or a queue or something along those lines, you can actually build custom whatever to keep your data; to have enriched types of experiences on, and you don't even necessarily know. That's where we start hearing about data lakes and data warehouses, or even emerging technologies such as artificial intelligence that's going to go through and do some machine learning on some of this stuff. By having it decoupled, what you're doing is that... Data is king, right? So, every user click that gets logged and says that the user came in here and bounced off the page was there, data's king. It's not the system at this point. It's absolutely the data. By having it go in there, and they're separated from your front end customer experience systems. Now you're enabling a different part of your business to go through and research or come up with new insights on it or even sell it. I had a CIO that I worked for once who worked for Experian. You want to talk about a company with a lot of personal information, all of the people and their credit history and stuff like that, right? They ended up producing a product that allowed them to identify out of state drivers that were going through open road tolling because the states don't talk to each other because they were able to tie all of this information together in terms of who's married to different people and where they've lived in different parts of the country and stuff like that. When someone from Iowa went zipping through an Illinois open road tolling, they could find that Iowa person and issue them the fine. And it ended up being a $1 billion enterprise product for these guys as they did it. So, data's king. To answer your question, by putting in these cloud-based scalable systems and having your applications, your individual systems that don't have to talk to each other directly necessarily, they're talking to a message bus or through venting systems; you can keep the data separate and have it do its own thing; you can have each application good at doing its own thing, and then your job just becomes to orchestrate them in between.

Yeah, no, that's good. Is there anything else you'd like to talk about that we didn't cover or any questions that I didn't ask you that could be worth talking about?

The only thing I would say, when we start talking about customer experience, I'm the guy that uses it. We mentioned several things, especially with some of the emerging technologies coming out, artificial learning, and chatbots; you mentioned chatbots. I just had an infuriating experience with Sonos over the weekend because they like to use a chatbot, and eventually, I got to a person that's out there. So, while some of these things are great, I also think they can hurt you. I'm all about bringing in a chatbot or some machine learning type of technology, especially to answer rudimentary stuff. But it has to be implemented correctly, and if it's not good, then it's not one of those things that I would put in.

And I would just add, just because I had this experience over the weekend as well, a non-functional requirement is something that the guys who created Stack Overflow talked about, that performance is a feature, and the speed at which your page loads and things like that should be forefronted. Users are savvy enough today to know that these things should load quickly. And there are studies out there that prove if your page takes over two seconds to load, people will just leave because they have no patience for that anymore. But even to that, users are savvy now where they understand, I don't want to say they know the cloud, but they understand that if there's an event that was planned and your application goes down, they're going to be very unforgiving. For example, over the weekend, sports betting is now legal in Illinois, and there are multiple apps you can now use; and DraftKings crashed right after the noon games, and as a sport better, what you typically do is you bet on the noon games, and then if you won, you double up on the afternoon games; if you lost, you chase your losses in the afternoon games. And basically, their application stopped working because their multifactor authentication system crashed. So, you couldn't log in because the MFA code was not being sent, and eventually, they just offed MFA four hours later because they had this single point of failure that crashed, so clearly their MFA solution wasn't highly available, and so, users are on Twitter basically saying, "We are leaving your application because your competitor, I was able to bet on them. So, I'm taking all my money and giving it to them". So, it's not just a technological thing; you're going to be completely alienating customers who understand that services like Facebook don't ever crash. And Facebook has 2 billion users. So, if they've solved this problem, it is a solved problem. Performance is a solved problem, and if I can log into Facebook and upload photos, why can't I place a bet on your application when you knew it was week one of the NFL season? And how did you not provision capacity? Now granted, they probably just had one little part of their system not working, the MFA part. Still, it limited everyone from using it, which then, now, Twitter is just filled with everyone complaining, and it's not a good look for them considering it was their first foray into some states with legal betting. So, it has a huge impact if you don't take these things... I don't want to say seriously, but the fact that it was down for four hours to me is insane. It took them four hours to realize that that was the problem and that they needed to turn it off to allow people to at least login. I don't know their system, obviously, so it might be... Again, if you can't turn parts of your application off when, say, one is failing, and then the whole thing doesn't work, it cascades. So that's something I wanted to add.

That's very good. You both made a good business case for how the underlying technology foundation really impacts every aspect of the customer experience and how ingrained it is into everything a business operates. So yeah, thank you so much for your time. I've learned quite a bit, and I really appreciate it, and I look forward to seeing it published.