Part Two – Bombchelle

Part Two: Getting Your Systems Out of Your Head

The last lesson was all about figuring out what you need – now we’re going to talk about working on actually creating and documenting those systems that you know you need.

Why you need to get your systems out of your head

First, we’re going to cover why you want to bother documenting your systems. Once you realize that you need systems and start actually putting them in place, it’s incredibly tempting to just keep them in your head. This is especially common with solopreneurs and those business owners who have very small teams (one or two people in addition to the business owner) – it usually seems like it’ll be a massive pain in the ass to document these systems, and besides, all of the important people know it already, right? There’s only three of us! So why do we need to write it down?

The answer goes back to the reasons we covered in the introduction – because if one of you gets sick or leaves abruptly, you’re screwed; if someone forgets a step (the human brain is not impeccable, as we’re all aware), you’re screwed; if you add a new team member, you’re not quite screwed (yay!) but you have to manually explain everything to them instead of simply sending them your system docs (boo!).

A large part of the avoidance comes from this idea that documenting your systems has to be some long, incredibly painful, slow process of writing a 10,000 word step-by-step list. No wonder people avoid it, when you think about it that way. But there are some easier ways to get your systems out of your head…

Creating system docs: the quick & dirty version

Step 1: Rename your system documents as something fun. My favorite so far is “minion manuals”. (Hat tip to Nadira for that one!) I am admittedly using the words “docs” or “documentation” here, because you might not exactly need a minion manual and those are good catch-all words, but if you’re already feeling avoidance, seriously – name it something that isn’t boring as hell. It’ll make you feel better about working on it.

Step 2: For about a week, you (and your VA or other team members, if you have them) should use Screencast-O-Matic or Jing (both free, easy to use tools) to record the process every time you do anything. Whether that’s putting an email in to your autoresponder system, scheduling tweets or Facebook updates, or anything else, every time you do something, record it, while explaining what you’re doing out loud for the recording (recommendation: do not try this in a public place, you might get some weird looks). In the meantime, start a note in Evernote, Springpad, or Google Docs (or inside your project management system) and every time you upload a new how-to video, add a link to that video to the note with a quick description (“process for client intake”). You can then show this to new team members and they’ll automatically have a place to start.

After doing this for a week or so and having your team do it as well, you’re already leagues ahead of most people, and if you really want to, you can stop here. But I’d recommend going a little further – the videos will be really helpful for the “smaller” systems, but they don’t necessarily document your policies, and they aren’t as good for the “larger” systems. What do I mean by that?

We need to talk about your TPS reports.

The difference between systems & policies

Some people might call this nitpicking, but I don’t see systems & policies as the same thing. A system in business, to me, is one of the two definitions I referenced earlier in the introduction – either a self-contained ecosystem or a step-by-step process. Policies are more like rules (or guidelines, if you’re feeling piratical). A system might be “this is what happens when a new customer starts working with us”, a policy is “these are the rules for giving a customer a refund”.

Step 3: Start documenting your policies. Here’s some places to start:

Refund policies: Under what circumstances does someone need to get authorization from you for a refund? A good example that I’ve heard is that any team member can send a refund of $X or less, but refunds of larger than that amount need to get the a-okay from someone else (a specific team member or you, the business owner).
Frequency of social media updates: If you schedule your social media updates, make sure you have down somewhere what the schedule is – every four hours Monday through Friday? Starting what time and ending what time? (And in what time zone?)
Customer service: How do you want emails to customers or clients formatted? Do you have a business-standard greeting and closing?
Frequency of other content: We already covered social media; but what about your blog or newsletter? How often does new content go out through those channels, and do you have any kind of an editorial calendar? (Example: new blog posts go up twice a week at 8 AM, inspirational video posts on Thursdays and written how-to content on Mondays.)

You can put all of these policies in one document – whether that’s on Evernote/Springpad/GDocs or inside your project management system, it doesn’t really matter. Or you can put them with their matching minion manuals. Whatever is easiest for you and makes the most sense for you & your team members.

Back to your systems…

Step 4: Start documenting your “larger” systems. The videos are great for day-to-day things – like, this is how we put someone into our client database, this is how we schedule updates, this is how the newsletter is formatted, etc., but not so much larger things. An example could be: this is how we schedule and promote a teleclass. When you’re dealing with a multi-person team, with each person having different roles, and you’re tasking out all of it, that isn’t necessarily a quick 3-step process.

There are a couple of different ways you can format the documentation for these larger systems – remember that flowchart I showed you back in the introduction, the example client follow up system? Here it is again (click for a larger version):

You could easily do that, and use different colors to represent different team members. Or you can write a step-by-step text document like the one below. Whatever floats your boat!

Example documentation: Teleclass

Here’s an example how-to document based on the above example of teleclass – this would live wherever you store your team documents. The idea is that you can turn to your project manager, OBM, or VA, and say “We’re doing a teleclass this month on the 15th, can you assign tasks and get the ball rolling on that?” All they have to do is turn to this list and put it into your project management system, and then everyone starts working on their respective pieces.

Minion Manual: Teleclass

Policies: Currently using InstantTeleseminar, username and password is in master password spreadsheet. Call in information: the number is 1-555-555-5555 and conference code is 55555; the calls need to be scheduled ahead of time (how-to video is here: www.exampleurl.com)

Steps:

Business owner: Come up with class topic/name/outline and a quick description of benefits from attending class, send that to content manager
Content manager: Write draft of landing page and tweets to share teleclass, send to biz owner for approval
Business owner: Approve/edit landing page and tweets
Tech guru: Set up a list specifically for this teleclass (naming it with the month or topic – i.e. SeptemberTeleclass), and then add opt-in forms to the landing page and change the template to the landing page template, add “Click to tweet” links to bottom of landing page and to signup confirmation page, as well as photos or anything else that’s necessary
Virtual assistant: Schedule tweets for teleclass, 4x/day from day landing page is finished up until an hour or so before teleclass – for times see social media policies here: www.exampleurl.com
Tech guru: Create Facebook event (on Facebook page) for teleseminar, using copy taken from landing page
Virtual assistant: Invite people to FB event
Content manager: Write 3 reminder emails to list with teleclass info (two days ahead, three hours before, ten minutes before) and send to tech guru
Tech guru: Schedule emails to teleclass list: two days ahead, three hours before, ten minutes before
Business owner: Mention teleclass to newsletter the week before
Business owner: Send reminder email to main list on the Monday before the teleclass

Whew!

That was a long lesson, but hopefully helpful! Any questions? Pop on over to the Facebook page and hit me up. Stay tuned for the next lesson, which is all about sticking to your systems.