Middleware, Not Isolated Solutions – How Paul Horn & soffico Connect Legacy and Modern Systems

In many companies, the effort required for connectivity and engineering is increasing—driven by the growing volume of data that needs to be collected from an ever-expanding number of sources. These include machines and sensors from the OT world, as well as various IT and IIoT systems.

Often, this data is locked away in silos and must be integrated in a way that enables more efficient processes and data-driven decision-making.

That’s exactly the challenge tackled by Paul Horn GmbH – successfully so, as recognized with the VDMA Award. In this episode, we’re asking: How did Paul Horn approach this issue? What are the key considerations for implementation? How can standards and software templates be established? And how do you calculate a business case for middleware integrations?
To dive into this topic, I’m speaking today with André Hoettgen, Head of Enterprise at Paul Horn.
Also joining us is Sarah Blomeier, IT Sales Manager at the integration partner soffico—the company behind the solution we’re talking about today.
I’m excited—let’s head to the podcast studio!

As always, you can find all the details on implementation at www.iotusecase.com. Let’s go.

Hello and welcome! Hi Sarah, hi André!
Sarah, how are you? Where are you joining us from today? Where are you joining us from?

Sarah

Hi Madeleine! I’m doing great. I’m calling in from our office in Augsburg. I just grabbed a coffee—so the best ideas are ready to flow. I’m ready!

Und André, where are you right now? How are you doing?

André

Hello Sarah, hello Madeleine, thanks for having me! I’m working from home in Eschweiler, which is between Aachen and Cologne. I’m currently looking enviously at the sunshine outside—but I’m really looking forward to our discussion about digitalization and future topics.

Sounds good! I just checked—you’re based south of Stuttgart, right?

André

Exactly. Tübingen is a small town, but right in the heart of Swabia, surrounded by industry. We’ve been based there since our company was founded and are deeply rooted in the region.

Before we jump into introductions, a quick question up front: I mentioned it in the intro—you won a VDMA Award with Paul Horn. What’s the story behind that? Did you apply for it, or can you share a bit of behind-the-scenes?

André

Absolutely. By now, we’ve actually won two awards—from Allianz Industrie 4.0 Baden-Württemberg, which is part of the VDMA.

In 2023, we received an award for our IIoT concept: How do you build a modern IT infrastructure within a traditional manufacturing environment? What are the key considerations?

And last year, we won an award for our service platform. It allows us to track the lifecycle of specific tools—especially for our service business.

Very cool – sounds like I’ve got exactly the right guest with me today!

And those are exactly the two topics we want to dive into today.

Let’s jump right in: Paul Horn – many people know the name, but maybe there’s someone listening who hasn’t heard of you yet.

Can you briefly tell us what your core business is? And maybe give us a bit of context about your customers and products so listeners get a sense of the market you operate in?

André

Sure! Paul Horn was founded in 1969 – a real Swabian success story: it all started in a garage, then grew steadily, and went international in the 1990s. Today, our site in Tübingen is our central hub.

We specialize in manufacturing high-precision tools—with tolerances down to one-thousandth of a millimeter, so extremely precise, and often in very small batch sizes.

That’s because, from the beginning, we’ve always developed either our own products or fully customized solutions for our customers. Our process is strongly build-to-order: we get involved early in the engineering process, manufacture small lots, and deliver regularly. Today, we offer around 25,000 standard tools and over 200,000 custom solutions. That only works economically with a high degree of automation—and ours is over 97% in production.

When it comes to anything that can be machined, we’re seen as a technology leader—and we also took an early lead when it comes to digitalization. At this point, we’re considered pioneers in that space.

So that means your tools are probably used across a wide range of industries—anywhere there’s drilling, milling, or cutting. Do you have a particular focus industry?

André

No, we serve a very broad customer base. Of course, we’re very present in the automotive sector, but also in aerospace, medical technology, and many other industries.

Our customers range from large corporations to small, specialized manufacturers.

Okay, and you already touched on it earlier: we’re talking today both about your plants, where you’ve implemented data connectivity concepts, and your service platform.

Quick question on the service platform—does it allow customers to order products online or get spare parts when something wears out or needs to be reordered? So is this the area where you’re building your own service business?

André

Exactly. What service means for us is: many of our tools have a very long lifespan—but there are also some that wear out more quickly.
For high-quality tools—like ones equipped with MKD or welded tools—it’s worthwhile to refurbish them.

