On Demand Webinar: 10 Myths about Spryker

Angela Meyer: So, a warm welcome to our diva-e webinar 10 Myths Around Spryker. Today our experts Alexander Graf from Spryker and Jan Stöckel are busting the ten myths around Spryker. We come to a short round of introductions. My name is Angela Meyer. I'm part of the diva-e marketing team and oversee our events and webinars. And I'm your presenter today. And now the birthday girl can start with a short introduction.

Alexander Graf: Yes, hello. I'm Alex, founder and CEO of Spryker, the cloud commerce technology, as I read here. And I write a lot for Kassenzone, and I also record podcasts. So we're going to talk a little bit about that today as well. And I'm glad that there are so many myths in the market that we can talk about. A few may be right, a few may be wrong. And would be especially happy if quite a lot of people write in the chat. But now is the opportunity to ask, if you don't ask now, you lose the right to ask for later. So, use this opportunity. And I'm glad that Jan is here, the new Janine, to support us here.

Jan Stöckel: Yes, hello, welcome to today's webinar from me as well. I'm also happy that the Alex is with us and we can talk about some topics in the Spryker context today. I've been working at diva-e for ten years now and advise our customers on all aspects of e-commerce with my team, and I'm also looking forward to your input on digital commerce and the like.

Angela Meyer: Great, then let-.

Alexander Graf: And we are on a first-name basis, I think we are on a first-name basis with the participants. Participants who have dared to come here can be addressed by their first name.

Angela Meyer: I think that's good. Then let's start. Alex, I'm going to give you the broadcast rights now and then, yes, I hope the participants enjoy listening.

Alexander Graf: And now, moderator, close windows with confidential content. Wait, there I have to close the whole-, the has to close the whole numbers here to Spryker again. No. Hold on, let me transfer that over.

Angela Meyer: And put away birthday wishes. Yes, that looks good.

Alexander Graf: Do you see the presentation in full screen mode now?

Angela Meyer: In full screen mode.

Alexander Graf: Very good. It's good that we practiced that. Yes, I think we should start directly with an introduction of you, Jan. So, what exactly do you do and how does the partnership with Spryker work? So, click.

Jan Stöckel: Yes, well, wonderful. So, diva-e has been a Spryker partner since 2018. Still a young partnership, very fruitful. We have been able to win many customers together in the meantime. As you can see, the number of developers is also growing steadily. Currently we are at 30, but I think that will increase significantly in the coming months. We have three certified consultants. And as you can see from the logos of the companies, our focus is relatively B2B. That means we support German upper midsize companies, hidden champions, and corporations in their digitization efforts, and we're looking forward to digitizing their sales and service processes in particular. Spryker naturally offers very good opportunities here, especially when it comes to deep integration in the direction of business models. But we will now look at that in detail. We work very closely with Spryker, it's a super partnership. We always have very good contacts and I'm happy that the Alex is also joining me today in this webinar. And that would bring us to the first myth.

Alexander Graf: Yes, we are doing this here in a dialog. So, of course, I hope that questions come in. I'm not quite sure if I've opened the chat, the right chat here. But then maybe the questions will be thrown in here, via audio, that would be cool too. And we always exchange a little bit. And actually, ten myths that we were able to identify, I think we chose from 50 myths, there are quite a lot that are told around us or where people think they know exactly how it works with us. Let's pick out the top ten. We have not shied away from addressing difficult myths today. And let's start with the first one. That-, this myth is called: Spryker is an e-commerce framework after all and I have to build everything myself. And I hear that a lot, I can imagine where that comes from, from the early years of Spryker. But whether that's really still the case and what the response to it is, that's what Jan is telling you now. Should I click on or do you want to tell a story about it first, about the myth?

Jan Stöckel: Yes, well, at the end of the day, the fact that we have already come to this, where you had more than 600 functions live, we never had any problems in the project to fall back on standard. And that also shows that the rapid development of your capabilities, that is, the range of functions that you are constantly expanding and in the next slide you can also see that nicely illustrated. This means that Spryker is always striving to expand its function modules. Also in close dialog with our customers. This means that we work closely together to look at new functionalities and implement them. The special feature is certainly that they are modular. This means that they are individually encapsulated, individually summable and offer the possibility of assembling the corresponding business models and using them as required. So, you can't and don't have to use everything here, but it's that, is switched on or implemented out, which is important for the customer's business model. And that starts with the frontend technology, which is API-first, i.e., different frontends from a classic desktop to IoT, voice assistance and similar, as well as different backend systems that can then be connected via middleware. Starting point of all the developments, we also see in a moment, offer there two demo stores, once optimized for B2B and once for B2C. And from there, we usually use a MWP to look at which user scenarios need to be additionally mapped in the company and build additional capabilities to match the business models or fall back on the standard repertoire. Exactly. And that's where I would go into the next myth as well. And, Alex, tell me, I've heard Spryker is really just a lot of marketing and nothing behind it. What do you say to that?

