Alright. Good morning, good afternoon, good evening, wherever you might be. Thank you so much for being able to join our webinar today.

From three weeks to three months, how Zuora smashed its integration constraints.

My name is Michael Douglas. I'm a senior product marketing manager here at Tray, and I'm joined by Mark Gill, a senior IT director at Zuora. Hey, Mark. How are you doing? Great.

How are you doing today? Thanks for having me.

Oh, doing great. Thank you so much for being able to, to join us today, and thank you for everybody out there for giving us the time out of your day to join this webinar. But I think it's gonna be well worth your while, and we've got a really great story for you. So, as I said, my name is Michael Douglas.

I'm with Tray. In case you don't know anything about Tray, we are an integration automation platform, and we're built on our universal automation cloud. And, basically, that means we allow organizations to automate their business processes and workflows as well as allowing them to integrate their disconnected and disparate systems. Right?

So we give a lot of scalability and secure, secureability to enterprises when they need to do this. And Tray really takes a modern approach to iPaaS. So iPaaS integration platform as a service, which when we say a modern approach, each core experience is really designed to meet your teams where they are. So unlike a lot of legacy iPaaS out there, which is what we're here to talk about today, we give both the developer and non developer experience through a code and low code solution.

So with that, I'm gonna just kinda move through to, a bit of a bit of background. So, with that, Mark, I'd love to get an introduction to yourself, how long you've been at Tray, your experience, and, we can move on.

Hi. Yeah. Thanks.

Yeah. So hi, everyone. My name is Mark Gill. I've been at Zuora almost three years now.

I work in IT for Zuora, and I'm responsible for a number of things, integration, security, service management, but also our integration layer, within our internal landscape.

I have previous experience in very large IT organizations, and so it was refreshing to be a part of Zuora where the team is smaller, more focused, and we're able to make a bigger difference as we implement these integration solutions. So, super excited to be here.

Awesome. Thanks so much, Mark. So just before we get started, I'd like to run through some of the things that we're gonna be talking about today with Zuora's journey. So we're gonna be going through some of first of all, an introduction to Zuora for anybody who's not familiar with Zuora, but I'm sure most of you are. Some of the key challenges that they were facing it from an integration automation perspective, the different approach or the migration that they had had taken, the solution that they ended up implementing, which, of course, is Tray, and some of the results and use cases that they ended up implementing. So we'll take some time to double click down on those. We will have a q and a section at the very end, but I would encourage anybody who has any questions along the way, please feel free to put them into the chat, and we're happy to address them at the very end.

So, Mark, you know, I'm not gonna bore the audience by trying to read off the slide of Zuora because it's great just to kinda get it straight from the horse's mouth, so to speak. So I'd love for you to give the audience a bit of a background on Zuora and the kind of the space that you guys play in.

Sure. Thanks.

Most of you have probably heard, the term subscription economy. Subscription economy is something that was created by our founder, Tinzo, who is one of the early Salesforce employees.

And it's really delivering a toolset that allows businesses to change how they sell and sell in a subscription kind of way. When you sell that way, it changes how you put pricing together, how you package your solutions, and how you account for that in your financial system. So there are a series of products that we sell, billing, revenue, collect, and some others. And, just recently in the last gosh. It's probably been ten days. We have acquired a small company called Togai, which is really gonna move us into the ability to measure and meter consumption, and really move us to the next generation of subscription economy, which we're calling total monetization. So it's a super exciting space to be in, and we think it's the future.

Oh, wow. Awesome. Congratulations on the acquisition.

Thank you.

So, Mark, as it relates to integration and automation, could you just take me back to when when you first joined Zuora and moved into this role, kind of the challenges that you were faced as it relates to, you know, your integration platform and and kind of where the team was at back then?

Yeah. When I came in three years ago, we had integrations running in many different technical solutions. We had an implementation of MuleSoft. We have AWS Lambda code running all over the place. We had a team that implemented integration comment concepts in the Apex code in our Salesforce environment.

Not and we had work auto running for a couple specific use cases.

It was distributed, inconsistently implemented, difficult to support, and you just couldn't keep track of it. And so as we started parsing the environment, we had to come to grips with, what are we gonna do with this? MuleSoft was a significant challenge because it was difficult to train people to bring them up to speed. When you needed a developer to get up to speed on MuleSoft, it took a long time, and it was a significant investment.

And our team just isn't big enough to necessitate having four or five people dedicated to keep that environment running. And so we had to figure out another way.