These tools come back to us, we restore them to their original geometry, and the customer receives a reconditioned tool—at a fraction of the cost of a new one.

So why a service platform?
It’s still in its early stages for us, but the topic of connectivity is gaining importance. You often hear: data is the new gold.

But what really matters is that this data also aligns with your overall company strategy. Just collecting data doesn’t do much—you need to make sure it contributes to a long-term goal.

What we realized early on is this: digitalization doesn’t work in isolation.

It’s not enough to digitalize a single machine or build a lighthouse project and then claim you’re digital.

Digitalization has to be holistic.

And that’s exactly what our first award recognized—our infrastructure and the approach behind it.

You hinted at it just now—what has changed in your market, and how did you adapt as Paul Horn?

What’s your vision when it comes to digitalization and data-driven operations?

André

We’re still a tooling manufacturer—and that’s not going to change. We’re not suddenly shifting our focus to digital solutions at the expense of our core competence.

Everything we do in the area of digitalization is meant to support and improve our manufacturing processes.

What we’re particularly focused on right now are the effects of demographic change. In the coming years, we’ll lose many highly qualified specialists to retirement.
So the question is: How can we offset that loss without overburdening the employees who remain?

For us, the answer lies in greater efficiency, better digital solutions, and optimized processes. That’s our overarching goal.

Before we dive into the business case behind all of this, let’s talk about your joint project: You brought the company soffico on board.

Now we’re sitting here in this three-way setup—how did that come about?

Why are the two of you here together on the podcast?

Sarah

Let me give you a quick intro to who we are, to give you some context:
We at soffico are a classic software developer based in Augsburg—and we’re a leading player in the field of data integration and processing. Our core product is our data integration platform Orchestra.

Orchestra is our flagship offering—custom software that we continuously develop further, based on the needs of our customers and partners.

You can think of Orchestra as the central hub in the IT/OT world: It bundles and orchestrates data streams across different systems, applications, and machines, enabling smooth data communication throughout.

At Paul Horn, Orchestra is integrated into the system architecture as central middleware—essentially acting as the data hub in a service-oriented architecture.
We enable seamless integration of brownfield systems, meaning existing production and IT infrastructures. That includes systems like IT, CAM, EDI, CAD, SAP—and also OT, such as production-level controllers.

Orchestra, as an integration tool, ensures that data from both worlds—IT and OT—can be captured, processed, and turned into actionable insights. This allows for informed decisions.

At Paul Horn, the tool isn’t just used as a support layer—what’s also key is the close partnership between soffico and Paul Horn.

It’s essential for us not just to provide the integration tool, but to really understand the customer’s use cases: What drives them? What are their goals? How can we support them?

That’s exactly the approach we take with Orchestra—it’s being developed further together with Paul Horn and adapted to their specific needs.

And with Paul Horn, this trusting, long-standing collaboration is particularly important to us.

We’ve been through ups and downs together, celebrated successes, and tackled challenges as a team.

That’s what defines a strong partnership for us: continuous exchange, growing together, and long-term development—as equals.

Great. I’ll come back to those best practices in a bit—many people ask me: What should you keep in mind with similar projects? What’s important during implementation?

You just gave me the perfect cue: use cases.

I’d like to put the project into context, to give listeners a better understanding of the bigger picture.

What I’ve gathered so far is this: On one hand, it’s about manufacturing—so the networking of data—and on the other, it’s about making that data from OT and IT usable in other cloud systems as well.

If I understood correctly, the first step is about technical implementation—specifically the middleware that gets integrated into the IT architecture.

Is that right, André?

André

Yes, exactly. For context: Starting in 2018, we began seriously considering how a modern IT architecture could address the challenges of a traditional manufacturing environment.

We have many existing systems—machines, ERP systems—that have been in place for decades. This legacy infrastructure isn’t something we want to just replace. That might be wishful thinking for some, but for us it’s completely unrealistic.

That’s why our goal was to continue using those systems—and the best way to do that is through a middleware architecture.

Some keywords here are: Enterprise Service Bus, or when applied to OT, Manufacturing Service Bus, and moving away from the classic automation pyramid.
In the first step, we implemented the concept as a prototype.
Together with soffico, we then decided to move forward with Orchestra.

And when it comes to the actual use case or project goal—well, that’s not easy to sum up in just one sentence…