Alexander Graf: Well, first of all, I would like to thank you on behalf of the team for noticing our marketing. This is often not the case with other providers. I have copied this slide in here. Because sometimes we have the feeling that no matter what we say, where we communicate it, it is immediately consumed. Gladly even by direct market companions who then try to comment on it in the form of podcasts or in the form of internal company chats. I can promise you, I get it all. I know exactly what's happening at Sales Force in the chat and at Hybris. That means we get the feedback as well. And that always causes a lot of amusement for us in the team that we are perceived that way there. And I think, even though this is a myth here and we're sort of accused of it. I believe that this is more of a success KPI. You just have to say, and I stand for this, that we do a lot organically. We were active in many channels very early on. We also started our own podcast show with, among others, another partner. It was like the English Kassenzone podcast when the topic was still much smaller. We launched that in 2018 and now reach well over 1,000 listeners per episode and can of course reach many CIOs, CEOs and others. Have pre-, have had full-time videographers for four years now. We now have two people in the company who do nothing but produce videos. I just uploaded one on LinkedIn. Some of you might want to take a look. The videographer happened to be there when I was on the phone with Frank Thelen. And of course, these formats also help us to generate the appropriate reach for the new emerging platforms - LinkedIn is currently the platform of the moment - that can no longer be generated with classic banner advertising or with sponsoring of the Werben und Verkaufen newsletter.

And we-, I'll come back to this in a moment, we have a very, very efficient use of marketing resources. So, we-, so to speak we are-, we are already spending in the six-figure range, but by far not even a million per year and thus generate a very, very large growth. A channel like that is probably unfair, most of the others don't have that, that's Kassenzone. It existed even before Spryker. And Kassenzone alone generates over 50,000 hours of consumption per month. So, who listen to the podcast, who watch YouTube videos. Who, so to speak, romp around on the site. And that's also active in our target group. And that, at least that's how I explain this impression that we do a lot of marketing, even though we probably spend less than most of our competitors in the market. That's probably because quasi this-, the content marketing and this marketing genesis is part of our story first. But we're sort of cost-wise, if we look at the whole apparatus, how many people do we have working in the development department, how many people are working on the product, how many people are working in the partner ecosystem as well. From that-as you see every day that there's also a bit of stuff coming in, we're actually very lean in the marketing team. But when I read the myth, I thought: Yes, maybe that's how it's perceived. But it's actually quite cool that it's being perceived. And there are still many new formats coming in the next twelve months, many things that will be significantly further developed. And, exactly. If the marketing is perceived, thank you very much. So. But that brings us to the next myth. If now here the Angela no questions from the group, or contradiction for example throws in. You can ask directly to each myth also what, we are here to answer that also. So, the next myth, yes. Spryker is only for very specific use cases. Jan, is that true?

Jan Stöckel: Yes, it depends. In any case, the answer once again confirms that Spryker is not just hot air in the form of marketing, but that you can get a relatively good store or two stores delivered to your location. I have just indicated it, you can see it on the slide. So there is a standard B2C store, so you can turn that on and you have a nice online store for B2C, full-responsive is, with which you can sell things if you want to. And you also have a B2B store on the other side, which is closed, where you can then show customers prices and the like again. Provided you tie your backend systems in there of course, there's something out of the box there. And that's a topic where many of our customers start. So, not with special use cases, but to test some things first, is the channel, is it accepted? Some start right back with product catalogs without commerce functions. The store is then also suitable for gaining initial experience. In particular, of course, companies that may not yet have a digital sales channel.

On the other hand, we have already seen that there are additional modules that can be switched on, such as a special payment later on, where it is said that credit card payments should be made possible. Or other frontends, that you develop independent apps and so on. And so it can be said that the system offers standard stores. Should there be more, we can gladly implement that, or fall back on the standards. And if you look at the details, you can usually find the use cases that you want to map. Apart from that, another myth that persists, which we also feel again and again in customer dialogs, is that Spryker would not exist without venture capital. Alex, is that true?

Alexander Graf: That's partly true. Well, it's basically a myth now, too, wants to have to say: Yes, it's partly true. And you have to look at two different versions of how a software company actually comes into being. And of course, we have already seen many software companies in our market, from Intershop to Hybris, Demandware, Shopware, Magento and many others. And you can actually-, I've broken it down very, very, very roughly now. Of course, this is not 100% correct in detail, but you can imagine it a little bit. So, most of our market companions, at least in the German market, abroad it looks a bit different, they were founded in the variant one, so to speak. They have in the context of their agency work, Shopware was also once an agency, Magento was an agency of Roy and Joa. Hybris used to be an agency. In their agency business, they developed a product on the side over the course of many projects, and at some point it became clear that: Hey, this product can be standardized.

