[PODCAST] Meten is (z)weten: waarom dashboards je voor de gek houden 📊

Welcome to Impactmakers, the SuperOffice podcast about all topics related to, uh, CRM, that flow and everything. And today, two very interesting guests. In this case Raymond Pietersen eh from Kompas and Wouter Schram from SuperOffice. My name is Harry van Ek. I am a sales philosopher, and we are going through a half-hour customer journey in which we are going to call everything about... uh... up for discussion. NPS is coming by . We are going to talk about, uh, the data quality that we have or don't have. We are going to look at how you can actually optimize the synchronization between data and the CRM system, and what the role of humans is in this. My name is Harry van Hek. I am a sales philosopher. Remon, I would like to start with three statements. That is something we, uh, do as standard. And after that, I would like to invite you to briefly introduce yourself and tell me exactly what you do. The first question. The first question I have for you is to measure and know. One of those slogans used everywhere. Is that really the overused cliché in the business-to-business market? Uh, the cliché hasn't been misused. Uh, but the definition is even being misused. Um, so uh, that's a no. A no. And for you? Um, for me it's a no too. Also a no. You already agree on a nice conversation. Of course . Systems that do not communicate with each other demotivate your employees. Yes or no? Absolute. Absolute. Yes. Absolute. You really agree with each other. Sound strategic advice is impossible without watertight data analysis. Not true. I find that one, uh, difficult. Um, I don't see that as true either. Nice. I'll get back to you on that in a moment. Raymon, can you briefly tell me what you do? Yes. Uh, director of uh, of Compas RM. Uh, we focus on uh on data flows, optimizing data flows across the board, integrations, migrations, data cleansing, keeping data sources uh clean across the board. Absolutely beautiful. Good. I think it would be nice to briefly return to one of those things. That sound strategic advice is impossible without watertight data analysis. What made you say no? Um, data is an important part of your business process. Absolute. But it is not the only thing. It is about knowledge and expertise, and that comes partly from data. That is the hard side of this story. But of course, it's about market knowledge, which ca n't always be captured in that. Okay . So I think it is, for me it is too sharp. Um, it is absolutely part of the strategic advice, but it is not the only twist. Yes. You were there too, uh... Well , I often see the data as evidence of certain... well, you can actually... you can use it at the beginning to go in certain directions, and then combine it... indeed, I agree with you, with certain knowledge that exists, but also, for example, a team that you have as a company. So where do my competencies or people's competencies lie? Um, then choices are made, and you can subsequently prove those with new data . Um, the waterproof part, I agree 100,000% with that. Because, well, what we often see is that it is used to prove certain choices , but the data is not always accurate. Hmm hmm. Uh, but it is made correct. And uh, and that is of course a very big risk. A kind of window dressing. Uh yes, that that there is another nice word a nice word for it. Yes. Yes yes yes . You see this happening more often at companies: people say, " Yes, the Excel, the Excel, the data isn't correct." No, exactly. Yes. Yes, but that is uh exactly where that measuring is sweating or uh knowing uh naturally plays a role. Well, what if we tackled that subject, right? That we all want to manage based on numbers, don't we? We see that in football. All data analyses, and yet still making choices. Uh, but on the other hand, those sources often contradict each other, right? Because, but how exactly do you deal with that? How, how, how does that confusion actually arise in those organizations? I think that what you naturally see in the conversations we have with supervisors is that you have domains and data. And for me, data is an end-to- end process, from the beginning of your journey with a client to the delivery of services and the follow-up of services. Um, and everyone talks way too much about those subdomains, right? Whether you are talking to sales, servers, or finance. No one has the end- to-end data process in the EH in order, or even keeps track of it. Yes, that is an important one in our conversations, you know, that is; I very often use the metaphor of the table. The data is here on the table, and you extract what you need for your role and your position. Hmm hmm. Well, what exactly do you mean by that? Um, just making the link with CRM, okay? CRM is a very broad definition to me. Uh, but the definition of a customer is different for a salesperson than for a finance manager. Says no, my client isn't paying. So for a salesperson, a customer can have a different definition, a different content, or even a different value than for a finance manager. So, so what you are actually saying is that is also a personal interpretation that has to do with absolutely the role of data in the customer relationship. But that is exactly what it could be about . It is not your personal interpretation. It is the value you assign to it in your chain. Yes. Huh, that's like when sales, uh, considers a valuable customer, uh, something a valuable customer with potential, but he doesn't want to pay. Um, what is the definition, uh, of his perception then? Yes. Um, ultimately that is again the determining factor within a company. You would say management, but how do you see that in your experience? Um, we have practical examples where sales thought they were in charge of customers and customer information. Uh, but the numbers proved otherwise. Yes. Is it that, or is that also because sales is good at making things look nicer or more positive, after all? Um, that is a qualification. I think that they have a different perception of their added value. Sales is, of course, the basis of everything. Marketing before that . But that is naturally the precursor to that. And sales sometimes lives in its own world of "I have to, uh, sell my product, my products." Um, we are actually looking at it from the other side: does the product actually fit into the chain of solutions at companies? Hmm hmm. So we actually always look end-to- end from the process to data to applications, and rarely, uh, from data to just an application. Yes. Yes, that seems very complex, doesn't it, when you, uh, describe that. Um, if you have to explain that very simply, uh, what is data then? Um, well, I sometimes make the comparison with when you go grocery shopping, uh, at Albert Heijn or another store. Um, you take you have a recipe in mind, uh, and the ingredients are the data you need to come up with a recipe. What you do with it and whether you are a good cook is not stated in the recipe. Um, but you need at least the basic data to come home with the, uh, with the right stuff to do something with. Yes. So data are the building blocks of processes, the building blocks of applications, uh, the building blocks of reports. Hmm hmm. But how do you determine those building blocks, then? I find that "that that" an interesting phenomenon, don't you know, because everyone has their own idea about the data they want to capture. But how do you determine what the truly most important data is, right? Suppose you let go of the idea that everyone considers their own data the most important. But you were going to look at standardizations . Then, how much information about a customer do you want to store? Are those five fields or are those 500 fields? There are not 500 of them, and not five either. Um, so increasingly, if you've been around in this world a bit longer, we see that there are standards around customer data, standards around product data, and standards around supplier data. And we really try to bring the client back to the standards, because applications are also moving in that direction. Yes. And uh, can you give a few examples of standards? Um, a very simple practical example is: how many addresses do you record for a customer? Okay . Uh, a salesperson who says: "I want to know the visiting address of the head office and I want to know the visiting address of the branches." Um, if you are delivering products, uh, it depends on the market, then you also want to know the service locations. Sales has nothing to do with that, but your service department does. Where should the invoice go? Um, so the source of the data is naturally derived from what I use it for. Precisely. And in the example of CRM systems, I very often see that we have one address or five addresses, but actually you want to be able to record an infinite number of addresses depending on your business model. Yes, also depends on how the client is organized and what the client is like. Absolute. Yes, but that argues in favor of possibly defining that data centrally after all. Yes. Um, that explains my table model. Uh, all Tava is here on the table in one model, or in multiple models if you would like to use it otherwise . Uh, but realizing where your data lives in your system is incredibly important. Um, and that you're going to manage that from the central location is evident. Yes. Uh, but of course we often have discussions about where the real data lives? Who is responsible for customer data? Who is responsible for financial data? Who is responsible for a customer's service address? Is that sales or is that service? What is your experience with how well companies can understand this? Um, do it like I do... I'm not going to give a grade for that , but the average company is relatively bad at this. Yes. Hmm hmm. Back again to the one before the previous section. Um, people think in columns; uh, sales needs x information, and that is his world. That is what he focuses on, that is what he looks at, that is what he collects. Um, but if I ask the average salesperson, do you mind putting the service contact person's email address in there as well? Tell me, why would I do that? Yes. Hmm hmm. Is it perceived as a burden at that moment, then? At that moment, it is perceived as a burden because it is not relevant to your job. Relevant for the central data packet and relevant for your business processes. Yes, in the past I have been heavily involved in, let's say, making uh CLM systems operational. Yes. Um, so I'm happy to leave the technical side to other people, but with the use of CRM systems, you see that salespeople, but also marketers, sometimes struggle to determine which fields to create on the one hand, and on the other hand, once you've created them, there is, let's say, no motivation to fill those fields. Yes. Uh, but how do you manage that ? Well, look, there are of course a number of them, and the thing is that we normally start with the process flow. Just simply explain, uh, what are the actions you take. Take the customer journey, what actions are involved in the customer journey, and what data do you need for your customer journey, your company, and your products? Uh, make it, make it visible. Um, then there wo n't be any weird, uh, weird fields in it. Um, that is one side of the story. So you are going to look at the data you are storing per role and per system , but you also look at which data is permanently recorded at which moment , but also reused in other systems. So, on the one hand, we speak very clearly from the perspective of the CRM strategy: what do you need to be able to do CRM? But again, what is the definition? But how can you reuse that data as cleanly as possible on the other side of the chain? Are you laying that, um, or what is your vision? Because I have that on myself too. But are you placing a certain responsibility there? Is it right to place that with a sales team? No. So, for example, regarding that service address—if it has to be in CRM anyway— is that useful? Um no, the sales team must be responsible for the sales part of CRM. Uh, but you see that very often, of course, and you see that in a lot of conversations. CRM is by definition translated as being, well, a sales system. Uh, CRM is a sales system. While I think of CRM as a system that you use to create your customer overview . That applies to sales, that applies to service, that applies to finance. Um, so your CRM data is much broader than just your sales data. Yes. Is that where the biggest misunderstanding lies, that people really, truly think CRM is a matter for sales? I, I, I had a conversation yesterday with a client about, uh, a sales system, uh, a sales system, and the burden sales had on entering the data. Yes. And my simple question right away: what exactly do you have to fill in? Yes, I have a list here with 30 fields that I need to fill in to get the results. If you then ask the question: "Why are you doing that?" Yes, IT wants that. Yes. Yes. Uh, why does IT want that? Because they initially need those fields to be able to start a process. Yes. But it is not stated that she has to fill it out. No, but that essentially means that ownership is not well- defined for the different domains you are talking about. Um, not for the domains, but also not for the transfer between domains. Oh, I find that an interesting one. Customer a a customer address um is uh is often is often lies in the domain of the sales side. Um, but if service needs to pay a visit, who is responsible for that? Is sales actually responsible? He is responsible for that initial sale. But if they move afterwards, then it even matters whether they move. Because it really matters to that service man . Yes. And then you come to the second element. If you want to safeguard that properly, it means you really need to make good agreements about roles. Yes. Yes. About ownership. Um, but also about uh, how do we ensure that that data stays up to date ? And then you come to that famous friction that always exists within companies , where you have so many systems together that they all contradict each other . Yes, but there is actually one very simple solution for that. After all, if you start writing out the process, anyone can create a customer journey. Uh it is the uh the most um describe the steps you need to take to uh uh create a process step, but also which ones that you need. And then suddenly it becomes tangible and visible. Yes. Um, and then we also handle the translation between okay, which data needs to be in which system ? Because the sales side looks very closely at, uh, CRM, uh, sales systems. Uh, but the service data could be in a completely different system. So you are essentially creating a layered timeline from the process step to the data step. Which data goes to which process that is connected to this in which application? I would also like to chime in on that, if that's possible, because this is very recognizable and this is something we see a lot as well. Um, the moment you start an implementation, for example with CRM, time is allocated, attention is given, money is spent on it, and resources are made available for it. So then it is good. However, what we also know—and I believe this is happening at an increasingly rapid pace—is that processes change. And these change because your customer changes, your market, your environment, but also management, for example. Um, and what happens then is that after a certain time—and that can be after as little as 3 months, but also after 3 years—your process changes along with it, and then you see contamination forming. And I think that in practice, a great deal of risk lies there, or will come to lie there. Um, so at a certain point it gets done well, but then taking ownership to keep maintaining it—that’s where I think it often starts to rub. Yes, you're already talking about two phases. I think it's hard enough to get it right the first time, isn't it? So what is your optimal model in a landscape? Yes. Um, change management is very often done on an application. Yes. Yes. And you do uh uh at your super office a change is being implemented. Does the logistics department know that that change has taken place? Uh no, because it is a sales adjustment. No, if it is relevant to the chain, your process chain, and your data. Um, so we always strive for a sort of impact analysis. If you are going to change, no matter how small, yes, conduct an impact analysis of the change. What does that impact? And that rarely happens. Who takes that ownership, or who should take it if you aren't there? Um, from your perspective. That is an incredibly complex question. Um, because we say, uh, at companies of a certain size, you have something like a business analyst who is supposed to do that. An architect, an entrepreneur architect, a data architect. Um, but it is very often blamed on the business side. It is either placed on the IT side or the business side. Because you want a change in your sales process or you want a change in your service process. Well, then we are going to look at the service, uh, uh, the service application . Yes. Um, and the simplest example in this chain is, uh, a service agent comes to a customer who knows there is a new contact person for service. How is he going to fill that in? Is he going to call sales then and say, "Hey, you're supposedly sales data?" These are where things almost always go wrong. Yes. So, the consistency in process data. So people are often capable of thinking end-to-end in terms of processes. Not everyone, but that is getting better and better. But there are very few people who sign the data streams. Yes. Yes. But the data stream is actually something that is hardly ever discussed in an organization, isn't it? No. Uh, uh, how come? Um, because data is very often made complex. Yes. Yes, because if you are going to process data across the full breadth of the organization, then there are an enormous number of data points, an enormous number of data elements. People either start on the process side— which they are good at, because they learned to be analytical at school—or they look at the implementation of an application, but the data tag is rarely touched. Yes. And what do you mean by that layer? Which data do you need to fill a screen or fill an Excel spreadsheet? Because that could be anything . Which data, uh, do you use on the screen, and what is the process of the process of that data, and what should your output be? Hmm hmm. And people are indeed able to refer to the output, because I want this report. Uh, but rarely able to see the impact of that data in the chain. There are simply too few of those people. Yes. But that also means that the input is often not clear enough to arrive at the correct output. Absolute. Yes. Rubbish in, rubbish out, huh. That which will be shouting for years that uh and to make it even more complex uh but I don't want that at all is because that it's not about data. It is about input and output. It is about information. Yes. You want to fill something in to arrive at something. Um, and you want to get the most out of it . But that must be information, not data. And that mistake is always made. Yes. Now it's getting very interesting, isn't it, because that is of course CRM systems. The mistake you often see is with CRM systems where everything is measured, but people don't actually know what they want to do with those measurements, right? That will be no different in the organization within the large data stream. Yes. Um, KPIs is of course the most uh used filler word that makes everyone itch . The real cliché. uh, which is really becoming a cliché. Uh, is KPI data then, or is that information? Um, for me it is it is it information. Um, but I'm also looking at you for a moment: when I talk to countries about KPIs—sales KPIs or service KPIs—they rarely come up with a very mature answer. They are really looking. Yes. Uh, the difference between reporting and KPIs isn't very clear. Hmm hmm. Yes. I think indeed KPIs, or just objectives and targets, are indeed asked for quite a lot. Those are indeed not very often very clear at companies. Uh, for me it's actually more like a KPI is just a thermometer, basically. For me, it is nothing more than, well, we... we have a way of thinking, I'll be back, my way of thinking. We've talked about that often in previous podcasts . Um, and with that, you want to strive for something to see if you can actually put that thermometer in there, like, are we on the path we think we are going to achieve? And that is actually a KPI for me. Yes, but that is really funny, isn't it? Because you often talk when I visit companies ; I see that they have KPIs, but they are always end-level KPIs, never in process measurements. Yes. Right, so... and... and I think that's where it goes wrong too. Yes. Uh, we actually use that one a lot now, by the way, and it really does work. So actually there are a number of end KPIs, but the important ones are actually the KPIs that feed the end KPIs, so to speak . Because then you really know, hey, we achieved this. Um, our ultimate goal, you know, that is often revenue-related or profit-related. However, there are a number of targets, KPIs, and objectives that influence that. Hmm hmm. You can often get the crutch out of that, so to speak . So if you see that you are n't reaching your certain revenue, you can say: "Well, we're not reaching the revenue, because we think X isn't going well." But with those sub-KPIs, you can actually very easily see where the problem lies and what we need to focus on . And that, uh, that does provide really valuable information, because those are often your KPs that, uh, come out of the operation . So basically from the people in the field. Yes. But is it a misunderstanding that you are talking about the customer journey, right? I always think that is also becoming one of those terms that everyone uses inappropriately. Uh, uh, a customer is taken through a certain process, or the customer allows themselves to, uh, uh, force an organization, as it were, to follow that process. Yes. But do we also have an organizational journey when it comes to data? I think that the um, but that applies in general to the implementation of systems. Um, technology and data are very often discussed as being a technical aspect. And actually, it is a transformation of everything, isn't it? You are getting a new system. Your people must be able to work with it easily. Um, they need to be able to easily, uh, uh, enter their data and get it back out. Um, and that is partly the transformation of your company. Who is responsible for these items? Um, how do you ensure that if things don't go well, who is going to pick it up? Uh, but where does that itch come from then ? By all the people I speak to who then say: "Yeah, KPI, it gives me the creeps." Uh, why is that? Does that have to do with people starting to link KPIs to salary or bonuses or things like that? Or is there another catch? Um, I think that in SE, defining KPIs is a profession. Yes. Uh, something you can't put on just anyone. There is a rationale behind that that aligns with your business strategy. Um, getting to the data to properly populate that KPI is a whole other journey. Yes. Um, because that's where you naturally get those discussions every single time. That is that KPI that was formulated completely out of nowhere. Yes, that is not feasible. Which puts my bonus under pressure, uh, or whatever. Um, if you look back at the segmentation of companies again, so service and uh and finance, then you very often see that uh um um that people look at this, at this process, purely from the perspective of sex, from their role. While they do not understand that they are dependent on the predecessor or the successor of this piece. What do you mean by leading, following? Well , that sales information needs to go to service, right? So the quality of your sales data needs to be such that servicing can easily pick it up and doesn't have to go back to sales. What do you mean by this field? What do you mean by that field? Yes. Um, with too many fields, then the definition is unclear. Unclear definition. Ah. And if that definition is unclear, what happens then? Um, then you end up with a massive search within your company for the translation of the information—which in this case a salesperson has—into a system. Very simple question. Um, was the customer satisfied? Always. The customer is always satisfied, unless you keep asking. Um, because he benefits from the customer being satisfied. Uh, but what questions do you ask then? So I think that your data can help you get from subjective to objective. Yes. So, and I think there is huge gain to be made there . Um, if you're talking about pipeline management, um uh, what is the real value of your pipeline? Yes. Was it weighed or not weighed? And by which methodology? Um, yes . Of course. And is that often done, but essentially based on standard patterns instead of really looking at your own organization? Well, I think everyone brings something from the organization where they worked before. Because things went better at this company than at that company. So this model is more convenient. This is, of course, about the essence of your own business. Who are you ? What do you want to be? How fast do you want to grow? And based on which parameters? Hmm hmm. And what is the correct flow to arrive at the right data fields? Um, by simply writing it out. It really is a matter of unsubscribing. Uh, it really is um really writing out. Grab a sheet of paper. sign whether that refers to the customer journey or the product journey, or uh—we do like those journeys by the way, because that clarifies a lot. Um, but write that out, write the steps in it, and also just write out what you need per step. And simply put, that is truly a remedy for many companies. Um, write it out, make it clear, then the whole company understands what is written, and if there is a change, you go back to the drawing board: "Why did I include it back then, or why didn't I?" Yes. Do you get the impression that they share those customer journeys from the different disciplines well with the other departments? Um, and my clients do, of course. Uh no, I think that is one of the hardest parts of this series on this journey. Uh, make sure you get that data clearly available in the right place . Yes. And just to show what matters , right? what the importance of data is. The reason I am asking is because I sometimes see that sales doesn't realize how much data marketing needs to do their job . Yes. And conversely, that people also do not understand what data sales actually needs to effectively carry out their sales process. And in that regard, I think that often—and I do n't know if you have this experience too—when you set up a CRM, a lot of irrelevant fields are created. Certainly. Uh, those that are interesting but completely irrelevant to, uh, daily work. Well, we certainly see that a lot, and we always try to prevent that too, because that can be a burden, so to speak, for... actually, the question is simply, and I think Raymond said that at the beginning... he said that correctly too, that you... you have to look at which data you want to reuse, and that is actually crucial. So if you are going to enter data that you don't reuse or perhaps only need once every two years , well, don't do it just yet, or don't do it . Hmm hmm. Um, something I find quite interesting—and something I run into myself quite often, both internally and externally—is what I see. Um, in CRM we set up quite a lot of data that is also pretty important for that customer queue or custom journey, right? So for example, uh, there is a certain sales opportunity, then you, uh, the salesperson eventually fill in, for example, a reason why leads are lost. And that is quite an important thing to base strategic choices on, isn't it? So we always lose on price. So our price needs to come down. Or we always lose out on, uh, I don't know, no uh functionalities that we don't offer. So we need to expand our product . But the data entered there, well, is that always correct, because that is interpretation data, so to speak. Data generated by customer behavior requires less interpretation. But data generated by the behavior of your own people is open to quite a bit of interpretation. Because suppose I do a sales pitch and, um, I lose that process, then I can very easily say: "Yeah, no, we were too expensive." Yes, but either I was unable to demonstrate our added value. And those are also things that, uh, and that brings us back to that statement about how, how important is that data? I think you always just need deeper conversations to arrive at certain choices, so to speak. And that, uh, and I always find that a very difficult topic, like, yeah, you're going to store a lot of data . Uh, but how strictly can you really base your choices on that? Because it just depends on what that person enters into that data. But there is a very, very, very interesting aspect behind that: the validation of that data, right? So at the moment, just take a look at the sales role. Um, you fill in your pipeline and you fill in and uh, the customer just doesn't like you, uh, but you write "price too expensive" or "price too high." Um, nobody checks that. No, so hardly any evaluation, let alone feedback from the customer to figure out, " Hey, what did we actually do right or wrong here?" Is our product simply not good enough? Are we missing any functionalities? Uh, are we too expensive? Yes. Um, in the data journey, we look very closely at the validation at a specific point in time . How do you know if that is doable? That is kind of the big question, then. Because ultimately, you need to set up people or systems there to be able to do that . Um, we aren't making the transition to AI just yet, but uh, it naturally goes from, to some extent, you can uh, score a bit on NPS, that sort of thing. At multiple points in your chain, you can consider asking your customer or potential customer how well you are actually doing. Yes. Um, and then you can either get an honest answer or not. Uh, eventually, you can make a big mess of things. But I think many people forget that. You no longer look at the results that you have had . No. Well, NPS is actually a good example. We do that ourselves as well. But we do call them back anyway. Yes. Because even if that data went back into your system as well. Of course . Certainly. So suppose that we, uh, well, let me just assume the positive scenario . We're getting a, uh, an 89 or a 10, right? So the promoter, as it is called in NPStaal. Then, uh, suppose it is that nine, then we want to know, okay, but how can we make that a 10 ? And this sounds very nice, and it might seem just like we really would n't do that, but we really want to know. Because there is always something; even if someone is fundamentally very happy, there is simply always something you can improve. And we really do capture that output. But that is great, because the fact that you are now saying that it serves as a trigger for action for us to do something with it if we get a response to it. Yes. Uh, but a lot of companies measure NPS and do nothing with it. You're just looking at that, right, that is uh, a topic for a future podcast, I would say now. But but what you say is true. And then it's also interesting again as if the source of an NPS is actually correct, isn't it? Because there really are discussions about the value of an NPS, uh, that there is. So there you come back to what the essence of the data is? The source of the data. Well, I think we could talk about this for days. Uh, just about continuing. What I find interesting is to also look at what behavioral data you could bring to the table. So really more my background in the psychology behind the behavior of salespeople, but also customers. How can you capture these, and how can you use them in your datasets to ensure you get a better picture of your customers? Um, time is up. That means we must reach a conclusion. Well, always fun. The best conclusions are always: do you have one tip that you can really use to make an impact when it comes to data in the phase we are currently in regarding data? And we are also looking at the bridge to the fact that if you want to do AI, you need good data. Make your data, uh, visible, really visual, uh, make them take a board and write out what the data flow is. If you do not know that, do not see it, and do not recognize it. Yes. Um, then you're missing a whole part of the follow-up process. Yes. And if I replace data stream with data stream, is that exactly that is absolutely uh the that is for for the for the sale is that uh yeah for the listener it is easy because data has a very very broad if I have to ask you, what is the best impact tip you can give when it comes to data? Yeah, well that has actually been a lesson for me too, but uh, stay critical of your data. So the data that you actually present yourself is the real data that, uh, actually tells the story of what you want to show. Beautiful. Good discussion. You'll never finish in half an hour. But in any case, the essence for me is that it actually comes down to four questions again. First, what do we want to achieve with the data? Uh, why is it important to use specifically this data for our analyses? How are we going to use the data? And who is responsible for which data we actually capture and will use? This was the Impactmakers podcast about data, together with Raymond Pietersen and Wouter Scham. My name is Harry van Hek. I am a sales philosopher.