Right—that’s often the big question: What comes first?

The business use case—for example, spare parts reordering via a service cloud?

Or the initial step of connecting legacy systems and integrating the data?

I just wanted to briefly provide some context.

André

Yes, that was definitely a key topic for us. On the one hand, we made a conscious decision to implement everything on-premises—meaning no cloud solutions for our digitalization efforts. That, of course, requires partners who are willing to go down that path with you—which isn’t a given anymore today.

On the other hand, we didn’t want to launch one massive project that takes ten years and is called “Digitalization of Manufacturing.”

Realistically, digitalization consists of many small projects and specific use cases that are implemented step by step.

When we connect systems, we’re laying a critical foundation.

You can think of it like urban planning: You build a road to connect places—not to define from the outset who’s allowed to use it.
We apply the same thinking to our IT infrastructure in manufacturing: We enable connectivity, create flexibility—and by doing so, we invest in a future-readiness that strengthens us as a company in the long term.

Exactly. I think the focus today is on the technical connectivity and the scalability of the system.

But do you have an example of a use case you’ve already implemented—or are planning to implement?

I’m thinking of something like spare parts reordering—that would be the ultimate goal based on data. But maybe there are simpler use cases in manufacturing? Do you have an example that makes it a bit more tangible?

André

Sure—one example is our service platform. When tools come back to us for refurbishment, they’re assessed individually. Only then can we send the customer a confirmation—because we first need to check what can actually be repaired.

Previously, this was a manual process: The assessment was done, then everything was passed to another department and entered into the ERP system (SAP). That used to take a lot of time.

Now, the whole process runs much more efficiently thanks to our digital infrastructure:
The inspection is carried out in a web application, the data is automatically transferred to SAP, and the backend processes continue fully automatically.
Sure, we might only save 1–3 minutes per job—but with the number of orders we handle, it really adds up.

We handle around 75,000 manufacturing orders per year—of course, not all of them are service-related.

But even if we save a few minutes on 2,000–3,000 of those, the impact is significant.

It’s exactly these small optimizations that matter—because in the long run, they make a big difference.

Exactly – and we’ll take a closer look at how that works in just a moment.

But first, I’d like to dive a bit deeper into the technology.
Sarah mentioned earlier that you’ve built a centralized data platform. So we’re talking about capturing thousands of parameters—from control systems, ERP, SAP—whether it’s for the use case you just mentioned or for others down the line.
What I’d like to understand is the business case behind all this:
In the end, you’re investing in technology and a new IT infrastructure. Did you evaluate this from a financial perspective? Are there KPIs you use to measure the value?

Here’s an example from our community: Schaeffler did a cost analysis for machine connectivity—where connecting a single machine started at around €3,000, largely due to high engineering effort.
Have you done a similar business case calculation on your side?
If you’re able to share some insight, that would be incredibly valuable.

André

Yes, you can definitely say that – I can also confirm the connectivity costs.
That said, we implemented a lot of things in-house and didn’t buy everything externally. It was important to us to build and retain this expertise internally for the long term.
Of course, that meant a larger upfront investment.

But why did we go ahead with it anyway?

We wanted to lay the groundwork early on—for example, enabling machine connectivity so we can collect and access machine parameters in the future.
And it was also clear: if we had to launch a separate project every time we bought a new machine—with external service providers or machine manufacturers—that wouldn’t be efficient or scalable.

That’s why we looked for a standardized solution—including for modernizing legacy machines so they could be connected in the first place.

So for us, the real business case lies in the ability to connect.

On one hand, this helps us meet our high IT security standards—because we need secure interfaces between the machines and higher-level systems.

On the other hand, our production environment is already highly connected. Now it’s about continuing to develop that connectivity in a future-ready way.
Here’s one example: Our long-term goal is to be able to transfer NC code directly from engineering to the machines—and we have around 250 machines in operation.

That only works if those machines are securely connected.

We’re also running ongoing research projects, for example to reduce setup times.

If we want to analyze that data centrally and automatically send code to machines, then connectivity is the foundation we need.

Before we jump into the implementation details, let me just highlight something:

You’re also talking about standardized data acquisition, right?

You just mentioned the keyword “standard.”

So the goal isn’t to treat each machine as a separate project and reinvent the wheel every time, but instead to create a centralized data foundation.

That way, for any new use case—whether now or in the future—you can simply build on the data that’s already connected.