However, it can take years to actually develop a product on the side in the agency business. And then you have to invest additional years to get out of the agency business and into a product business. And then, after ten or twelve years, scaling and internationalization can begin. That's what we're seeing. We have also seen this with many companies. And we had the advantage that our product was already pre-developed in the Project A ecosystem and we could say: Okay, we actually save this whole part of the agency work, we can immediately go into the-, into the product development. Spryker turned five years old a good six months ago. And we can build the product and the product business and ecosystem in parallel, so to speak. With external money. Well, it wouldn't be possible without venture capital, that's true, yes. Of course, we had to pre-finance a lot. But we can also-, we've been on the path of internationalization for two years now and will probably-, will, I think, in three years, so to speak, probably make more sales outside Europe than within Europe. So, and that saves us, so to speak, this venture capital path, saves us about ten years. If you look at 20 years until a product company is really mature, so to speak, and has a very mature global ecosystem. That would not be possible without venture capital. That is definitely true.

But what is wrong is this accusation of non-profitability. You can, if you look at the data in the Federal Gazette, you can understand that pretty well. But there is-, or there is often the accusation that of course we can't be profitable from internal financing. That's not true. But we don't want that either, because we collect external capital in order to grow faster and not to be based on internal financing. And for us it's-, there are sort of in this software scene, in the global software scene there are KPIs that investors look at, something like Average Revenue per Account, yes, APA. Or Customer Acquisation Course or LTV, Lifetime Value. Or MRR, Monthly Recurring Revenue. So, A, what is that number, how fast is it increasing or decreasing, how stable is it. And these numbers there is-, because there are hundreds of SAS companies worldwide, there is already a certain-, a certain pigeonhole system where you can say, okay, if you are in this range with CAC and MRR and MPS, that's kind of medium good. If you are in this range, you are very good. And we're active in the top cohorts there to some extent. So the way we are targeting our business, it's extremely positive from an investor perspective. And that also means that you have to work very cash-efficiently. You can't just burn money. In other words, I would say that we are much more profitable and cost-sensitive than some of our competitors on the market. But of course that's also due to the origin of the business model.

And another question came in here: Does Spryker then eventually get sold and become less innovative? Because we were founded in a venture capital environment, at some point there has to be the possibility for the investors of the early hours to sell their shares again, so. That happens either in the context of an IPO or in the context of a sale or in the context of a transfer to a private equity firm. The fact that there is a lot of private capital on the market now means that a sale, even in the next five years, is often not even necessary. There are a lot of holdings that is now- that are trying to build their own tech conglomerates. And that's not something that we're ticking towards either. So, we kind of don't have an incentive to sell. I don't have to buy a Porsche or anything else here, so to speak. We want this-, we want to win in this market. We want to be the most successful, the best platform for customers who are tackling these kinds of digitalization projects in commerce. And also want to be the global market leader. That is our aspiration. Whether-, that doesn't necessarily get better with a sale.

And the question of more or less innovative, ultimately, I don't know, if we lose our innovative touch, at some point, of course, we become a bit more immobile. I agree-, I would completely agree with that. But if at some point you become too uninnovative, then of course-, then the switching costs are not particularly high and then the customer can choose another provider. But I personally can't predict what the shareholder structure will look like in ten years. The only thing we can do is to ensure that growth is very, very efficient, and that it takes place globally. I don't believe in local market leaders. There must always be a global claim. This market has simply grown together too much internationally for that. There is no such thing as a small, medium-sized software provider from Bochum that can somehow manage to serve only German customers. That is no longer possible. And I believe that our partners, including diva-e, see it similarly. And it is only with momentum, with growth momentum, that we will be able to raise enough capital to invest in the product, to invest in the ecosystem. But I can reassure you. So, we have enough money, we are not dependent on an external financial investor in the next few months, not even in the next two years. And can also grow pretty much adequately. So. I hope I have answered all the questions now. I've only seen the one, but Angela will post that in if there's anything.

Angela Meyer: Yes, exactly.

Alexander Graf: So, I'll move on to the next myth. The one that I'm going to pante over to Jan again Spryker is just a store system.

