Show Notes
How many things in your business are broken—little things you see every day but haven't fixed?
Frictions: Scott captures every broken or inefficient process he sees. He calls them frictions. They go on the automation loop worksheet. Then he prioritizes by closeness to revenue and team efficiency, and fixes one or two at a time.
The hot mess: In Scott's loan servicing business, the collections process was tracked in a spreadsheet. It worked—but it wasn't scalable and wasn't something to be proud of. It became the next priority.
The process:
Opened the spreadsheet, brought Claude in, explained the process end to end
Asked Claude for a product requirements document (PRD)
Read the PRD over two days, pushed back, refined it
Applied the SCALE framework
SCALE applied:
S (Scope): Collections process only. Not the whole internal tool.
C (Clarify the Flow): Whiteboard. Drew the future state.
A (Automate the Trigger): Notify humans when new cases arrive. Don't automate judgment—humans decide before anything fires.
L (Leverage the Data): Know when it's working AND when it's broken. "Automated processes die silently."
E (Elevate the Experience): Make sure people can always get back to a human.
The build: Fed the refined PRD to Claude Code. Built an internal tool replacing the spreadsheet—better tracking, security, visibility into who changed what and when.
The principle: Think first before you build anything. Don't jump to "how do I automate this?" Think through the entire process first.
Got a business question? Ask Scott here: scotttodd.net/ask
📜 Full Transcript (Click to expand)
Scott Todd (00:04.504)
How many things around your house are broken? Little things. You know, maybe the door doesn't shut right or the door handle is loose. I know at my house the door hand a door handle or two is loose. Or that door that squeaks every time it opens and closes. It needs some lubrication. Like this is stuff that we tend to kind of maybe jump in immediately and fix, or sometimes we make a list. Or maybe your spouse makes a list that becomes the honeydew list.
Just just saying. But what about your business? How do we handle this in business? And that's what we're going to talk about on this episode. I'm Scott Todd. I've built multiple seven figure businesses. And after leaving corporate, my corporate job, my Fortune 300 job, and this channel is dedicated to helping you do the same thing. Now, one of the things that I see happen a lot is that
It's easy for business owners, you to see all of the problems within your business. And then sometimes we begin to just see them and not necessarily correct them or know how to correct them. But within my organization and with within my companies, the one thing that I continue to do is I look at everything that I see that's just not right, that's broken, and I capture it. Now, see, I call each of these things frictions.
So my goal is to to capture as many frictions as possible. Little things that just aren't right. It becomes the honeydew list of the business. And then what I do is I look at them and I try to work on one or two of the friction points at any one time. I don't try to solve them all. I try to prioritize them. I look at their closeness to revenue. and
And really team efficiency, I look at these pieces, I choose the next one, and then we go off and we build it. And when we build it, it's not necessarily a building like an automation. Sometimes it is automation. Sometimes it's process redesign. And I start to work off of these things, but I capture the frictions on what I call the automation loop works worksheet. So if you're interested in that, you can just I don't know, in the comments or email me.
Scott Todd (02:23.828)
Give me the automation loop worksheet and I'll give it to you. But the thing is, is that we capture the friction points on this worksheet and we don't try to necessarily answer it. We just identify this is a problem. Then when we start to go into build, when we say, hey, this is the one that we're going to work on next, we begin to go through a methodical process of looking at the entire process end to end.
And I want to walk you through one that just happened this week because it was super important. It is super important to my company. And it was what I would call the hot mess of the company. It wasn't necessarily the best part of the pro of the company or the best process within the company. And so it became the thing that we were going to fix next. Okay. So here's what I'm
Here's the process. What happened is in my business where we have loan servicing, there was a portion of the business that we call collections, okay? Like it the defaults collections. And we had a we we have a very documented, defined process. But part of that process was we broke down within the tracking. We were basically using like a spreadsheet to track
The loans that we were tracking within the collections process. And it worked, but it's not the best. It's not necessarily something that's scalable. It's not something that I would be absolutely proud of. So the other day, beginning of this week, I was in there looking at it and I'm like, this is the next priority. And then we started to sit down, I started to sit down and I started to think about how I would redesign the entire.
Process, not just make a fancy user interface for it, but how does the process need to change overall? Because while it's functional, it's not the best. So I sat down and I went back through and I began to look at it holistically, as if it didn't exist. But I also used AI to do this. And I want to walk you through the process of what I did to do this. So what I did was
Scott Todd (04:42.055)
I opened up it was in a sheet, a spreadsheet. I opened up the spreadsheet, I asked Claude to come into it, and I explained in detail what Claude was looking at and how we used it from end to end. And then I said, This is a hot mess. Help redesign, like help design the system. So to ask some questions, I gave some answers, and I didn't want it to.
Build, I asked it specifically to give me the PRD, product requirements document. And Claude went through and it looked at the process, how I answered the questions, and it gave us a product requirements document. So then from there, I read through the document. I took about two days to read through the document, and I said, no, I don't agree with this. This is not the way that it's supposed to be.
Here's the way that I want it to be. But then I walk through the scale framework and I'll share it with you again. It's it's on this channel as well. But the scale framework basically says S, what's the scope of this thing? So the scope of this process was very, very specific. We wanted to fix the collections process only. I'd love to build a whole like new automated internal tool.
But that's outside the scope of this one project. So scope, the S sc of scale is scope. What were we focusing on? We're focusing only on the collection process. The C in scale is clarify the flow. This is where I went to the whiteboard. I drew out the way that I wanted it to work in the future, the way that I envisioned it working in the future. And then I included that as part of our
requirements document, we refine that. The A in scale is automate the trigger. What does that mean? It means that we're looking for a way in which when work comes into this process or at any other given point of the process, what are the automated triggers that are gonna pull people back into the work? How do we take the humans and bring them back? See
Scott Todd (07:05.846)
It's easy to want to say, well, when a when something goes into default or collections just to start firing off all these automated things, a human never has to look at it. But that is to me the wrong decision. The right decision is that we put the humans where they need to be. Humans are needed for judgment. Okay. Is this data even right? Okay, we don't want to send stuff that's like completely wrong. Did we mess something up? Is something broken?
We want the human to physically look at this, make the decision that this is the right move before we fire off automated mail and emails, et cetera. We want the human looking at it. So I added the human element through the automate the trigger. Meaning when a new case comes into that workflow, I want the human to be notified, hey, there is work here for you.
So that they don't just forget and then these things pile up, right? So we wanted to automate the trigger. The L in scale is leverage the data. And what that means is that we wanted to figure out, I want to figure out how do we know when things are working correctly? And how do we know when things are broken? So many automated processes die silently. Think about it. Like you
Processes are typically, especially automations, they're typically built for the happy path. Come data comes in here, something happens, and then it goes out the door. And we never know. We also don't know if it's broken. Like a process that something changed, and maybe it's something that runs monthly. And guess what? Last month it broke, and you go back and you look for, like, huh, that didn't happen because the process broke. See, we want to know.
What that looks like when it's on the happy path and when it's on the broken path. And then the E is elevate the experience. And what I mean by that is we want to look at it from the human perspective. Even though we're adding in some elements of automation and form letters, how do we make it so that there's a way of getting back to the human? Okay?
Scott Todd (09:28.876)
There's there's countless stories where and maybe you see it where y you have a problem with a company and you can never get to the human. And it's frustrating that you can't get to a human. So we're always looking for ways in which we can help people get back to a human. Again, because humans bring judgment. Humans bring a different level of of empathy or understanding than say technology does.
So how do we build this back out? And I took each one of those elements and fed that or made sure that it was back in the PRD. And then I gave the PRD to Claude code and it began to develop out this new kind of system user interface that allows us to better interact with each of these cases. I see them as cases.
So basically what we end up with is we end up moving a process in a very quick time from something that was in a say a Google Sheet or an online spreadsheet. We're able to kind of take this or airtable. We're able to take these things and now build it into an internal tool that provides much greater level of tracking security, and we can actually see who's making changes to where and when. And that's the way that I think about these.
These areas of the business that need to be improved and changed. As we think about it, hey, what has to happen? What needs to be true to make this the best performing part of this business? And then we go and we build off of that after we've thought about the entire process first. So my argument to you is think first before we build anything. And that's what you're seeing play out here. So
Next time you have something on your list to go fix in your business, think about it from a different perspective as opposed to just, hey, what can we build or how can we automate this thing? Think through everything first. That's my goal for you in this video. And if you have a business question, head over to scott Todd.net forward slash ask. And I will see you in the next episode.
How many things around your house are broken? Little things. You know, maybe the door doesn't shut right or the door handle is loose. I know at my house the door hand a door handle or two is loose. Or that door that squeaks every time it opens and closes. It needs some lubrication. Like this is stuff that we tend to kind of maybe jump in immediately and fix, or sometimes we make a list. Or maybe your spouse makes a list that becomes the honeydew list.
Just just saying. But what about your business? How do we handle this in business? And that's what we're going to talk about on this episode. I'm Scott Todd. I've built multiple seven figure businesses. And after leaving corporate, my corporate job, my Fortune 300 job, and this channel is dedicated to helping you do the same thing. Now, one of the things that I see happen a lot is that
It's easy for business owners, you to see all of the problems within your business. And then sometimes we begin to just see them and not necessarily correct them or know how to correct them. But within my organization and with within my companies, the one thing that I continue to do is I look at everything that I see that's just not right, that's broken, and I capture it. Now, see, I call each of these things frictions.
So my goal is to to capture as many frictions as possible. Little things that just aren't right. It becomes the honeydew list of the business. And then what I do is I look at them and I try to work on one or two of the friction points at any one time. I don't try to solve them all. I try to prioritize them. I look at their closeness to revenue. and
And really team efficiency, I look at these pieces, I choose the next one, and then we go off and we build it. And when we build it, it's not necessarily a building like an automation. Sometimes it is automation. Sometimes it's process redesign. And I start to work off of these things, but I capture the frictions on what I call the automation loop works worksheet. So if you're interested in that, you can just I don't know, in the comments or email me.
Scott Todd (02:23.828)
Give me the automation loop worksheet and I'll give it to you. But the thing is, is that we capture the friction points on this worksheet and we don't try to necessarily answer it. We just identify this is a problem. Then when we start to go into build, when we say, hey, this is the one that we're going to work on next, we begin to go through a methodical process of looking at the entire process end to end.
And I want to walk you through one that just happened this week because it was super important. It is super important to my company. And it was what I would call the hot mess of the company. It wasn't necessarily the best part of the pro of the company or the best process within the company. And so it became the thing that we were going to fix next. Okay. So here's what I'm
Here's the process. What happened is in my business where we have loan servicing, there was a portion of the business that we call collections, okay? Like it the defaults collections. And we had a we we have a very documented, defined process. But part of that process was we broke down within the tracking. We were basically using like a spreadsheet to track
The loans that we were tracking within the collections process. And it worked, but it's not the best. It's not necessarily something that's scalable. It's not something that I would be absolutely proud of. So the other day, beginning of this week, I was in there looking at it and I'm like, this is the next priority. And then we started to sit down, I started to sit down and I started to think about how I would redesign the entire.
Process, not just make a fancy user interface for it, but how does the process need to change overall? Because while it's functional, it's not the best. So I sat down and I went back through and I began to look at it holistically, as if it didn't exist. But I also used AI to do this. And I want to walk you through the process of what I did to do this. So what I did was
Scott Todd (04:42.055)
I opened up it was in a sheet, a spreadsheet. I opened up the spreadsheet, I asked Claude to come into it, and I explained in detail what Claude was looking at and how we used it from end to end. And then I said, This is a hot mess. Help redesign, like help design the system. So to ask some questions, I gave some answers, and I didn't want it to.
Build, I asked it specifically to give me the PRD, product requirements document. And Claude went through and it looked at the process, how I answered the questions, and it gave us a product requirements document. So then from there, I read through the document. I took about two days to read through the document, and I said, no, I don't agree with this. This is not the way that it's supposed to be.
Here's the way that I want it to be. But then I walk through the scale framework and I'll share it with you again. It's it's on this channel as well. But the scale framework basically says S, what's the scope of this thing? So the scope of this process was very, very specific. We wanted to fix the collections process only. I'd love to build a whole like new automated internal tool.
But that's outside the scope of this one project. So scope, the S sc of scale is scope. What were we focusing on? We're focusing only on the collection process. The C in scale is clarify the flow. This is where I went to the whiteboard. I drew out the way that I wanted it to work in the future, the way that I envisioned it working in the future. And then I included that as part of our
requirements document, we refine that. The A in scale is automate the trigger. What does that mean? It means that we're looking for a way in which when work comes into this process or at any other given point of the process, what are the automated triggers that are gonna pull people back into the work? How do we take the humans and bring them back? See
Scott Todd (07:05.846)
It's easy to want to say, well, when a when something goes into default or collections just to start firing off all these automated things, a human never has to look at it. But that is to me the wrong decision. The right decision is that we put the humans where they need to be. Humans are needed for judgment. Okay. Is this data even right? Okay, we don't want to send stuff that's like completely wrong. Did we mess something up? Is something broken?
We want the human to physically look at this, make the decision that this is the right move before we fire off automated mail and emails, et cetera. We want the human looking at it. So I added the human element through the automate the trigger. Meaning when a new case comes into that workflow, I want the human to be notified, hey, there is work here for you.
So that they don't just forget and then these things pile up, right? So we wanted to automate the trigger. The L in scale is leverage the data. And what that means is that we wanted to figure out, I want to figure out how do we know when things are working correctly? And how do we know when things are broken? So many automated processes die silently. Think about it. Like you
Processes are typically, especially automations, they're typically built for the happy path. Come data comes in here, something happens, and then it goes out the door. And we never know. We also don't know if it's broken. Like a process that something changed, and maybe it's something that runs monthly. And guess what? Last month it broke, and you go back and you look for, like, huh, that didn't happen because the process broke. See, we want to know.
What that looks like when it's on the happy path and when it's on the broken path. And then the E is elevate the experience. And what I mean by that is we want to look at it from the human perspective. Even though we're adding in some elements of automation and form letters, how do we make it so that there's a way of getting back to the human? Okay?
Scott Todd (09:28.876)
There's there's countless stories where and maybe you see it where y you have a problem with a company and you can never get to the human. And it's frustrating that you can't get to a human. So we're always looking for ways in which we can help people get back to a human. Again, because humans bring judgment. Humans bring a different level of of empathy or understanding than say technology does.
So how do we build this back out? And I took each one of those elements and fed that or made sure that it was back in the PRD. And then I gave the PRD to Claude code and it began to develop out this new kind of system user interface that allows us to better interact with each of these cases. I see them as cases.
So basically what we end up with is we end up moving a process in a very quick time from something that was in a say a Google Sheet or an online spreadsheet. We're able to kind of take this or airtable. We're able to take these things and now build it into an internal tool that provides much greater level of tracking security, and we can actually see who's making changes to where and when. And that's the way that I think about these.
These areas of the business that need to be improved and changed. As we think about it, hey, what has to happen? What needs to be true to make this the best performing part of this business? And then we go and we build off of that after we've thought about the entire process first. So my argument to you is think first before we build anything. And that's what you're seeing play out here. So
Next time you have something on your list to go fix in your business, think about it from a different perspective as opposed to just, hey, what can we build or how can we automate this thing? Think through everything first. That's my goal for you in this video. And if you have a business question, head over to scott Todd.net forward slash ask. And I will see you in the next episode.