In other words, your use cases are all based on a common standard.

Did I understand that correctly?

André

Exactly—and not just when it comes to the data itself, but also the surrounding infrastructure, which often gets overlooked.

When it comes to data, we started working with standards like OPC UA and others very early on and implemented them.

But we also standardized the entire infrastructure:

Every machine network is built the same way.

How we handle remote maintenance, how our IT manages machine security—all of that follows defined standards.
And with our scale, that’s absolutely essential:

In Germany alone, we have 250–300 machines, and around 600 systems worldwide.

The IT operations behind that are massive—and standardization helps us keep it manageable.

Totally makes sense—and that’s just on the OT side.

On top of that, you also have plenty of IT systems in place.

Just looking at your service area, for example—you’re using SAP, which comes with additional interfaces that need to be managed as well.

André

That’s where the middleware comes into play. It enables the level of connectivity we need.

Very often, it’s about transferring data from one domain to another—and in that process, formats or languages might change.

So it really helps if you’re familiar with the data models, and if those models are standardized on both ends.

That way, you can build efficient mapping—ideally something that’s generic and intelligent in structure.

This makes many things much easier.

And that brings us directly to the topic of mapping.
But before we go there, one last question: Why did you choose to work with soffico?
You could have done all of this in-house, with your own software team.
What tipped the scale for you in favor of this partnership? And what was important to you in making that decision?

André

That was a classic make-or-buy decision.
Sure, in theory you can do everything yourself—but do you really want to?

Our core competency is in manufacturing precision tools—not developing middleware.

So for us, it was clear: We’ll focus on what we do best.

And when you develop software, you don’t just need the right staff and know-how—you also benefit from exchanging ideas with other companies, bringing in new perspectives. That’s often how truly great things are created.

That’s why we made a conscious decision to enter into a long-term partnership with soffico—not just a one-off project, but an ongoing, strategic collaboration.

Sarah, I have to follow up with a question for you here:

You support many different projects and customers—could you share your perspective on the whole make-or-buy topic?

Why do companies tend to go the external route instead of developing such solutions in-house?

I see both sides—some do everything themselves, others buy selectively.

Based on your experience, what does it take to implement projects like this successfully in-house?

And from what you’ve seen, what are the main reasons companies ultimately decide to go with an external solution?

Sarah

Basically, you’re right – our use cases are extremely diverse.
The actual technical connectivity part is often relatively straightforward. But the underlying systems vary widely.

We work with companies in process manufacturing and discrete manufacturing—like Paul Horn—but also with customers from service-oriented industries like e-commerce, banking, insurance, or logistics.

That means a huge variety of use cases and system landscapes.

What’s especially important for companies in these kinds of projects is this: They’re not just looking for a data integration tool or middleware. They’re looking for a partner who will support them from the very beginning—from the initial idea and concept all the way to the final interface and implementation.
They want someone who’s accessible, engaged, and not just delivering a project and disappearing afterward—but instead committing to long-term collaboration. That’s exactly the approach we take—also in our work with Paul Horn.

We’re not here for a one-hit wonder.

We start with one use case, at one site, and then scale it out.

The focus is always on long-term, collaborative partnership where companies benefit continuously from our expertise.

That’s something many of our customers value—not just our strength in data integration, but also the supporting services, from technical implementation to ongoing strategic support.

Let me pick up right there: We already touched on data mapping earlier—which isn’t just relevant for Paul Horn, but for many companies.

Especially when it comes to handling interfaces, there’s a massive effort involved.

Creating those mappings in the first place—and ideally doing so in a standardized way—seems like a real challenge.

You’ve already solved that on your side, right?

Sarah

Yes, exactly. As André mentioned earlier: What’s important for many companies—like Paul Horn—is the ability to work with generic templates.

So instead of building a custom solution for every new use case, the goal is to reduce effort through reusability.

In our platform Orchestra, we offer a wide range of adapters and connectors—for both standardized and custom interfaces in the IT-OT integration space.

Whether it’s SAP, IT systems, or OT systems—we have connectors for almost any scenario.

Our goal is to keep everything as generic as possible.

This allows us to connect different systems in different environments without having to start from scratch every time.

The foundation of this is what we call channels—these are connectors that communicate with systems via specific protocols.
On this basis, we can create generic templates that can be rolled out across multiple business units or sites.

