271 Standardizing Services - A Better SOP

Back on the road with day four of our exploration of building a better service library for your accounting firm. To standardize how you sell stuff, how you get the work done, and start corralling all the random crap that clients ask you to do into a more clear framework. Today we're talking all about SOPs, which I think we can all agree kind of suck. Like standard operating procedures, they are one of those things that you know you need to do, but you never make time for, and then you doubly don't make time to maintain them. Right. And part of the problem here is when we do totally different things for every single client, the volume of SOPs that that requires is absurd. Like, it's just huge. But now that we have developed a service library to have a common language for all the different things that we do for our clients, Even if only 80% of engagement A is similar to to 80% of engagement B, the approach now is, rather than making an SOP for client A and client B, we making an SOP for that 80%, because we now have a common language for what it means to do that. So that's what we're talking through today. Some best practices. At what level of the hierarchy do you develop SOPs? How to make them modular. So I'm not, like, explaining how to do a thing here and then making the SOP over here. That's also explaining the same thing, right? Because if SOPs are going to have to be, like, big and long and complex, uh, we're just not gonna do them. So it's like a more lean way of building SOPs. So come on in, Buckley. Seatbelt. Let's talk SOPs. Okay, Maybe off the top to define an sop, because I was over a decade into the profession, I think, before I even knew what an SOP was. And somebody explained it to me at one point, and I was like, oh, you mean three ring binders? And they're like, yeah, not. Not really. But for many of you, that's probably what SOPs looked like and maybe still look like. So an SOP is any sort of documentation that outlines how to do a thing to someone that hasn't done the thing before. And oftentimes, a common trap for accountants here is they're like, well, it's. It's my sage wisdom that lets me do the thing, and I can't just document that for somebody else. And this is ever so occasionally the case. The reality is, for most of us, it's very rare that you're, like, pushing that noodle to the limit or learning something new. Most of the stuff that we do is pretty rote and, you know, repeatable. Entering a W2 in some tax software, reconciling a bank account in, in QuickBooks. These are opportunities for us to like, standardize the aspects of projects that each engagement shares. So that your incredible brain isn't burning brain cells on the trivial stuff. You're just being brought in to handle kind of the most complex things. The trouble with SOPs and accounting firms has always been when we do different things for every client, it requires a different SOP for every client. And that's just a volume of both creation and maintenance that most firms are not willing to to do. And because we have that client fixation, like, because we're thinking of it on the basis of what that client needs. Because usually when you're working with a teammate, it's. You're talking about a very specific project and something that has to get done right now through the lens of a client. Oftentimes what we'll do is we'll sit down and like, okay, I'm finally going to make a video for this thing. I'm going to sit down, show them how to do it. And it's all about that client. When if you had made that video generic and maybe steered clear of the last 10% of just what was different about that client's engagement, then that same video could have been used for 10 other engagements. Right? So this service library that we've been working on this week, by the way, if you're random, randomly tuning into this episode, worth checking out the last three that we've done, because these kind of build on each other. This hierarchy of the service library gives us actually a helpful structure within which to build SOPs that can be shared across client engagements. A couple best practices on SOPs, there are two type of people, types of people in this world. Video enthusiast, people that just want to make a loom for anything and everything. Partly because that's just sort of their love language and partly because they just, they want to show you how cool video is. And then the other end of the spectrum is the manual, like text and screenshot documenter. And this was, this might be a recovering three ring binder. Enthusiastic. You've seen this in the past in a Word document where it's like you've got like a bullet, like a single bullet and a line of text and then a screenshot that takes up two thirds of the page and then another bullet with a line of text and then the next image Wraps to the next page. You know those nasty things. Most people are either that or they're like the video enthusiast. And when it comes to the format of an sop, because your firm probably needs an SOP for sops. Otherwise people will document things in wildly different ways and it won't be standardized. There are pros and cons to both documenting with video and with text. Where I stand on this today is I think video is genuinely, for the first time somebody's doing something that's the most helpful format for them to see it and to maybe drill into a couple things. I cruised past Loom, the app. Loom. Loom.com, it is. It has the person talking in a little bubble in the corner. Or you can actually turn that off. You can. But the beauty of Loom is it's, it's recording the screen. The screen is the area of emphasis when you're recording a video for an sop. Probably doesn't really matter like you on video. It makes it a little more personalized. But what we're wanting to do is record the screen and how to do the work and your narration over doing that work. That's the most important thing. You can also use zoom for this. You can share your screen and then hit record just in a, in a zoom meeting all by your lonesome. But videos, I think are usually the best way to see something for the first time. The trouble with videos is they're not. They can't be updated in a granular way. So if there's one part of that that you want to change and it's in a five minute video or a 30 minute video, you just, you can't do that unless you're like going to chop it up in editing software, which most people just aren't going to do. I would also argue that for every time after the first time you do something, videos are actually a really annoying way to get the source for how do I do this thing? Because you're like, I kind of remember it. And you're scrubbing through the video trying to find it. And this is where text and screenshot based guides are more helpful. So think video is helpful at first. After that, you almost always want text and screenshots. Because if one thing changes, just a matter of updating the text or changing the screenshot, the reality is when you shoot that video, you're not going to make that thing absolutely flawlessly in a way that won't be updated for a decade. Text, you can add clarifications. You could Change stuff. You can update a screenshot when some part of the process changes and when you're coming back to just remember how to do that one part. Text is much more useful because it's searchable. Like you don't have to scrub through it like you do a video. Today's episode is sponsored in part by LiveFlow. LiveFlow's the tool that puts a little Louie button up in your spreadsheet app. Whether you use Excel, whether you're into Google Sheets, puts a wee little button up there that lets you pull any QuickBooks online data that you have from clients into a spreadsheet. Imagine your spreadsheets now with access to all your client QuickBooks data. How can you use that? Tell you one useful way getting people information when you don't want to be in QuickBooks internal members of a company's team. Let's say you got a marketing manager and they're in charge of the marketing budget and need to be overseeing spend or something like that. You want that person in the QuickBooks file? You sure don't. But you know what I do want them to see marketing spend. It's a great example of like all these barriers and siloed pieces of information that are with help from team members just because we maybe didn't have a good way to give them access to it. If the business owner is responsible for a set of KPIs, all of those KPIs need to be tied back to team members. Where team members are like okay, they have to do this, this and this or collection of team members have to meet their goals in order for the business owner's KPIs to get to where they need to be. While how do we get really clear information to those team members access to the data that they need and as you're advising clients, LifeFlow is a great way to carve up all of the data that lives inside of QuickBooks. Either pull out one time snapshots or reports that will continue syncing live on an ongoing basis and then all I'm doing is I'm giving that person access to a spreadsheet. Not the keys to the entire kingdom, right? Besides, QuickBooks got all sorts of like user limits and I'm consuming those every time I add a person. Anyways, Lifelo does a whole bunch of stuff consolidations as well. That's one cool use case. You want to learn more, check out the link in the show notes. Today's episode is sponsored in part by the folks at Team up who help you find talented Accountants in the Philippines. Join your team. Education Break common vernacular you hear when you're hiring offshore bpo. What is a bpo? BPO is a business process outsourcing company. Basically a company that employs a bunch of folks offshore and then you hire the company to get part or all of those people's time. The appeal of a BPO is for folks that haven't done offshoring before. Sometimes this can feel like maybe a more comfy place to start. Can help you navigate, you know, kind of cultural misunderstandings. Usually the BPO will do the actual recruiting and bring a bunch of folks to you. Some BPOs also sell you more like the product, the deliverable, not the time. So like buying tax returns or month end closes instead of just having a person that works for you around the clock. But there's some downsides to BPOs as well, namely high ongoing fees. It's not uncommon for half of what you pay to the BPO to actually go to the BPO and the other half to go to the person. The BPO is usually gonna set the person's schedule as well, who's working for you. So you lose a little bit of control. And if you ever wanted to leave the bpo, getting those staff to come with you and like getting them out of the bpo, in my experience is virtually impossible. So you're kind of stuck with that BPO if you love the people that you have at the BPO. So upsides and downsides. Two BPOs. But if you want to do direct hiring, that's what today's sponsored team up does. They've got recruiters that'll find you awesome folks to join your team. You pay a one time recruiting fee, they don't pay anything after that. Those folks just work for you directly. There you go. Now you're a BPO expert. If you're looking to hire folks directly in the Philippines, check out team up link down in the show notes. Some SOP traps to avoid that I jotted down here. Keep client specific SOPs to a minimum. Think when is a situation where I should ever be making an SOP specific to that client? It is probably only if you literally do that just for a single client. And if that's the case, there's a, there's a question there of like why am I doing a thing that I only do for one client? But it's almost always a no, no to do a client specific sop because surely there's another client, at least one, that we do the same thing for. Most likely there's another 30 that we do the same thing for. And if I didn't make a client specific, that SOP would be helpful across all those engagements rather than just the one. Right? And then in the future, when it needs to be updated down the road, I'm updating it in one place rather than updating these 30 different SOPs that I made. So steer clear of making them client specific. They almost never should be client specific. Make them as modular as possible. So don't give me like a one hour video about how to do a ton of things, make them bite size, make them modular. Some aspects of service delivery are actually shared across our different services. So for example, loom delivery, maybe sometimes you deliver tax returns via loom, maybe sometimes you deliver financial statements via loom. Do we need loom delivery instructions for both of those things independently? Probably not. I don't know, maybe there actually is an argument for, for doing that. But look for opportunities like that, we're going to have something, something, something modular that can be shared in like various different contexts. Because when it comes time to, it's the same as with, you know, making copies of work papers. If you have a work paper or a source document or a Rosie or, you know, whatever it is and you put a copy of the exact same thing in several places, you're just, you're begging for trouble because someone will come through and be like, this doesn't apply anymore. And then when it exists, seven other places that update didn't get pushed there, right? And so that's what we're going for with making these SOPs modular as it makes updates and maintenance down the road much easier as well. Last SOP trap. To avoid a lack of accountability, I touched on this at the top, how everybody agrees, like, oh yeah, sops, we, we should totally be doing that, but always gets shuffled down, shuffled down the list. The thing about SOPs is you're never making them for yourself. And in the life cycle of somebody who works for you, and I'm sure I went through this same process. When you're learning how to do the work and doing it yourself and taking pride in your ability to do it yourself for the first time, you're like, I don't need SOPs. I must be super smart because I can just remember, I can just remember how to do this stuff, so I don't need SOPs. And the moment that that person gets to capacity and they realize, oh, there's no way out from under this work, it is not until then that they value SOPs as a gateway to getting out from under their work. But then what happens? As soon as that work goes to somebody else, the next person's like, I don't need an sop. I must be super smart. I just, I just know how to do this stuff. And the cycle continues. And because we're never making SOPs like for ourselves, and usually after doing a few cycles of it, you'd like no longer need to refer to that SOP because of this. SOPs oftentimes only come up in these, like, disaster scenarios where you have to transfer something in a pinch or something like that. And I've talked about this on the podcast before. The best solution for this I've ever heard, I stole from Chad Davis, told it about us, told us about this on the podcast. The notion of having kind of like this roving team where the goal of an SOP ultimately is, is to have clear documentation. So if you disappear tomorrow, someone else could do that work, right? Well, if that's the goal, do that. Don't make somebody disappear, but have like a roving team of like, okay, we're going to come in and do this bookkeeping, or we're going to come in and do this bill pay for this client today based off your documentation, somebody who's never done it before, or we're going to do this month end close for a bookkeeping client based on the documentation, they've never done it before. Can they successfully do it based off the documentation? And then importantly, how well this goes needs to be part of the feedback loop and one of the inputs for, you know, reviews for this person. How are they performing? What does their pay raise look like? Like their ability to pass this test and do this well needs to be factored in there. Otherwise there's no stakes. Right. So this notion of these kind of secret shoppers and there being a possibility that somebody could come in and do this stuff based on the SOPs, there's maybe a, I don't know, overly dramatic, spooky, like, evil way of implementing that that just stresses everybody out and isn't any fun. But that's, that's the best method I've heard for enforcing accountability and encouraging people to prioritize doing those SOPs. Now, if you have somebody overloaded and they have way too much work to do, are they going to do the SOPs? Probably not. They're probably going to try to deliver the thing that the client needs when everything's on fire. So it is like all things in an accounting firm. It's also a capacity issue. As soon as you go over capacity, all that stuff falls apart. But absent some sort of like third party checking in on those SOPs, in my experience, like there just, there just isn't enough of a feedback loop there for folks to do it well. Okay, so bringing this back to our service library and the hierarchy that we have created. At the top we've got packages that go to clients. Second, we've got service levels. Third, we've got services. Fourth, we've got service items. Fifth, we've got those service item options being like monthly, quarterly, annual for the service item frequency. At what level in that hierarchy should your SOPs live? Definitely shouldn't be. Should it be clear at the top, at the package level, this is maybe possible if you run like locked packages for your clients. So the scope of what you do for them is, you know, one of three flavors of dog food. And that's it, like that's how locked down we're running our firm, my firm was never anything near that. There are pros to running it that locked down. Obviously it's much easier to systematize. I would argue even the firms that say they are doing that, beyond that they're actually doing a whole bunch of like one off custom things for people, whether they will admit to it or not. So sometimes it can be a bit imaginary. But then the full opposite end of the spectrum, where everything's unique for every single client, that's, that's a nightmare also. Right? So there's, there's a happy medium there somewhere. But in terms of where you set the set up those SOPs, if all of your packages are the same for every single client, would it be a good idea to set up SOPs at that level? And so I, if all my firm does is we sell a bronze, silver and gold package and the scope of that is the same for everyone, doesn't mean the price has to be the same for everyone. The service library is just identifying what we do, not necessarily the price for it. But I don't think you would just have three SOPs then bronze, silver and gold. Because bringing this back to making SOPs modular, many of the things that happen, in fact, probably all of the things that happen at the bronze service level also happen at the silver and gold service level. Right. So what's the most modular version of that that we could make? Well, just making an SOP for all of those things is probably going to be a ton of overlap. So that probably wouldn't make sense. Right. So let's go down to the next level. Service level, you know, bookkeeping two. Let's say an engagement has bookkeeping two and payroll one, and that's the engagement. It has those two service levels. Would it make sense to make then an SOP for bookkeeping 2 and for payroll 1? You still have some of the same pros and cons here, right? It's a little more broken up, which is better. It's split out based on bookkeeping and payroll. But you could also see how if they're doing bookkeeping two, it would probably include all the same instructions that you had at bookkeeping one. So I don't. There isn't like a completely perfect answer here. Besides, even having this conversation is a hundred times better than making it for every single client, which I think is. Is the norm for most firms. I think where I'd be setting up here is probably making SOPs at the service level level that are designed to help my functional teams. So I have my functional bookkeeping team who are getting all the books done behind the scenes, and then I have the other accountant who's more the relationship manager. Whether there's a functional team doing it or it's just the accountant doing all of it, probably doesn't matter either way. But I can go to a single place where I have all my SOPs for bookkeeping, a single place where I have all my sops for bill pay. And in those sops we're calling out, uh, what is the difference between service levels? If I have to run a report package A versus report package B, and those are a little different for each client, then I need to have SOPs showing how to run each of those reports. Right? But then things like how we name our work papers, how we organize them, that's the same for all bookkeeping projects. So I would take it to the level where it can be modular. So you're not creating SOPs for the exact same thing in different contexts. But I don't want to go clear down. I probably wouldn't go clear down to like, the service item level, with the exception of, like, specific cases where that was a fiddly, nuanced thing that people were getting wrong. So my SOPs. And honestly, even in that situation where you do have to make an SOP for a service item, at least now you have a clear label for exactly what that SOP is. Right? So I'll have my general SOPs for, say, a receipt management service of what we generally do. But maybe there's a service item about the receipt management service that is a thing that we do. Differently for different people that requires some additional instruction. You could either put that in your general receipt management SOPs, or you could have an SOP that was just the name of that service item. Right? Like that. We've got some structure here now so that when a bookkeeper or whoever's doing it, an admin is doing this receipt management service and they see the client has this service item and they're like, oh, I've only ever worked on clients that had the other option for this service item. In the past. I've never done this one. Well, now we got an SOP for that one. So that's really clear. I can watch that, I can read through it. And now I should know how to do that just based on the sop, right? That's what we're trying to get to. This episode is sponsored in part by Maker's Hub. I freaked some people out recently saying the biggest thing AI is set to change in the next six months. 1040 prep workflows. The reason, AI vision models. It's the same tech that Maker's Hub is built on that in my opinion could revolutionize how accounts payable happens. Recently did a demo day on my channel in the first 10 days, actually the most watched video I've ever done about how AI is automating accounts payable makers. Hub is using AI Vision models to pull information off of invoices in wildly detailed ways. So, so much better than anything OCR could have ever done before. Finally delivering on the promise that we can stop doing manual entry on this stuff. Right? I mean, it feels like for, for over a decade we've been having apps coming and telling us, you know, we've finally eliminated manual entry. It actually feels like we're pretty darn close to that. For the first time, I had clients with super hairy AP workflows where this genuinely would have replaced like several FTEs, probably in my firm in like the very best way. Because for every single one of these people, we had a hundred other things that we wanted them to do. Super cool app. You'll see them out and about at accounting conferences. I'll put a link to them in the show notes. If you want to see a quick five minute demo, just search Maker's Hub Jason Stats on YouTube. We've done two of them now and they're pretty cool. Today's episode is sponsored in part by client Hub Time machine. The year was 2017ish 2018. I was running a cast practice and we had all of our task management system stuff happening in ClickUp and it was fine for managing tasks. But the big headache, every single month I had stuff that I needed my client to do so that I could do my work. And we had our system all nailed down. But when it came to having to get the clients to do that stuff, just a bunch of freaking emailing and following up and so, so annoying. And I literally remember telling the team, can't we just like give our clients access to this ClickUp or just create a ClickUp that we can can both use together? My clients know how task management systems work. They use them themselves. Gang. If you have ever said that Client Hub was created around that idea. A two sided task management platform. Not some funky old nasty like portal that's been bolted on to a practice management system, but genuinely a task management system that actually looks pretty much the same on the client side. And on your side you got a bunch of ports, more firm tooling. But on the client side it looks like a beefed up task management system. Literally a spot where you can collaborate with clients and work through things together. Because unfortunately there's oftentimes still stuff I need clients to do. Questions come up, I want to push those out through their task management system and we could just manage this stuff like grownups, okay? Not all this email and back and forth and having to remember and it's something the Client Hub does really, really well. Client Hub is a full practice but management system. But if you've ever been looking for something that is going to feel more premium to your clients like, like a proper modern task management system could be the solution for you. I'll put more info about Client Hub down in the show notes. So pros and cons of going really macro because it's probably not modular enough, but then going really micro and doing it at the service item levels probably, probably too detailed. But you may have a combination of service item and like service level sops. I wouldn't try to overthink this too much. Like I said, it's worth having like an SOP for SOPs and having agreed an agreed upon format for how everyone has to build those instructions. Otherwise gosh, I made this mistake and it was a total mess. A whole. You just cut a whole bunch of people loose and say go make some SOPs and they're wildly different. And then I just had a bunch of people spend all this time on this thing where we're like we're gonna have to remake all of these. Because when I thought SOP it looked like this. When all of these people made their own SOPs, they all looked completely different, they used different tools, different levels of detail. We learned these people suck at this and these people are really good at this. And we actually ended up with a couple of people who are sort of almost like librarians because they really excelled at doing that well and that benefited everyone. And so it is, it is worth defining like what will be our process for an sop? Does the name of an SOP have to tie to, you know, a service to a, to a service item? Like really getting specific about how do we make this as structured as possible so that in a single view your team can see your whole service library, all the service items and how to get to an SOP for any of those things. Like that's, that's the goal. And just think how powerful that is for your entire client database to be mapped to this, the services you provide, the service items and how it's done for them. And, and to have a super clear roadmap for your team for how to do each of those specific things. That's something that many of us have always dreamed about but felt out of reach or impossible. This approach, I didn't get it perfect in my firm, but it's the closest that we ever got. It's not a perfect system, but as we talk about a lot, a system is better than no system and it's something you can improve upon. Like it's, it's a starting point where we can be like, here's what's good and what sucks about the system, so let's make this change to it, make it a little bit better. And then over time it should only ever get better. Right. Now, one other thing that I didn't really touch on here is what about SOPs that have nothing to do with the delivery of a client service? You're probably going to have a lot of those too that are more like administrative or operations based. And an opportunity here is. Many of the non accountants that I worked, that I hired were phenomenal operators and oftentimes better than the accountants at building out and managing SOPs. And a funny thing started happening as we started having more of these, these conversations around exactly what our specific service deliverables were is the admins now had a better understanding than ever before of what we did for our clients too, right? Not just the professional staff, but now the admins could see at a snap, like at a glance, a client calls, oh, here's all the things that we do for them and they've got a bunch of context immediately. And then the other thing that started happening was as we built out those SOPs, we realized, you know, this whole big ambiguous client engagement that in the past required this level of professional expertise. Well, it turns out that this is actually, it's bookkeeping two, it's payroll two and it's, it's bill pay one. And the only person that knows how to do all of those things right is the person with technical skill level way up here. But if we carve that stuff up, this non accountant can do, can do bill pay, this non accountant can do payroll, they can do receipt management and building. All those SOPs actually DE skilled all of that work. Because we're able to do it on a new dimension now where the dimension that most firms deliver client services is on the client dimension you have a person who's responsible for everything for that client. We now have a second dimension that is all of the things that we do for those clients. And so we can pull in functional teams and other people to do all things receipt management for that client, all things bookkeeping for that, for that client. And you could keep the same person like on the vertical kind of client management dimension doing all the client communication. That's what we ended up with at, at my firm as we had pods managing client comms and then we had functional teams doing all the services. But once we broke that out, we found we were much less skill reliant. It gave more space to our best technical people to continue to grow and not get mired in the really basic stuff that was a waste of their time. And ultimately we pulled a whole bunch of admins into stuff that was previously deemed like sort of professional work. So you'll have some SOPs that are not tied to client service delivery, but there's value in pulling non technical staff or your VA even into how the work gets done and how SOPs get delivered. And the more touch points they have with your service library and seeing how you support your, see how you support your clients, you'll find that they will oftentimes very organically get pulled into actually doing work that was once considered professional work. When you have that roadmap of SOPs of how to get it done and how that ties back to the service. Many of those services can just be done with an explainer video, right? Like, like bill pay. That is not a complex like high skill ceiling thing. Preparing a tax return is a whole lot more to that. Right. But many of the things that we do are not, are not that complex. Okay. Sops, if you've got any wisdom on how to do sops. Well, it's very rare that I talk to someone that is like, proud of their team's SOPs. If you got any learnings there, man, drop that stuff down in the comments. Keep the questions coming. Going to do a Q and A tomorrow. If you haven't yet, swipe that resource that's down in the show notes and I'll see you in the next one. Thanks for coming and hanging.