 OK, the title in this case is quite important. We will see a couple of details in a few slides. But the first thing that we will do, apart from this brief introduction, we work just from ING. And as most of you know, ING is an international company. We are presenting more or less all the continents in either the retail or commercial areas and in some countries in both areas. And we are in the middle of an important transformation. We are building an international banking platform for several countries. And we are also building or establishing an international data hub here in Madrid for all the world. So we are hiring for both of these projects. And if you're interested, please let us know and come to the booth, OK? So apart from that, in order to succeed in our mission, we have a lot of technologies. But this talk is not about technologies. It's not even a talk for discussing our architecture. It's for sharing with you our vision to inspire you. There were a lot of talks with the technical aspect during these two days. So let's move on, because we have a lot of things to share with you. So we will start with the title. So we said Omni Channel, Customer-Centric Strategies. What do we mean by this? Because Omni Channel is not about using any kind of weird or strange channel to reach the customer at any cost. Yeah, this is not a set of weird creativities and how to deal with them with a strange way of performing. This is not about putting the customer in the middle. It's not that. And strategies is not about selling. It's not just selling. We want to achieve more broader objectives. Yeah. So what we want to achieve is to have not only a good commercial proposition, but also what we call a relevant dialogue with the customer, taking into account the customer preferences with every communication at the right moment, not only for the bank, but also for the customer, and of course, with a totally Omni Channel approach. Yeah, they all should be at the right time under the customer preferences, as Luis said before. But we are part of a business strategy. We need to sell. We need to perform cross-sell and upsell. We need to advise. And we need to be smart. We need to empower the customer to make better decisions. And also we need to help if something pops up in that journey. So we will start with a brief terminology, because maybe not everyone here is, let's say, familiar with this kind of marketing or communication concepts. The first one is quite easy or quite known. It's about what is an outbound channel. An outbound channel is any time that the organization needs to communicate something with the customer. And the organization is choosing not only, let's say, the technical channel, but also the contents, the moment, the creativities. Everything is chosen by the company, OK? Yeah. In the other hand, the inbound channels are more spaces. And those are the places where you need to react to a customer interaction that does not depend on you. The customer, in this case, has the initiative and start the communication for whatever reason. So you need to be able to react. So first question, just to know if you are still awake after lunch. In the case of assisted channels, it's a quite complicated example. What do you think? Is this an outbound or an inbound channel? Please raise your hand if you think that it is an outbound channel. OK? Then raise your hand if you think it's an inbound channel. Yeah, the majority thinks it's an inbound channel. OK, the reality is not. The reality, the channel has both nature, because the customer could even pick up the phone dial-in. And you need to be prepared. You need to assist that customer at that moment in time. And you need to give that customer the precisely the information, the right information he's waiting for. So you need to be prepared. And in the other hand, also you can plan. You can schedule some calls in order to contact the customer for whatever reason. Imagine you need something and the customer prefers to be called instead of being mailed. OK, next concept. When we call out, when we say communication, we mean a very, very specific thing, OK? Communication as part of a very specific definition. Of course, it has a name, it has a category, some validity dates, no? And start date and end date. But then you put this communication into a category. For example, we normally use this kind of four categories. And you link this communication always to a specific offer or business proposition and to a specific, in some cases, a promotion and with a very, very specific business priority. You link, this is what we call, let's say, metadata in the following slides. And you link this metadata, this communication definition with a specific template with the creativity according to the channel and so on. And then you use this communication. We will see what we call data repositories in terms of communication. Once we have the most basic definitions to follow the deck, we need to talk about the main data repositories. The first one following the previous order is the album contact history. The album contact history is the combination of what is a communication. As you can see, the metadata plus the template, plus the data that you use for personalization in that communication in that moment in time. And also, you need to address that communication through a specific channel. So you need to record all that information in a row. And the most important thing here is not what you can see in this slide. Maybe you need to have one single definition of what is an album channel, a single definition on what do you want to store and how. In a similar way, you will have a very, very specific repository for all the, in this case, the assisted channels contacts. Follow the same pattern. You are not only storing, let's say, the most low-level technical details about the communication. You will also store the details that the agent has recorded related to the communication. If the customer rejected a specific offer, what was the reaction? What was the preference of the customer? Following the previous definition I said before, the inbound channels, we also need to track the web partners and the application banners we saw during the navigation, during the customer interaction. Because that information is very relevant for us to know and for the agent to know. And what to tell, what would be the next offer, the next business proposition to the customer is somehow connected with that navigation and that pattern. The geolocalization is available, is there. And also, as Luis commented before in the assisted channels, the customer cannot see the contents by his own, but the customer receives an information. And that information, we need to track the agent somehow, tell the customer whatever, according to the information that was shown in that channel. And more into the detail, what we call the clear stream, we also need to link the behavior or the actions of the customer in the application, also to correlate the clicks that the customer is doing in the private part of the application with the clicks or the actions that the customer is doing in the public website. So this is not only about storing all the contacts for traceability purposes or for auditing purposes, this is also about understanding what are the needs and what is the desire or the needs of the customer. So let's say, for example, we need to communicate or we want to communicate with the customer in these three different channels. Yeah, for example, if you have something to say, you can use your channel, imagine that you have only three channels, the push notification, the application banner, and the postal mail. And because of the importance of that communication, you decided to use those three channels and you deliver the three communication, each of them with the template and the creativity and the metadata to the customer. In this case, you have channels where you know how the channel behaves and if the final communication finally reached the customer or not. For example, in this example, imagine that the push channel acknowledged the delivery and you know that that communication was delivered. But the application banner was not shown because the customer didn't log in, so you cannot count with that visual extension. And regarding the postal mail, of course, you have the confirmation of the agent, of the postal mail service, but you don't know what happened with that letter. So you need to understand first that you need to separate. There's a first concept that is, let's say, the purely technical integration status is what Pablo was describing. You need to know what happens in each of these channels, but also in some other cases, you have also the possibility to really capture what is the customer opinion on the offer that was displayed, if it's interested, not interested, and so on. You need to record these direct responses, but also in some cases, you need to record what we call the infrared responses that is not a direct answer by the customer through any of this channel, but you need to detect this as a consequence that was expected from you according to this campaign. Yeah, what that was, you can see in the lower left part of the slide. You need to define what actions you want to detect and what are the triggers associated to those actions in order to emphasize, to recognize those infrared responses. And go much into this detail for any business proposition. As we said, you will have different communications for the same purpose. You not only need to record the reaction of the customer, in this case, for example, the customer discarded the notification, maybe the customer has not even seen the email, but for example, during a call to the contact center or during a visit to the branch, the customer has declared an interest in this business proposition. You need to link all these reactions into one single concept that is what we call the lead, but in the end is the most relevant status for all the communications that are sent for one specific business proposition. The lead is directly connected with the business proposition and you need to have that concept clearly in mind because it's one of the key concepts behind all of this, especially for the commercial communications. The next topic we want to talk about is what do we mean with the most meaningful responses. The most meaningful responses, I think it's a simple concept, but it's better to illustrate it with an example. Imagine you have several possibilities. Imagine you are talking about a banner, as we said before, with the inbound channel. The first thing is, okay, if the customer didn't log in, but the banner was not shown. But if you display the banner, you can have several options, you can have the remind me later, the customer decided in that moment, this is not the moment for me, so I prefer you to remind me this later. I can accept, I can be interested in that offer. I can accept the offer, finally the offer could be signed and I could buy the service or the product you are offering me. This is the direct path, the happy path and based on explicit responses, but it's not the unique. Yeah, there's always the possibility that from any of those, let's say, different states, the customer somehow says or confirms that he's not interested in the offer, and on the other hand, as we said before, from most of these states, we can always infer that maybe the customer didn't follow the happy path, the complete happy path, but we know that according to our proposition, the customer finally acquired or finally completed the expected behavior, okay? Yeah, this is a good takeaway, taking this into consideration and define for each business proposition an estate that reflects this reality in order to understand them, the customer. So for the different type of communication that we were saying before, yeah, for the regulatory or purely legal communications, there's nothing to say, we need to communicate those to the customers, but for the other communications, there's some logic that needs to be applied. First of all, for the commercial or even for the advisory communications, you need to take into account the consent from the customer, not only GDPR, and for the operative communications, you need to take into account also the preferences of the customer, okay? So based on all these different possibilities, you have, let's say, a more selected or more limited options to communicate with the customer. Yeah, but that specific subset of selected or even accepted or possible communications, they are not going to compete randomly to reach the customer. You need to perform an orchestration and here is the first point when we talk about what are the customer profiles and the customer profiles are a set of values, a set of attributes, a set of propensity scores and a lot of things where you can apply, for sure, all the learnings that you are acquiring during these two days in order to manage and in order to be able to reach the customer, as we said before, in that right moment with the right channel being smart and so on. And this is important because the strategy that we are talking about is based on this orchestration, okay? So going deeper into this, what are the inputs for this orchestration? All the data repositories that we were discussing before, they can be in the same database or in different databases, but all of them are relevant also with all the relevant three specific customer profile and apart from the, let's say, the row or govern data, you need to take into account all the relevant propensity models and the business strategy, the priorities for the business in its moment on time and you need to put all of this in the hands of a business expert that can, in a single way and in a single place, make all this prioritization. Yeah, this is important to remark here that the business strategy should be considered as a static definition of what are my guidelines or what are the direction I want to follow, but it's not just the unique input. You need to also consider the material learning and the automated decision because you cannot be smart without them. And the panel that you see there in the middle that depends on our customer expert is the place where the organization was through experts decide on the possibilities. It's not deciding on what are the final impacts on the consumers. No, it's not, it's just to manage the possibilities, the creativity and so on. So after the decision is taken, you are, again, you are not just sending the contact, okay? We have a very specific concept, sorry, that is called the control group. That is what you use in this kind of campaigns to test the effectivity of your campaigns and the effectivity of your communications, okay? So because all of this is not very, very, let's say, relevant or effective if you're not testing it and to check if there's always room for improvement and you constantly need to be reflecting not only on the consequences compared to the control group but also taking into account the responses from the customer, okay? So after some theory, let's go to based on our experience building this, let's say, complex platform since a couple of years ago. Let's go for some lessons learned, okay? First one. First one. The first one is the vendor locking. The vendor locking, you should consider the vendor locking as an unavailable consequence of this. You are not going to develop the entire stack of components you need to deploy this. For example, regarding the panel, the control unit you need to have in order to enable the business to perform their decision and put their stuff, you need to choose if you are going to follow a strong vendor lock strategy or if you prefer the other side, think about a strategy most often in that case. If you go through the first one. For any, for all of this lessons learned we have included three different status, okay? Based on the feeling in the organization when they are taking into account each of these options, okay? Yeah. The first one for sure is, if you choose the first one is because you don't have so much experience about these kind of solutions and you are more than happy with that vendor that tells you a lot of things and is able to somehow fulfill all your expectations. But while doing, it's a kind of honeymoon. Everything goes well and, you know, but at the moment you need to think about another partner and try to change whatever you need to change there or even if the partner decides to deprecate the product or create another version that you are not interested, the problems will pop up and the consequences you won't be happy. Yeah, on the other hand our recommendation is that you first think about the data that's important for you, the business requisites that are important for you, what you want to achieve with this kind of tools and then you need to find the proper vendor. You will have followers to adapt but the first is that you are comfortable with your design and your architecture, okay? So in this case, yeah, you need to take this since the beginning and yeah, you will suffer a bit when you are adapting and asking the vendor to adapt in some cases for you and you need to adapt in some cases for the vendor but in the end it's worthy, okay? Second lesson. The second lesson is about the reference data. The reference data that you may know is the list of values you may have for a specific data item. So if you forget about this and you don't care, you are happy, you live in your happiness, totally disconnected from the reality and in the step before and while doing, you are more than happy because you get rid of a lot of complexity, you are comfortable with your solution and it seems to be it's day closer to the goal so you are more, but in the end it's totally a mess. You cannot rely on data that is not well structured so it's not, definitely it's not the way we advise you to follow. Yeah, the way to go and our recommendation is to put reference data as a very, very important concept in your organization, a first citizen and you need to build everything on top of the same govern reference data then you will start with a lot of passion because you are sharing a lot of concept between the teams, you will suffer a bit, but in the end again, it's a good recommendation. Yeah, lesson three. Well, this is about data consistency. If you attend this morning to the keynote, this is very close to the topics we talked about this morning. If you don't care about the data consistency and you need to choose if you follow a weak data consistency strategy or a strong data consistency strategy, probably you are tempted to choose the first one because it's lighter, you need to do much less things and you are happy, you are not worried, but okay, you prefer to center your effort in other components, but at the moment, you start doing and while doing, you realize that data consistency is key and you cannot maintain a communication, you cannot maintain a contact with your customers if you are telling different things based on different information, that should be the same in the back office side and that will destroy totally your architecture, your approach, your business understanding of what is happening and it's impossible to grow if you choose the first approach. Yeah, the second approach, obviously, you need to have a very, very strong data consistency. You need to trust your data because if not, you are taking decisions that are based on fake information and yeah, this maybe it's not the most appealing thing in the beginning and sometimes you need, in some of these cases, to achieve this strong consistency, you need to replicate data, but you don't need to over complicate yourself because there are a lot of easy and more or less plug and play solutions to have this replication, okay? So in the beginning, yeah, you will suffer a bit, but in the end, it's pretty straightforward. Fourth lesson is about the definition of loosely couplet, couplet domains. Here again, you can choose, you can go the lazy way and perform a poor definition of what are your domains and as a consequence of that, you can have, you will have blue bounded context definitions with, okay, you are happy because you don't have that much things to do and everything somehow fits. The thing is, okay, you feel a pirate, you feel like a pirate, you feel like you are doing whatever you want and as I said, everything fits, but at the moment you start developing and you go through the details and realize that the things are not that happy, you get dizzy and you probably need to rethink your entire architecture and your entire definitions. If you choose the first approach, maybe you need to rebuild the entire architecture, define your entire domains again and if you do that after the design phase, that will cause you a fortune, it's something that you cannot... On the other hand, you need to have since the beginning a very, very strong domain concept with very, very specific boundaries between the domains. If you can apply domain-driven design as we did, but even if you don't apply a very specific or very formalized framework to define all this, you need to have a clear view or not interest too much between the domains in terms of accessing directly the data and yeah, this is very, very complicated, but again, it's a good recommendation to follow. Five. Okay, you need to choose what are your real-time battles. There's a little bit of hype here, everything seems to be real-time or otherwise you are not in the 21th century, you are out of the fashion if you want to do something bad, but the reality is not that. The reality is every data flow has its own nature, so you need to realize that that's the reality and you need to take that as an input, so put your focus, your emphasis in what is needed and what is not in the real-time, in the before part, you are happy, you think that everything is the way you were appealing to do the things, but while doing and in the after, you are trying to justify the efforts and the cost of having that architecture with that mechanism in place that are not worth it. Yeah, this is maybe the most controversial recommendation and it's not obvious because even sometimes you can have the possibility to calculate everything in real-time and sometimes it's tempting to do it, but the recommendation is more about don't focus on everything is to be in real-time, you have the opportunity to leverage and to choose your battles and to put priority on the things that are specifically relevant in the real-time, okay? So yeah, you will choose this kind of battles wisely and in the end it will pay off and you can bit by bit and little by little put in your organization in more, let's say real-time fashion. And last but not least, the data-driven culture in your organization, we found that this is a key part of all these things. If you try to, this was also present in the keynote this morning, if you think that the data is, instead of what I need, it's just what I use, if you think that way, you will probably out of the reality and data is part of you, it's what really enable the next level in your proficiency, in the way you behave, the way you develop, the way the entire architecture will perform in this strategy focused on the customer, but we can find examples everywhere. So, forgetting about the data is not a good idea at all. Yeah, data is critical and if you take this into account, it will be not only useful for you but for the entire organization, okay? Because everything, all the data is trustworthy, everything is useful for everyone, everything can be shared with everyone. So yeah, in the beginning you will have different discussions, more or less let's say appealing with other parts of the organization, but in the end everything will be clarified, everything will be agreed and everything will be great for everyone. So, last section, yeah, this requires a lot of complexity. Yeah, for sure, it's very easy to say that you need a big data platform to achieve all of this, but in the end, for any kind of communications, omni-channel, customer-centric strategy, you need a lot of different components. We will not go into the detail of each of them but the important recommendation here or the key message here is that you don't need all of them since the beginning, okay? You can go little by little and incrementally to build your modern, let's say, communications architecture. Yeah, we have done a kind of example for you. Just to illustrate, there is no need to accomplish such complexity in a row. So, imagine you choose first and it's something that I personally advise to have a basic outbound communication. For that scenario, you only need a few set of components, very simple, very easy to integrate and if you start this way, you can learn about the journey you need to fulfill in the end. So, the second... Going forward, the next step could be to start using your platform for specific operative communications. There's not a lot of things that you need to add to your architecture. If you want to start building not only outbound communication but on low-inbound, you will start building other parts of the architecture to enable real-time... There are specific components for this and only for the full, let's say, capabilities in the target architecture, you will need all the components, okay? Yeah, I think that's it. That's it from our side. Thank you very much. Thank you very much. If you have some questions, thank you. Any questions? The final message is the complexity is exponential. The things we are learning during these two days are here to help us. So, take this in mind, take this complete photo to have a plan and a better understanding of what's going on and what are the next steps. Thank you very much.