Many customers really appreciate this approach—especially because we also follow a low-code philosophy.

That means: orchestration, mapping, and similar tasks can be set up in just a few minutes—with no deep IT expertise required.

Very exciting! And if you’re listening right now and thinking, “This is exactly the challenge we’re facing”—I’ll be happy to include your LinkedIn profiles in the show notes, if that works for both of you.

That way, people can reach out to you directly to exchange best practices or discuss the concrete implementation.

And André—perhaps one last question for you:

Which connectors are you using specifically?

And how have you integrated them into your IT infrastructure?

André

That really depends on the specific use case and the department involved. In the administrative areas, it’s often the usual suspects: connections to databases or ERP systems like SAP in various configurations.

Something we frequently do—as Sarah already mentioned—is to build a service-oriented architecture.

That helps us reduce complexity by encapsulating processes behind web services.

In production, it’s often more traditional: sometimes we simply move files from A to B.
Or we use specialized connectors—particularly for control systems, for example with OPC UA.

Right, and earlier you mentioned an example—I think it was in the context of MKD tools—where you assess whether refurbishing a tool in the service department is worthwhile.

In that case, you’d typically connect SAP, right?

That use case isn’t directly tied to production.

André

Exactly, that falls under the administrative side.

We want to automate administrative tasks and reduce the workload—so it’s more about horizontal integration within administration.

And in that case, you’d check whether Orchestra already offers a connector to implement that integration?

André

Exactly. In general, here’s how it works for us: We start with an idea—a kind of ideal vision of how we’d like the implementation to look.

Quite often, we’re able to develop a first internal prototype ourselves, because by now we have solid in-house knowledge of Orchestra.

We know the tool and how to use it.

Then we coordinate with the consultants at soffico early on.

As soon as the requirements and interfaces are clearly defined—meaning we know which data needs to flow where—we hand the implementation over to the specialists at soffico.

The big advantage is: they build us a stable and reliable solution.

You just said: “You have to know the interfaces”—that’s definitely a key topic.

And I promised we’d share a few best practices.

You mentioned earlier that there were ups and downs in the project—experiences you learned from.

What should others watch out for when implementing such a project?

Do you have some final tips or lessons learned to share—things that might save others a second iteration?

Maybe the two of you could share a bit of behind-the-scenes insight?

André

Absolutely. One thing we’ve learned over time: this is a very interdisciplinary topic.

You need people on one side who deeply understand the operational processes—ideally with a company-wide or group-wide perspective.

On the other side, you need technicians, engineers, and software developers who can turn those requirements into a working solution.

Our key takeaway: Get involved in these projects early on, and make sure that the discussions are conducted from a holistic perspective—but also broken down in a way that makes them technically feasible.

That’s also how our team with soffico evolved.

As Sarah already said—there were highs and lows. But that’s what makes a strong partnership: open communication and a shared commitment to finding solutions.

By now, we have a team that can deliver exactly that.

We bring in our internal experts—they know exactly what we’re trying to achieve and where we want to go.

And they probably also know your interfaces for the respective use cases, right?

André

Exactly. They know our systems, our interfaces—and on our side, we have the technical contacts who can say: “Yes, that’s doable,” or “We need to lay some groundwork first.”

Sarah, maybe you could add something here—especially with regard to interface management. André, you just mentioned this, and I’d be curious to hear if you can share any best practices from other projects.

Especially when companies are building an IIoT concept or a modern IT infrastructure—what should they particularly keep in mind from your perspective?

André

Yes, definitely. We’ve been working on this topic for a long time—this was a conscious, strategic decision. As a company, you need to make a clear choice about whether or not you want to go down this path.

The reason it’s working so well for us now is that we did our homework. The middleware is just one part of it—we also clarified all the fundamentals, for example how we even connect a single machine and get the data into the data center.
We already have functioning solutions for that.

A lot of other companies are just starting at that point.

And if you approach the whole thing as an isolated lighthouse project, it becomes difficult to define business cases or to clearly quantify the return on investment.
My tip for everyone facing similar challenges: Set up a solid, overarching architecture.

Think early on about how the overall system should work in production—that’s the foundation for everything else.

Sarah, what about you? You’ve supported many different projects and worked with a wide range of customers—what are some additional takeaways from your perspective?

Sarah

What’s most important is not to try to do everything at once—or to go into the project with that kind of expectation.

