ERP109 - The Magic of Chat

Welcome to Evolved Radio Podcast. Join us as Matt Linn, the COO of Thread, shares insights from his journey from account management to spearheading innovative chat solutions in the MSP space with Thread. We'll explore the dynamic integration of internal ticketing systems with platforms like Microsoft Teams, address the real-time benefits of chats for triggering workflows, and consider the pressing challenges and opportunities of evolving chat support models in the MSP industry. We'll also explore how AI will have a major role to play in chat support. Don't miss this engaging discussion on the critical role chat platforms play in IT support and how it's set to revolutionize the IT service industry.

This episode is brought to you by Evolved Management Training Courses.

Online courses specifically crafted for MSP needs. A Service Manager BootCamp course, a project manager for MSPs course, an MSP security fundamentals course, and an IT Documentation Done RIght course.

What is Evolved Radio?

Evolved Radio Podcast: Interviews with technology experts, industry thought leaders, business leaders and other interesting minds. Exploring the evolution of business and technology.

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.