Jan Stöckel: Yes, perhaps a brief comment on what Alex just said. In addition to being cost-efficient, it has to be said that the partner management works very efficiently and very closely with us. And we are always pleased that they always respond actively and are keen on a close partnership. At this point, we would like to thank them once again. And that also gives us the opportunity to ultimately advise our customers well and to get the best fit. And the fact that it's not just about store systems, but rather about the digitization of business processes, is reflected in most of the project inquiries we receive today. After all, customers are no longer thinking only in terms of desktops, as was perhaps the case here at the beginning, but end devices are diversifying. The touchpoints to the customer and that too. Rather in B2B, here IoT plays an important role. In the meantime, however, also mobile devices, where we also develop special use cases in the customer projects, such as complaint processing, for example, special apps, where the customer can directly, when he gets the delivery, request returns, if there are things. We work-, have prototype direction voice assistants and everything. Spryker, with its Glue API, of course offers the best possibilities for integration into the backend. And via the middleware, we can then directly access the business process logics from the ERP, such as an SAP, for example, and thus really offer digital added value for the individual customers. And thus respond to the wishes of the end customer.

And that is what the digitization of business processes is all about. We have to set ourselves apart from other channels and create added value in the digital channel. I always say that we are competing here against a fax form that the customer sends. And we can only replace that by giving the customer something that binds him to our portal and also drives the use of the portal. And that requires deep back-end integration. We'll see what that looks like with SAP and the like in another myth in a moment. In any case, Spryker offers the best foundations for deep integration and digitization of business processes, far beyond a standard front end. And of course, the question that arises is, the product must be extremely expensive, Alex, if it can be integrated so well, and so on?

Alexander Graf: Yes, I hear that myth a lot, actually. But, so, I think that's fair when it's told by someone who's looking at Shopify right now and somehow for the self-knit socks, they're looking at a store there. For him, 200,000 euros may seem expensive now. But the companies we work with usually think outside the box a bit. And there are different types of companies that we work with. We have a lot of companies that already have experience with standard systems. These standard systems were introduced at some point to build a standard web store. I had recorded a podcast yesterday with Jochen Krisch and Joel Kaczmarek. And then we do a podcast and there is-, there we talked about this whole topic of mobile e-commerce. And one statement that came out of the podcast is that desktop is the new stationary. And that's really the case. So, the desktop case is a dying case. And if you've built in a solution for a store that wasn't supposed to change much, that was heavily desktop-focused, then it's become increasingly expensive to adapt that to modern requirements.

And what the customers we work with have learned is that these adaptations no longer happen once, but are an ongoing process. So I have to-, I have to manage to make this adaptation process as efficient as it can be. And that's what our pitch is. We're not pitching that we make the better web store. We're saying: If you want to adapt permanently, if you want to adapt to customer requirements, if you want to be faster than the competition, you need a technology that allows you to do that. And of course, over time, we are much more efficient than technologies that are designed to serve a web store, or even a mobile web store, at the latest after the project launch, or even well before. That's the feedback we get again and again from the developer environment. That's also the feedback we keep getting from the project management environment.

We once compared this with: The standard software is a kind of Playmobil, you unpack it and start playing. Spryker is more like Lego technology. One is not bad, the other is not good. They are two different toys. My daughter is still into the Playmobil world, thinks it's good. My son is in the Lego technology world because he's further along. And we see more and more companies that are now outgrowing the Playmobil age, so to speak, and need a different technology there. And then 100,000 euros, if that's the basis of the infrastructure, in order to then partly handle millions, meanwhile also hundreds of millions of business, that's not a lot of money. And I have also discussed this very thesis with Tarek Müller.

We have recorded our 300th Kassenzone podcast. It will be released tomorrow, no, the day after tomorrow. And we also talked about Spryker and what else I do here on my farm, and I told him that too. That's when I told him this myth as well. And he said, "I think that's very, very little money." He wouldn't dream of valuing basic infrastructure by those standards. Because, of course, it's super expensive when an infrastructure like that just doesn't run when it's down on Black Friday, as you see with a lot of big stores in Germany. If the-, if a feature that I have to roll out in order to be somehow GDPR-compliant, if that is far too expensive to roll out and accordingly claims for damages flutter into the house. Therefore, yes, so for the Shopify store user who can alternatively use a technology that otherwise somehow costs $30 a month, yes, it's expensive. For the target group that diva-e serves here or that we want to serve, this is actually only a very small part of the total project costs and also a now a business unit, they want to be faster and more productive with it and optimize there not at the last software cost screw. It also buys other people. It's no longer IT procurement that buys, it's the business that buys. Are there any questions about this or do you only see head shaking in the chat, Angela?

Angela Meyer: No, currently no other questions asked. Those might come in.