It was also an expensive environment because we had multiple different teams running. And this is a little bit of our own problem that we created for ourselves. We had different implementation styles. We had custom code written in different ways, not consistent, and it was overall just a landscape that was challenging.

The biggest point that I would make, in our challenge space here is because of this, people didn't think about our integration layer as a place to solve problems.

Mhmm.

And that's what we needed. It was too hard. It was, hey. If I come up with a need for the integration layer, I might get it next quarter, or it might take two quarters to implement, because it was a traditional development style. It was a design you had to do design. You had to figure it all out. You had to have a test phase.

And so it was not the place that people went to to solve problems, which was the worst part.

Right. And, you know, we've talked about before in terms of the developers that you had to hire and had to, you know, keep on staff and and and kind of their skill set. Could you kinda, like, give us a little bit of an overview of that? Because I know that was a real challenge for you guys.

Yeah. So we had a small team of developers at the time, and we sent two of them off for MuleSoft training, and it takes a long time.

And because we didn't have demand to implement MuleSoft changes or new integrations every week or every month, the training would either go stale or that investment was too much for us to bear with our small team. And so we did it. It was hard to make sure we had coverage across a development team of five or six people because the investment to train them all was significant.

Right. And if I remember correctly, the other challenge was that they could only be integration engineers. Right? Yeah. They were trained specifically in MuleSoft, and that was it. Was that correct?

Yes. Yeah. That tends to be a career choice that they make. And so we found that it was difficult to have somebody come in and say, you're gonna take care of MuleSoft along with the four other responsibilities that you have in your role.

Their training and knowledge would go stale, or it wasn't a career choice that they wanted to make.

And what impact does that have in the organization when you didn't need it right? Like, you know, you don't need integrations built every day. Right? So when you don't need those integrations built, what were those engineers then doing?

They were supporting the other tool sets that we had in our integration layer. They were managing the AWS Lambda integrations.

They were solving for other technical problems because it was our technical team. So if there was, we have a couple custom applications if we needed help in that code. So they were spreading their knowledge and skill set across multiple different technology layers, then and it wasn't a great solution for them. I think the other thing I would mention is we're a worldwide company. We're up to about fifteen hundred people.

The integrations that ran, if they ever had an issue or ever had a failure, we had to support twenty four by five at a minimum. And so you couldn't have your two technical people that sit next to each other in the same time zone be the only ones that know how the system works. So that spread across a small team also made it challenging.

Got it. And if we think about kind of you know, you said that the view in the organization was that integrations kind of went, you know, problems went when there were integrations, they sort of died. Right?

Yeah, Yeah.

Yeah. They were seen sort of as a graveyard versus, you know, problems getting solved.

How did that impact the IT organization? Kind of what was the view then of the IT organization from the outside?

Yes. Yes. Well, that we're not here to solve problems, which which you don't want that to be for your IT organization.

But it also generates shadow IT. You get teams that just try to solve for themselves because they don't wanna wait.

Yeah.

It creates a relationship with your business partner that you don't want, because they don't feel like you can solve their problems for them in a quick and efficient way.

Yeah. That makes sense. So if we wanna kinda shift to, right, you've identified that you've gotta make the change.

Right? You've got MuleSoft as your primary kind of integration layer along with a few others, and you've got these competing solutions, and it's sort of inhibiting the business from inhibiting IT from being a true business partner. Right? What was kind of your process in terms of, okay.

We know we need to make a change.

What is our approach? How do we come up with a new approach to solving a lot of these integration automation challenges?

Yeah. So the first two big variables that we put in front of us that seem really obvious in hindsight, one is I didn't wanna write custom code anymore. Mhmm. Given the size of our team, we at the time, we had a development team of six worldwide.

I didn't wanna be creating deep custom code bases that I had to maintain and keep alive, and that's actually how I perceived integrations that we built at MuleSoft because it was hard.

And so I knew that to be the case. I also knew that I needed something more cost effective, than MuleSoft was for us. We were running with if memory serves a single core, that was the smallest level that you could run on the MuleSoft platform, and it and it's it is a significant impact to our to our cost envelope.

And I knew I wanted a solution that my team could ramp up on quickly and that was leverageable across the landscape. So the idea of connectors, for example, was very compelling for us because if we have mechanisms to connect to all of these applications in our landscape, that's a huge leap forward.

I didn't mention this at the beginning, but we're almost entirely SaaS based. So we have very little on prem with the exception of our BI layer.

