We Get Mail
Andrew dropped me a note to suggest that I cover exceptions to the rules. In other words, when is it okay to not follow the Standard Operating Procedures you've laid out?
You might be surprised to hear me say this, but there are lots of exceptions to the rules. Well, to some rules. There are built-in exceptions, emergency exceptions, bad habit exceptions, and common sense exceptions. There are also different kinds of SOPs. Some SOPs must be followed exactly and perfectly each time and some are much more flexible.
First, let's talk about these internal to your company. Then we'll look at how you manage exceptions with clients.
In the big picture, common sense is the most important piece of all of this. SOPs exist to make life easier. Well, life and work. When SOPs get in the way of smooth and efficient operations, then need to be set aside. We'll come back to this.
Built-In Exceptions to SOPs
Some SOPs work best if you can build in the exceptions. For example, we have a very strong policy of working from highest to lowest priority. We don't want people wasting time working on Low-Pri activities when High-Pri activities can be moved forward. Further, we have a well-defined process that says that all service tickets are worked from highest to lowest priority. BUT . . .
We also have a built-in exception to this rule.
When I go to a client's office, I start by looking at all the open tickets they have. If I'm going to go onsite, I will try to knock out all the tickets I can in the time allotted. I'm not going to take care of one high priority item, bill them for an hour, and then leave. In addition to being less efficient in the long run, that would be pretty bad customer service.
So I try to get as many tickets completed as possible. In particular, I make sure that the tasks that require an on-site technician are completed.
This built-in exception makes sure that I give good service. It also makes sure that we address all those medium and low priority service tickets that might not otherwise get any attention.
When you create built-in exceptions, make sure they actually add value to what you're doing. I think the example here is perhaps the most important built-in exception we have. It truly improves our process in several ways.
Emergency Exceptions and Bad Habit Exceptions
Emergency exceptions to SOPs should be rare (of course). Sometimes you just need to cut through the red tape - even if you created the red tape. The problem is that this decision is so subjective. You get to decide what's an emergency. If you're the owner, you don't really have to justify it to anyone.
It is a bad habit to start making exceptions and excuses. Once you go down that road, every day is a series of exceptions to the rules. Pretty soon there's no point in having SOPs at all.
The most common "excuse" given for breaking SOPs is that it's faster to "just do it" rather than follow the established process. It's very much like hiring an employee and then doing all the work yourself because it's faster than training them how to do it. You know intellectually that it's better in the long run to follow the SOP (or train the employee). But right now, today, with this one little task, it's faster to just do it.
The bottom line here is discipline.
I will say: Having employees helps. The favorite employee past time is watching the boss. So if the boss cuts corners, the employees know it's okay to cut corners. Employees will keep you in line. And they will support each other.
Once you have established SOPs and everyone is trained, then you should have the discussion about exceptions. Think of it this way: Once you know all the rules, you can make good decisions about when to break them. But that doesn't change the fact that the rules still need to be followed.
Letting Clients Make Exceptions
Andrew's original question was largely focused on client-related policies and procedures. For example, it's easy to say that you have change your password every 30 days, but many clients simply refuse to follow this. So where do you stand firm and where do you let the client make the rules?
You probably have very few technology-related rules that you impose on your clients. You ask them to switch the backup discs or tapes; you ask them to change their passwords; you ask them to log off and night but leave the machines on; etc. A few very reasonable suggestions.
In fact, every "policy" you give them is either 1) For their own good, or 2) Related to doing business with you.
When it comes to doing things that are in their own interest, you have very little control. You can educate them, remind them, and warn them. But at the end of the day, you can't care more about their network than they do. So if they don't tend to the backup drives, there's very little you can do.
You should protect yourself when clients make certain bad decisions. For example, if a client will not take steps to make sure that they change passwords or backup their data, you need to let them know - in writing - that you can't be responsible for these things.
At the end of the day, the best you can do is to make good recommendations and encourage the client to take your advice. But if they don't want to follow your advice, there's not much you can do.
Comments welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at SmallBizThoughts.com.
- - - - -
Next week's topic: How to Track Credit Card Autopayments
:-)
Andrew dropped me a note to suggest that I cover exceptions to the rules. In other words, when is it okay to not follow the Standard Operating Procedures you've laid out?
You might be surprised to hear me say this, but there are lots of exceptions to the rules. Well, to some rules. There are built-in exceptions, emergency exceptions, bad habit exceptions, and common sense exceptions. There are also different kinds of SOPs. Some SOPs must be followed exactly and perfectly each time and some are much more flexible.
First, let's talk about these internal to your company. Then we'll look at how you manage exceptions with clients.
In the big picture, common sense is the most important piece of all of this. SOPs exist to make life easier. Well, life and work. When SOPs get in the way of smooth and efficient operations, then need to be set aside. We'll come back to this.
Built-In Exceptions to SOPs
Some SOPs work best if you can build in the exceptions. For example, we have a very strong policy of working from highest to lowest priority. We don't want people wasting time working on Low-Pri activities when High-Pri activities can be moved forward. Further, we have a well-defined process that says that all service tickets are worked from highest to lowest priority. BUT . . .
We also have a built-in exception to this rule.
When I go to a client's office, I start by looking at all the open tickets they have. If I'm going to go onsite, I will try to knock out all the tickets I can in the time allotted. I'm not going to take care of one high priority item, bill them for an hour, and then leave. In addition to being less efficient in the long run, that would be pretty bad customer service.
So I try to get as many tickets completed as possible. In particular, I make sure that the tasks that require an on-site technician are completed.
This built-in exception makes sure that I give good service. It also makes sure that we address all those medium and low priority service tickets that might not otherwise get any attention.
When you create built-in exceptions, make sure they actually add value to what you're doing. I think the example here is perhaps the most important built-in exception we have. It truly improves our process in several ways.
Emergency Exceptions and Bad Habit Exceptions
Emergency exceptions to SOPs should be rare (of course). Sometimes you just need to cut through the red tape - even if you created the red tape. The problem is that this decision is so subjective. You get to decide what's an emergency. If you're the owner, you don't really have to justify it to anyone.
It is a bad habit to start making exceptions and excuses. Once you go down that road, every day is a series of exceptions to the rules. Pretty soon there's no point in having SOPs at all.
The most common "excuse" given for breaking SOPs is that it's faster to "just do it" rather than follow the established process. It's very much like hiring an employee and then doing all the work yourself because it's faster than training them how to do it. You know intellectually that it's better in the long run to follow the SOP (or train the employee). But right now, today, with this one little task, it's faster to just do it.
The bottom line here is discipline.
I will say: Having employees helps. The favorite employee past time is watching the boss. So if the boss cuts corners, the employees know it's okay to cut corners. Employees will keep you in line. And they will support each other.
Once you have established SOPs and everyone is trained, then you should have the discussion about exceptions. Think of it this way: Once you know all the rules, you can make good decisions about when to break them. But that doesn't change the fact that the rules still need to be followed.
 |