Jan Stöckel: Okay, one thing I would like to add. At the end of the day, every company invests more money per year in a sales employee by putting a company car there and computer technology and iPads and whatever else. And that is not scalable. And I hold that against the companies and say: "Attention, you invest so much money in your sales, your trade fairs, put that in relation to a store, which is scalable." And there goes also fell then the eyes and say: "That's actually true." Because, the bottom line is then really several employees that you don't save there in the bottom line, but you make their work easier every day and they can focus better on important issues, the final meeting or getting the signature for example.

Alexander Graf: Yes. Yes, and this is followed by the question, okay, if it's Lego technology, then you certainly need a large Lego technology experienced team, which is able to use that. Because the little girls who used to play with Playmobil or the little boys usually can't handle it.

Jan Stöckel: Yes, to a certain extent it's definitely the case that companies that are thinking about digitization also have to think about how they're going to manage the issue with what kind of personnel. Because as I said at the beginning, sales employees are there and go out to the customer and sell the solution. In the same way, there must be people in an online store or in the digital processes who take care of the getaway management itself, who bring the store to life. About the online marketing, rather also about the fact that traffic also comes. And if you take a look at the project organization we've drawn up, it's often the case that there are many more people involved. That is, of course, the sales department itself.

Alex, if you can go one slide further, as you can then see, who comes into play on the customer side in the end and has to help us find out how we can market the products online, what of the products can be digitized in the direction of services and also take on board correspondingly suitable areas such as service and co. And, of course, we need to find someone to take care of this. We call this a product owner. In other words, a person in the company who thinks about the further development of Spryker, develops user stories on the agile track, i.e., use cases for the system, and also discusses with internal IT how such business processes can be integrated into the backend systems in the best possible way. And this requires a minimum level of commitment from the company. What we recommend, despite everything, is that a certain number of developers be made available to drive the project forward with a mixed team. Because, let me say, not for every small request should a ticket run up at the service provider. This is not necessarily the case at the beginning. We often take over the development completely. But we also recommend in the future, especially if you see digitization as an important tool for your business processes, to provide developers here as well. And the fact that you can also find developers for Spryker these days is ultimately also due to the fact that there is a lot of standard technology in the belly. Be it a PAP technology, then works together with Redis, for the developers who know what is meant. Elastic Search in it, that is standardized. And also Symphony as a framework will come in there. And through, for example, Clean Code or Solid, in principle, you get into the development quickly. At the end of the day, we see three main scenarios of how to proceed.

Either you build up your own internal team, the whole thing. The advantage that you can certainly push the TCO costs here quite, because you have no external costs. Develops there merrily before itself. The disadvantage, of course, is that you often don't have the people in the company who have the experience. That means you have to buy them in at a high price, or find people who know how to digitize our business. And I believe that diva-e and Spryker can create much more value together, because we have enormous experience in this area. We have supported many companies in the area of customer portals and brought a lot of live. And from this expertise, we can also give a lot of input on what works and where there are challenges that need to be solved. And there are of course more, higher costs, because you have to buy in external consulting. Certainly there's a higher onboarding cost because we have to understand your business model and based on that, of course, we have to do the consulting. But on the other hand, you get tremendous know-how and have a faster time to market.

That is, we usually want the projects after an initial familiarization phase, so-called discovery of one month, after 100 days the first MPP out on Spryker. And then we have the opportunity to try it out and gather initial insights and then proceed iteratively. If you then take your own developers on board, you have killed two birds with one stone. You can reduce the costs a bit, especially for small requests, small changes, quickly add a banner or change something. In the area of product detail page in the end effect to respond directly to customer feedback. And in the end, we still have the communication effort as a deficit in a few places, of course. But the agile project organization ultimately results in very good tool-supported work. And we work, well, in most projects nowadays, you could say, with mixed teams. To start with, we often use pair programming, which means that we also onboard the developers from the individual companies who may not yet have any experience in Spryker, take them on board with us, and integrate them into the teams. And that way, they get to know the product on the job and are constantly developing it further. And that is, I think, one of the success stories in most of our projects. And the companies really get added value from having their own colleagues on board.

Alexander Graf: Two more questions came in here, which I would like to address briefly. One comment was-, come-, goes to the analogy of toys: There are also inexpensive Lego. That's right, there are also, for example Fischer Technik, which is also a modular principle. But there is a very good anecdote, I think, that also fits in with this. Fischer Technik, I don't know who here in the chat has ever built that. For example, I have the big marble run from Fischer Technik. It's kind of like Legotechnik, except it's in the instructions, there's only every tenth page. That's really how it is. It takes a long time, it's not very expandable, there are not many people who support it. It's not pretty, yeah. It's less fun. And it's the same with cheaper technologies. Of course you can find a self-made framework somewhere. But everything around it is missing. And the enterprise customers we usually deal with say to themselves: Yes, these 20,000 euros that I might be able to save here compared to Spryker are completely saved in the wrong place, because then I'm missing exactly this access to the ecosystem, the growth as well, this international aspect, so to speak. But if you prefer to play with Fischer Technik, the marble run is really cool. I can only recommend it.

