Learn how modern SaaS teams turn customer integrations into revenue by offering premium features, reducing churn, and boosting win rates.
Customer demand for SaaS integrations is higher than ever—but integrations don't have to be a cost burden. Learn how companies are modernizing their integration strategies to drive new revenue, increase customer retention, and win more deals. See real examples of monetization models, bundling strategies, and flexible delivery methods using embedded integration platforms.
Direct monetization strategies for customer-facing integrations
Indirect revenue gains from improved retention and sales win rates
How to scale integration delivery with flexible embedded platforms
Lessons learned from real-world monetization success stories
Why SaaS integration demand is rising
Moving integrations from cost center to profit center
Direct and indirect monetization strategies
Scaling integration delivery with embedded platforms
Success stories: monetizing integrations with Tray
How to prioritize integrations and manage costs
Hey, everybody. This is Mike Belsito, cofounder of Product Collective, and we're back for another industry webinar. I hope wherever in the world you are, you're doing well. I'm gonna give you a little bit of an idea of what's in store for today.
We've got a great session planned with one of our sponsors, a longtime sponsor, Tray. And, and we're gonna get into the topic, very soon. I'll introduce our guest. But first, if this is one of your first sessions with us here at Product Collective, first of all, welcome.
I'm gonna give you a little bit of a lay of the land and kind of, give you an idea of what to expect and how you can participate throughout. But, yeah, these are a production of product collective. We're a community for product people, product managers, product leaders. We've been doing this since 2015, really with our conferences and webinars like this and our podcast, and, it's been a lot of fun.
Basically, we were very confused product people and realized that we can get smarter by connecting with other product people and learning from them, and that's what we've been doing ever since. So, but this webinar today, we're gonna go through a great presentation that our guest has planned, but I wanna give you an idea of how you can participate along the way. So at the bottom, you'll notice there's a chat and there's a Q&A. The chat is really for you to participate throughout.
Maybe you hear something within the presentation and you wanna share an anecdote of your own. Maybe, you just want to, yeah, share something that's on your mind. You could do so right in the chat. And if it's okay with you, we'll practice that chat right now.
If you want to go ahead and open up the chat and select to everyone, not just the host and panelists, but to everybody so that they can see what you're saying. Maybe to practice, you could share where you're tuning in from. You know, I'm coming at you from Cleveland, Ohio as I always am, pretty much, but it's always fun seeing where everybody else is tuning in from. So if you wanna just go to the chat, select to everyone and share, everyone will be able to see.
And I could see some of you are already doing that right now.
So that's great. We have people from Austin, Texas, Worcester, Massachusetts, either Los Angeles or Louisiana. Could be either one of those. People are tuning in from all over.
So that's that's awesome. Thank you for doing that. So, again, that's how you could use the chat. If you have questions for our featured guest at any point, you could do so by pulling up the Q&A.
That's another section in the bottom. I'll be monitoring that throughout. So what's gonna happen is we have a presentation for about twenty, twenty five minutes, and then we're gonna open it up to questions. And we'll have about fifteen to twenty minutes of questions or so.
And so we'll wrap up probably about between one thirty and one forty PM eastern. But, yeah, use that Q&A section, and maybe you came with questions of your own. That's great. But you could load them up in the Q&A section there, and I'll be monitoring that.
But for the most part, I'm actually going to be fading away to the background pretty soon, and I'm gonna introduce you to our guest, Chris Ferraro. Now Chris is a product marketing manager at Tray. And, you know, the whole topic of today from cost center to profit center, how do we monetize customer integrations?
And that's coming at you from Tray, a company that's been helping customers do that for quite some time. So with all of that, let's get right into the topic, and let's meet our guest. Chris, thanks so much for being here with us.
Yeah. Thank you, Mike, for a great intro, and I'm really excited to present to you today. Again, the topic is monetizing integrations with Tray Embedded. This is something that we have a lot of experience with in terms of helping our customers execute on the strategy, and we wanted to sort of share all of our subject matter expertise with you all today in the product collective. So we're gonna be talking again about how you can monetize customer integrations, which are historically thought of as a cost center and turn them into a profit center for your organization.
So the first section is going to be customer integrations from cost center to profit center. We're gonna be talking about ways of direct productization, so tiering and charging for integrations, ways that you can think about customer integrations, saving you money in terms of churn reduction and increasing your deal win rate, and then speaking a little bit about how it's actually embedded iPaaS tools that are able to, you know, galvanize this whole customer facing integration approach towards your business. And we will end with some Q&A, so feel free to post your questions in the chat. We'll make sure to get to them at the end, and that's why we're saving so much time for questions. I want this to be a very engaging presentation, engaging as it can be virtually. So first, customer integrations from cost center to profit center. Let's take a step back and talk a bit about the proliferation of SaaS usage.
So every B2B SaaS team knows that their products don't exist in a vacuum. Right? The SaaS explosion has created an endless array of highly usable purpose-built line of business application that teams across the org have readily adopted.
Our recent state of the automation report actually found that forty percent of teams currently have more than forty different applications in their text desks, and this isn't showing any signs of slowing if you look at the chart below. Eighty three percent of teams are expecting the number of applications they use to increase in the next three to five years.
And so much software means that almost every business process is now spanning multiple applications, and completing tasks requires teams to do work or create data within a specific application, which they then must share other applications.
And teams' growing needs to share data across applications is translating into a growing number of customer integration requests. So buyers of software expect that applications they buy will play nice with other tools that they already have in their stack by providing easy maintenance-free integration capabilities.
And you need to offer these integrations to customers to really be competitive.
Right? Whether that's in presales validating that you can achieve a certain use case to win a deal, for your services team to be able to complete an SOW and deploy an integration within a time frame that they specify that in under a given cost. And then the final piece is the product. Right? Delivering productized integrations to your customers that feel native within your UI and allow your customers to easily activate them via some sort of an apps or integration marketplace as you commonly see.
And all of your competitors are doing the same. So ninety eight different, SaaS app SaaS integrations on average are offered by, SaaS one thousand companies, and sixty percent will bundle one or more third-party integrations by 2025.
So this is only going to grow over time.
But the swell in all these customer integration demands has created a significant backlog. So almost every SaaS product team has a really, really big backlog of integration features, and the customers and prospects request for integrations between their own software products and specific tools. And most of these requests are remaining in the backlog because a lot of times, there's sort of this cost center mindset that's preventing teams from realizing the potential value of these features. So oftentimes, they're considered table stakes versus maybe new feature development or new items on the road map. And you think about them as constantly requiring monitoring and maintenance as vendors are releasing and updating new APIs and endpoints.
So this cost center mindset, right, where software buyers are considering integrations again to be table stakes features, product teams are hesitant to develop integrations internally. They push back on requests.
It's missing two important points. First, there are many different ways to deliver integrations, and not all of them require significant engineering resources. And second, while integrations might not appear to be highly differentiating features, there are many successful monetization strategies that turn them into significant revenue drivers, and that's really what we're going to cover within this presentation.
So how do we get from a cost center to a profit center when we're talking about our customer facing integrations? So rather than approaching integrations as a sometimes necessary pain, SaaS companies should focus their approach around monetization and revenue. Every company experiences integration pressure from customers and prospects, but having a strong strategy in place where, companies can get ahead of these requests and focus on the delivery model and monetization approach, will help you, number one, grow revenue streams from direct productization. Number two, reduce churn, so that's more indirect. And then also more indirect, increase your deal win rates. And we're going to cover sort of all three of these methodologies, via some pretty cool and unique examples.
So first is direct productization.
One methodology that we've seen that works really well is actually charging a fee per integration, and you can make it annual. So we've seen anywhere between zero and fifteen percent of total ARR in that account being charged. And the reason that you can actually make this a recurring fee is integrations are a one and done effort. They require consistent maintenance, and your team is responsible for that maintenance over time. And since it's an ongoing cost for you, it can also be an ongoing cost that you can pass along to your customer.
And so for this example, we're assuming that the customer base is growing twenty two percent per year and that there's one integration that's priced at fifteen hundred per year and another integration that might be a little more valuable that's priced at twenty five hundred per year, assuming that the attach rate, meaning, ten percent of customers are adopting the first integration and four percent of customers are adopting the second integration.
We can start to see how the ROI pans out when we look at the total revenue on the bottom. So you've essentially created a hundred thirty six thousand five hundred sixty two dollar recurring revenue stream by pricing in these really valuable integrations as, again, that and a percentage of your ARR and a recurring fee for your customers.
Another example that we've seen that works really well is actually creating integration bundles.
So one could be a segment based bundle. Right? Maybe you only get customers only get access to the premium tier of integrations or, sorry, the premium integrations if they're in that premium tier. And maybe those integrations are grouped.
So CRM integrations, ERP integrations, EMR integrations are only available in that top tier, which is forcing customers to go up in terms of what they're paying you to capture that additional value. And there could also be complexity-based bundles. So maybe point to point integrations that really don't take your team that much time and effort can be in sort of a beginning or entry-level package. And then a set of complex integration use cases where your team is spending more time developing these integrations will be part of that enterprise package.
So both cases, you know, you're getting your customer to pay more and get into a strong a higher price tier based on the value and the quantity of integrations that are being offered. This is one that we see really commonly, amongst our our whole customer base.
It's important to note here that the way that you monetize integrations is largely predicated on who your end users are. So if we went up to the previous examples where you're charging a percentage of ARR, that might make a lot of sense if your end customers are enterprise accounts that are paying you five and six figures. But what if you're servicing freemium users? What if your users are only paying you five, ten dollars a month?
We also have customers who adopt this approach. So sometimes freemium version they'll offer a freemium version of a product that has no or limited integration capabilities, and they'll use integrations or offering integrations as a way to get these users onto paid plans. So a way to kind of steer them to the right when it comes to their pricing and packaging and to turn them from a nonpaying customer to a paid customer.
Another way to do it, we've seen see the second bullet is offering an integration trial period for new sign ups where all features are available. So they get to see and connect into all of these integrations and really experience a lot of value. And then once customers see live data flowing in from your product across their tech stack, to turn that on again after the trial period's over, they will have to move to a paid tier.
So for some of these earlier examples, we were talking more about productized integration. So maybe white labeled one click activation integrations that appear on your website as some sort of marketplace or catalog.
But there are also integrations that are really complex and ad hoc. Right? Maybe you need to connect into the ERP of a large enterprise where it's not necessarily a repeatable integration. It's one that's going to be done in sort of a services style SOW.
It's a one-off integration that is scoped out, and you can charge based on the amount of hours that your team spends and make sure that you're making a margin that makes sense for your business.
It's again, this is slightly a tougher approach where it's going to be more of a one-off fee.
So we always recommend making this recurring to some degree. But, again, we do have customers who will adopt the SOW style. Maybe they're more services-oriented, and they'll make sure that they have a little margin on top of the hours that they're spending so they can make a little bit of a profit on these integrations.
So we talked a little bit about some of the more direct monetization strategies.
Let's talk about indirect.
So let's talk about ways that getting your customers to adopt integrations will actually lead to less churn for your business. So a customer that has an active integration running is using data from your product as part of the product team's processes or workflows. And as a result, the stickiness of your product increases as customers will have to address stakeholder and system dependencies if they wanna stop using your products. In fact, some companies see as much as a thirty six percent higher retention for customers that use integrations with an embedded solution.
So we covered this. Let's take a look back at that example that we used before, that same software company that before was monetizing their integrations. Let's look at some of the indirect, results that you can see.
So if we follow a few assumptions, assuming that the current customer churn rate is six percent and our average deal size is twenty five thousand, and every customer that adopts integration has a twenty percent lower churn rate to be conservative, we'd see the following in terms of saved incremental revenue that would have churned. As you could see, by year five, we're up to ninety five thousand, which is really significant, not to mention a reduced burden on your post-sales teams and your customer success teams as well.
Another example is increased win rate. So companies can realize benefits from integrations in terms of increasing their overall win rate on new deals. In the same way that integrations can improve customer satisfaction and retention, they could also make your product more attractive during the sales cycle. While some integrations might seem like basic requirements, certain integrations are must-have features for your customers, and vendors that can't provide must-have integrations are typically going to lose out to those competitors. Losing deals is one of the most common sources of internal friction around integrations. And sales teams are always pressing product management and other members of the org to address the deal killing lack of integrations.
So if we continue our example from before, let's assume that there's a baseline sales win-win rate of twenty five percent.
And just having two, additional integrations live, those two that we talked about before, we'll have a marginal one percent increase on win rates. In reality, they'd likely be higher. We're, again, we're being conservative with all of these predictions.
This is going to save a lot of money, and you're going to win a lot more deals, which, as you can see in the bottom right, is gonna manifest itself into a lot more ARR for your business.
So if we look at the final results from the direct monetization strategies and indirect savings in terms of increased customer retention and sales win rates, there's really significant benefits to adopting this customer-facing integration approach. So we had five hundred twenty three dollars in net new revenue for integration monetization over the years and then one point three million in new revenue from increased customer retention and sales win rates. So not only are we opening up a new revenue channel, we're also winning more deals, and we are saving more of our current customer base from churning as a result of churning our integrations from a cost center to more of a profit center.
So we talked about the different strategies that you can employ to monetize integrations.
But what's behind that strategy? You need some sort of tool in order to scale out your customer-facing integration strategy. Because a lot of the traditional ways of maybe adopting a point-to-point tool or, trying to do this yourself with your development teams and custom code doesn't scale over time.
You need an embedded iPaaS tool that's going to have out-of-the-box functionality like a connector library.
It's easy to use, so you're taking some of the burden off your developer team. It has a scalable architecture, so it can handle all the customer data that's flowing in and out of the system. And, also, it has to be white-labeled. Right? In order to make productized integrations feel native to your UI and your UX, you don't want it to look like there's a third party present. Right? You want us to look completely seamlessly as an extension of your product.
And you're gonna have a wide variety of customer-facing integration needs. As we mentioned before, there could be validating use case and presets.
You could be part of a services team that's delivering a really complex one-off ad hoc integration.
And then you could also be a product team where you've figured out a certain number of integrations that are really valuable to your customer base. You wanna templatize those. You want to release them and have them be part of your product in terms of the integration or app marketplace.
And you want one solution that fits all of these needs versus maybe point to point tools that accomplish some of these use cases.
And so this is just an example of Tray’s Builder where we have the ability to handle all of these one off custom integrations while also allowing you to white label and serve up a full in app integration marketplace for all of your end users. So when you think about monetization, whether you're monetizing via services style SOW or you're bundling integrations or you're charging a a one off fee, it's one solution that's enabling you to really be agile and roll out whatever one of these strategies makes the most sense to your business.
Okay.
So now I'll just run through some concluding thoughts. So integrations are becoming increasingly important as we mentioned before, and customers are rapidly losing patience with offerings that can't fully operate as part of their increasingly complex tech stacks. So for product teams, for strategy organizations, adopting an integration monetization mindset isn't just a good business opportunity. It's become essential for product success. And to do so, adopting an embedded iPaaS strategy to power that approach has also become absolutely critical.
So I wanted to open things up to q and a. I know that was a lot of talking, and I wanna make sure that we have enough time to get to each and every question.
So, Mike, I wanted to see if there were any questions in the chat or anything that's come up that I can answer or shed some more light on.
Yeah. For sure. Definitely have some questions. And, yeah, if you have audience out there, if you have more questions, submit them in the Q&A section. That's the best place for that. Now I'll go through with with definitely have time for, at least a good couple questions here. I first off, Chris, in terms of it Tray offering a fully white labeled solution, does Tray do that, or maybe you could talk a little bit about that?
Yeah. So Tray does offer a fully white labeled solution where you're actually able to OEM Tray and offer what we call our configuration wizard, which is a self serve activated wizard experience where users would never know that Tray exists in the background. You could have it colored and schematically however you like, but, basically, it ties to our back end workflow builder. So you'd be able to build all these integrations, templatize them on tray, and then expose them to your end users in a way that's completely self-serviceable and feels native to your product.
That's great. That's great. Awesome. I know some people are definitely curious about that. And I was curious also, though, you know, this is something that you've you know, Tray as a company has been doing for quite some time. What are some of the companies that Tray works with?
Maybe some of those I don't know if you have, like, a specific success story or anything like that, but, what are some of those companies that Tray's worked with in the past?
Yeah. So I think just to highlight, what one thing I talked about before was how we support customers with a wide variety of different business models. So we've worked with Eventbrite that was more B2C or maybe B2B small business where we help them go live with one of their integrations that now has sixty thousand end users.
And then by the same token, we've also worked with the HackerOne's of the world, the big ID's of the world who are servicing those large enterprise customers who adopted us more for those ad hoc custom integrations that they were able to build using our our high powered automation builder.
Awesome. That's awesome. Well, I'll go to another couple audience questions here. One of them is that you you had shared information about additional revenue generated by an API as a service tool. What are profit margins, on that kind of revenue? Does it vary widely? Is is there some sort of industry benchmark?
Yeah. When we're thinking about additional revenue, what kind of profit might be we be able to might we be able to expect with that?
Yeah. That's a really good question.
I think when you're so profit margin, can you specify the question of whether they're asking what the margin is in terms of, like, what they would pay for a tool like Tray and the ROI or just in general the profit margin that they would get from a customer?
Yeah. Their question was just, you know, if there are general profit margins on revenue when it comes to API as a service. So, you know, I don't know this person's specific situation. Maybe you could talk generally, though.
Yeah. So, generally, like I mentioned with the ARR piece, you like to keep a somewhere below fifteen percent what you're charging customers for integrations as it relates to total ARR. So you need to make sure that your that your customers aren't paying too much for the integration, but also paying for what they use. So we like to charge between zero and or we like our customers to charge between zero and fifteen percent of the ARR, for integration slash API access. And that's a good point. Some of our customers will monetize through just offering access to their APIs as well. So that's another strategy that we see.
Yeah. That's helpful. I appreciate that. Another audience question was asking whether there were industry benchmarks on which monetization approach is most prevalent, direct versus indirect.
Yeah. What what are your thoughts on that?
Well so I think indirect is always there. So no matter what approach you're using, there is always going to be churn reduction if customers are adopting your integrations.
And if you're offering more integrations, you'll be able to win more deals. So I think the indirect pieces are are are part of everyone's strategy.
Where the difference lies is in the monetization approach, the direct monetization approach. So we find that if your end users are typically bigger enterprises, large companies that maybe have really complex systems that you wanna connect into, style approach that can't really be replicated as well. But if your end users are maybe more on the SMB side or the B2C side, then we find that it's really common for you to offer up an integration marketplace or some sort of self-serviceable productized integrations, in which case you'd be bundling those as as part of either a premium or silver package or whatever you call it. So it's easier to bundle those integrations when they're actually a part of your product, which we find more commonly in the when you're serving SMBs, smaller companies, versus when you're serving enterprises. We find it's a more common monetization approach to charge for that one off integration, either services style or as recurring revenue.
Okay. Yeah. No. That that's helpful in lots of different ways that we can approach it. So, yeah, it's helpful for you to walk us through it like that.
I like this question coming up. This is, you know, when we sit through the presentation, we think of ways that we might be able to open up integrations with Tray. There's a lot of possibilities. Right?
A lot of things that we could potentially do. So this question is, hey. Development bandwidth is finite. So what, you know, how do we best determine which integrations are must have?
You know, how do we help sort of figure that out once once now our minds open up to offering integrations?
How do we make that determination? What are your thoughts on that, Chris?
I think that's a really good question. And no matter how efficient you are as a engineering organization, you're gonna have to prioritize because within the amount of SaaS applications out there, there's an unlimited amount of requests coming in, probably hundreds. I think what you should do is listen to two main personas. One are the prospects.
So are prospects coming to you with a specific integration request that you can't fulfill? Are you losing deals consistently because you don't connect into x system or y system? So that's something where you wanna be in constant contact with your sales team since they sort of have their ear to the streets. And if there's a recurring integration that is a reason that you're missing out on potential revenue, that's one that you really wanna prioritize and move to the top of the stack.
And the other stakeholder is your actual customer base. So if you're seeing that during customer feedback sessions or customer panels, they say, hey. I love the product, but I really wish you had x integration, or I really wish you connected to a y system.
That's something that you should really prioritize because it's a way to increase the stickiness of your current customer base and also increase their overall satisfaction. So listening to really your your prospects and your customers is the best way to determine the highest impact integrations.
I would also say that Tray’s, this is more of a side note, but Trays' flexibility allows you to maybe first survey the market a little bit. So let's say you're unsure what integrations your customer demands.
You have this flexible platform where if you need to, you can just build out a workflow that achieves a certain use case, and you can handle it in a one off. But once you get to a point where you're like, well, hey. This integration's come up five, ten, fifteen times. You can actually roll that into a productized integration and offer that white labeled experience that I talked about before. So it gives you the flexibility to go from maybe surveying the market, figuring out what integrations are being demanded to productizing what's valuable from your customer base, based on what you've learned.
Yeah. That's great. Well, thank you for that. Another we'll take a couple more audience questions here, and these are great questions. If you have more, feel free to send it tomorrow. I'll get as many as I can in the next few minutes here.
This question kinda getting into the nuts and bolts of things. The question is, when you're executing a particular customer's integration, does it take a developer to perform the integration work, or is this something that somebody else, whether it's somebody in onboarding, technical sales, is somebody like that able to oversee that that piece of work? What what does it take, Chris? Like, just, you know, kind of as we think through actual execution here of the integrations.
That's a really good question. I think with some of the more legacy iPaaS tools, the MuleSoft’s, the Informatica’s, the Dell Boomi’s of the world, it was traditionally just that developer audience that could be successful with the platform, and it would take months and months of onboarding.
Tray is still a technical product.
It can achieve a wide, wide variety of use cases, but we say that anyone with a basic understanding of APIs and data structures can be successful. So we've had sales engineers be successful with our platform. We've had technical operations folks be successful with our platform amongst typical developer audiences as well.
That's awesome. That it's one of the beauties of the platform, it seems like. It's like you know, sometimes people ask that buy versus build question. What's one of the advantages of of, you know, buying? Working with a company like Tray here is that you don't have to have an entire team of of developers necessarily trying to create every single integration, which is that's a really good thing. Frees up time for, maybe creating other products and features. Right?
Certainly. And we've had a case with Eventbrite where they had, six developers who are focused on building integrations. And Wow. After Tray, they're down to one product manager and one developer. So if you think about it, that's for developer resources who can now be fully devoted to creating new features versus building integrations and maintaining them. So for them, it was a really tremendous ROI that they saw in that sense.
That's great. Well, I'll take, let's see. Another audience question here is yeah. Again, trying to think ahead a few steps on, okay, what happens when we actually move forward with this? Is there a formula for calculating maintenance costs to the business implied for a given integration?
And I imagine that this certainly can depend on the type of integration and, you know, maybe the type of company you're kind of connecting into and what that product is. But, yeah, maybe you could talk about maintenance, for integrations. What what's your take on that?
Yeah. So within our process at Tray, when we're selling to prospects, we make sure to take them through a calculator that goes through all of these costs, one of them being maintenance since you're offloading the maintenance of Tray, and Tray’s handling the maintenance of all of these connectors. As far as how I would think about it at a high level without getting super granular, you wanna see how many hours your development team is spending on maintaining integrations and then also factor in what you're paying those developers per year. And all of those hours at their pay wage is ultimately the cost associated with it and the money that could be spent elsewhere.
Got it. Got it. Well, this is super helpful. We're kinda getting towards the end of our time here. But, you know what, I know when sessions like this where we learn a lot, we get all this information, it's really helpful. Sometimes it's like the last thing in the back that we hear, you know, in that presentation that sort of sticks in the back of our mind. If there is one big takeaway that you hope people get from this session today, what would you want that takeaway to be?
Yeah. So I think my biggest takeaway would be sort of where we started and where I've tried to convince everyone of within this presentation. But, basically, to challenge your organization to stop thinking about integrations as a cost center and more to think about integrations as a profit center and really take a holistic look at ROI, not just from direct monetization, but the indirect benefits as well.
How many more deals are you going to win as a result of having these integrations, which leads to a happier sales team? Right? How many more customers are you going to save from churning, which is going to help your customer success organization tremendously? So really taking a holistic lens on your integration strategy and realizing all of the direct and indirect benefits of adopting this approach is what I want everyone to take out of this call.
That's awesome. That's awesome. I appreciate that, Chris. What I'm gonna do with everybody, I'm gonna send a follow-up email to everybody with more information on Tray, how you can get a hold of Chris, if you have any questions.
And, Chris, any sort of final, points that you want to make sure people know whether it's about getting in touch with you and Tray or or anything else from the Tray team?
No. I mean, I think our website is Tray.ai. So if you're interested in any of our resources, you can find them there. You could find our documentation in tray.ai/documentation.
And then feel free to reach out to me if you wanna connect, even just to ask a few questions. I'm I'm always down for a coffee chat.
That's awesome. And I'll share that in the email with everybody as well. So with all of that, I hope you all had a great session. And, Chris, thank you so much again for joining us for this.
Thank you, Mike. Really appreciate it.
Alright. Have a great afternoon, everybody.