SPEAKER_00 0:02

What does it actually cost your business when the most important knowledge in your company lives in a few people's heads? It's probably way more than you think. Misordered equipment, delayed invoicing, scheduling fire drills, frustrated clients, and burnt-out employees. It may not show up directly as a line item on your PL, but it all adds up. In this episode of Insights, I'm joined by Jason Sayan for a conversation about exposing the invisible work that quietly erodes your operations as the business grows. We cover the real cost of miscommunication, how to design standardized processes that actually hold up to the fluid and dynamic nature of CI work, Jason's five-layer framework for unpacking any process before you document it, why new software tends to expose process problems rather than solve them, and how to fix the product-to-service handoff that trips up so many companies in our industry. We also get into why AI has made process documentation more valuable than ever, and how getting things out of your head affects what your business is actually worth when it's time to sell. As always, this conversation was recorded live with an audience. For a link to the video, check out the episode description. If your business still runs on tribal knowledge and you're ready for a better way, this episode is for you. Let's dive in. Alright, we are live. Hello, everybody. Welcome to the September edition of the Insights Podcast here. I am your host, Jason Griffin, Director of Product at OneVision. I am joined by uh Jason Saiyan today, a fellow Jason and a fellow bald Jason in a black shirt, nonetheless. So hopefully all can keep us straight today. Uh Jason is the founder and process architect at IM Saiyan, where he helps companies uh expose the invisible work that's quietly uh breaking operations, you know, and driving scale and growth without the burnout that so often comes with the territory. So Jason is a process architect and a master of this domain. We're looking forward to diving into some of the core frameworks and concepts that he teaches his clients so that you can go back and apply them uh in your company right away. Jason, thanks so much for being here.

SPEAKER_02 1:57

No, thanks for having me. I'm super excited for this conversation.

SPEAKER_00 2:00

Yeah, absolutely. So uh give everybody just a quick preview of coming attractions, just some of the topics we're gonna uh touch on today. We'll keep things loose and conversational. And by the way, I'll take this opportunity to remind everybody that we love two-way dialogue. So if you have any questions, comments, feedback throughout the course of our conversation, please do drop those into the chat. And we'll do our best to address all of those either in the moment or at the end of the webinar. At a high level, some of the topics that we want to touch on, why new software tends to expose process problems rather than solve them, how to turn tribal knowledge into workflows a team can actually follow at integration companies. We've got a lot of knowledge often trapped in our heads. Uh, how do we convert that into knowledge that the team can actually uh use in a scalable way? Um, where operations most often break as a business grows, starting with the handoff from sales to production. That is a big one as a former integrator. I know that closing out projects and getting those over uh into the service department is a huge challenge. And then we're gonna touch on AI. There's some very cool overlap, I think, Jason, with what you're doing and process architecture and how that can be used as sort of rocket fuel for um AI operations and AI agents for those who are interested and diving into those sorts of topics. So again, really looking forward to the uh conversation. Uh, to start things off, Jason, I'd love to set the stage. You know, as a product person, I often think in terms of customer problems. And so I'd love to start out by having you rift on riff on like what is the real cost of communication breakdowns? Like when you go into an integration company, they've brought you in to help them get processes in order. Fundamentally, what problems are these businesses experiencing that you can help them solve?

SPEAKER_02 3:40

Yeah, no, it's and it's a great question because I think as as business owners, we look at metrics like top-line sales and profit margin and hopefully net operating income. And most of those things tell us how good we're doing or, you know, maybe how bad we're doing, but um it really doesn't tell us about that cost. So I came across a stat uh a couple of years ago from Grammarly. They did a study that showed that in most companies, uh miscommunication uh costs companies about $12,506 per employee per year. And not just for miscommunication, I like to tie in uh more to that, which is invisible work, right? Invisible work, which is the things you can't see, spreadsheets people are using, unclear handoffs, unclear roles, that's all invisible work, like stuff's getting done, we don't see it. That feeds into that miscommunication number. So if you look at a company with 10 employees, that's 125 grand a year. And when I talk to people about that, I pull from my past experience as a manufacturer's rep. We we sold a brand called Future Automation. Everybody knows their products, their great products, but every month somebody would call us and say, we just got a lift that um got ordered incorrectly. And uh now we have this $18,000 lift sitting in our warehouse next to a pile of shades that got misordered incorrectly. And there is your $125,000. And I say that jokingly, not to make fun of people. It's just the reality. And it's funny, uh, on a side note, I was at a conference this spring and I talked about that. And afterwards, somebody came up with their phone and said, that's my warehouse and that's that future automation lift. So those are real numbers, right? And I think that, you know, what we don't think about is well, we'll just go sell more. And, you know, fortunately, our industry has really good margins on products and labor. Um, and it affords us to run inefficiently because we still make money. But if you look at like net operating income and uh say it's 10%, which is actually high, you'd have to go sell another $1.25 million to make up for that $125,000. Um, and those problems are going to get worse and that number's gonna compress. So what if you could just cut that number in half from operating more efficiently without having to sell more? Like that's probably the right path to look at.

SPEAKER_00 5:54

Right. Right. And you know, there's like as a former integrator, this this resonates, and it's not just the you know, the bottom line and the money uh impact as real as that is, you know, there's also the whole um human factor, the toll that it takes on your team in the form of increased stress and strained relationships and uh just all of that friction that goes on in the company. I'd love to hear you talk about that in terms of like an integrator who is struggling with process, because I feel like sometimes it's not always totally obvious that like broken processes are the problems. You can sort of write it off to like, oh, it's the nature of the business, things are just crazy right now, you know, whatever it is. There's a million reasons why maybe this is happening. But what are some of these other like more human symptoms that you see in integration companies where processes are broken and how can integrators recognize those?

SPEAKER_02 6:46