Instead, it’s better to think about how to create the greatest possible value with the least effort—so the project can become a self-sustaining success in the long run.

In my view—and based on many projects—one key factor is to think things through beforehand:
What are my actual requirements? What should the architecture fundamentally look like?

There will always be changes: systems will disappear, others will be added—that’s completely normal.

You need to stay flexible, but also have a clear overview of your system landscape, and you should know what your target processes are.
If you have that clarity, you can get started right away—and that’s exactly how many of our customers do it.

We usually don’t start with a big bang, but with pilot projects or smaller use cases that are then scaled step by step.

And what’s especially important to me—especially in the collaboration with Paul Horn:
We don’t just look at the project—we look at the team behind it.

At soffico, we work closely with the customer—as equals and as partners.

Yes, that’s really a very important point.

And with that, an open invitation to everyone listening:
If you’re interested in these topics, feel free to reach out directly to Sarah or André.

You’ll find their contact details in the show notes.

I’d also like to invite you to join our community. That’s exactly where we discuss questions like these:

How can digitalization be scaled effectively? What solutions are others already using successfully? And which standards support this process?

I’ll include the community link in the show notes—we’d love to have you join the conversation!

Maybe one last question to wrap up: There’s a lot happening in the field of artificial intelligence right now. Are there already approaches or ideas on your side for what might emerge toward 2030?

What are you currently working on, and where do you see trends or potential—either within your company or in the industry in general?

André

It feels like we’re still just at the beginning when it comes to digitalization.
One of our main goals for the coming decade is to counteract demographic change—primarily through efficiency gains and reduction of administrative tasks.

Artificial intelligence will definitely play an important role—even if it’s not a silver bullet.

We’re currently involved in several research projects and are testing concrete approaches.

I don’t want to give too much away just yet, but if I may do a little advertising:

From May 14 to 16, 2025, our HORN Technology Days will take place—and these are exactly the topics we’ll be presenting there.

Perfect—I’ll make sure to include that date in the show notes.

If you’re listening right now: May 14–16, 2025.

And if you’re tuning in later—no worries, there will surely be other opportunities to check it out in person.

Sarah, one final question for you as well: What’s happening on your side? Which new features are you working on—especially regarding AI? And how is Orchestra developing as a product?

Sarah

There’s definitely a lot in the pipeline—it’s going to be a really exciting time over the next few years.

One highlight we’re about to launch is our new AI assistant, which is available with the latest version of Orchestra.

It supports users directly in the Orchestra Designer—our development environment where data mappings and integration scenarios are created.

The assistant is based on a generative AI model and helps make processes faster, more intuitive, and significantly easier.

It’s integrated as a chat function, and we’re already seeing that many customers and partners are benefiting from it—it really makes working with the Designer much easier.

Of course, AI is a broad term. This is just the beginning—but with the AI assistant, we’re laying the groundwork.

Many more features in the areas of AI and digitalization are already in the planning stage.

Very exciting! If I understood correctly, it’s about suggestions for mappings—like recommendations based on existing templates.

So you’re using AI to make mapping significantly easier. That’s really cool!

Sarah

Exactly, that’s correct. We’re moving away from a purely manual approach. Mappings were already possible in a graphical interface—but now, through the assistant’s chat, users can simply describe where they want the data to be written.

From that, a communication scenario is created automatically—in the form of a process model—including the corresponding data mapping, based on existing message types.

This not only makes the work significantly faster, but also much more intuitive.

Very interesting—sounds really exciting and like a real step toward scalability.

If you’re listening right now: feel free to check out soffico’s website at soffico.de—you’ll find more information there.
Of course, I still have lots of questions—but for today, we’ll wrap up this session.

A big thank you to both of you—we really got a clear understanding today of where things stand at Paul Horn, how you’re positioning yourselves in the market, what your IoT concept and service platform are all about—and above all, how relevant the business case behind it is.

We talked about technical implementation, shared best practices, and even touched on challenges around mapping.

From my side: a huge thank you for taking the time—it was super insightful!

And with that, I’d love to give you the final word.

Sarah

I can only return the thanks—thank you so much, Madeleine, and also thank you, André.

I really enjoyed this conversation!

André

Same here—thank you so much for the invitation!

Thank you, Sarah, thank you, Madeleine—it was a great discussion.

Looking forward to next time!

Take care—have a great week, bye!

Sarah

See you soon!

André

Bye!