We need to make connections and leverage those connections for all future integrations. So there were a number of variables that we knew we wanted to attack when we started looking for solutions.

Yeah. That makes sense. So let's transition then to your move to a new development approach. So you make the strategic decision to retire MuleSoft.

Mhmm. And then you have decided that you want a modern based approach.

Kind of talk me through kind of what were the hurdles you went through. Like, what were the core challenges in that transition in development?

Yeah.

One of the first things we did was we asked a couple of the developers on our team to get into Tray and get into, you know, other workflow choices to get oriented around, hey. This is a different way to build things.

Can you go hop in, do some proof of concept work, and understand what this means to your workflow and how you deliver solutions? And so we spent a couple weeks having the team do that. At the same time, we had another team in Zuora that was talking with Tray already. And so I was able to leverage those conversations to understand more about what Tray could do for us.

And the planets aligned around, hey. We can actually prototype and understand and iterate on solutions here in a much quicker way, and the team actually really liked working in the environment. And so we headed down this path of, could this actually really work for us? And that was the beginning that took us to the journey of investing in Tray.

Well, I'll pause there and let you think about that and ask more questions.

Yeah. So, I know that there was, you know, the initial feedback from the team because you're fundamentally shifting the way they Yes. The way they think about building applications, the way they think about building integrations.

So what was the feedback from the team, you know, because it's obviously, as I said, a monumental shift in your approach.

Yes. For people who are, you learn about, you learn about your development team, when you make a transition like this. For those that and in my journey, I've met many different kinds of developers. And for those that wanna write code, this is not their path.

This is not their journey, and that's okay. And so we had some people that said, I still want to be in the code, and they made different choices for their career journey, and that's great. For those of the team that stuck with it and really learned, now it's become a tool in their tool belt. And, I had just heard I think I mentioned this to you, Michael.

I just heard that our team in Chennai is starting to do brown bags with the other folks there because they're hearing that they're working on this thing called Tray.

That's right.

Wanna know more about it, and how do they leverage it. And so, for those that were ready to make the move to a different way to build things, it's proven to be quite advantageous.

Great. And so in terms of you talked about MuleSoft in kind of the costs that they were impacting on the business. Were there any other costs that you saw that you're able to extract from the business by being able to move onto this modern based approach?

From a pure write a check perspective, the cost of the software definitely was an advantage, but now we find value in shorter time cycles.

Mhmm.

And we find value in things that are a little bit harder to quantify but still bring us value. So when you ask about cost, it could be quantified or qualified. Right? So I would say we're saving time. We're starting to change the narrative with our business partner because we can have a conversation with them about their need. And in seven to ten days, we can show them something that is close to what they already need, and they're surprised.

And that's a savings to me because now I can turn things around much faster. It brings more work, but I think of it as a savings.

Right. And we discussed earlier about the view of IT within the organization.

Right? As a place where problems go to or integrations go to die. Right? Yep.

How is that this move to, you know, the workflow based approach, how has that changed the dynamic between yourselves and other business partners within the organization and the teams?

Yeah. So I'll use a really simple example.

Towards the end of our conversation, we were gonna talk about some of the use cases that we have coming for us. But if I use the very first use case Mhmm.

That we implemented, it was, wow. How do these connectors work? How do these workflows work? And we implemented a simple connector into Salesforce that watched for when the sales team won an opportunity.

And then we use Tray to let everybody know in a Slack channel so everybody could celebrate that win. It's a super simple use case, but it did a couple things for us. It was our first implementation of what we would call a production Tray use case that did something that we would have never considered to be in MuleSoft.

But after we did that, the exposure has now generated additional requests. So now we've done an iteration on that. Mhmm. And we're communicating with a group of salespeople about when we lose an opportunity.

And it's becoming that that sales team looks at us now as, oh, they can actually deliver on requests in a week or two. And especially when we iterate, it goes really fast. And so they're starting to leverage us as a mechanism for solving their problems, which is our fundamental goal in the first place. And so it's great. It's great to see that behavior starting to change.

Yeah. And I'm sure for our morale perspective, right, it's it's it's a lot more, inviting and and kind of exciting for you guys to be sort of a center of excellence versus kind of like, oh, I guess I'll go to IT. Right?

Yes. Yes. Yeah. It it's, there are a number of really interesting scenarios that we're starting to consider with Tray.