Yeah, it's everybody thinks, you know, when they feel friction in the business, they say it's time to document our processes. And while that's true, it also feels like it's permanent. And we're literally going from stuff that's in people's heads that hasn't really been clarified. So, you know, what you really seek is clarity, clarity on how the work gets done, clarity on who's responsible, clarity on how software is supposed to help us. And once you've identified that clarity and that invisible work, now you can improve it and then document it. So simple things like I was working with a company a couple of years ago in the workshop. We, you know, at a high level, I asked everybody to share where there was friction. And the CFO says, Well, I got a $20,000 check sitting on my desk and I can't deposit it because I have no invoice. And I'm like, that's pretty interesting. Why don't you have an invoice? Well, the sales team didn't attach an invoice to the check. So I asked the sales team, why doesn't she have an invoice? And I got three different answers. Everything from, well, it was Friday and we didn't want to leave the client's house with uh without money, and they agreed to the proposal. And then I got, I didn't know it was our job to actually create an invoice. I just thought I was doing it to be nice when I had time. And then the third one was, hey, I'm new, can somebody train me how to do this? Like that didn't require an SOP, that just required clarity from all the people involved in the process just to get on the same page. And you know, it probably was happening four times a week. So, one, it affects your cash flow because you can't deposit money in the bank. Two, somebody's spending all this time chasing people down for invoices. Like, sometimes it's just that simple.

SPEAKER_00 8:17

Yeah, yeah, it doesn't have to be overly complicated. And uh that segues into a question I want to ask. But before I do that, I'm gonna launch a poll and would love. So if you're live with us today and you're on the webinar, I'd love if you could just take a few seconds to uh drop your input in here. We'd we'd love to get a pulse for how how folks on the call are feeling about this. How would you describe your team's current documentation? So there's a few uh options up there, you know, mostly in your head, solid, it's written down, some exists. What's documentation? Uh so we'll see, you know, as those answers come in, and we'll come back to those shortly. While we're waiting for those answers to come in, Jason, I'd love for you to talk about um like I alluded to this before, and I'd love to go one layer deeper on it. There's as a former integrator, I feel very viscerally the reality of a lot of integration companies where the work is custom and extremely dynamic, and there are lots of things out of your control. For example, a general contractor calling you on a Monday morning out of the blue and saying, We need you guys, we need you guys here this week, right? Like the, and that's one example. These things sort of happen all the time. As somebody who's trying to go into these companies and get people to think more about process, how do you reconcile the very um you know difficult realities of this industry where it can be it can feel sometimes almost impossible to say we have a standard process because things are just so fluid and so dynamic and gosh, it just feels like we're constantly on our heels and and reacting. How do you uh square the circle there?

SPEAKER_02 9:47

Yeah, no, uh again, great question. I I try to tell people like, listen, because we think of process as black and white and it should be, but we're just trying to have structure so we can manage exceptions, not be managed by them. So if we have no process and no structure, guess what? Four out of 10 times, the project might go great, but those other six, it's just gonna pull us every which direction. Whereas if we have like a general structure and framework, and yes, it's documented, but it's again, we we have it so we can manage the exceptions, not be managed by them. We might be able to now at eight out of 10 times execute the project the way we want. And again, I know we are in custom, but there are ways to filter and kind of control those aspects and have stage gates to catch things before they become a bigger problem. I spent most of my career in manufacturing, um, 10 years at JL Audio. We built stuff here in South Florida. And so I was constantly watching assembly lines and how they applied this, where there was clear stage gates on where stuff had to get checked before it proceeded, because otherwise it becomes a bigger problem downstream. So if anyone's gonna take one thing away from this entire webinar, it's think of your business as a production line. Like things have to go through a certain set of steps. Otherwise, if you skip or go around it, it creates problems. You already know this. And most of those things in production are just things that started upstream. They're not actually production problems.

SPEAKER_00 11:10

Yeah, yeah. I think I think that's a good way to frame that up. I'm gonna end the poll here and share the results. So it looks like uh out of our participants here, uh, the majority, 53%, say some of it exists, but it's outdated or scattered. And then second place, most mostly in people's heads. We've got a small portion of folks who have solid documentation that's written down, and then a couple brave volunteers that were uh, you know, chose the what's documentation option there. So uh Jason, I'd love for maybe you to react to these results. Are these pretty consistent with uh with what you see out there when you're out there working with integrators? Give uh the folks that are live with us today a sense of of kind of where they sit relative to what you're seeing out there in the market when you do this every day.

SPEAKER_02 11:55

Yeah, I mean, I think this is spot on. And first, what I'll say is like, listen, it's natural. So don't think because you're low on that percentage, it means you suck as a business owner. It's the nature of starting a business. Um, read the emyth contractor. It was a book that really got me started on process. It's a simple read. Um, and even other businesses I work with in different industries, they all struggle, right? Like as a business owner, you found something somebody was willing to pay you for and you figured out how to deliver that. You never sat there and documented it, right? But at some point you have to. And usually the documentation that is not fully complete, as people laid out, is because it was trial by fire. Like they just got fed up with the fire that kept being created. So then they created documentation to solve it. Um, but now it's gone beyond that because a folder full of SOPs doesn't solve it. Um, and you have to operationalize it. And so it's it is complex, it's hard. Um, but if you don't do it, the problems just keep coming up.

SPEAKER_00 12:56

They just keep piling up. Yeah, there's a few comments in the chat. So Angel said some people document, some people don't. Andrew said what we have is solid, but we're quickly learning that we need more as the team grows. And then Chris Smith pointed out, you know, it's also not one and done. As the team grows, software changes, you know, it's time to redo it. So yeah, it is these things have to be living, breathing, uh, artifacts, and they're all the processes around this is kind of a meta point, but the process of keeping process documentation is itself a process that has to be enforced and looked at over time. And to Angel's point, you know, making sure people are consistent about it. If an integrator is out there and they're like in this position of, hey, we have some, or maybe we're starting from zero, are there recommended starting points that you would give to somebody who's like, hey, I really need to get my house in order, but I feel like I'm getting pulled in so many directions and I can't stop everything I'm doing and spend like hours on end figuring this out. I need to uh do this iteratively and start small. Do you have tips for like how people can get started on that journey?