And then there was a second question that Angela copied in here: Is it still the case that the company has to adapt to Spryker and not Spryker to a company. Den-, I've never heard that before, I only know that in the context of SAP. They also say that if you introduce an ERP system, which is not a modular system, but rather a large block of software, it is extremely expensive to adapt this block of software, so to speak, then the company should rather adapt. With Spryker, the exact opposite is the case. That's why I'm not sure where that comment comes from, or where that comes from. So, I've never heard it before. I don't know, Jan, if you've heard it before. But would I now know that-.

Jan Stöckel: Think of the, as you say, SAP context, we hear that more often. And that's where this fits-, are out of place here and we were also able to, yes, disprove the current myths, I think. We now have an additional myth here, myth number eight: Spryker is just a big agency with its own software. Alex.

Alexander Graf: Yeah, let me click on. After that, we'll also go back to this question that was still added in the chat. I think that's very good. So, always questions, questions, questions. Yes, this-, well, this is what I think we hear-, this is, I think, the most frequently heard myth, although people always shoot their mouths off about it: Where does the revenue come from and is it all service and not software. I can reassure you, so to speak, that the agency share, i.e. the number of developers who are actually involved in the projects, together with the agencies, as is also the case with diva-e, we also support these projects, is less than 20 percent. It can't be any higher, because then we wouldn't fit into these pigeonholes for international investors. If we had a share of 40 percent, 50 percent, then they would have exactly this impression: It's actually an agency and not a software company. But that's not the case, we have less than 20 percent. And in the long term, it will tend to get smaller.

We don't limit the artificial, because we say there are companies that, as Jan just described, have this approach: I don't want an agency. Here, dear software supplier, give me one of your developers, and we'll learn it ourselves. We have just seen the advantages and disadvantages of this approach. But there are also people who say: I would like to have a developer or a product manager from the manufacturer involved, so that I have a certain degree of security that the agency is doing it right. There are many different ways of playing this game, but the percentage is less than 20 percent. And this has also been picked up again recently, so to speak, this thesis. This is due to a mistake on my part, so to speak, because we are listed in the Gartner Quadrant. And it was incorrectly stated that we generate 75 percent of our revenue through Professional Services. That was due to a communication error on my part. Of course, we talked intensively with the Gartner teams and described what is done in such a project. So to speak, that every euro we make is then mirrored by an agency with four to ten euros, yes. So you don't get a finished project for 100,000 euros. So. And then they took these four and said: Okay, they say that a project for a customer is only 25 percent of the software. That's where this 75 percent share comes from. This is already in the correction loop and will no longer appear in the next reports. So, this is right: less than 20 percent revenue share is, if you want to describe it that way, a kind of agency revenue. And so, to come back to the drawers, we are pretty well on track with what our shareholders expect. And then to go into the third question in the chat, 100 days on average for a rollout, does Spryker also include a CMS and PIM system? Can you maybe say something about that as well, yeah, maybe I'm getting a little bit out of history there. The-, there are CMS and PIM logics in Spryker, of course.

But the vast majority of the companies we work with already have a CMS or a PIM system in place, work with specialized systems, so to speak, because a PIM system is also a very, very complex system. And you can't imagine it like Magento or Shopware, that you somehow upload some product data into the store. That's not the use case that our customers usually have to deal with. That's why we have made a significantly higher investment in the interface, so to speak, in order to connect existing systems from partners such as Akinio, for example. You can also edit and upload product data with the demo store. But that is at most for the proof of concept, which is generally used. And of course there are also many use cases where a CMS and PIM system is no longer necessary at all, because this kind of frontend is no longer delivered at all, but instead corresponding data is transferred on the hand scanner, for example. And we had really intensively in recent years there was-, there was always this question: Come on, let's build something into the product and let that-, but that just leads to the Playmobil castle yes, yes. So, the more you build into the software and make the parts thicker, the more likely it is to be a Playmobil castle. And that, of course, is always a balancing act for us from a software development perspective, where we then have to look at what is actually in the long-term interest of our customers. What-, and what can partners perhaps do much, much better. And in these areas, we rely on a very light standard, so to speak, and prefer to integrate the top partners that exist in these two worlds. Or do you have a different approach?