| https://www.microsoft.com/en-gb/security/pc-security/password-checker.aspx |
Letting Clients Make Exceptions
Andrew's original question was largely focused on client-related policies and procedures. For example, it's easy to say that you have change your password every 30 days, but many clients simply refuse to follow this. So where do you stand firm and where do you let the client make the rules?
You probably have very few technology-related rules that you impose on your clients. You ask them to switch the backup discs or tapes; you ask them to change their passwords; you ask them to log off and night but leave the machines on; etc. A few very reasonable suggestions.
In fact, every "policy" you give them is either 1) For their own good, or 2) Related to doing business with you.
When it comes to doing things that are in their own interest, you have very little control. You can educate them, remind them, and warn them. But at the end of the day, you can't care more about their network than they do. So if they don't tend to the backup drives, there's very little you can do.
You should protect yourself when clients make certain bad decisions. For example, if a client will not take steps to make sure that they change passwords or backup their data, you need to let them know - in writing - that you can't be responsible for these things.
At the end of the day, the best you can do is to make good recommendations and encourage the client to take your advice. But if they don't want to follow your advice, there's not much you can do.
Comments welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at SmallBizThoughts.com.
- - - - -
Next week's topic: How to Track Credit Card Autopayments
:-)
SMB Books, Audio Programs, and More
100% Small Business I.T. Focused
- Technical - Business - Marketing -
- Managed Services - Cloud Computing -
- Network Migrations - Sales -
All these resources and more.
SMB Books is THE resources for the small business IT consultant who wants to move up to the next level.
|
No comments:
Post a Comment
Feedback Welcome
Please note, however, that spam will be deleted, as will abusive posts.
Disagreements welcome!