SPEAKER_02 13:59

Yeah. And one thing I'll just add to kind of the comments and the poll is you know, if you're feeling the friction or if you have stuff that's outdated, most likely somebody doesn't actually own this and somebody has to. And if you, the owner, don't want to, put someone in charge. And honestly, a lot of times I work with companies and there's usually someone who's kind of a process nerd or documentation nerd that's just hadn't talked about it and that wants to own it, but somebody has to own it. And once someone owns it, it's actually easier to keep things updated. Um, you know, it's update as needed because this problem keeps surfacing, or look at it quarterly, or look at it yearly. It's really not hard, but somebody's got to own it, and then you have a process for the process. Um, but yeah, and then as far as how to get started, like look at your business and and just create some simple uh phase gates, right? Like there's a proposal phase that your your business goes through. There's a, you know, call it engineering project kickoff phase, basically the phase between we sold a project and we got to start installing gear. And then you have production and you could break up production to pre-wire trim and final. And then after that, you have service. And within those buckets, like where is the biggest pain point? Like, where is the biggest problem that keeps surfacing? And again, you might find problems in production, but what are those root causes? Like, what caused those to happen? What process broke that is now creating you to do 20 change orders on a job? It was probably a bad scope of work or bad handoff to production. But honestly, what I would do is I like I would write those those things on a on a whiteboard proposal, project engineering kickoff, and then your phases and service, right? Your production phases, and um, hand your team post-it notes and say, write down where where the biggest pain points are. They're gonna tell you where it is, and then you can have a healthy discussion on what's breaking, not who sucks, right?

SPEAKER_00 15:48

Yeah. Yeah, I like that point about really thinking critically about it. Like, don't mistake the problem, don't mistake symptoms for root problems, right? So you may have a symptom downstream in your production uh workflow that if you're just focused on the symptom, you might miss that the root cause of that consistent breakdown is actually happening upstream in your process. And I think that's one of the ways where having this all visualized can be really helpful. I know for me, I'm a very visual thinker, and I like to have things in front of me that I can look at and sort of get my hands on, so to speak. And so I think like visualizing that can be really helpful. There's another uh point that I've heard you make that I think is really important, which is has to do with the fact that a lot of people, especially, I presume, when they first get started down this path of doing process documentation, might try to might over-engineer it accidentally or try to get too detailed. And I think this goes back to the question I was asking earlier about how do we do this in when the nature of the work is so fluid and dynamic. Talk about the level of detail, like the level of abstraction that you should be flying, the altitude you should be flying at, so to speak, when you're looking at processes. And do you see a common failure mode maybe where people are trying to get too granular and too detailed in their process documentation?

SPEAKER_02 17:05

Yeah, that is that is definitely a big problem. If someone has gone from we've identified the problems and now we need to document it and make it permanent and put it in this piece of software, whatever it is, then that's the next area they get stuck, which is like how detailed to I get. And there's two kind of two aspects of that. One is people are trying to write something that's so detailed you can hand it to a five-year-old. And we're not hiring five-year-olds in our business, right? We're hiring competent people that have skills. Yeah. Um, so it should be written on the level that you can hand it to that person that has the skills. They may not know how to do the job, but they have the skills and they can do the work. So, like your bookkeeper's out, right? But Jason, you know how to use QuickBooks. Well, the SOP should teach you how to go run an invoice. But if you don't want to use QuickBooks, like we're not going to write an SOP that shows every little detail of QuickBooks. Um, within that framework, I like to say separate skills training from job training. These SOPs are just training them how to apply their skills to do the job, right? If they need skills training, they can go do that. They can go watch a webinar and watch a YouTube video. Now, some companies actually want that layer of detail, but I wouldn't start there. Like the SOP should train them how to do the job, right? And it should be training a uh you should be able to hand it to a competent person that has the skills to do it. So that's one kind of like framework that you should use as your as a filter. Like, am I just, you know, is this too detailed? Is this can I hand this to someone, or am I just trying to write too much? The other one is um they're trying to solve for future problems, right? Like, well, you know what? Once we do this, we're gonna need to do X, Y, and Z. So we better build that in. Well, guess what? When are you gonna do that? Like, solve for today's constraints, right? That's gonna make your team operate better, help morale, it's gonna help your profitability. And then as you see, you know, as you get to that future state, now you're trying to update. That's why somebody has to own it or or monitor where these problems are surfacing to go back and rewrite it. But you know, write for the to train them how to do the job and solve for today's constraints. Don't try to solve for the future.

SPEAKER_00 19:10

Yeah, yeah. There, there's a couple things there I'd love to react to. So as far as the level of detail, I know like internally at OneVision, we practice EOS, which is an entrepreneurial up entrepreneurial operating system, fairly popular in the industry. And one of the constructs in there is core processes. And EOS is very explicit about saying core processes are called core for a reason. You're not trying to document everything in your business, but you're trying to document the core, most important functions at a level that, like, if some, you know, the proverbial like bus test, if I walk out of my office and get hit by a bus today, like can somebody at least have some sense of where I am going to do things? And again, it's not about documenting every little step, but it's about understanding, okay, we invoice in QuickBooks, there's maybe multiple projects or one project per client, or you know, whatever those high-level things are, just to at least get the person on the right path and then trust that they can, like you said, apply their skills. I love that breakdown that you gave of like job training versus skills training. Um I think, you know, I think that's really useful. Uh and so ultimately, uh, I'd love to, you know, shift gears here and maybe get a little bit more practical. Uh, you've got a framework, a five five layers kind of framework that you shared with me that's something that you show your clients, uh, I believe at the outset of engagements to help sort of put put some uh put a model in place for how we think about process engineering. So I'd love for you to just give us a quick uh thumb, you know, thumbnail sketch of what that five layers framework looks like, and then we can jump a little bit deeper into the different components of it.

