Transcript
Hi Marcos, great that you were able to make the time for this call. I know you've been helping multiple retailers to find the right price and tool for their specific situation, context. I'm really curious to hear how you do that. How do you assess the different pricing solutions on the market?
Thank you Fabian for your invitation and, um, for your interest in selecting the right pricing software. Um, yeah, I'm happy to share how I do it. Should I start right now?
Let's dive into it.
Perfect. I would like to share two parts of the secret source: first, what are the criterion dimensions to evaluate pricing software, and the methodology, how to do it.
If you want to evaluate a pricing software, we first start with the highlevel dimensions. What is important to make a decision about the pricing software? And the first one are, of course, the business criteria. How is the pricing software able to solve my business needs? This is the content, that's are the functions and functionalities that pricing software should deliver.
The second piece is, of course, the software. How does this software fit into my infrastructure, in my architecture, and what are the technical performance criteria that describe this pricing software?
The third part is the, are the financial criteria. How much does it cost? How much does it save? What is the business case of implementing this pricing software?
A fourth one, and important one, is: what is the provider, what we dealing with, and what kind of experience does provider bring to the table?
And lastly, the implementation risk. At the end, pricing software is an implementation project. It's not 100% plug andplay, it's a project, and the question here is: how is the, what is the implementation risk? How risky is it to implement it by a certain date? Do we have the resources, and so on. So these are the high level categories.
I think those five categories make a lot of sense. I can very well see retailers especially looking at the financial criteria of the whole project, of the outcome. Can you elaborate a bit more, what are the criteria behind those categories?
Yes, I, yes, I can do. Um, so once we define the categories and we are very sure that they cover all important dimensions, to evaluate those dimensions we need to have criteria, very concrete points by which we can conclude on the performance of the underlying dimensions. For example, on the business criteria we can define a full list of functional requirements and check off whether the pricing software can perform these tasks. Or second, we can define use cases that we think are very important and very unique to our company, and to see in, for example, life demonstrations how they are solved.
I guess this is probably very specific stuff, right? How they do their pricing, what special product relationships or channel complexities they have to cater.
Yes, yes, you're 100% right. So we cannot take a, a shopping list or a checklist and go into this project. We have a discovery phase at the beginning to see what is important, and that's also explains why there is no single pricing software on this market, like, if winner takes it all. Each company has their own specific unique characteristics, so that there is a fitting, best fitting pricing software out there.
Then the, of course we have the technical, uh, criteria. That's a, that's a summary of completely different criterion, ranging from data security to architectural fit, to scalability, to SLAs, and what is the liability insurance, and so. Very, very, um, much, um, many technical and actually nonfunctional criteria.
These probably are also very, let's say, the relevance are and the, the complexities depends a lot on the company, sales size of the retailer, I would assume.
Yes, you can have a very small, um, online shop versus a international multi channel company, um, across the globe, and of course they have 100% different, uh, criteria also on the technical part.
So then you have the financial criteria, um, and this is not only what are the, uh, annual license fees and, um, the cost for the implementation project, but also sometimes it's important to know how long does it take to pay back the whole project, or how to finance the whole project, the financing model. Sometimes you can put it on the balance sheet, sometimes you can use it as expenditure for the given year. Some, yeah, it depends what is important for you, and also here it depends on the company, the company structure, the liquidity and many other criteria.
I guess the challenge probably here, especially in the make or buy decision, that people don't forget the cost of make, also in the long run, to maintain and continuously improve and adapt the software solution if it's built inhouse, right?
Yes, um, you're right. And also the opportunity cost. So if you have a, a development team that creates a pricing software, at the same time it does not create something else. So what is the value at of this something else that you are losing out right now? And this has to get into this, um, as well.
Given that development capacity is limited.
Yes, you have to look into the opportunity costs. Uh, then of course the provider and the product, um, investment security. Is the company so small, for examp, that it, that we doubt that it will exist 5 years from now, or has it a successful track record and, um, positive trajectory? Um, how confident are we that we will do a successful project together, together, and how much experience do they bring to the table from comparable products, a project?
And, uh, lastly, implementation risk. So once we sign the contract, we embark on an implementation project. How confident are we that we successfully arrive at the end of the rainbow? How, how feasible is the project given our resources, the resources of the software provider? Um, how much do we rely on documentations, everything documented we need, for example APIs and processes and, uh, security, um, um, functionalities and security, um, requirements.
Yes, and this is all we can, these criteria are so concrete that we can evaluate them in a, in a reasonable way. That's how I would do it: categories, you have criteria. But this is only exante, this is at the point when we decide to prod pricing software. Then you have implementation going on, and I know that you, Fabian, did a lot of implementation projects. Looking back in hindsight, what of these criteria have the highest predictive power on a successful project?
I think that's a good point. I mean, we are dealing with RFPs, and many of these criteria we've seen and we've been answering. We are working with, we are offering these features and can succeed on these criteria. But in the end you not only buy a software, you buy the team behind the software, which brings, let's say, a, a broad experience across multiple implementations and retailers and categories on the one hand, but also has the capability, um, to also innovate in the future. And therefore you're not only buying a tool at the status quo, but you're also buying the capability to evolve the tool in the future.
And most important for the implementation then is also the team that is running implementation on, on all ends, so to say, and that they're working hand in hand and are able to, um, agile, in agile manner adjust, uh, the software if needed, if, uh, requirements change. Despite a thorough assessment of all criteria and use cases, there's always, uh, smaller details, uh, that are being adjusted throughout the implementation, and that's also an important thing, that the providers able to cater that.
And in the end it's also, it's human beings working together. So the, the collaboration, our view, is probably after all the most important predictor of the success. If the team is, is working together in a constructive manner, the result is going to be great. If it's working against each other, um, proving one is better than the other, or proving the software can, cannot fulfill all requirements, it's designed to fail.
Yeah, I can, I can totally relate. You're not only investing in software, you're investing in a relationship, and, uh, I think that's really important, um, for the time after, even after the implementation. So that's true, uh, but before the implementation, when you not yet know your relationship partner, so to say, to marry, how do you get information about all these criteria?
You need to create, um, points where you see the, where you can make a conclusion about the character of the people. For example, during the, um, RFI process: how much interaction do you have, what kind of counter questions do you get, or question for, um, clarification? Um, how tailored is, um, are the life workshops, is it customized to you? How much effort do you see your counterpart is investing, um, in, in you, um, without knowing that they will make the contract, and actually knowing that there are two, three or five other companies in, in the run? Um, of course you could also to create some artificial time pressure and see how they work, but, um, that's, I think that's not 100% ethical, so I won't do it.
But to be very sensitive to the moments where interaction happens, and to, yeah, to rely a bit al on your gut feeling: how is, uh, your counterpart, um, also reacting to you? And then, um, to make this more sensitive, you need to evaluate ex anti how do you want to evaluate those, um, uh, the, the teams. And talking about what makes a good collaboration partner makes you already sensitive about this, and, um, this is what I see that most companies don't, don't do, uh, consciously decide what would be the ideal partner. They're looking at requirement list and so on, but they don't take the time to think consciously about what makes a good partner. And I think already this, defining this criterion makes you more attuned to your partner, more sensitive and more aware.
Yes. I guess the other categories are much easier, um, to assess and get information, but also for those I, I assume you have a, a structured, uh, as I know you, procedure how to do that, and, uh, sources of, of information, right, that you can leverage?
Yes, um, that's how I would do it. I would always start, uh, in a pment order, like, st the categories, we have the criteria, and then, so that nobody is surprised at the end, um, that we don't have the information, um, define before you start the evaluation process where do you get the information to evaluate a criteria. And this is also how I, how I would recommend doing it: to link each criterion to a source of information where you get it from.
And once you have all the information for all the criteria, you then need to decide: okay, I have the information, but how do I evaluate this information? And of course you have qualitative information, um. In this case you need to evaluate qualitative information in a quantitative, as objective as possible way, and here I would suggest defining evaluation matrices before the evaluation happens. So what, um, what means three points, two points, one point, what do we need to see here?
And second, you can, you also have quantitative models. How do we modeled, for example, total cost of ownership, or how do we evaluate technical criteria? What is compensatory, so if it's, um, the performance is low here but better here, does it offset each other or not? My experience is that in most cases you have, um, must have criteria, or so to say knockout criteria, uh, even, either it has the capability to be integrated in your system or not.
Um, yes, um, this is how, how I would do it: categories, criteria, and then the evaluation. And then you put everything together, and the question is, how does it look like? And for this case I brought an exemplary summary with me for three different tools. Data are, um, just for the purpose of illustration.
And here you can decide: either you bring everything to the same currency or, um, denominator, like you bring everything into points, and then you even weight these points, and then each tool gets a single number, and then you take the tool with the highest number. My experience is this, um, is too subjective, because the weights are already subjective, and the way you move from a quantitative data to qualitative points, in this case, or, yeah, points are quantitative, but, um, it's subjective how you define what gives three points when you look, when you look into implementation cost.
My imp, my experience is that you take the evaluation for each criteria one by one, and then you discuss in your steering committee, or actually before that, um, how do you wait it, for example. And surprisingly, um, in all of my projects there was a clear winner, although you could assume, okay, this is functionally better but cost more, and that's why maybe, um, they had two winners. But usually, uh, you don't have them, and, and, um, this is how I would do it: each criterion, show the evaluation, and everything actually fits on one slide, and, um, then you make the case.
Thanks a lot, I think that's super val, valuable. I think especially this comprehensive overview, and of course I understand that the, sanitize the slide and remove Quick Lizard from number one, um, to keep it neutral for this purpose. No, but I think this is, this was super helpful. Marcus, thanks so much for your time, um, and I wish you good luck with the upcoming, uh, and ongoing, uh, consulting of, f, the retail clients and, and process, uh, tool selection processes.
Thank you so much for having me, and, uh, yeah, for this interesting conversation.