Show Notes
Most people see a broken process and think "I'll automate it." That's a mistake. You're locking in the problems—baking in the traps, the patches, the operational debt.
It's like a blown car speaker. Turn up the volume and you amplify the distortion. Automation amplifies whatever is already there—good or bad.
Clarify the Flow isn't just "document the process." It's about seeing the REAL process. There's a difference between how you think people work and how they actually work. Have them record themselves. Watch with your eyes.
Walk through each trap:
Control Trap: Where does work get stuck waiting on someone? Is the approval necessary? Can you build in thresholds?
The Ritz-Carlton $2,000 story: Any employee can spend up to $2,000 to solve a guest problem. A couple lost a wedding ring on the beach. Five employees bought metal detectors, found the ring, delivered it at breakfast. The husband called local news. Free publicity—because they removed control.
Variability Trap: Does the output depend on who does it? Is there a defined standard for success?
Memory Trap: Does someone have to remember? Can you add an automated trigger instead?
Visibility Trap: Do you have the data to know if it's working or failing?
The three questions before automation:
- Should this step exist at all? (Sometimes the best automation is deletion)
- Can it be redesigned to remove the trap?
- Only then: Can it be automated?
Automation is the last decision, not the first. Even Elon Musk says automate last.
The goal isn't to replace humans. It's to amplify their output. Plan for handoffs between human and machine. Anytime there's a handoff, traps hide there.
C comes before A in SCALE for a reason. Clarify first, then automate. Skipping C is how you amplify chaos.
Your action: Pick one process you're thinking about automating. Map it out. Walk through the four-trap audit. For each step: eliminate, redesign, or automate—in that order.
Next episode: The build session. Watch Scott take a real process through the entire framework.
Got a business question? Ask Scott here: scotttodd.net/ask
📜 Full Transcript (Click to expand)
Scott Todd (00:00)
Most people see a broken process and think, you know what? I'm gonna fix it. And I'm gonna fix it by automating it. And that's a mistake. It's a bad mistake. And here's why it's because what's happening is you're actually locking in the problems that the business had. And so my word of caution here is that before you automate anything, you have to see the whole picture.
And that's what today's episode is about. It's about how to automate a process before you build anything. And over the last few weeks, we've been talking about this scale framework. And the C in scale means clarify the flow. And it exists for this very reason. But I'll get to that in one second. Welcome to Fix My Business. I'm your host, Scott Todd. I have built multiple seven figure businesses after leaving my
Fortune 300 VP career. And this channel is designed to help you build and scale your business so that you can actually love it. Now, here's what happens is when we get this, you know, feeling that something has broken our business or that we want to try to automate something, our gut instinct is to just rush to the technology so that we can fix it. And I've seen this so many times where a business owner will go in there.
And they will buy a tool or they'll kind of look for an app to solve the problem without ever first stopping and looking at the process. And that really is the beginning of the entire automation journey is to look at this process. So it's why I'm a big believer in building swim lanes. We want to map out what happens in this particular process, who does what, how the work flows through.
Because it's not as simple as just building a zap or you know creating some automated AI that can handle something for you. Because what happens is if you try to automate a broken process, you get the broken process faster. Now think about this for a minute. It's like a car stereo. If you've ever heard a car stereo that the speaker has been blown and you turn up the volume.
On that speaker, it just distorts it even more. It amplifies the distortion. And that's what happens with broken processes. You take a process that's broken, you make it go faster, and then all of a sudden it breaks faster and the damage is larger. The blast radius is larger. Because what happens is if you don't first map out this process, you bake in the traps. We've talked about the four traps. You bake them in.
We've talked about in the last episode, we talked about the patches and the operational debt. All of this gets baked into an automated process that ultimately amplifies whatever is already there, good or bad. Okay. So whatever's there is going to amplify whether you want it to or not. Now, a lot of people think when I talk about clarify the flow that it means, well, let me just document the process.
And while that's kind of where we're where we're going, really when I talk about clarifying the flow and swimlining the business and the processes, the reason that I talk about that is because it allows you to see what the real process is. It allows you to not just document the way that it should work. It's about documenting the way it actually works. And there is a difference between the way that you think that.
People are working in your organization and the way that they actually work. And it's when you don't see those things and how work is moving through the company that you then begin applying patches. Because again, they're going, they're going in a different direction than what you could have even envisioned. So then you start patching the work with checklists and these other kind of, you know, ⁓ patches. And ultimately what happens is.
you create that operational debt. So what I want you to really think about doing here is that before you're automating something, that you actually want to pause and look at how work actually flows through this particular process. Where does it begin? Where does it end? Where are the handoffs between other people? And all of this needs to be documented. Now, if your business is one in which your employees are local into your office, it's
Quite simple. You can walk over to them and say, hey, show me how you do this. Show me how you do this particular process. And then you're looking at it, you're watching it. And a lot of people today have more remote teams. And that's fine too, because what we can also do is when we go through this process with them, we want them to maybe do what I would call like a reverse training where they record themselves on Loom or Zoom or whatever you're going to use. Let
them record how they do it so that you can actually see, you can see with your eyes how they're doing it. Not the way that you think they're doing it, but the way that they actually do it. And then as you're walking through the way that the work is actually getting done, what you're thinking about is okay, where are the traps? So let's talk about the the control trap for example. Where does the work get stuck waiting on somebody? It could be you by
Okay, who has to approve this work? And you want to be thinking like, is this approval actually necessary? What if this person disappeared tomorrow? Would this particular process stop? How can we avoid these approvals? So for example, can you bake in to the process? Can you bake in some automated approvals like thresholds? If it's above this certain amount, then you need an approval, but below this amount, you don't need an approval.
Let me give an example. ⁓ the Ritz Carlton, for example, is famous for their $2,000 program to where any employee can use or spend up to $2,000 to solve a guest problem. And recently I was at an event and the ⁓ the co founder of Ritz was there. His name was Horst. And basically he was talking about that particular process. And someone asked him, hey, what is your favorite success story of that?
you know, $2,000 limit. And he explained that there was a couple that was that at the Ritz and ⁓ they were newly married and she had lost her ring on the beach and she was devastated. Five employees went out that night and bought metal detectors and they scoured the beach for her ring. They found her ring. They cleaned it and the next morning at breakfast
They delivered it back to her and she was in tears. As you can imagine, she was in tears. Okay. Now, they just wanted to buy five metal detectors to solve that problem. It was below the $2,000 threshold. They did it. They didn't need to ask a manager to go do it. They just went and did it. See, that's the control trap antidote in place there. And by the way, the husband was so
overwhelmed by this entire experience that he reached out to the local media, the local new news station, told them what happened, and the next thing you know, Ritz got all kinds of publicity because they removed control. So that's what you're thinking about as you're looking at a process that you've mapped out. Is there controls there that we can remove? Do I really need all these controls? Or can I bake them in with exceptions?
Let's talk about the variability trap. Does the output really determine or depend on who actually does it? You see, is there a defined standard of what success looks like? Or would two people doing the exact same result or same process end up with two different results? And if there's any room for variability there,
You need to make sure that you're reducing that need. You're defining what success looks like. And then, in fact, you can truly automate that particular process because the automation will ensure what that success looks like. But you have to first identify and define what success looks like. The memory trap, this is where somebody has to remember to do something. My one example that I always think about is the fact that.
Every other Thursday, somehow, some way I end up having to approve payroll. Maybe that's because I'm in a control trap myself. Maybe I don't trust somebody to go do it on my team. I'm the final approver approver. And I can tell you from experience that even though you know it's every other Thursday and you know that today is payday, somehow, some way, at least once in many, many years, I have forgotten to approve it by five o'clock. Because it was on my memory and other things happened that day.
So, what can we do? What kind of time alert can we put in there to build this trigger that says on this day this happens or on this day at this time, somebody is alerted that something wasn't done? You see, we're removing the memory from it so that our systems are now hitting us with it, and we no longer have to worry about forgetting it. What about the visibility trap? Okay, the visibility trap is where we don't have the data that we need to make a decision.
We're somewhat flying by the seat of our pants. We're just kind of guessing. And as a result of that, we can't really see what we don't see. Stuff can fall through the trap, the cracks. work may not well, it may not ⁓ be the best it can be because we don't have the whole picture. And remember the visibility trap can isn't just about financial data. It can also be about what's on the minds of your customers too.
Okay, so before you go automate, we're looking at this map and what we're trying to figure out is are the are these traps present? And if so, how can we mitigate them? And so this comes to the three questions that I want to ask before I try to automate a process. And the first one is, should this step exist at all?
Remember, it's not necessarily about adding the best processes are ones in which we can subtract. Okay, we want to try to subtract steps as much as possible. So the question there is can we eliminate it entirely? Okay, if we can, great. And if we can't, we have to really ask ourselves is this step actually adding value or is it just adding more time to something?
Because sometimes the best automation is actually deletion. I want you to remember that. Write that one down. Better to delete than add. Can the step be step question number two is can the step be redesigned to remove the trap? Because you're going to have these traps built in. Every process is going to have the trap. My payroll example that I'm going to stick with, that payroll example is one in which
I don't have the comfort level with someone on my team yet in which I'm okay with them approving that. So the fact that I know that there's the control trap in place there, that's fine as long as I mitigate it in some other way. So what we're trying to do here is we're trying to figure out ways that we can patch, let's say, the memory trap by adding an automation trigger. So in my example of payroll.
What happens is if I don't have that approved by ten AM on every other Thursday, I get blown up with messages, text messages, I get emails. It is all hands on deck. And I know now I have to go do it. Sometimes, sometimes I just forget to close that I did it, but I still get those alerts. And that's what we want is we want to try to mitigate our memory as much as possible.
If the trap that we're looking at is in fact a memory trap. You see, only then, once we've got this process as tight as it can be, only then can we automate. You see, automation is the last decision. It's never the first one. There's a video that circulates social media quite a bit, and it's Elon Musk talking about his five rules of business and redesigning.
Processes and the last one, the fifth rule says you automate. Even Elon Musk says you automate last. And that's so important because so many people they want to jump to the excitement of automating something, but it's never really the first step. Now, as we build our automations, I want to encourage you to think differently. I'm gonna be different than all the other automation gurus out there that are like the machine can handle everything.
No, the machine cannot handle everything. The goal of automation is not to replace humans. It really is not. It's to amplify the output. It's to multiply the output of the humans. And you need humans because humans are better at things than machines are, and vice versa. Okay. And so what you have to do is you have to plan for these handoffs. There needs to be handoffs from the machine.
Where the machine has taken as far as it can go and give it to a human. And the human can now take it the rest of the way and maybe give it back to the machine again. It is a constant, potentially handing off of work multiple times. And I want you to remember this: anytime there's a handoff between human to human or human to machine, you have traps that hide there. And this is where clarifying the flow really, really makes the most sense. Okay. So
You have to go through that process and you really need to map it out, look at it, and challenge it before we build.
Remember, you wouldn't build a house without a set of blueprints. You also wouldn't drive across this country without at least knowing some fashion of a route. And that's what clarifying the flow is. It's the map. It's the thing that you can see the whole picture, the whole the whole journey becomes visible on this clarify the flow so that
You can identify where the issues are and we can address them before we bake them in forever. So again, I'm going to go back to the scale framework. S is for scoping the solution. It's one specific play. We're not trying to automate the entire business with one play. It's one specific play. Think about a football game to go from one end of the field to it.
Touchdown, it's many, many plays. Rarely is it just one play. It's many, many plays back to back. So we want to build our automations and we want to build our processes as individual plays. C of scale is clarify the flow. That's what we've talked about here. A is automating the trigger. So we want to make sure that we have some sort of a trigger that kicks off our workflows. L is leveraging the data, meaning that we want to know if it was successfully ran or if it failed.
And also he is elevating the experience, which means that we want to not talk in robotic language. We don't want to talk in, you know, stuff that nobody understands, like error nineteen. That means nothing to anybody.
So we want to make sure that we have the human side of it there. And I want you to remember that C, clarify the flow, comes before A, which is automate the trigger. Because when you clarify first, I want you to remember you clarify first and then you automate. But most people want to skip the C and jump right to the automation. And that's how we amplify our chaos. Okay. So
We now understand how this ties back to our scale framework. We talked about the four traps in previous episodes. We've talked about operational debt. We've talked about pre-automation audit. And in the next episode, you're going to watch me do a build session. And I'm going to work with one of our ⁓ one of my customers. And we're going to actually do a build session. And I'm going to take you through the entire process. I'm going to walk you through the whole thing in the next episode.
And you're gonna see how I find the traps, what gets removed, and what we automate. Okay, so here's your action plan for today is I want you to pick one process that you're saying about automating. I want you to build anything, anything that you're gonna build, just map it out and walk through the four-trap ⁓ audit.
And then what you're gonna do is you're gonna ask for each step. Can I eliminate this one? Can I redesign it? Or in fact, can we automate it? Map it out, see the whole workflow before you actually touch it. And that's how you are going to avoid amplifying the chaos. So clarifying the flow is the discipline that's gonna separate those good automations that you do from the chaos.
The traps are there. You know how to find them before you build. Our next episode is the build session. If you have a business question, head over to scottod.net forward slash ask. And I will see you in our next episode.
Most people see a broken process and think, you know what? I'm gonna fix it. And I'm gonna fix it by automating it. And that's a mistake. It's a bad mistake. And here's why it's because what's happening is you're actually locking in the problems that the business had. And so my word of caution here is that before you automate anything, you have to see the whole picture.
And that's what today's episode is about. It's about how to automate a process before you build anything. And over the last few weeks, we've been talking about this scale framework. And the C in scale means clarify the flow. And it exists for this very reason. But I'll get to that in one second. Welcome to Fix My Business. I'm your host, Scott Todd. I have built multiple seven figure businesses after leaving my
Fortune 300 VP career. And this channel is designed to help you build and scale your business so that you can actually love it. Now, here's what happens is when we get this, you know, feeling that something has broken our business or that we want to try to automate something, our gut instinct is to just rush to the technology so that we can fix it. And I've seen this so many times where a business owner will go in there.
And they will buy a tool or they'll kind of look for an app to solve the problem without ever first stopping and looking at the process. And that really is the beginning of the entire automation journey is to look at this process. So it's why I'm a big believer in building swim lanes. We want to map out what happens in this particular process, who does what, how the work flows through.
Because it's not as simple as just building a zap or you know creating some automated AI that can handle something for you. Because what happens is if you try to automate a broken process, you get the broken process faster. Now think about this for a minute. It's like a car stereo. If you've ever heard a car stereo that the speaker has been blown and you turn up the volume.
On that speaker, it just distorts it even more. It amplifies the distortion. And that's what happens with broken processes. You take a process that's broken, you make it go faster, and then all of a sudden it breaks faster and the damage is larger. The blast radius is larger. Because what happens is if you don't first map out this process, you bake in the traps. We've talked about the four traps. You bake them in.
We've talked about in the last episode, we talked about the patches and the operational debt. All of this gets baked into an automated process that ultimately amplifies whatever is already there, good or bad. Okay. So whatever's there is going to amplify whether you want it to or not. Now, a lot of people think when I talk about clarify the flow that it means, well, let me just document the process.
And while that's kind of where we're where we're going, really when I talk about clarifying the flow and swimlining the business and the processes, the reason that I talk about that is because it allows you to see what the real process is. It allows you to not just document the way that it should work. It's about documenting the way it actually works. And there is a difference between the way that you think that.
People are working in your organization and the way that they actually work. And it's when you don't see those things and how work is moving through the company that you then begin applying patches. Because again, they're going, they're going in a different direction than what you could have even envisioned. So then you start patching the work with checklists and these other kind of, you know, ⁓ patches. And ultimately what happens is.
you create that operational debt. So what I want you to really think about doing here is that before you're automating something, that you actually want to pause and look at how work actually flows through this particular process. Where does it begin? Where does it end? Where are the handoffs between other people? And all of this needs to be documented. Now, if your business is one in which your employees are local into your office, it's
Quite simple. You can walk over to them and say, hey, show me how you do this. Show me how you do this particular process. And then you're looking at it, you're watching it. And a lot of people today have more remote teams. And that's fine too, because what we can also do is when we go through this process with them, we want them to maybe do what I would call like a reverse training where they record themselves on Loom or Zoom or whatever you're going to use. Let
them record how they do it so that you can actually see, you can see with your eyes how they're doing it. Not the way that you think they're doing it, but the way that they actually do it. And then as you're walking through the way that the work is actually getting done, what you're thinking about is okay, where are the traps? So let's talk about the the control trap for example. Where does the work get stuck waiting on somebody? It could be you by
Okay, who has to approve this work? And you want to be thinking like, is this approval actually necessary? What if this person disappeared tomorrow? Would this particular process stop? How can we avoid these approvals? So for example, can you bake in to the process? Can you bake in some automated approvals like thresholds? If it's above this certain amount, then you need an approval, but below this amount, you don't need an approval.
Let me give an example. ⁓ the Ritz Carlton, for example, is famous for their $2,000 program to where any employee can use or spend up to $2,000 to solve a guest problem. And recently I was at an event and the ⁓ the co founder of Ritz was there. His name was Horst. And basically he was talking about that particular process. And someone asked him, hey, what is your favorite success story of that?
you know, $2,000 limit. And he explained that there was a couple that was that at the Ritz and ⁓ they were newly married and she had lost her ring on the beach and she was devastated. Five employees went out that night and bought metal detectors and they scoured the beach for her ring. They found her ring. They cleaned it and the next morning at breakfast
They delivered it back to her and she was in tears. As you can imagine, she was in tears. Okay. Now, they just wanted to buy five metal detectors to solve that problem. It was below the $2,000 threshold. They did it. They didn't need to ask a manager to go do it. They just went and did it. See, that's the control trap antidote in place there. And by the way, the husband was so
overwhelmed by this entire experience that he reached out to the local media, the local new news station, told them what happened, and the next thing you know, Ritz got all kinds of publicity because they removed control. So that's what you're thinking about as you're looking at a process that you've mapped out. Is there controls there that we can remove? Do I really need all these controls? Or can I bake them in with exceptions?
Let's talk about the variability trap. Does the output really determine or depend on who actually does it? You see, is there a defined standard of what success looks like? Or would two people doing the exact same result or same process end up with two different results? And if there's any room for variability there,
You need to make sure that you're reducing that need. You're defining what success looks like. And then, in fact, you can truly automate that particular process because the automation will ensure what that success looks like. But you have to first identify and define what success looks like. The memory trap, this is where somebody has to remember to do something. My one example that I always think about is the fact that.
Every other Thursday, somehow, some way I end up having to approve payroll. Maybe that's because I'm in a control trap myself. Maybe I don't trust somebody to go do it on my team. I'm the final approver approver. And I can tell you from experience that even though you know it's every other Thursday and you know that today is payday, somehow, some way, at least once in many, many years, I have forgotten to approve it by five o'clock. Because it was on my memory and other things happened that day.
So, what can we do? What kind of time alert can we put in there to build this trigger that says on this day this happens or on this day at this time, somebody is alerted that something wasn't done? You see, we're removing the memory from it so that our systems are now hitting us with it, and we no longer have to worry about forgetting it. What about the visibility trap? Okay, the visibility trap is where we don't have the data that we need to make a decision.
We're somewhat flying by the seat of our pants. We're just kind of guessing. And as a result of that, we can't really see what we don't see. Stuff can fall through the trap, the cracks. work may not well, it may not ⁓ be the best it can be because we don't have the whole picture. And remember the visibility trap can isn't just about financial data. It can also be about what's on the minds of your customers too.
Okay, so before you go automate, we're looking at this map and what we're trying to figure out is are the are these traps present? And if so, how can we mitigate them? And so this comes to the three questions that I want to ask before I try to automate a process. And the first one is, should this step exist at all?
Remember, it's not necessarily about adding the best processes are ones in which we can subtract. Okay, we want to try to subtract steps as much as possible. So the question there is can we eliminate it entirely? Okay, if we can, great. And if we can't, we have to really ask ourselves is this step actually adding value or is it just adding more time to something?
Because sometimes the best automation is actually deletion. I want you to remember that. Write that one down. Better to delete than add. Can the step be step question number two is can the step be redesigned to remove the trap? Because you're going to have these traps built in. Every process is going to have the trap. My payroll example that I'm going to stick with, that payroll example is one in which
I don't have the comfort level with someone on my team yet in which I'm okay with them approving that. So the fact that I know that there's the control trap in place there, that's fine as long as I mitigate it in some other way. So what we're trying to do here is we're trying to figure out ways that we can patch, let's say, the memory trap by adding an automation trigger. So in my example of payroll.
What happens is if I don't have that approved by ten AM on every other Thursday, I get blown up with messages, text messages, I get emails. It is all hands on deck. And I know now I have to go do it. Sometimes, sometimes I just forget to close that I did it, but I still get those alerts. And that's what we want is we want to try to mitigate our memory as much as possible.
If the trap that we're looking at is in fact a memory trap. You see, only then, once we've got this process as tight as it can be, only then can we automate. You see, automation is the last decision. It's never the first one. There's a video that circulates social media quite a bit, and it's Elon Musk talking about his five rules of business and redesigning.
Processes and the last one, the fifth rule says you automate. Even Elon Musk says you automate last. And that's so important because so many people they want to jump to the excitement of automating something, but it's never really the first step. Now, as we build our automations, I want to encourage you to think differently. I'm gonna be different than all the other automation gurus out there that are like the machine can handle everything.
No, the machine cannot handle everything. The goal of automation is not to replace humans. It really is not. It's to amplify the output. It's to multiply the output of the humans. And you need humans because humans are better at things than machines are, and vice versa. Okay. And so what you have to do is you have to plan for these handoffs. There needs to be handoffs from the machine.
Where the machine has taken as far as it can go and give it to a human. And the human can now take it the rest of the way and maybe give it back to the machine again. It is a constant, potentially handing off of work multiple times. And I want you to remember this: anytime there's a handoff between human to human or human to machine, you have traps that hide there. And this is where clarifying the flow really, really makes the most sense. Okay. So
You have to go through that process and you really need to map it out, look at it, and challenge it before we build.
Remember, you wouldn't build a house without a set of blueprints. You also wouldn't drive across this country without at least knowing some fashion of a route. And that's what clarifying the flow is. It's the map. It's the thing that you can see the whole picture, the whole the whole journey becomes visible on this clarify the flow so that
You can identify where the issues are and we can address them before we bake them in forever. So again, I'm going to go back to the scale framework. S is for scoping the solution. It's one specific play. We're not trying to automate the entire business with one play. It's one specific play. Think about a football game to go from one end of the field to it.
Touchdown, it's many, many plays. Rarely is it just one play. It's many, many plays back to back. So we want to build our automations and we want to build our processes as individual plays. C of scale is clarify the flow. That's what we've talked about here. A is automating the trigger. So we want to make sure that we have some sort of a trigger that kicks off our workflows. L is leveraging the data, meaning that we want to know if it was successfully ran or if it failed.
And also he is elevating the experience, which means that we want to not talk in robotic language. We don't want to talk in, you know, stuff that nobody understands, like error nineteen. That means nothing to anybody.
So we want to make sure that we have the human side of it there. And I want you to remember that C, clarify the flow, comes before A, which is automate the trigger. Because when you clarify first, I want you to remember you clarify first and then you automate. But most people want to skip the C and jump right to the automation. And that's how we amplify our chaos. Okay. So
We now understand how this ties back to our scale framework. We talked about the four traps in previous episodes. We've talked about operational debt. We've talked about pre-automation audit. And in the next episode, you're going to watch me do a build session. And I'm going to work with one of our ⁓ one of my customers. And we're going to actually do a build session. And I'm going to take you through the entire process. I'm going to walk you through the whole thing in the next episode.
And you're gonna see how I find the traps, what gets removed, and what we automate. Okay, so here's your action plan for today is I want you to pick one process that you're saying about automating. I want you to build anything, anything that you're gonna build, just map it out and walk through the four-trap ⁓ audit.
And then what you're gonna do is you're gonna ask for each step. Can I eliminate this one? Can I redesign it? Or in fact, can we automate it? Map it out, see the whole workflow before you actually touch it. And that's how you are going to avoid amplifying the chaos. So clarifying the flow is the discipline that's gonna separate those good automations that you do from the chaos.
The traps are there. You know how to find them before you build. Our next episode is the build session. If you have a business question, head over to scottod.net forward slash ask. And I will see you in our next episode.