SPEAKER_02 20:48

Yeah. So um let me make sure I have that file open because I got another one I want to share. So this kind of came from my time at JL Audio. Again, I gave tons of tours, I was constantly staring at this assembly line. I saw the benefits of just these stage gates of allowing them to build better product and faster. And so I use this framework to think about process because, again, in our business, it's so easy to get lost in the process. We're invoicing and we're building uh racks and we're ordering equipment, we're engineering, and it just feels like it's all in just this one huge area as opposed to breaking it up. So once you've identified, you know, you take the concept that I shared with you, or you just know there's an area in our business that we need to um unpack before we document. This framework can help you. So once you've identified it, let's just say it's invoicing a client, right? The first question is like, how does it start? How does it stop? Where does it get stuck? Right. And that creates bookends of the process. That's the hardest part I think most people have because they don't even know where to start or where the process starts. So how does it start? How does it stop? There is your bookends. Again, some Something simple like invoicing, what's the trigger that triggers us to invoice? That's how it starts. And then what's the stop? That's why we get paid, right? But once you have the bookends, what are the what are the tools that we use? What are the checkpoints? What are the steps in between? That's where you can get as granular as you need to. Somebody says, hey, we need to invoice the client. All right, what are those steps? And again, using those two kind of filters I said of like how detailed do you need to get? Don't solve for future problems. Why is your standard? Why do we do it this way? Why do we send an invoice within 24 hours of being notified? Right? Those are your standards. And again, there's a stand, there should be a standard for every process. Who's responsible? Right? Who is doing this? And that could be multiple people. And again, we're using this to unpack the process because if you're sitting with the team that's involved in invoicing, you might find out there's three people involved and there only needs to be two. And then last is the system, all the software that's used. And that's last for quite a few reasons. A lot of people try to solve process problems by adding software. And software is a tool to make your process more efficient. And so if you can unpack through these layers, it's much easier to either optimize your software, align it with your process, or actually go find net new software because this is what it needs to actually run better. But you this is what you can use to unpack it. You can do it in a whiteboard, you could build a process map. But like if I ask somebody how do you invoice a client, they're just gonna like brain dump a bunch of stuff and you're gonna miss a lot of steps. But this specifically forces you to think through it and unpack, you know, not just what's happening, but how it happens today and all the waste.

SPEAKER_00 23:35

Yeah. Yeah. And I I I'm willing to bet, like to your point about starting small and not solving for future problems, this is something as a product person, we think and talk about a lot is like, how do we just get something out there, get version one done, don't over-engineer it, get something out there that you can iterate on and get feedback and so forth. And I'm I'm willing to bet that if integrators picked one process in their company, to your point earlier, like where are things routinely breaking? Where are we experiencing problems? Schedule an hour with whatever it is, two, three, four key stakeholders around that process and just go through and ask how, what, why, and who. Just that conversation alone would probably drive a tremendous amount of clarity into that process and at least give you a starting point, like for for um, you know, a jump-off point from there. Would you agree with that?

SPEAKER_02 24:28

Yeah. The other thing it does is it keeps it structured, right? Like we don't want to pull our team off a job where it's unbuildable hours, and then all of a sudden we opened up Pandora's box and we're ordering pizza because we didn't get through it. So if you if you stick to this, it actually one, it gives you the information you need, it surfaces all the bottlenecks, and then it also like you could do this in an hour, maybe even faster. So, like the common one, and we're gonna show an example with an AI agent how this translates later, but like project handoff, right? Like, how does a project project go from sales to production? How does it start? Is it when you get paid? Is it when the client agrees? Well, some people do both and they start before they get paid. Some people skip it, but like that's a great question we need to define. But like once you define that, all right, what do we need to do in that project handoff meeting? Well, we need to review scope, we need to review plans. Like, again, you can brain dump those things. What's our standard? Like, why do we do it this way? Who's all brought into that? Do we have software tied to it? And then what's the end point? We go order product, we go schedule the client, we go check the job site. Boom, you just unpacked your project handoff. You can use that to create an agenda. You have a checklist, like it can be that simple.

SPEAKER_00 25:38

Yeah. You've mentioned software a couple of times. I'd love to uh ask you a specific question about that. We alluded to this at the beginning of the webinar and also got a a question from the audience ahead of time, which was uh basically, you know, John Reeves at EMC Security said, I'd be interested in hearing how new software tends to expose problems rather than solve them. This is something we put in the promotional text for this. It's something that you've told me multiple times. I can intuitively kind of guess where you're going. But I'd love to hear that in your own words. Like you mentioned that a lot of times you're working with clients and they're like, we need new software, but the software is actually not gonna solve the problem. And in fact, it might make it worse. At least that's your perspective on it. I think. Feel free to correct me if I stated that wrong, but riff on that idea and help us understand like what you mean when you say that software can actually make the problem worse in some sense.

SPEAKER_02 26:31

Yeah, so uh I'll leave names out to protect the innocent and I'll also say that there is no magic software, there's a magic process. So, like recently, I was sitting with a client and again using a visual workflow because it triggers your brain better. And we start asking questions like, well, where do you store project files? And like, oh, we use OneDrive, and you know, how do you invoice in QuickBooks? And how do these things happen? And then we started asking how does that happen in the software? Well, they don't integrate with OneDrive. So we're gonna have to store project files in their storage solution. Oh, okay, so that sounds like we need to train and now we have to do things differently. And maybe that's gonna work, maybe it's not. Um, oh, they don't have two-way sync with QuickBooks, they just have one way, and that's gonna mess up our accounting practices. Okay, so that feature's not gonna work. Um, they don't have a direct way of communicating on projects, so we're gonna have to go back to text messages or we're using Slack and they don't integrate with Slack. So, like, okay, so now information is scattered in multiple places. So you jump to software and they're gonna sell you on all the features. Some of those features work, some of them don't quite work, but they'll call it a feature and an integration. But asking the questions of like, how does this actually happen in the software? Because you're trying to align the house. Like, how do you store project files? Because this is how we do it. That's either gonna work or not work. If you don't ask those questions, next thing you know, you have to change your entire process. And then in some cases, like that's gonna be more disruptive than just having a better tool that builds better proposals, right?