Jan Stöckel: Yes, I can only add to that. I can only add to that. However, we also usually have the e-frontend in the projects in an MBP, in a POC. Otherwise, many of our customers rely on their own CMS. Often they are driven to have a website where we say, "Well, we need a touchpoint to the customer and not a website or a store. A customer portal and maybe an app, but that should be an access point and then we continue to use the existing CMS systems such as Bloomreach, such as FirstSpirit, where partnerships are also being built closely and in part connectors are now being built. And we develop a uniform customer portal and ultimately fall back on Spryker for transactional topics or, as we saw earlier, for special capabilities, using the business logic. But the executing layer or user layer is the CMS system and a PIM is similar. That is one of the main drivers in many of our e-commerce projects, the product data, because products can only be found if they are provided with the corresponding attribute sets and you also have the corresponding classification trees in the background to enable a good search and a good filter.

And there is no way around a PIM system, especially in B2B with highly complex products, where you have to build wizards or finders or filters and even configurators. And we are also happy to provide support in the selection process, or to fall back on the parts of SAP, for example, which we will come back to in a moment. SAP has a classification system that we can use as a PIM system. This gives rise to various constructs that we can discuss. But as a rule, it usually ends up in a PIM project as a stand-alone solution to professionalize the entire topic of internationalization and data maintenance, because it is a major part, as I already mentioned, of the entire commerce.

Alexander Graf: Exactly. Maybe that also fits quite well. There is this myth that integrating Spryker into SAP is extremely complex. I think this myth exists for virtually every software plus SAP. But why don't you answer it from the Spryker point of view, so to speak.

Jan Stöckel: Yes, we certainly have an advantage in that we have SAP consultants on board and I have also been involved in CRM and ERP projects in the SAP environment for many years, so we can talk to both colleagues, to an IT manager as well as to marketing colleagues, and I recognized this as an asset at an early stage and started to build connectors. You just had the slide up. We want to introduce a connector today, which is basically a standard connector that we have built to connect Spryker to an SAP ERP. And if you open the slide again, I can briefly explain what the basis is. Alex, in the background.

Alexander Graf: What-, where do I have to click on this somewhere?

Jan Stöckel: Yes, one more, yes, exactly. Here you can see that quite nicely.

Alexander Graf: But there comes already the next-, there comes already the next myth here in my presentation.

Jan Stöckel: No, back. Yes, that was-, probably the internet is too slow. Slide 28, exactly. So, if you look at the SAP ERP system on the right, we're using the JCo library, which is basically a library from SAP that enables external communication. It was introduced a long time ago with SAP R3. I think it was ETC 6.0, an original, where this external communication was opened up to access special knowledge logic in SAP. These are such topics as Order Simulate or ATP Check. The experts now know what I mean. In the end, these are direct accesses to SAP logic. And for this purpose, so-called RFC calls are used, or Idoc documents are inserted when it comes to asynchronous communication. So, in the end, we have built a middleware, an extension of the Spryker middleware, which we build where the customer wants it. Either into their own data center, directly into SAP or with into the Spryker cloud or an extra cloud. And thus enable direct communication between the SAP ERP or also with the S4 HANA, the customer wants that, and Spryker, by doing the translation in the end. That is, the data that we take from SAP is translated and then pushed towards Spryker. There we work mainly with Restserver Sys and Rabbit MQ. There we have built two example cases, you can see below left explains the whole topic Order Simulate or order data simulation. We use it very often to enable and display individual prices for customers in the store. This means that an order simulation is ultimately triggered in the store in SAP and the customer-specific prices are extracted from SAP via stored price lists and condition records of the customer.

And this can often only be done by pre-simulating an order with certain framework conditions, i.e. how much of the product is needed and when. And then SAP delivers it to us via the route, i.e., we call up RFC, call up the business logic, the API, Order Simulate, then the RFC returns it to us, we translate it into rest and transfer it via Spryker and then display the corresponding price in the shopping cart or on the PDP. When it comes to master data, such as customer master data or item master data, we usually use asynchronous communication. This means that an initial upload of Idocs, which we receive from SAP, is made possible in Spryker. And then in the future, there will be data handling. That is, we look at what information has changed, contact persons, at the customer or material masters are-, have changed. And we also get this information from SAP via Idocs in XML standard. Can we say we let translate pass the data then via Rapid Encue asynchronous to Spryker. This is now a standard connector that we have in use in five projects by now. And it has to be said here that we also initially used up one, two, up to three months to create the breakthrough for all the interfaces that I have now called up. And in the meantime, through the Connector, we have really connected the store to the live SAP system in two or three weeks. Provided is standardized and the standard business logics are used and no special changes have been made to the Order Simulate or ATP there. But this can be found out relatively quickly at the beginning of the project by having SAP consultants who work directly in the customer's system and log in or, in the best case, have access to it. And then, on the basis of the information, they are also able to say whether this connector can now be used relatively quickly, or whether changes can be made in SAP or on our end. Maybe there are questions about that?