Yeah. So we'll just take the pause there, and we'll we'll we'll, we'll dive in them in a second. Yeah. So,

You know, you talked before about the rapid iterative development process.

So could you kind of give some context to you said you were doing a lot of prototyping on ideas. Yes. And then sort of where all those ideas come to a flourish in, or kinda how was that working?

Yeah. Not every so not every idea do we end up implementing.

Right.

Some ideas are, hey. Can we connect to this source and use it in the way that we're thinking about trying to use it? And sometimes the way we're thinking about it doesn't work out, but that's okay because the team learned something by doing that. And it's usually only a couple day investment to see what the art of the possible even is for what we're thinking about. And so we've now completely implemented this iterative process with the team. If we have an idea, we ask the team, come back in a week and tell us if this particular idea has merit and how it would work, and they come back and tell us. And sometimes it works and sometimes it doesn't, but it feels like you're making progress every time because you're learning about what the platform can and cannot do, and you're connecting that to the need that you have.

Yeah. That makes sense. And, you know, the obviously, the title of this whole webinar is moving from three months to three weeks. Yeah.

How is that you know, obviously, you're able to build integrations faster, and that's super important. But how has that impacted kind of your ability to deliver software for the business? Right? How has that impacted kind of the sort of the end goal of serving your customers and driving the business forward?

Yeah. So it improves the relationship.

You can show them seeing things much quicker. You can have engaging conversations with them about what they need the solution to be.

But it also compartmentalizes and changes how you deliver the change. So when we were doing change in MuleSoft, it was this large monolithic delivery of this application to that application with a bunch of logic and data in it.

Now it's I can iterate on, alright. Let's move the first three compartments from A to B. Let's add to it. Let's transform it.

Let's build on top of what we've already got. And so it makes for a more engaging conversation that takes us on a journey rather than a specific deliverable, that we'll get we'll get to you next quarter. And so Right. It changes your whole narrative.

And the other thing I'll comment and, Michael, we didn't talk about this, but I'll mention it. It actually has emphasized that we do need to spend some time thinking about enterprise architecture with the implementation of this tool. We have to make sure that we're not creating too many use cases that just make too many connections around our landscape. And so we've now started to implement conversations and architectural reviews before we go live with any of our Tray solutions just to make sure that we're not violating any of the principles that we have for the architecture.

And three years ago when I got here, we weren't doing that as robustly as we could have been either, and so that's something that we're doing now as well.

Okay.

Great. And with the, if we remember, when we were just speaking about having developer teams that were focused solely on integrations and building in a you know, building for MuleSoft only. Yeah. And the restrictions that give you there, kinda how is that transition went and kind of how has that impacted your overall developer teams?

So I think of Tray now as a tool in their toolkit Mhmm.

That they're able to ramp up on and understand in a relatively short period of time. And so as they're progressing through the landscape helping us integrate systems or helping us, you know, bring up a new SaaS solution for us, Tray is a tool they can use, and they'll identify that they need to use it when needed. And so it doesn't mean I have to have one hundred percent Tray dedication in any resource. It means that anybody on the development team can pop in the Tray if we're having a problem, see what's going on, or use it as a tool. So it changes how I resource the team. It changes how I think about them working on solutions. So it's much more flexible for me as a team leader for sure.

And has, I understand the orientation of the developer. Has it allowed you to, you know obviously, three months to three weeks is a huge difference in terms of has it reduced the amount of development time that you have had to really dedicate to integrations?

Oh, that's an interesting question. I think if you measured it with one integration, yes, it's shorter.

I think we're doing more integration work now because we can. I see. Right? We're solving problems here now that we would not have considered solving problems with here before.

And so the integration work, depending on how you measure, you could make the argument that it's gone up, but it's gone up in a good way because we have this tool to solve problems.

Yeah. You're bolstering your output versus just kinda hitting your head off the same problem for three months. Right?

Correct. Correct. Yeah. It's better. It's okay to have that kind of new work.

Sure. That makes sense. So with that kind of the results you went, you know, we've we can just kind of summarize these. You went from your three months to three weeks.

The cost savings, we already spoke about. The developer output. Right? That kind of, we've already talked about being able to, you know, bolster your output and improve the development time.

Is there any other results that you guys could think of that maybe we haven't covered here, that that the audience would wanna know?

I can't emphasize enough how valuable it's been for us to, as an IT organization, to improve our relationship with our business partners.