SPEAKER_00 28:01

Mm-hmm. Yeah, that's a great point. And I think like change management is something that I've done a lot of in my career. And uh one thing I've learned is that it can be very difficult at the outset of a project to anticipate all of the second and third order effects that a given change is going to have on the company. So like correct this if you feel like anything I'm I'm saying is misstating your point. But one interpretation of it, my interpretation of it is if you start with like, okay, I've got this particular problem, I'm gonna go get a new piece of software to solve it. Like, what you're ultimately actually gonna end up doing is maybe you solve that one problem that you had, but you create five others because you went into it and you didn't actually fully understand the entire process around the uh what the software is aimed at. And if going into that process instead, you had a clear document or process map of like this is how everything related to this part of the business works, then you can hold that up against the new software. And at a minimum, you can be sure that you're asking the right questions and you don't have like gaping blind spots in terms of how you're um analyzing this decision of whether or not to change software.

SPEAKER_02 29:13

Yeah, like this happened recently with a client, really small integration firm, and project management was a big challenge for them. Um they're they're still using you know group text messages. It's again really small company. You could easily say, well, we need new software that does project management. Well, if you don't really have a project management process now, now you're forced to follow exactly how they do it. And that change management is going to be hard. So I found out they were actually using Slack. They just weren't using Slack very well. I'm like, okay, but you already have that software and we're just not holding people accountable, and it's probably not set up very well to get the benefit that you're trying to get. So something simple of just setting up project channels, which a lot of companies do, using the lists in Slack as a way to manage things, and no more texting. All the pictures and files and everything goes in that channel. So there's one place, those are things we surfaced. And three days later, like they're up and running, like they're already seeing relief. So it was again, go it goes back to like documenting. Like, don't try to solve for this future of we're gonna have we're gonna go from six employees to 15. So we better have this robust software. You don't solve for today. They just moved into Slack, they're already running better. And guess what? Now, when they graduate to something more robust, they have a process and a structure they can easily adapt to.

SPEAKER_00 30:30

Right, right. There's a question in the chat that I uh would love to hear your take on, and I I can share what I've seen as well. Pat Ward asked, uh he said, I've heard of you know companies out there writing their own software to align their uh basically to build the software uh around their current processes, like with AI, this is now theoretically possible where it was never possible before. I'm curious, are you seeing this out there? Are you seeing clients do more of this custom software thing by spinning up Claud Code or Codecs and building things instead of going out there and shopping for off-the-shelf tools just building their own?

SPEAKER_02 31:05

Yeah, I've seen a lot of it. And I've seen some stuff that I wish I could share more because it's like so cool what people built. Um, and then I've seen people build basic stuff. Like um, to me, I still think you should still have enterprise grade software. Um, there's benefits to that because a lot of companies are building MCP connectors or even with their APIs and just use AI as this invisible layer. Um, so things are porting back and they can actually transport the data the right way. So people don't need to be in QuickBooks, but they can actually be in Slack asking questions about payment and they get all the information they need. Like, why reinvent the wheel? But listen, I've seen some people build some pretty cool stuff on their own too. Now you got to maintain it, you got to have data governance, like be careful what you're building there and what you're exposing it to. And you know, um, I was having conversations at a conference this spring, and there's multiple owners that have built 10 agents and all these cool stuff. And it's like, but guess what? That's like you just hire 10 employees and they all report to you. You're potentially building the same potential bottle deck you have. So you can do it and it's cool, but be very careful with how you execute that.

SPEAKER_00 32:12

Yeah. Yeah, I think that's a good perspective. And I would echo that. I I've definitely seen more uh folks out there building their own custom solutions, and uh, I think that's great. I mean, I it's amazing. I'm a huge AI user, I'm building my own little apps for various things from time to time. But I do think that it is, you know, you need to be selective about it. And I think like be careful not to reinvent the wheel. And I am increasingly seeing like the maybe if you asked me this about a year ago, I was kind of like, oh man, I think professional SaaS is in real trouble. And now that I've done more with it and I've seen like the limits of it and what's really involved in maintaining things, uh, you know, ultimately I see more of a future where a lot more people are building custom solutions, but they're not necessarily replacing the software tools that they're using. They're acting, like you said, as that glue or that invisible kind of operational layer that has hooks into your various systems of record and gives you one place that you can interact with all of those things, you know, through things like AI agents. So it's really interesting to see how that's playing out.

SPEAKER_02 33:14

Yeah. I mean, essentially those pieces of software just become the database. And then you can create a separate database so you can reconcile the Ryan Smith job and the Smith Ryan job because it's marked different, different pieces is the same, but they already have a really good robust uh database. Um, and and I want to point out something Ryan Larkin said in there, which is he's having success using AI, but the last part of his comment is extremely important. He's inputting existing SOPs, job roles, best practices. AI needs context, just like your employees. So you could open up Cloud Code and tell it about your business and share your website and actually knows quite a bit about custom integrators. I mean, you could ask AI flat out to give you a Lutron centralized lighting control checklist and it will do a pretty good job. But if you don't give the rest of the context, it's just gonna give you slot back. So, like you still need the thing we talked about started with, which is some sort of framework structure, best practices before you go building that up software. Otherwise, you're gonna create a bigger problem.