Angela, I don't see anything yet, on integration?

Angela Meyer: Not yet. Maybe later. You are welcome to continue

Jan Stöckel: Okay. So, if you have a question, I can support you up to a certain level of detail. Otherwise, we could go into more depth with our SAP experts afterwards and discuss details in the direction of process automation or business process logics, out of SAP and into digital business. Yes, that brings us to the last myth, if there is no question here. This is a myth that also accompanies us every day. It's that Spryker only has customers in the DACH region and can't internationalize at all. Alex, is that the case or what is your focus?

Alexander Graf: Well, in 2014 that was the case, two months after the founding, that's true. But it has changed, of course. Now, of course, you have to look a little bit, for whom is this relevant, yes. For a large medium-sized company from Germany, it's perhaps not so relevant that you-, so to speak, that you have many international customers. But most of them, of course, have an international company setup themselves and expect us to be able to serve markets internationally. We now have over 150 clients in over 15 countries. We serve many, many industries and have over 100 partners spread around the globe. We still have a focus on Europe, which is of course primarily DACH. But we now have customers in Eastern Europe, India, the USA and Brazil. Large customers, too, yes. Siemens Brazil, for example, is a customer. And the-, that comes with time. Of course, we have a very high focus on the customers we are still working on. Because there is actually no immediate product advantage in serving customers in three other markets, and we have to use our resources sparingly and don't want to spend all our time on sales or marketing; instead, we want it to flow into product development and into helping our customers, so to speak. I think you can get the first taste of this international footprint now, so to speak. Because in order to even be listed with Gartner, you need one or two customers in the USA. That's where we started last year. We already have a few customers in the USA. We are still-, but it is still very small. That's why we've only made it from 160 companies to the top 15 in the Gartner quadrant for the first time this year, and we're also listed as a non-player. There has never been a company that has achieved this in less than ten years, so to speak, since it was founded. We did it within five years. They only do this for companies that have a global footprint and can also operate globally. And we also managed to be the most visionary among the niche providers. That is, so to speak, our roadmap, the way we see software development. So, so to speak, how we also see the decline of the whole microservices topic, that helps us to verify that. And that's sort of-, of course we are very, very proud of that ourselves. But I personally don't see a need for most customers now that we can internationalize.

I think we can deliver internationally. But we first have to serve the customers that we have in the DACH region in the best possible way. And it won't help them if we hire 50 sales people in the USA. So it's always a step-by-step process. And I'd rather have one satisfied customer than another three projects in the pipeline in China or the USA. We are perhaps a bit more cautious in our expansion, but we have also seen that many companies have made a big mistake and burned a lot of money. And we simply don't want that, because we don't think it makes sense for customers. But as I said at the beginning, this very European footprint, this DACH footprint, will probably have changed significantly in five years. The reason is simply that there are a lot of companies around the world that have a U.S. focus, a China focus, an India focus, and of course we have to deal with them because there aren't that many enterprise providers in the commerce sector that are even capable of helping to shape such complex projects. And then.

Jan Stöckel: Yes, I can briefly add to that, Alex, that is of course, as you say, driven a lot by the B2B companies, also is, with which we work. That is, we really also drive two companies, one wants to start a MWP probably in South Africa. Another one that we're just-, that we're in dialogue with right now and development is going to start now, we're in the discovery phase right now, they're going to build their MWP in China. That means that there, too, the footprint will of course increase enormously through the customers alone. And at the moment we don't have any challenges in the direction of the technology in the markets, but rather look at what customer characteristics or special features there are in the markets on the part of the consumers or the end users, what special features do they have that we fall back on. So, especially in the Asian sector, user guidance is a bit different, the expectations are different. And that is, remains exciting. I don't think technology is the decisive factor here, but rather understanding the users in the different markets and addressing them.

Alexander Graf: So, if you've enjoyed this so far, you can book us. Now Jan and I have two slides here, if we are to present the various myths to your software company, I can highly recommend it. Talk to Jan, he has studied this, he has been working in the industry for a long time. He has seen it all, he has heard every myth about our competitors and can probably help you. Of course, I'm a bit biased, even though it's absolutely clear that we are the leading technology provider, so to speak. But we have agencies and partners who can evaluate this a bit more from a distance and help you there as well. And I really hope you've enjoyed this so far. I would like to wait one more minute, minute of silence, maybe there will be one or two questions in the chat. And thank you already to all viewers and listeners. So, now I have to see how I can finish this, the sharing of the screen.

Angela Meyer: I'll just take over the screen here.

Alexander Graf: Ah yes, good. Maybe that's better.