How to Fix Employee Mistakes (My Process)

So not long before sitting down to work on this video, ProcessDriven made a mistake. Pretty public client facing mistake. And this kind of inspired this video about how do you handle an employee of any kind making a big client facing mistake? What's the right way to handle that? Because as a first time manager, a first time business owner, and a first and probably only time human, I have made a ton of mistakes and my team around me has also made mistakes. But how do you reconcile making mistakes, which we all do, with being process driven? Like, how do you make that shift? Well, my solution is having a process for handling mistakes doesn't mean you can prevent them always, but it gives you a game plan for how you get through them. I know you probably saw that coming, right? It looks something like this. And what you can see from this chart is that there's just a few questions you need to answer and it gives you a decisive next step as to how you can resolve any issue. This decision tree, which I'll be going through for the rest of the video, outlines my approach to handling employee mistakes. Oh, and a quick disclaimer. I'm using the word employee in this video because employee is a good general catch all for people who work in your business. But that doesn't mean I'm excluding owners here. I don't know about you, but as the owner of my business, I have been in this business the longest. I have messed up the most and most mistakes in my business somehow stem from my limitations. And so whether you're an employee, a contractor, a team member, a volunteer, a partner who does occasional work in the business, a business partner, or whatever the hell else you want to call yourself if you are capable of making mistakes. I'm talking about you in this video. So let's start our journey at the very beginning with a client facing mistake happening. It's unfortunate, but it will happen. And when it does, what do we do? The first thing is we want to find out how we found out. That will determine what kind of action I would take next in a given scenario. The two options for this are I either found out by another person or by discovering it myself, or I found out by the person who made the mistake. Those are the two options here that determine what my next course of action is. I want to imagine a real scenario that actually just happened at ProcessDriven. Before I was filming this video, we had an event for our clients inside processdriven Foundations. I was going to be doing a rapid review where I review people's processes and workspaces in real time in this group consulting call, super fun event. If you remember, make sure you go. But we have it twice a month and in our internal calendars we had it for I think it was December 28th, but on the public facing calendar it was on December 22nd. This was a mistake. Now the first question I would go through when trying to face this mistake is how did I find out about it? In this case it was kind of a lot of things, but ultimately I found out I was told about it from someone who noticed it because the person who did it frankly didn't notice it. It was an honest mistake. So if I find out about a mistake, here's what happens next. The next thing I do is I add a discussion point, a little bullet point to the agenda that we have for each weekly one on one check in. So in this example, if I know Susie is in charge of scheduling all of our member events, I I would add a bullet point into our next one on one call saying, hey, can we talk about the mistake that happened with scheduling events and how we can fix it? My goal for adding this is not to punish but to make space for some of the steps that follow so that way we don't forget about them. Because most often when businesses get into firefighter mode, things just get forgotten. And that's what I don't want to have happen. So my first step is to document. Oh, and at this point, let me just zoom out one click here. And I do want to show you that there's a bit of an offshoot in this process. If this was a recurring issue with Susie around this kind of data quality checks, or if there was a recurring pattern of behavior forming here, I might also kind of kick off more of a management process of helping improve performance. But that would be down the line and only if there was kind of a recurring thing happening. For the most part I would just treat this as a discussion, something that happened that we need to figure out. So anyway, that is that the next thing that happens is another check. In this case I would want to make sure that the issue is already identified as an issue issue with a capital I. I should also probably clarify what I mean by issue. Issue with a capital I is actually definition we teach at Process Driven to our clients. We also use it internally. It basically just means a task that happens to you kind of like an emergency or a ah that you have to respond to. At ProcessDriven we teach putting in a certain spot with certain fields. For more about all that, just check out the description you can join our foundations program where we teach all this stuff. But basically that's what I mean by issue. There's a certain way an issue needs to be logged and categorized in our task management system. That's what I'm checking for. If it is logged as an issue task, meaning the task is already created, the rest of the team is aware of this because again, documentation is my top priority, then I'm going to move on. If it is not logged as an issue, I'm going to create an issue task, meaning just creating that task inside my task manager. That lets the whole team know this is a known issue. This is so important to do early on. So that way, if your team is hearing about the issue from multiple people who will email in as happened with this situation. Unfortunately, they know how to respond. They know just by seeing the issue task come in. Hey, this is a known issue. The team is working on it. It's currently in progress, yada yada. All of that detail is right there in one shared area. The next question is whether this issue is ongoing. So is this something that was already fixed and we're just logging it as an issue so people were aware that it happened, or is it something that's ongoing? A common mistake like sending an email at the wrong time is not an ongoing issue. It happened. Yes. We still want to follow some of these other steps, but nothing we can do about it now. However, things that are actively going wrong, there is more stuff we can do. For now, we're going to assume that this issue was ongoing. So we're going to go. Yes. The next question is, is whether the person responsible for this issue is available to help resolve this issue in a timely manner. Because ideally, the person who did the thing in the first time would be the person who correct the issue. This will help them learn. It'll also help them improve their process in the future because they will see what went wrong. If the person is available, they would be assigned this task. Otherwise it would go to whoever else is available to act swiftly. I know in the case of this issue that recently happened, I actually stepped in because most of the team was on vacation for the holidays. I'm the only hands available, and that's okay. There's nothing wrong with getting your hands dirty. It's what's necessary sometimes to make sure you're able to put out fires. Oh, and I should say I'm scrolling around the screen here because I have bad eyes and I want you to just see what I'm focused on. If you'd like a zoomed out copy of this whole decision tree so you can make it your own, you can mark it up, you can do whatever. I'll actually have a link to it below this video. You can get it for free. Just put your email in and I'll send you a copy of this in a nice, you know, actually easy to read all at once format. The next thing we want to do is acknowledge the mistake. This is the very next action. This usually happens publicly if it was a public issue, if it wasn't a public, ongoing issue, it might be happening in private emails. But we essentially want to say, yes, you're right, there is a mistake. We're working on it as quickly as possible. Anytime we're posting publicly, we would leave a note inside this issue task letting the rest of the team know the status. So in the example issue that kind of kicked off this video's inspiration, we had messed up the dates, so I made a post in our community forum and I basically just said, sorry, I'm so, so sorry for disrespecting your time. And when I did that, I also wanted to leave a comment inside our internal issue task. Again, that task we put in our task, manage the whole team can see. And I basically just put something like, you know, hey, I wrote an apology, here's the link. Boom. Just so that everybody else who might have an inquiry coming in knows where that's at. Now the next step is to stop the bleeding. And this just means if the issue is ongoing and there's something you can do to stop more people from getting confused, do that thing that might be, you know, making sure that the link works in the future, that might be unpublishing a page that might be setting up a redirect URL. Whatever you need to do to stop causing more people that harm, do that. In this case, there wasn't a lot I could do because the harm was in the past, but have this step nonetheless to make sure I'm responding to any active issues or correcting any posts that went out at the wrong time. Next up, we have the final task here, which is make tasks to make up for it and then some, and log this as an internal comment. All of these things. We're leaving notes internally to the team saying, FYI, I did this, FYI, I did that. And in this case what I'm doing is creating more tasks for myself and the team to make up for the issue that just happened. If it's something like a broken link, maybe there's not a whole lot we can do to make that up to somebody. But in this case, we really goofed. We had a calendar for one event, clients had another date, and people were waiting in the waiting room to come to this event for 10, 15 minutes in some cases. And the event never started because the date was just totally wrong by the time I saw it. And I went into the room 30 minutes after it should have started. No one was there. So how do we make that up to somebody? How do you make up wasted time? That's the most painful thing. But what we ended up coming up with is making an even more convenient way to get the exact same promise of that rapid review. So in that case, rather than rescheduling the event, asking people to inconvenience themselves again, what we ended up doing is keeping the event when it was actually scheduled, which was the following week. And also I opened up kind of a live chat room for members for three days every workday. I just went in, I always had the tab open and I was just responding to questions, comments, any feedback anybody needed. It's a little bit of getting used to to have that live chat room. But it was a nice way for us to at least somewhat make up for those who maybe stayed up late, went out of their way to join us, and then were not able to. I ended up having to create a task for myself to monitor that every day, to remind myself, as well as some tasks for other people to make sure that they followed up with people who had had issues to tell them about this new option. And this long path takes us to one more decision point. This decision point is the same decision point we referenced back here when we asked whether or not the issue was ongoing. Because if it was already resolved, we would go right to this. It's essentially a double check to make sure that a corrective action was made. All that means is did we learn from the mistake if the mistake happened because a calendar event went out at the wrong time, or what are we doing to prevent that? Just hoping that we don't make a human mistake again. I mean, that can be okay for low risk processes where it's not worth the extra headache to have multiple double checks, but for high stakes processes where there's a high cost of an error, where you're just really disrespectful. I don't want us to have that kind of experience again. We want to do more than just hope that we don't forget about something. In this particular instance, the situation I'm describing in this video, we have multiple corrective actions. We are changing the schedule of the event to be more consistent so it's easier to schedule and more automated so human mistakes are less possible. We're making sure we eliminate duplicate areas for data entry so things can't get out of sync and so on and so forth. One thing I'll just say about this corrective action piece is personally there is nothing that makes me angrier than an issue happening and then no corrective action happening afterwards. I'm not someone who's going to get upset with a mistake because I make most of them. So I can't without being a hypocrite. But. But I get so frustrated when mistakes happen again and again and again and we don't learn from them. We don't change our behaviors, we don't change our processes, we don't change our SOPs, we don't add a double check. There are so many ways like the ones I just listed for making a process stronger. And if you are seeing recurring issues, those are no longer optional add ons like they need to be there. But anyway, whether or not there's a corrective action taken, we either want to just close the task saying hey, the corrective action. Is this letting you, the person who had the issue happen, know about this change that we're making. It's all done. Thank you. Or if there's no corrective action, or if the corrective action needs to be done by the person who did the process, we would just reassign maybe a comment or task to that person saying hey Susie, I fixed, you know, stopped the bleeding on this event piece but I don't know what the corrective action should be since this isn't my process. Would you mind creating some kind of corrective action preventative measurement to make sure this can't happen again because this was pretty bad. That would be considered the resolution of this issue in my view. To zoom out a little bit, this is how far we've come. There's still one more tiny leg of this journey that I still want to go through. If you are still with me. If I scroll in the other section just changes the steps a little bit. If the person who made the mistake told you this is obviously ideal for so many reasons. One, you find out sooner. Two, it means they're taking accountability and three, you're not surprised by it later on. Now, of course, course this isn't always possible. People might not realize the mistake happened because the mistake was them not realizing it. But if it can happen, here's how that would change your flow if the person told you about it. The very first thing I would do is add some kind of gratitude shout out for that person. Notice how this is a little bit different than what happens if I just found out. If I just found out about the issue. I would post something in our one on one chat. But if they told me to me, that's something we're celebrating and I want to celebrate in public. So I will add something to our next ALTI meeting. I might not spill all the beans, but I would post in a public forum of some kind, just celebrating this person for owning up to this issue. One of the core values at ProcessDriven is embrace responsibility. So I might bring to the next ALTI meeting a little shout out. Saying something like shout out to Suzie for really demonstrating embrace responsibility by identifying and bringing to me an issue that happened with our Kajabi event scheduling. And my goal for sharing this is to celebrate Suzy for doing the behavior that the team needs to stay healthy and to make it clear that the mistake is not an issue. If anything, a mistake ignorant, knowledged and worked on is a great opportunity. The next thing I want to check with Susie who brought me this issue is whether or not they solved the issue. So if they've tried to solve it, then we're actually going to go back to our normal step. So you see, this hasn't been logged as an issue. We're just going to go through the normal flow from then on. If Susie hadn't tried to solve the issue, I would kind of prod and try to see if Susie could solve the issue. If it's something that Suzy owns, nine times out of ten, Susie will be able to fix the issue she caused. Very rarely would there be an issue that Suzy caused while doing her day to day work that had such a large ripple effect that Susie herself could not solve it. And so that's what I would push next. In a conversation, I might say something like, hey, Susie, thank you so much for telling me about this issue that happened. Yeah, we definitely want to get this fixed. Have you tried anything yet to fix it or is it still active? If Susie says no, they. They haven't tried to solve it yet. I would just respond with a little bit of a push to get Susie thinking in that direction. Something like, okay, Susie, well, let's try. How would you go about fixing this? And my reason for asking this is not to point fingers, although I kind of did just by talking with my hands. It's to get Susie thinking about what solutions would be needed? If Susie is able to understand the issue and kind of start talking about what solutions are needed, I can leave knowing with confidence that Susie can solve that issue. Probably. If Susie's like, I've got no idea. It broke something in the ether and everything's crazy and, you know, she's got no concept of how to fix it, then we might either go through a little bit of some teaching time of, oh, maybe try this, that, and the other, or if Susie's not able to solve it and she's not even close to being able to solve it, I might suggest that she pull in some reinforcements, find a teammate who knows more about the thing that she's broken somehow, and work together to fix it. Either way, the only two options here are either an absolute no, meaning that person is absolutely not capable of working on this, or a probably, meaning they can do it, or they probably could do it. As long as they can somewhat have a chance of resolving this issue, I want to leave it in their court. I want to leave with encouragement and encourage them to solve the issue that they've identified that might go in conversation. Something like, okay, Susie, I understand the issue's ongoing. You haven't tried to fix it yet, but it sounds like you might be able to. Would you mind just taking the reins on this? Make sure you create that issue task and just try to solve it. If you need any support, reach out. You know, all of us are here, but I think you should take the lead on this. Once this step happens, we go back up into our normal issue flow. I'm sure I'm missing a few steps in this process. I was just trying my best to reflect on what I currently do. But that pretty much summarizes the entire process we have here for handling issues when they inevitably occur. And one elephant in the room. I just want to clarify here is most of the time this client facing mistake is is caused by me, the same flow applies. The conversations are a bit more awkward and less polite, but the same flow applies whether I'm the one making the mistake. A VA is making a mistake, an employee's making a mistake, partners making a mistake doesn't matter. Now, remember, everything I'm sharing is just what's worked for me. In my experience. I'm not some kind of disciplinarian pro. I'm not a quality assurance whiz. I'm just a small business owner who loves to think about things from a process lens, taking what's worked for me, what's worked for others, and putting in a resource that hopefully saves you time, headache, tears in your next mistake. Because the only thing we can guarantee about mistakes is that there will be more of them. Yeah, if you want to support this content for free, like subscribe, comment below, all of those things. And until we speak next, enjoy the process. Oh, and remember, you can get the whiteboard thing that I showed on the screen in the description below. You can just grab a copy for free if you want to reference this in the future, maybe amend it to your own style, what have you. Okay, now you can enjoy the process.