SPEAKER_00 34:16

Yep. I I say it all the time. Context is king. And uh I think the companies that understand that and really internalize that at a deep level are gonna be in a really advantageous position because you've got to get your house in order, you've got to have your processes documented, you've got to have clean data that's governed and accessible for these agents, and then they can do magical things. But if you don't have that context layer right, uh, then I would say it's all for naught. I would love to shift gears uh as we come down kind of the back half here and make this a little bit more tangible. You mentioned earlier we've got an example that we wanted to jump into and talk about how some of these concepts map onto a particular challenge. We pre-selected one that we think uh pretty much every integrator out there is going to be able to relate to, which is this idea of closing out a project, handing it over to service. This is something I know is a really endemic sort of challenge uh across the industry. So, Jason, I'll let you sort of tee things up here. How do we put some of these concepts into practice around again this idea of like the project-to-service handoff?

SPEAKER_02 35:17

Yeah, yeah. I and I again, I'm a big visual learner. Most people are. Um, we process images 60,000 times faster than words. So when you have something visual, people kind of get it. And so um, this was, you know, I was uh using my framework to help a client with identifying weak points with an agent. Now we didn't build this one. I use this example because it comes up a lot. I was running some uh roundtables at some conferences this spring around the handoff and uh was in some peer groups. So I thought it was relevant. And actually, um, shout out to Ron Callis and his podcast. He did one um uh right before CEDIA with Jason Barth, and I forget Jason's company. I think he's in Indiana in uh somewhere in Indiana, but he built this, which was we don't have anyone that can spend the time of compiling everything that a client needs from warranty information to product catalogs, and they automated it. Um, so I kind of used his idea. Um, but again, project closeout, the gap from going project close to service handoff is a struggle for most people. So again, if you run it through your framework, which is again, how does it start? How does it stop? Well, when final QC is signed off and service says we got it, like hopefully services coming on site saying, you know, they get introduced to the project, they know where all the stuff is. That's your trigger point. What happens in between, right? Client gets trained, they get trained on service, whatever all those steps are, what are the whys? What are the what are the standards? Who owns it? What software is used, like where is it marked that it's been signed off? Is that in Slack? Is that here? QuickBooks, how does all that stuff happen? And then that can feed into building the agent. The agent gets the trigger, project complete, it already knows the handoff package it needs because you have to create that documents, warranty, whatever. Um, and again, all of this feeds the logic. You have to have a human in the loop, and then you know, some sort of success measure follow-up with the client. So again, using this as a bookend and then feeding that into the agent. And this is like super high level. Um, I don't really build agents, but they need that operational context, right? If you were gonna train someone to do a proper handoff to service, that's all the stuff they would need. Run it through the layer framework, create that, and then now you can go and kind of build that agent.

SPEAKER_00 37:33

Yeah. I I think you mentioned that you had put together some sort of uh a markdown file or set of like starter instructions that we're gonna share out with everybody who uh registered for the webinar today. Let's let's jump into that and just give folks a preview and give us some sense for like uh what you've built that and how it might be useful for somebody who's attending the webinar to take that as um you know just something that they can go uh play with and and implement on their own.

SPEAKER_02 38:00

Yeah, so sorry, thought I had that open and I didn't.

SPEAKER_00 38:04

Um no worries. We're doing it live. Different screen.

SPEAKER_02 38:11

Yeah, so um we will share this. So this is the PDF that walks you through it. But if you have a handoff process or maybe you don't at all, um I took a SOP checklist that I've created with a lot of my clients that covers the majority of what you need to do and put that into a markdown file. And you can use this to in the markdown file, basically upload it and say, let's get started. And it's gonna interview you about your close-offs process and ask all the pertinent questions related to the standard that I created. Um, and then you can go as deep as you need to, right? Um, you could take it to depending on your you know level of comfort with AI, you could just turn that into your own SOP that you want to use, which could then could become a template in your software. You could use that to go deeper and build agents. Um, but this PDF kind of walks through the five layers, dissects it, the project closeout process, the SOP, all the things that you would do, the serve off service package, the checklist. And again, you could just use this as your own standard for your company. But the markdown file that was created with this, you can upload, say, let's get started and have a little fun session there, regardless of your level of, you know, if you're just using Chat GPT to write emails and answer questions, the markdown's gonna guide your way. Uh if you're more advanced, you can take it as far as you want.

SPEAKER_00 39:27

Yeah, either way, I think it's a great document to just throw in there and give it like a starting point. And then I suspect you would agree, like, make it your own. Every company shares things in common. Uh, we all have commonalities, but we're all unique as well. And ultimately, like that is one of the beauties of AI is that you can really get in there and have this expert that understands you know your needs. Like you said, it can interview you and ask you very specifically, like, what do you need this process to look like? What are some of the constraints that you're up against? But starting with this piece of context, just to give it that general framework, uh, I think would be really useful. I think this dovetails nicely into something that we've alluded to a couple of times, but I'd love to zoom in on, which is this idea of like, I would imagine, Jason, that as a process architect, you're welcoming AI with open arms, probably for multiple reasons, but one of them being the one I want to talk about is like for me, full transparency in the past, you know, and I'm sure others struggle with this, like, I've looked at process documentation and I go, okay, I get that it's important, but there's this voice in my head that says I'm gonna spend all of this time documenting these processes, and then nobody's gonna read them, the documents are gonna go stale, and all of that time will be spent, like, for what? You know, and like there are many counterarguments to that, but one of them, again, the one I want to zoom in on is like now in the age of AI, having these processes documented is like gold for your business because that context can be fed to AI agents that now can look at that one document and have a crystal clear understanding of exactly how you need to do things in your business. And like we said before, context is king. So I would a short way of summarizing this is that I would imagine AI has made process documentation a lot more valuable. Uh, not less valuable, but not less valuable, but in fact, a lot more valuable now that you you have this secondary use for these documents. Are you seeing that? Would you agree? Is there anything you disagree with there or that you would clarify?