And that's something that's not necessarily here on the slide, but it changes the narrative. It allows us to respond in a quicker way, than we just couldn't before. And so, yes, all of these results are true. We're we're delivering more. We're going faster.

We've saved some dollars, but it's really solving those problems for our partners that cannot emphasize how valuable that is to us.

That makes sense.

So now with all of this said, right, we were very excited that you guys are, you know, moving to the next stage and the next level. Yeah. I would love if you could kinda give us some examples on let's start with some of the use cases. Right? You already spoke to a few of them that you've been able to implement with Tray. And then looking to the future, kinda what are your plans to, you know, to expand out the usage and the value that it's bringing?

Yeah. Yeah. There's a number of uses so I'll talk about some significant current use cases. I already talked about the Salesforce one.

We also had a legacy integration, that was low that loading travel expenses from Concur, back into Salesforce, and that was running in AWS, with Lambda code.

It was brittle.

It was inconsistent. It was implemented in a way that failures were sending emails to unmonitored mailboxes kind of thing, and we reimplemented that solution in Tray in a way that we understand what's happening. The error handling is proper.

The daily run is infinitely more reliable now. And so our global services team, for example, that's gotta get billing expenses back in the Salesforce, it's something they actually can rely on now rather than three years ago, they were opening tickets every week that they don't see expenses showing up, and we didn't know why. And so just just a huge improvement in our Concur to Salesforce, the platform, for example.

We also have a significant amount of work going into, and we've just started this journey, but it's significant work around Workday and doing people feeds to systems that need hierarchy data and information about our employees. So one of the more recent examples is it's how we're feeding, Jira service management, for example. So you've got approvals for tickets following the right scheme.

All of that is now being run with Tray, in addition to a number of other, smaller examples that are running. But those are the recent significant ones, and none of them took us more than a month to get implemented.

And so, yeah, that list is continuing to grow, and that's a couple examples for use cases.

Great. Thanks. So I think we're at the Q&A stage, and we have a lot of questions here.

Oh, there's questions coming. Okay. Cool. Good.

Yeah. There's a lot of questions coming. So I have a question here. How exactly, it helps to reduce the time? Let's say, if we have a MuleSoft batch flow getting the daily data from Oracle and up starting in Salesforce by applying some transformation, how do you reduce the time comparison to MuleSoft?

So I guess maybe if we just ask that you answer that generally.

Yeah. So anytime, if you think of, so if I go backwards, anytime that we're interacting with Salesforce, we've created one service account based connector that anybody on the Tray flat platform with the appropriate credentials can leverage as that connector. So you don't have to build something new. You leverage the connector.

It's got the data the data design already exposed in the connector. And so the team is able to go in and build the workflow for that logic for the daily run in and it literally takes the team a couple days, and then validation just takes a couple days.

In the old environment, it took our team a long time to formulate that MuleSoft path. And it would take by the time we walk through the design and we talked about what it took to implement to do it the right way, we'd be four or five weeks in, and then you'd have to test. And so in work in Tray, usually, our test validation is a day or two at the end. And so our cycle ends up being, you know, less than ten days, we can have something running.

Got it. Okay. Great. Thanks for that. And so another question here. Hey, Mark. I love a lot of what you're saying, especially around improving integration team optics.

You mentioned the continued need to maintain Zuora's internal architecture practices. I'm curious if or how you handle architecture audits in Tray.

Architectural audits? Yeah. Yeah. Yeah. So, yeah. So that's an interesting conversation.

We have an enterprise architecture team that has just actually, the new leader hasn't started yet. And one of the gaps that we had when I came here three years ago was the architectural view of how everything was put together was not very robust. It didn't understand the dataset at all.

And from an application integration perspective, it only understood about half of the integrations that were actually in place. So we've done a lot of work around just getting our arms, Just step back from Tray for a moment. Getting our arms around what is our landscape doing such that when we start talking about audits, we actually understand what we're trying to do. And so I'll admit to you, we have not done Tray specific architectural audits.

The way we're thinking about it is the integrations that are implemented are just integrations on the list along with some of our legacy ones that still exist, and that becomes of the data and architectural audit that the EA team is gonna tackle. And so this is part of our journey that's new. And so we've not we're not thinking about it trace specific. We're thinking about it architecturally.

Got it. So we have a question here.

If an integration needs to apply transformations on the source code on the source data, high and non developer business user will apply using Tray as those users don't have much dev exposure.

So I guess the broader question is there, how have you found developers, using Tray for source for source data?

