ERP109 - The Magic of Chat

Matt, welcome to the Evolve Radio podcast. Thank you so much for having me, Todd. Alright. So we'll get started. Just a bit of background and intro for yourself, your history in the MSP, and the company that you're operating in now. Yeah. Definitely. So today, I'm a cofounder and COO of Thread. But in a former life, I was an operations professional with an MSP by the name of Richard Fleischman and Associates, RFA for short, based out of New York City. And so they focused on financial services companies, hedge and private equity, primarily joined them on the the compliance side back in, like, 2013, 2014 when the SEC decided that they cared a little bit about cybersecurity, not enough to regulate it, but certainly enough to issue guidance and guidelines. And so that was an interesting time to be starting your career, in technology. Promoted through there into account management, so I had about a 100 funds underneath of Eden, and then on through the ops tree to, to chief of staff. Excellent. So an operator by nature, so we're we're fast friends, I think, because of our our views of business in that that respect for sure. Got that right. Alright. So, some of your your background, I'm I'm I'm I am curious, like, we we maybe talked a bit about this in in some of the lead in as well, but, you what about sort of the operations side of the business as you were kinda growing up in in in the MSP that you worked at? You know, eventually you sort of get pulled out of some of the technical things and I suppose like maybe if it's relevant, compliance is a very specific type of technical work. Right? Like it's not like a lot of other things. It's more sort of governance, very procedural. Did you were you always sort of wired towards the operations side of the business? Was that of interest? And and sort of how did you get pulled further into the business side of things versus the technology side? Yeah. So I didn't have a technical background at in school. I actually studied English. I had a technical writing minor. And, that's that's how I ended up being in in kind of a documentation heavy role like a business analyst, slash compliance analyst with the MSP. And I found it a very helpful way to get a really strong foundation layer, in terms of technology. I didn't know what a Cisco ASA was. I didn't know what a switch was. I I didn't know anything about UTM and, you know, MDR and EDR and all the good stuff, all all the good acronyms that we could throw out there. And so it was a great education for me in that, you know, we would have a technical due diligence service whereby we would audit a hedge fund's environment, document it, and then present it back to a prospective investor of theirs to say, this is how they're protected. This is how they're secured. This is how they're backed up. And this is what they're doing in terms of, BCDRS. And so for me, it was a great education in that sense, like I said. But it evolved into migrating from an in house, ticketing system to ConnectWise manage, for for the business. And so I I really dove deep into, well, how did the workflows that we're doing in the existing system map to manage, and how do I help to migrate the business from from this to that. And so I think that was really my directional, evolution, I would say, into the the ops side of the house. K. Interesting. Yeah. So nontechnical background and now working in a very, very tech heavy industry. So did did you find the learning curve on that sort of heavy or, like, especially in the account management phase? I imagine there was a point where you were kind of faking it till you make it type thing and learning enough in the background. Oh, yeah. Yeah. So I I remember on my first day, actually, I I walked into into a conference room, and it was the man with his name on the wall, Richard Fleischmann, with my future boss, our c COO at the time, Johan, and our CTO and, like, the whole c suite. And we were putting together an RFP proposal response. And so, again, that was another way to really get a good understanding, lay the land for, like, how do you position technology as an advantage for your prospective customer in the future? So the the combination of those two items, I found to be super, super helpful. But, also, when you got to the the account management, side of things, it's it's about understanding where the technology estate is today, you know, where where there are gaps, if there are gaps, and then helping them navigate to what it should look look like in the future, whether it's a cloud based environment or upgrading their SAN, so on and so forth. And, it was a really it was a great broad education again without kind of having to get too too deep. Yeah. Awesome. Okay. Cool. So, you know, you've you've, like, what what was the transition, I suppose? Like, you you were working there and then, you guys got sort of went off and created this product originally ChatGenie for people who sort of recognize that name and now Thread. What was that transition look like? Like how did you go from, you know, account manager into non technical background working inside this this MSP to, you know, starting, you know, a very a very sort of, like, MSP centric, software company. It seems like a pretty pretty dramatic change, of course, I think. Yeah. Yeah. Definitely. And so, after I was promoted out of account management into operations, I was running the ConnectBlaz stack for for the company, with with help of a few folks. And so I really got to see how the the business, like, relied on it and interrelated on the platform very intimately. And so I started to engage with the community a little bit looking for solutions. Maybe there were there were shortcuts for me to be able to, you know, use it as leverage for the business at scale. And I I wish, that I had found evolved management, back then and and known more about Todd King, because it would have, saved me some steps. But, but at the time, that's when I started to really fall in love with the MSP channel and community, you know, going on Reddit, seeing posts from from Ray or Sydney and the the, OIT VoIP folks. But also at the at the time, Mark Goliath, who's the CEO of Thread rejoined RFA, and we shared an and that's when we decided to to launch, what would become ChatGenie. Awesome. K. Cool. So, you know, my introduction to ChatGenie was was I think sort of, like, a similar need than that that, you know, I think maybe you guys are trying to fill and maybe verify this for me. But, whenever I would talk to organizations about chat, the like, all of the options out there were very sort of sales centric. Right? There wasn't a lot of sort of, chat options. And for me, like, the reason that I loved, chat is is way back in the day we'd use this product, Bombgar, that I guess still exists, but, you know, it's it's extremely enterprise. Like, the the amount that we spent for the box that had to sit in our office to kinda manage this stuff was obscene. Like, it was very, very, very expensive for what we were trying to run. And every time like, I loved using chat, but I just didn't find it really applicable or cost effective, it didn't integrate with any of the tools. So, you know, when I finally found ChatGenie, I was like, well, great. Like, here is an MSP tool that actually fits into all the things that you're already utilizing. That was a real game changer for me. So, you know, you guys started as that. I guess the transition to thread and sort of what you're building much beyond, just a chat interface for tickets. Maybe you can sort of start there of the sort of the history and then the transition of the company. Yeah. Definitely. And we started from almost like a chat ops lens. We we just wanted to connect the internal ticketing system and the internal, collaboration platform together so that, you know, we saw the people were talking about tickets in in Slack, but then had to replicate all of that data back into the system of record, which was the PSA. And we felt like, you know, above and beyond the duplication of effort that there were there would or could be opportunities for automation, you know, triggering a a workflow based on an approval, things of that nature, right from where you you're you're living and breathing every day, which is the the collaboration platform. We brought it to IT Nation, IT Nation Connect as it's called now, when we decided to, build the MVP. And we we showed it to other MSPs, and people were like, oh, man. This is awesome. You know, we love this. But we're moving to Microsoft Teams because Teams was then bundled into the 365, suite of products. So we're like, okay. Great. Back to the drawing board. We then built the team's integration, brought it back the next year, and was like, oh, man. Awesome. Let's check this out. And then COVID happened and everybody dispersed, both customers and, MSP, like, the the the technicians. And then that's when we really had a big realization, which is nobody's and you had come to it before us. It sounds like nobody's really solving for the the customer to MSP collaboration, and experience in a way that integrates natively with the stack and connects to the system of record. And so that's when we set out to raise a little bit of funding and, ultimately became Thread. K. Very cool. So you kind of alluded to working inside of, the the chat platform. Right? And I I think generationally and just sort of operationally, like, we see this this change happening. I'm curious sort of your you you gave sort of one, piece there around, like, the the the having notes in system of record because you're a 100% right. Like, you see so much discussion about issues happening in the chat platform that is not captured anywhere else, you know. So, the only notes that you have is, escalated, talk to a couple of people about this. You know? Here's the resolution that I found. It's like, okay. What happened offline? Like, now we have no information, but there's all this discussion that happens in the chat plan, but the platform outside of that. So I think having that information actually captured in the ticket is is huge. What are some of the other advantages you think of operating inside of the like, a Teams or a chat platform like that instead of inside the PSA? Yeah. It's a real time interface, and you're having real time conversations. So I think that's that's one major advantage. The other is that, and the reason that we landed on chat as, our web, so to speak, or where we wanted to add a lot of value to the to to the MSP community is that it's, it's real time, but also it's it's, you know, ordered in time and it's text and and database. It's something that you can integrate, well into, unlike email where it's like a a turn based strategy game, and chat or phone, which is more of like a m m m o r p g or like a a real time game where you you get your, your squad together and you attack these these problems as they come up. And, you know, for us, that means there's a lot of opportunities to, again, trigger workflows, whether it be on the the customer side or within the MSP, because it is integrated. It meets people where they work. K. Cool. And I guess this is timely as well because, like, I had a I had a conversation with a client, yesterday about sort of, like like, how do we actually integrate chat to to our current workload. And you've kinda shared with me before, something you're releasing which will be in the wild by the time this this, episode goes to air. So it's it's safe for us to talk about it. But, one of sort of the interesting parts of this is, like, there's some there's there's there's some ideas around how chat is engaged in and where it's relevant as far as a support modality. Right? So Mhmm. Incidents versus requests, just sort of the quick, sort of, dictionary definition for people. Incidents are things like something is broken. I need help with this. A request is something like, hey. Could you do this for me? It's not actually some like a something broken or something I necessarily need immediately, but it's it's something that needs to be sort of planned for to get done. And historically, I guess, like, chat makes sense for things that actively need to happen because, like you said, it's it's an active engagement. It's a it's a a sort of a form of synchronous engagement with someone to ask and it feels sort of like timely. And maybe that doesn't feel as relevant for, just putting in, like, an onboarding a user or an you know, changing equipment to a different office or, you know, scheduling something to happen at the end of the week, that sort of thing. So you guys have kinda captured this and and are rolling out a a new feature, to allow for this different engagement in in sort of time You wanna expand a bit on this this feature? Yeah. Definitely. And and I'll I'll I think I'll start by taking it up a level before, digging into the the feature, which is we tend to think of things on, if you think about the classic, like, t or or cross, diagram where you have complexity and urgency, as the 2, the 2 parts of that, the 2 by 2 matrix. Yep. Exactly. The the 2, vertices or axes. And so for things that are high urgency but low complexity, I think that's where chat shines, both from an incident and a request standpoint where it's high complexity and and high urgency that for us feels like it should be a a phone call, right, where it can be escalated to the right person right away. And then there's the the spots between the 2 where it's like, you know, low urgency, low complexity. Again, probably a great place for for chat to shine. And so it's really all about being intentional and having a point of view on, training your users on when to use the the best of each each scenario, each modality based on those factors. You you can distill it down into there's work that needs to be done now versus not now, and we've really optimized an index on the the now side of things. Historically, what we're launching now is, is a it's a product or a feature called Planner, which introduces the concept of scheduling into the platform whereby we can now field or triage stuff now and then book it out, schedule it for for stuff that falls into the not now category without having to go back into the PSA to schedule it. Right. And what you shared before, is, this will satisfy all the Kanban nerds that wanna schedule cards for for your tickets. This, satisfies that itch as well, so I'm sure a ton of people will appreciate that. That's right. That's right. It's a it's a kanban. Like, everything's drag drag and droppable and sortable and, reorderable and filterable. So it's a it's a very smooth dynamic, view that we're really excited to to launch. Yeah. And people that love it do absolutely love it. So that'll be great to see. Alright. I'm curiously the other piece around, sort of chat as a as a modality, you know, Teams is prolific in because it comes well, it used to, come with Office 365. And, for those that don't know, they they were forced to sort of like, make it a side cart option, because of, I guess, an FTC regulation. So, but generally, most in most offices have teams, but most, I would say, don't actually leverage it. And I think, a, this is a serve an open, green space for MSPs to leverage this as an opportunity to drive Teams as a communication, option in their client base. But for those that don't have that, some may say, well, you know, this sounds great, but, you know, my my clients don't use Teams and therefore they wouldn't communicate with me in chat. And so, like, is that wrong? How would you sort of push back on that as a sort of a well, this doesn't qualify for me because my clients don't use Teams? Yeah. I think, you know, in the future, we we aim to be much more, omnichannel. And what I mean by that is we believe in in a world where all channels have a place and a time and and a a use that's best fit for that channel. And, really, it's about orchestrating an experience across all of those channels, right person, right place, right time, right communication style. So, you know, taking it back from the the grand vision, what that means for today is, you know, we do have a a desktop, application in the system tray that they can launch much like, a screen connect or, like, a lab tech, type experience, except it'll be branded for your MSP, and it'll feel exactly like the modality for your your customers who are in Teams or or Slack. We can also stand up a plug in on your website or their Internet. Really, it's about it's about meeting them where they work and, making sure that it's a smooth and frictionless experience, wherever that might be. Okay. One of the really important pieces for for that type of, like, agent based, communication, option, is a presence indicator. It was always one of my favorite things. Like, going back, know, back in the day, I built one of the largest linked link, practices. So the predecessor actually for Teams, was the the, MS Microsoft voice communication software. And one of the selling features that was so what's that? Was it Microsoft Office Communicator? Is that, my data? Yeah. Yeah. And Lync was was the product. Yeah. That I guess it eventually became. Yeah. I think it was communicator then link and then now, sort of MS Teams Voice. Yep. And, one of the the biggest selling features for that product is was the jelly bean indicator of software indication of whether or not someone's actually available. You know, to this day, this is sort of under leveraged, right, as people don't necessarily kinda capitalize this on communicating someone's availability. But, where I also found this really, really useful was, again, kinda using chat in the past was, having a presence indicator as to whether or not the person was at their desk to be able to reach out to them. And one of the things that we hate in the MSP ecosystem is telephone tag. It wastes Mhmm. So much time. Right? And you have this this support ticket and the sales guy says I need this fixed right away and every time you call him he's on a call with somebody else and he can't like, oh, I got I'm busy. I can't do this right now. Or the executive that is never seems to be at their desk because they're traveling and don't don't have time to help you with this. And there's some tools out there that will help you with the scheduling of this, but I really like the fact that these chat tools, you can sort of like scan through your tickets and see that, oh, this person is actually on their computer. I can push a message to them and say, hey. I see you're available. Can I support you with this right now? Boom. Like, cuts through all that noise. I have to assume this is well, I hope this is something that you guys are are gonna be able to leverage in as a an engagement model for those clients. Yeah. Yeah. So we don't have a presence indicator today, but it is very much, on the road map. And it's something that I I totally agree with conceptually in that, you know, the beauty of having a footprint wherever the user is is that the the need for phone tag or or email tag, right, goes away. You stay connected. You have access to them when you need them. It's not just them finding a an email address or a phone number or having to remember to go to a a customer portal to ask for an update on something. They can get it right in their workflow, and they can get back to you, you know, when it's convenient for them or, you know, same goes for for for the MSP, when it's convenient for for you all. You can get in touch when you know that they're available. Yeah. Right on. Okay. I'll I'll look forward to to to those that feature for sure. The, I guess the other piece to to consider here is rollout. Right? So, for organizations that don't have a current chat, support model, there is some consideration around, you know, how does this change support? Right? Like right now, we have to have people manning the phones. We either have those people or other people managing the triage of inbound email, and then we add chat to this. And, you know, I think the sort of the tricky part to this in people's heads is that it is live support in the same way that that phones is. Right? Like you can't just sort of get to it an hour or 2 later, not that you should in triaging and inbound. But, if someone opens up a chat request and have to sit there for it open for 30 to 45 minutes, I don't think you're gonna get a lot of love for that as a support feature. So it does require this sort of immediacy, that in my mind is really beneficial because these are the types of people that you wanna pull off of phone calls. Right? Because I've always suggested, like, you can have a triage person support kinda 2, 3, sometimes even 4 chats at a time without losing their their marbles. But, you know, you can you can literally only have one phone call at a time. So it automatically kind of doubles or potentially even triples the inbound workflow that you can manage it one one time. But, again, it does require that immediate sort of staffing and recognition of there are chats coming in. We have to have someone to be able to to sort of pick this up. So what do you suggest to people that are like, well, what do I do here? Like, how would I change my model? Do I have to, like, put additional staff just for chat? What does that look like in your mind? Yeah. And I think it it depends on I'm not going to end with it depends. Don't worry. But, as we well know, there there are few a consultative. Yeah. Exactly. There are a few models. Right? You you have more of your pod based, quick fix technician. You know, if I can fix it in 15 minutes, I do. If not, I pass it up the chain type approach. Or if you have more of a centralized dispatcher triage model where they're picking up the phone, they're triaging it, they're getting into the right queue, In both scenarios, I think it translates really well in that you dedicate a quick fix technician, to man the chat desk, so to speak, until you get a a sense of what that volume will look like, in terms of inbound, service requests via chat as you scale the the deployment, as you scale the footprint into your customer base. So that's a really good way to understand what the capacity requirements would or could be, into the near future and then build a model around that understanding of capacity. So that that's one way. The other, again, I think, as we think through the the shift from phones to chat, that's a very natural progression and one that we recommend because, yes, phone calls are incredibly expensive, not only for just the provider but also for, the company, you know, your customer and the user on the other side. You're you're both tied up for the duration of the call when you could or maybe you should be working on on something else that's more production oriented. And so, generally, we'd recommend having whomever would be manning the phones that shift or one of the resources manning the phones that shift, again, repointed to the inbox and fielding emails and chats out of there. So something else to consider here is, you know, AI, is exploding and, you know, it's showing up in pretty much every corner of the technology. And and, basically, anything that touches technology is is being impacted by AI. Chat seems like a very natural have to assume this is something you guys are considering. What do you think is sort of the future of chat with sort of the explosion of AI in the industry? Yeah. I I think the future, and it it might be closer than than many think, is that certainly with first party integrations where, say, you're connected to the Microsoft, environment and stack, you'll start to see end to end remediations whereby if you can capture the intent of the request, like, say, I I need to stand up a new, a a new group or a new team within my tenant, and I'd like for it to have this email address, and I'd like to add these members to that team, like low hanging but high volume, requests. You'll start to see the cost structure around that go from, you know, it doesn't take very long, but I still need a human to intervene and do the work, to I can handle it on a very automated AI driven fashion in the not so distant future. That's that's definitely a concept that we're working on, and we believe we'll have in place before the end of this year. And I'm I'm sure we're not unique in in that sense. But in the in the intervening time, there's, you know, things that that we and others are doing already, which is understanding the, typification, the categorization of their quest as it comes in. And then based on that, understanding the urgency and the priority of it and handling all of that, information gathering in an automated fashion so that by the time it gets to a technician, the baseline information is elevated, and they have a really good sense of what needs to be done before it it gets to a human. Yeah. So this is, I think, like, I I had said kinda 2 years ago that, my my AI sort of prediction timeline that so far is sort of proving to be true. I got a ton of pushback when I originally released this 2 years ago about sort of, like, thinking I was I was thinking too slowly, and I would say 2 years later, I'm kind of right on track. So I'll give you kind of my quick extrapolation of this. As 2 years ago, I said the first one to 2 years will be just, like, pure experimentation. There'll be a lot of things that are labeled AI, and it's just, like, people taking a stab at stuff and some of it'll look interesting but, you know, ultimately it won't really show up as a material change for a lot of people, a lot of experimentation. Then sort of that 3 to 5 year period is where things start to show up that are actually sort of like our true use cases where it starts to show up as side carts like tools inside of tools, where there's actually legitimate uses for it. And I think we're right at that stage where those things are starting to show up. And then, said kind of that 5 to 10 year period is where AI will, dramatically change the technology support landscape and ultimately decimate help desks. I think, like, over that 5 to 10 year period, it's messy as to sort of when that happens, But I can 100% see in the future where, you know, like, you don't need a full staff of help desk people because most of the things, like, like, if we extrapolate on what you're talking about of, you know, the there's an intent understood by the request and it just goes out and automates a bunch of stuff based on scripts and APIs. That definitely felt like a pipe dream for the longest time. Like like I'm an old school IT nerd where like in like 1998 and stuff like that there was stuff being sold by Compaq that labeled itself as self healing. Right? And then IBM got big into this in in the early 2000. And it's never really been true, but in the future, it will be. Right? So, I'm I'm curious sort of your thought on on sort of my mental modeling of that and what the implications of that are to sort of the MSP ecosystem of, you know, do you need a support support desk staff of 30 people or, you know, 10? Will that be sufficient? Because most of sort of that that, high volume, low complexity work is just being managed by bots. Is that sort of something that you envision in the future? Yeah. So I think your your timeline is is very astute first off, so kudos to you. You know, I think a lot of times people get excited about, leaps and advances in technology, and, we saw it ourselves. Right? We we brought the early v one of our time entry automation functionality using, OpenAI's, GPT 3 at time, I believe it was. And, you know, the light bulb wouldn't really go off. We'd show people and we'd be like, this is so exciting. Look, we're we're writing the time entries for your team. And, you know, we would we would get very muted response back. But then when ChatCPT became publicly available and there was the big kind of groundswell of excitement around, around AI and use cases of AI. Then all of a sudden, we're getting, you know, prospects on demos saying, well, why doesn't it do this? Why doesn't it do this? Why doesn't it do this? And so, you know, definitely embrace the creative the creativity of of MSPs and folks in the channel. It's something that we love about working with, about, with MSPs is is the knowledge sharing and the creativity and solutioning. But, but yeah. So back to the original point. I think your timeline is just about right on, and I think we'll start to see, we'll start to see design patterns where you have multi, what what first, you'll have agents which are designed to handle a very specific function or subset of functions, repeatedly. And then we'll start to see, design patterns where you have multi agent workflows and experiences. You might have, an agent that's a specialist in desktops and an agent that's a specialist in, networks, collaborating together ultimately to to to, solve a problem, with no or low human involvement. And I think what that looks like and means implication wise for for the channel over the long term is that you'll start to see very well scaled operations whereby a team of 10, 15, 20, can do the work and have the reach of what used to be what used to take a 40, 50, 60 person shop, if not more. So it's exciting, but it does change the the nature of the work, in in a sense. And so those who can navigate that evolution and stay ahead of the curve, I think, are are going to be really well positioned. Yeah. I think, like, I don't mean to sound sort of like, Chicken Little about this of, like, everyone's out of a job because, you know, AI is coming for your help desk roles. I think there will be some of that. I think a lot of it just forces an evolutionary change of the industry. And the the way that I sort of like like explain this backwards is similarly like when we were building, these, MS communicator and link practices, This was when BPOS, the, like, business productivity office suite, the predecessor of of Office 365 and now, M365 was rolling out. And I would have chat with chats with industry executives that are like, you don't understand. Microsoft is stealing all of my money. Do you realize how much money I make on exchange upgrades and maintenance and hosting? It's like, well, okay. You can go throw yourself on those gears and and try to maintain a hosting business with Exchange and doing project upgrades. Similarly, you know, why does anyone wanna fight to maintain the help desk if they don't need to? We're talking about really long time cycles here. I'm not saying these people are gonna be out of job in 2 years. Like, this is an this is again an evolutionary change to the industry where, like, there'll be lots of other jobs opened up. And I a lot of ways, I see this as sort of a return to the mean or a circle about what we're doing is a lot of what we do goes back to consulting. Right? Like your human skill set and your consultative skill set will be far more valuable than than your general technical skill set because that stuff just won't be as sort of necessary or unique as it is right now. Because a lot of it will be filled by agents. But, you know, who can go out and have consultative conversations about all these wild technology changes that are happening with humans that don't know anything and don't care to know anything about technology. That's where the business will sort of evolve to. Right? Yeah. And and I think it ultimately just it changes the nature of the value that you're delivering to to your customers and to your partners. I think you're spot on. It's it's how then do I, take the knowledge that I've gained in orienting that, technology to give give leverage within my, my MSP, my consultancy? How do I then, orient that towards my customers and help them gain leverage within their operation? And I think that totally changes the the calculus, so to speak, and and the value proposition that we're we're we're able to offer to, to businesses everywhere. Yep. So I mean, it's a cool space. Right? Like, I always joke, like, you know, if if you like things to stay the same, technology industry is probably not for you. But if you like an industry that's so dynamic, everything has a 6 month shelf life, this is a great spot for you. Right? And that's that's the nature of being in an IT service industry is is the only, the only the stability you have is that things will change. Right? Like, it's it's, it's fun. Like, all of these things that will shift the industry and have to adapt. If it were easy, it'd be boring, and everyone would be doing it. So this is where the margin gets made, basically. Right? Yeah. It's great for my ADHD. Yeah. That's right. Along with everybody else in this industry, for sure. It's like, like, maybe that's part of the reason that there there's a bit of a, a bit of a bias as those people showing up in this industry is it's just tuned exactly for you. Right? Exactly. Yeah. Getting, yep, getting engaged in change. Oh, it's a good thing. That's right. Cool. So, we'll throw in some links and everything to to yourself, Matt, and to Thread. Any sort of parting words of wisdom, that or, requests to the audience that you would suggest they check out? Yeah. I mean, I would just say get stay engaged with the technology. We we've learned so much by standing up proofs of concept and and speaking with our partners and and in some cases, their customers to understand how are you thinking about it. It is this design pattern feasible and realistic for how you foresee the use of this technology within your business in the future. And I think the more you have those conversations and, you know, you you you find the areas in which you want to invest and believe that, the the better, outcomes that that you'll have, going forward. So that would just be the recommendation is is stay engaged, stay in touch, keep tinkering, and you'll end up, with a good answer. Awesome. Appreciate your time, Matt. Likewise. Thanks, Todd.