SPEAKER_02 41:29

No, uh a hundred percent. Uh again, because I don't think of AI as another software tool. It's literally a digital employee. And again, employees need context as well. And um, you know, sometimes you could give an employee too much information and they get overwhelmed. AI doesn't, right? Like the more the actual better. And my one of my aha moments was a couple of months ago. I I started using Claude in January before I was using ChatGPT, and I still use both for different things. And um, I was like, I'm gonna set up Claude Cowork. And first thing it asked me was, What can you tell me about your business? Well, I have a process map, no surprise, that architects everything from discovery calls to how I deliver services. All the software is identified, all the SOPs I have, even though it's just me, are identified. And it said, This is a great snapshot. Would you like me to start installing MCPs and analyze where we could build agents for the repetitive work? And I was like, holy crap! Like it got all that from a simple process map. Like, that is how powerful this stuff is.

SPEAKER_00 42:31

Yeah, it can infer a lot. I'm I'm continually blown away by like if you give it just um, you know, even a little bit of context about your company, especially the newer models. Like, I don't know if you've played around with Astra or Fable um for these sorts of higher level, like strategic process engineering questions. But I have been blown away. They're more expensive to run, so you have to be kind of mindful of your how much you want to be spending on tokens and and watching your usage. But like when you're really trying to think through maybe a complex process uh in your business, like having those those higher power models and being able to feed it some context about how you already do things, I can imagine would just be you know insanely powerful. Pat in the chat said AI agents with contextual uh instruction on how to interpret and summarize recorded meetings has been fantastic. So site surveys, initial qualification, change order meetings, et cetera. I can totally see uh how that would be super valuable. So um definitely like some some cool stuff to uh to explore there. Um zooming back out, Jason, like we've talked about some of the problems that uh a lack of process documentation can cause uh in the company, and then conversely, some of the opportunities that you can go after if you're uh gonna invest the time to get these processes documented more clearly. One of them that we have not talked about is company valuation. There is a lot of discussion in the industry right now with mergers and acquisitions, and a good portion of our owners in our industry are starting to get to. Age where they're starting to think about succession planning and how do I make an exit from this company. So we're hearing a lot more dialogue about that. I'm curious for your perspectives on how actually getting in, mapping out processes and getting these things documented so that everybody understands how does that play into an owner or a leader in a business who might be thinking about enterprise value?

SPEAKER_02 44:20

Yeah. I mean, at the simplest level, it just makes your business transferable. Like it needs to run without you for you to be able to sell it. And so, yeah, of course, just having a workflow PDF and the SOPs doesn't guarantee that, but it's the start and the structure of a process. Um, interestingly enough, they're they're not public, they haven't announced it publicly yet, but I think some people have heard uh I'm working with a new franchise company that's entering the market. They hired me six months ago. Do you know what? To document the processes. Because if they're going to sell franchises, you got to have playbooks and processes in place before they actually launch it because so the business is transferable. Um, but yeah, it's super important for multiple reasons. And I've worked with uh a couple of clients who were able to go sell their businesses after documenting processes because people could see what it was that they how the business runs and how it runs without the owner.

SPEAKER_00 45:13

Mm-hmm. Yeah, and that that actually uh I want to I want to pull up one more uh poll here. So we've got a one more poll up on the screen. If if uh you're with us live here, I'd love if you could just take a minute to take a look at that. Uh if you stepped away for 30 days, you know, like how would your business run? Um, and I'd love to hear uh how folks respond to that. But then while we're waiting for that to come in, you know, Jason, I would imagine too that if you're an integration company, any small business really, but if you're an integration company, you're looking to sell, somebody comes in to buy your business. A lot of this is subjective and psychological. There's a dance that goes on, right, between the buyer and the seller of the business to arrive at the final number. And some of this is about like, what's the impression that you make? And I would imagine that it's just an entirely different impression if somebody comes in to buy your business and you're able to say, This is our top 10 or whatever it is, processes, they're all documented. This is exactly how we do things. What would you like to know more about versus the buyer having to come in and sort of pull that information out of you? I'm curious if you would agree with that.

SPEAKER_02 46:19

Yeah, 100%. Because listen, even if you have that stuff documented and your team's not following it 100%, that person that's looking to buy you just at least knows what they need to do, right? They understand the business. Otherwise, they're just gonna spend months and months and months learning and learning where the challenges are. So yeah, it's uh yeah, it's incredibly valuable in so many different ways.

SPEAKER_00 46:41

Yeah, absolutely. All right. Well, as we wrap things up here, I'll share the results of this poll. So the majority of folks said some of it would run, but would be very reliant on one other key person. Uh, and then the second place answer was very little, most of it lives with me. So again, just like we did with our previous poll, Jason, I'd be curious to hear is this consistent with what you're seeing out in the market? Give folks an understanding of like the clients and integrators that you talk to, uh, are they seeing and experiencing the same thing?

SPEAKER_02 47:12

Yeah. And again, it's usually because the owner is still stuck in either a sales role or maybe even in a you know, engineering production type role, they haven't elevated to where they're actually running the company. And then if they are, if they're still stuck running the company, again, it's probably because there aren't documented processes in place. So I think there's varying levels, right? Because if you're still doing the majority of the selling, even if you have processes in place, it's hard to step away. Um, so I think it's identifying that. But again, if you as an owner at some point want to keep elevating your stuff yourself, you have to be able to have things documented so you understand what it is you want to delegate away from you so that you can bring the right people in.

SPEAKER_00 47:52

