We are Jessi and Martin from dotSource. As mentioned, German Agency. So a few sorry's before you start. Sorry for our bad English. And I know that Geberit is here. So yeah. Sorry, guys, for the presentation. Maybe next year. Who knows? Great. Okay. And today we want to take you a little beyond integrations. We don't just want to plug systems together, but we built a content commerce strategy that truly serves our customer and the brand. So this is about the content commerce strategy for Delray of War. I'll take you very quickly through the agenda. We have to talk about a little bit about us. They forced us. Then we talk about the challenge at the customer. Then the plan we had, we thought that would be the plan. And then the actual journey we took. So yeah. So yeah. So yeah. So yeah. So yeah. German agency. We see ourselves as specialists in digital strategy and technology projects. For more than 20 years now, we've helped companies design, build and evolve a digital business. We accompany our clients on every step of their way from the start of their digital journey through ideation, strategic planning, tool selection, implementation, maintenance, and ongoing development and training. Our work spans nearly all service areas around sales, service, and marketing like e-commerce data, process and change management, cloud services, cloud services, sorry, AI, and of course content commerce and digital experience management. Our teams collaborate across our disciplines. So we share technical expertise and industry knowledge to support customers across their entire digital landscape. Many of those customers become long-term partners and they are working with us in multiple areas. So at the moment we are around 450 people strong and we have six office locations in Europe. So if you're nearby, come visit us for a coffee in Jena, Berlin, Leipzig, Dresden, Stuttgart, and Rijeka in Croatia. Our main market is the DACH region, but we work with international clients across the Globe. One of those clients. And our longstanding partners is the reason why we're here today is the reason why we're here today, Villeroy & Boch. So Villeroy & Boch is a premium ceramic brand from Germany. The company was founded in 1748 and it's one of the world's oldest ceramic manufacturers. The company focuses on three main areas. The first is dining and lifestyle. This includes the tableware, the cutlery, and gift items. The second is bathroom and wellness. Here we can find, um, Carabay sanitary ware, baths, and wellness solutions. And the third is all around living such as furniture and decoration. And the third one is a special case because the products are not directly made by Villeroy & Boch, but they support and complete the product rate so that the customers can purchase everything they need on one platform. So the client has had a major challenge. The brands had to build the bridge between traditional hand crafting and modern digital customer experience. The client reached out to us in 2017 to help choose an e-commerce platform. Since then, we've supported them throughout the e -commerce and digital experience journey. In 2023, we kicked off the initiative we're going to talk about today. And to add to wonder the detail that you can keep in mind, this was before the AI breakthrough. So it was a long, hard and handmade process. No prompting, no vibe coding. So, um, will probably feel like a history lesson in the next few minutes. So let's talk about the challenge. The brand Villeroy & Boch was split in two different worlds. On one side, there were content websites, like more than 30 consumer sites, full of inspiration and advisory content, serving three divisions and more than 12 languages. On the other side, there were 60 online shops for the dining and lifestyle division, built on Salesforce, Commerce, Cloud, Storefront, Reference, Architecture Foundation. So solid shops with standard functionality, but largely separate from the content world. The content sites list on an aging type of re-platform. They weren't future-proof. Content updates took too long. Editors marked flexibility, and the three divisions didn't even look and feel like the same brand. So they couldn't create one coherent customer journey. The websites and the shops needed to converge, but technically the options were limited. To give you one example, users could jump from a content page into the shop, but they couldn't navigate back to the corporate site. That's not a journey that's like more like a dead end. Widow and Boch also conducted user tests, which confirmed what the data hinted at. There was significant potential to improve navigation, content quality, and the overall experience. And there's one more layer. Widow and Boch operates in two different models, B2C for dining and lifestyle, and B2B2C for bath and wellers. Their target groups have distinct needs and very different expectations around inspiration, interaction, and transactions. Yet the brand must speak with one voice. And the company wants to benefit from the efficiencies that come from harmonized communication. So the question comes, how do you respect different journeys while creating one brand experience? Oh, that was just sad. I think you get a hand out of those. So we focused on three levels. First, technology. A holistic platform strategy. The goal was a unified technical foundation that becomes the base for all future development. Not a big bang in platforming for its own sake, but a composable approach. Let the shop do what shops do best. Let content systems handle rich storytelling. And connect them through clean APIs and shared services like design, identity, search, and analytics. That way you can scale new capabilities without breaking the core. Second, structure. Clear user-centered navigation. We needed to make the journey needs-based. Start from the tasks people are trying to complete. Inspiration, configuration, product discovery, service, purchase, and repeat. That required a global information architecture, a persistent header and footer across sites, and a taxonomy that works for all three divisions in all target markets. The outcome we aimed for? You always know where you are, and you can always get way better. Third, user experience and content. Enhanced content. Better content quality, rated design flexibility, and a consistent brand experience. Practically, that means a modern component by a shared design system, reusable content models, and translation workflows that make publishing in 12-plus languages fast and reliable. Editors get freedom to tell stories. The brand team gets control to keep everything coherent. So we tried to not promising magic through yet another integration. We were focusing on aligned tech, structure and content, so they reinforce one another. And with Willa Berman Buff's vision on an aligned shop and corporates website, we launched the ShopRite project. We wanted to talk a little bit more about this. Thank you, Jesse, for working through the historical growth landscape. The important one, the name, ShopRite, a combination of Shop and Corporate, and that's saying exactly what the vision was. We wanted to do a lot of combining the different business units, put every corporate content together with the eShop content to one single platform. So that we have a seamless transition from information and inspiration to transaction and conversion. And technically, that means, two years ago, we called this Composible Storefront a decoupled frontend based on Commerce Cloud. And of course, we started to think about some challenges and make the plan. Of course, there was a lot of stuff to consider. Sales for us, we have to set up catalogs, a cool infrastructure. We have an external search. Everything has to be considered. But especially for Magnolia, we had three topics. We think about it. The first one was connecting everything together. And here, yeah, we wanted to start with the headless Magnolia Accelerator. And yeah, take it for a little run both. Yeah, of course. This is an accelerator. I think everybody should know this is a good starting point. You see things how they could do the things you want. But in a project, you have to adapt this and have to find your own way. But this is not a project work. The second one was the content model. This is also a project work in my opinion. You try your best not to make mistakes from the project before. Develop a very cool content model so that the editor was happy. And you always have this trait of editor gore and the most flexibility. Yeah, want to arrange stuff, want to configure background colors, want to configure fun colors and so on. And on the outside, everything should automatically look good and in line to the corporate design. But normal project work today, we have a look at this commerce integration. And in my opinion, we have always two questions here. How can we enrich Magnolia content pages with commerce elements like products or categories? And the other side, how can we enrich commerce-driven pages like product keep your page or category pages with Mark Werner funded? And we want to do both in a way. That's simple and clear for editors. Yeah. So. Our plan to go with the Salesforce Magnolia accelerator. This is a typically a picture where you divide the or split the sides into parts from Magnolia, parts from Salesforce. And yeah, the idea of this accelerator was easy. You have components with, uh, uh, I click to my, uh, to, uh, and if you did the door, uh, this component, something that have to do with something with, uh, commerce. Then a dialogue pick, uh, goes up, uh, where you select the catalog, uh, drill down the category structure. I get a list of products and, uh, select one product. And yeah. Uh, then you have a reference in, uh, the CMS and then the decoupled front end, uh, do the magic. And yeah, you have product information or product list days. So that was the plan. And now the journey, um, yeah. And yeah. And as often the pen looks great on the paper and, uh, then the implementation starts. And for the first topic, yeah, we delivered the first components, um, with this, uh, dialogue presented to the customer and the customer said, Yes, okay. And, uh, yeah, okay. It's not so good. Uh, and so we, we asked, uh, what, what's the problem with this, um, a dialogue with this picker? Yeah. And, uh, we learned that the coordinators are not product managers. They don't have knowledge about the category structure. Um, yeah. And, and they need a simpler way, uh, to pick products. Uh, they told us, yeah, our breathing list. We get the product, the SKU, uh, we get, uh, especially the content, uh, for this product places on the, um, landing page. And that's all breathing and that must, uh, yeah, go in the easy way. And so we think about this and, um, yeah, luckily Magnolia offers here a very, very great tool. The so-known, uh, JavaScript UI modules and build up our own, um, product digger. And this JavaScript UI module allows us to implement small web ads directly in the dialog of, uh, Magnolia. And you can connect every external internet you want, a content you print. And, uh, what you hear, see this exactly this, this product ticker. Um, we start, uh, select the product slider. Then we have here a small, uh, yeah, widget, uh, a free text search where editor can, uh, insert an SKU or the title of product. Then, uh, a loading bar, uh, that something happens. Um, yeah. And, uh, after that, uh, suggestions where you can see, okay, uh, you found something, uh, get additional information about the products. Um, and it's a very easy way, uh, for the editors to, to, yeah, connect, um, content, Magnolia content with, um, with commerce content. And we built this pickers, uh, uh, for products, for product lists, for categories, also for, uh, Einstein recommender, uh, selections. Um, yeah. And that was our solution. Um, we have to connect, uh, Magnolia content with commerce content. Mm. And one thing, if you integrate commerce content with CMS components, um, you automatically unlock, uh, all the cool Magnolia additional features we have. Uh, so we have fully the possibility, um, to, uh, yeah, uh, create variants and make those analizations on, uh, on maybe products later. Yeah. Um, because, um, yeah. Um, yeah. Magnolia acts as orchestration frame. Yeah. Uh, you define the Magnolia page layout, um, the, uh, placements, the authorization rules. Yeah. And this is Magnolia stuff and the commerce stuff, uh, comes, uh, from the API. And so it's possible that you can place a product slider on the start page, uh, for anonymous users, maybe you, uh, place the top sellers and for like in users, you play out, um, let's say, um, um, yeah, tiny lifestyle products. Um, that's my big easy one. Um, the other side is enhancing category and product detail pages with additional content. And again, um, yeah. Magnolia also provide in the accelerator, a solution, the so-called, I think, Google most category thing. Um, and the idea how we this understand was synchronized the categories with the IDs into Magnolia. Then enrich these, um, categories with additional fields. And, uh, play it out via rest ATI and yeah. And which your, uh, commerce, uh, sites, uh, with these information. Um, and again, um, we prevent this and was also, it's okay. Um, because problem was, um, Salesforce itself already offers a solid way to extend category and product models with additional fields. And so again, we ask, what's the problem? And yeah, the editors, uh, of Willer & Boch, uh, want full editorial, uh, editorial power of Magnolia. Uh, the same experience as a normal page. Yeah. They want to have all content, uh, components, uh, on such pages. And yeah, so we had to rethink, uh, our approach and ask ourselves, um, how can we make every category, uh, behave like a normal page? Yeah. Uh, make it to a normal page. And the only challenge is how you look into Magnolia, uh, and, um, uh, and, um, yeah, get the correct, uh, category page, um, for this category you'll get from Salesforce. And, um, yeah, um, so we analyzed this category structure of, uh, Willer & Boch. It up a clever hierarchy in the Magnolia pages tab, uh, that met two requirements. The decoupled front end can find the correct page based on the Salesforce catalog structure. And the editors do not lose the overview in the pages app. And so, um, with some fallback strategies, it's possible for the content editors to maintain, um, yeah, content rich, uh, category pages, uh, here on the right side. So, um, this stuff here comes from Magnolia, everything here. We have the normal product listing, uh, from Salesforce and, uh, we low here additional content, uh, from Magnolia. And this is possible for every 200 category pages. Nobody in time to allow the original riches. Um, then in, in second example of in category pages, um, the editors also want, uh, to all content on category pages. That's an example here. Um, we make it, uh, we made it possible that an editor can configure on a category page in Magnolia. that the product listing from Salesforce, uh, should not be available. Um, so this is a full, uh, Magnolia, um, sorry. Full Magnolia, uh, etate category page. What's that? Uh, yeah. Yeah. Yeah. Sorry. Uh, full content, uh, and after a click on a special button, the normal, um, product listing, uh, came up. Yeah. Okay. On the page, right. And at the end, the same approach for product as for category, a clever here and here, and in theory, it's possible, uh, to maintain for every product, a single, um, product detail page with a special content, uh, for this product. Yeah. And here we have additional, uh, use the, uh, uh, Magnolia quoted inheritance and also the presentation and variant, variants framework. Um, so we can, uh, build up the variants for, yeah, special SKUs for special master product IDs, or, uh, let's say products who are assigned, uh, to a category. Uh, yeah. Uh, at the end, um, to sum it up. Hmm. We have implemented both scenarios, um, tailored to Biller and Bach. Content pages enriched with commerce elements, uh, commerce screen pages enriched with rich personalized content. Um, digital teams now have a flexible toolkit to manage content. Um, we did end up using the Salesforce Magnolia Accelerate. Accelerate, Accelerator and exactly the way, uh, we initially planned, uh, but it was a good starting point instead. But instead, uh, we found the best solution, uh, for Biller and Bach in combining other Magnolia standard features like, yeah, prospect UI modules, rest client modules, content inheritance, variants and personalizations. Yeah. Yeah. Like we say today, Magnolia offers a lot of stuff. Um, yeah. Yeah. Have a look at this and think about it to use it for it. That's it from my side. Jessi? Aus Glück. Thanks guys. Thank you both very much. It's such an interesting journey, been the Villeroy and Boch. And, uh, yeah, it's really great to see the flexibility you've managed to give them. But on that though, just look out to the cart. Do you have any questions? The lovely Jessica and Martin. Oh, we've got one in there. Over there if that's alright? Yeah. Thank you. Uh, just a question, uh, regarding the connection between, uh, Adneria and Salesforce, from Earth. And how do you have all, uh, changes, uh, divisions in the categories, uh, gracefully, Adneria, in the, uh, changes in the KPI or? I mean, in the, uh, categories, uh, the, uh, categories you showed. Yeah. We, we reference categories only via ID. Yeah. And the change in the categories structure should not make a problem. Okay. Uh, and so only with the ID, uh, the decoupled front end have to look up in the comma system, uh, and yeah, get the correct, uh, category and stuff. And if it's missing or is it, it was, uh, deleted, then it's a manual task for the content editor. Yeah. The decoupled front end must, uh, yeah, note or notice this and I have to read it, uh, like maybe, uh, fallbacks or something in this. Um, did the ID is maybe, uh, if you think about this product slider as a product is missing, then you, uh, let them out in slider. There's a category is missing. You let them out as teasers or what else. Yeah. Maybe this is a solution, but you have to think about it. Yeah. Uh, that's of course, this is a change. Is that an answer to the, the, the, maybe a virtual URI nothing or something? Yeah. So if, if the name of the product is a change, then. No, this is a Salesforce given. Salesforce, uh, decided which URI ref for the category curve. And so we asked first to look up, uh, and our Salesforce list. What is this? Is this the category or call up? And then we determine what to do. Yeah. Okay. Thanks. Thank you for the question. Thank you for the answer.