Standard Operating Procedures (SOPs) define the actions of your business, and can cover the most basic actions all the way to the most comprehensive. Ironically, while most business owners agree SOPs are vital, few actually see that they're ever created or, if they are created, that they're maintained.
This disconnect is greater than with any other core business principle.
With that in mind let's take a look at suggestions for, and why you should be, taking steps to ensure your business is one of the exceptions.
Generally speaking an SOP is a how-to document for a specific area of your business.
SOP:
a procedure specific to your operation that describes the activities necessary to complete tasks in accordance with industry regulations, provincial laws or even just your own standards for running your business. Any document that is a
how to" falls into the category of procedures.
It will be up to you, the business owner, to decide how you divide your company activities, and which activities get an SOP. You may opt for a broad-view approach and simply do overviews for the larger aspects of business operations, or you may choose to drill down to very precise levels of detail.
Our recommendation is that you have an SOP for any action with multiple steps, and that you also have one for any of what you might call single-action functions; actions which may not involve actual 1, 2, 3 steps, but which are nevertheless important to make clear. Something like "How to handle an angry customer", or some other type action. You might not be able to break that down into specific steps, but you can (and should) describe your expected procedure.
If it's something you would need to explain, write it in an SOP.
Believe it or not there's actually an international standard for formatting SOPs. It's called ISO-9000, and it specifies a format with sections for:
Revision and amendment info is also specified.
If interested you can read more about the ISO-9000/9001 family of standards
on the official site. You can even get certified.
Unless you're a large and/or public company you probably don't need to adhere to that standard. However, you can derive some great ideas from the ISO materials as to how to lay out your own SOPs. Those fundamentals will apply for any scenario.
The main thing is to decide on a standard and stick to it -- whether following a complex, official specification, or winging it based on your own ideas. Another way to put this might be, "Have an SOP for your SOPs."
In other words, decide how
your
blueprint will be laid out before working up your first document.
Your company may be small but it will grow. Or it may already be big. A large entity -- with many procedures -- is either in your future, or it's in your present. You should build your SOP foundation with that in mind. Plan to scale.
Scaling is easiest with good organization. When you have a logical system in place it makes it easy for that system to keep working seamlessly as you get bigger. And bigger. And bigger.
You
will
grow. You'll add people. You yourself will forget things you once new, or have to refer back to procedures you haven't used in a while. Maybe a long while.
For this and other reasons, we recommend the following at the outset:
Create a template, or otherwise outline how each SOP should look, what it should cover, what information it should always include (responsible persons or positions, revision or amendment information, what area(s) of the business it covers, etc.), then use that guideline in the creation of each SOP document.
Give each SOP a logical name, one that conforms with the way the other SOPs are named. This is probably overlooked more than anything else. A haphazard naming convention can create real issues later when trying to find things. Think ahead to a time when you'll have dozens, even hundreds of SOPs. What will be the best way to find them? What document name will make it easy to know, just by looking at it, what that SOP covers? What additional name info will make it easy to sort and group your SOPs? Should you include the date in the name? These and other questions are important to consider before you begin.
Decide on these guidelines early, then follow them as you create your documentation.