Yep. I was at a pro source event earlier this week, and uh Matt Wallen, uh, a name I think some folks will recognize in the industry, was he gave a talk and he talked about the leader being the lid on the business. That was not his idea, he cited somewhere else that that came from. But I really liked that visualization of like you as a leader uh owner of your company are are really the lid on the business, and the business can only grow to the extent that you can sort of grow yourself and like transcend that. And I think a lot of that comes down to just you got to get stuff out of your head, you got to bite the bullet and get these processes documented so that you can delegate more, delegate and elevate. That's something they say in in EOS, right? The more you can hand off, the more you can turn your attention to these kind of higher level problems uh in the business. So um we'll see. I I want to put a prompt out there. If anyone has any questions, uh anything that we didn't touch on that folks want to uh know about, drop those into the chat uh while we're waiting to see if those come in. Jason, one final closing question I have for you is if somebody's out there listening and they're just like, I feel this, I need to get started on my documentation, I need to get my processes in order, but I don't really know where to start. Like, what is the one piece of advice you would give somebody who's who's in that position?

SPEAKER_02 49:09

Yeah, kind of like what I said earlier, which is, you know, lay out your phases of how a project flows through your company at a very high level and sit with your team and just ask them like, where is the biggest, where are the biggest friction points? Where does process break that creates the majority of our problems? Most people will understand what you're trying to get to and it disarms them because nobody's asking who screwed up. And then see see where the heat map lays you. Um, most of the times it's around scope of work and project handoff, which then when those things are broken, it creates more later. Um, but sit with your team, they're gonna tell you where it is, where the problems are, and then now you have a place to start. And listen, start with one or two things. Don't try to take them all on at once. Like literally, if you can find the the biggest pain points that your team is self-identifying, fix those, get them into a routine, move on to the next. I mean, yeah, we run a business that's moving, like you know, in manufacturing, you can stop the assembly line to figure out the problem and fix it. You can't do that in these businesses, it's impossible. So you just got to try to figure out how to make changes on the fly and find the ones that are gonna have the biggest impact. Because if you can do that, it starts to become a flywheel effect because the the project that you just sat and made sure that the scope of work was accurate and that everybody has what they need in a couple of months, you're gonna feel that efficiency because that project just ran smooth and it's gonna keep getting better and better.

SPEAKER_00 50:29

Yeah. Yep, 100%. Uh, no new questions came in, but there was one from Chris Smith that came in earlier uh that I want to circle back to. This is kind of a newer thing. I mean, I think some companies have been doing this for a while, but I know like recently with Grokbot, for example, uh, they've been really advertising and touting this ability to um basically sit down, go through whatever task you're doing, uh, generating an invoice as a simple example. And Grokbot, the AI, can sort of basically just records what you do and it can watch your screen. And then just by you walking through that process with Grokbot, so to speak, looking and watching what you're doing, it can then kind of understand what that process is and document it. I have not played with these things yet. I'm curious, Jason, if you have or if anybody else in the audience um drop it into the chat. But I'm curious about these kind of newer tools that allow you just to sit down, essentially hit record, do the job, and then the AI can kind of take it from there and get the whole process documented. Is that something that you've played around with yet?

SPEAKER_02 51:31

I haven't used Grokbot. Um, I've used Scribe a little bit. So Scribe's very similar where you can hit record, log into QuickBooks, generate an invoice, and it and it can build an SOP in a video for you. And I imagine Grokpot can then go do build an agent. I think all that stuff's great. Um, the only thing to consider then is if that person is in their silo doing that, we we still miss like the collaboration with other people in the handoff. So I think it helps you get to a place quicker where you've captured something, whether it's on video or a written SOP. But again, making sure that there's some team collaboration because otherwise you're the CFO documenting your process and you still have $200,000 or $20,000 checks showing up at your desk without the rest of the collaboration. But again, I think these tools help us get to a place faster. And certainly once you have it dialed in, um, it's even better because you know, SOP sitting somewhere, uh even a well-defined one um is still kind of archaic, but like videos that people can go to. Um, or again, if you're going to try to build agents using these tools is really cool.

SPEAKER_00 52:32

Yeah. There's probably a tie-in to the comment you made earlier, too, about I think you said um documenting the job training versus skill training, right? So I would look at these tools personally that record a very specific thing, like you generating an invoice as almost a different layer of the process documentation. Most all of what we've been talking about on today's webinar would be higher level, trying to get a view of the whole process, where the handoffs are, who are the various teams involved, where tools like Scribe or Grockbot, or I'm sure there's dozens of others out there that can record these individual processes are more like micro of like when you get to this step and you need to do this thing, generate the invoice, here are the exact steps to do that. If you want to get those documented in a way that's very granular, that's where I would see a tool like that becoming uh really useful.

SPEAKER_02 53:22

Yeah, yeah, I would agree as well.

SPEAKER_00 53:25

So, all right. Well, no new questions have come in. Uh, Jason, this has been super fun. I really appreciate you uh taking some time to come on to the show today. If there's anybody listening who wants to connect with you, uh learn more about what you do, ask follow-up question, what would be the best way for them to do that?

SPEAKER_02 53:42

Yeah, uh, you can reach out to me directly. My email is jason at iamsan.com, um, or you can go to my website, which is iamsayan.com. Um, and I think we're gonna share some follow-up information um that I shared with you guys, and you'll have my contact information there. You just always happy to sit on uh on a call and kind of unpack what you're dealing with and share things and try to provide some value and help you get started.

SPEAKER_00 54:06

Excellent. All right. Well, Jason, thank you again for being here. As you alluded to, uh, everybody, we will be sending out a follow-up uh email that'll contain links to some resources and ways to get in touch with Jason. Uh, would highly recommend you connect with him. He's got a really uh great framework for helping integrators just tackle these really difficult problems in the business. So, Jason, once again, thank you so much for being here. To everybody who joined us live today, thank you as well. We appreciate you taking some time out of your week to join us with that. We will wrap up. Hope everybody has a great uh rest of your week, and we will see you on the next one. Take care.

SPEAKER_02 54:37

Thanks for having me.