This one brings up the conversation, Michael, that the Tray team and I were having about giving access to Tray to other parts of the organization to leverage the no code components. Right? And so when I think about people that don't necessarily understand the data, if we are in a scenario where it is a complicated enough transformation, we have access to some analysts on our team within the IT organization.

If the data transformation or the understanding of what's happening in the data is getting complex, sometimes I will ask for, we refer to them as business system analysts, BSAs. I would ask for a BSA to be part of the conversation to help navigate that journey, to make sure that we're not deviating or negatively affecting our datasets. And so I would bring that in. But it's a good question because sometimes our user community sees and they think they know what's happening, but the data underneath is not what's that's not actually how it's implemented.

Great. And, one other question here is about the difficult to migrate to Tray. So we talk so I think this is a good, a good question here. Was there any limitations or any difficulties in migration, any hangover, right, as we hangover, applications that were current that are still running from MuleSoft that were a difficult transition over to Tray?

Yeah. So technology wise, I don't think I could say we had any hangovers techno you know, technology gaps, things we couldn't solve for by moving to Tray. I think the hardest part about making the move was understanding the intent of the integration with the business team and working through okay.

We see it moving data. Let's have a conversation about intent and about the business process that's running around this thing to make sure we support it properly, getting through that conversation so when we reimplement it in Tray, it makes sense. That's the hardest part.

Got it. And was there any connectors that weren't available that you had to kind of work around in order to do any migrations?

Oh, you mean, like, if we had to use a universal connector or something?

Yeah.

I don't think I can. I don't think I have one in my head, Michael? I don't think I can say that. I do know in one of our future use cases, one of the things that we're talking about doing is, we use Vimeo for Mhmm. For our video platform. And one of the one of the ideas that we have is we wanna use Tray to be able to get into the Vimeo repositories and actually search for particular topics that we've recorded in our video landscape.

I think we've discovered that connecting into Vimeo is gonna require some universal connector components, but we haven't implemented that yet. That's the only one I can think of. But what we've implemented in the production has not been a challenge. Like, we have not experienced the gap there.

Got it. And I suppose the one of the questions that I have, what is your kinda long term view of adopting AI within your organization and kind of infusing AI within Tray?

Yeah. So we have a CIO who started about nine months ago, and he is very connected to the AI community. Mhmm.

So we're being careful.

Right.

The one thing that Karthik, our CIO, really wants us to think about is providing an AI experience to our employee community that is consistent. And so we don't necessarily want, you know, Einstein and Salesforce doing AI just for Salesforce, and then the Okta AI just doing AI if you're trying to do something in Okta. We don't want employees to find their way based on what they need. We want a seamless AI experience that an employee can go to.

And then behind the scenes, we actually get that request to the right location.

We're exploring Tray as a mechanism for providing that connection point and then using Tray to figure out, hey. Where should this request go in our landscape? So it's almost like the front layer that establishes consistency.

Now within the workflow, how do we make choices for where do we actually parse and send that request across our landscape? So our community gets a unified AI experience. And so we're exploring that now. We actually just started those conversations in the last ten days.

That's awesome. That's super exciting.

Yeah. It is.

Super exciting. So looking at it from a, you know, holistically when you're looking to migrate across and what are being the biggest challenges in this migration journey?

There have been a couple.

One is when we implemented Tray and we did our first implementation, we were still in a place where we understood or we could see what Tray could do, but we actually had a hard time convincing all of those around us that we had this tool that we could make a difference with. Mhmm. And so it took time for us to get the people around us understanding how to use the tool, and that that's something that we could actually do that would help them. And so that took time, and we're still working on that.

The people that we've done work for across our business organizations are very appreciative, but I don't think we've done enough for our company to understand what Tray can do for us. And so we still have work to do there. Mhmm. Technically, I have virtually no significant issue with the way we've implemented Tray. It's great. I I I it it's it's true.

I don't have significant technical gaps that I need filled from a Tray perspective.

It's really about the change management of it all.

Great.

Well, I think we'll leave it there, Mark. Yep. Thank you so much for your time today and for all of the great insights. We really do appreciate it, from everyone here at Tray.

Thank you to our audience, for being able to join us again today. We hope you got a lot of value out of this. This will be on demand, so it will be emailed out to you. Thank you once again, and hope you have a great rest of your day or evening.

Hey, Michael. Thanks for having me today. I appreciate it. It was fun.

Thank you, Mark. Bye. Right.