Best Practices for Documenting Your Autotask PSA.. I mean, your MSP

A more mature MSP will want to document each process they have. That includes their PSA, RMM, backup/recovery, disaster recovery (DR) process, etc. In this blog, I’ll walk you through some major “sections” of Autotask to document and the best way that documentation should be done.

The first thing to realize is that you should not document Autotask. You document business process and then back out into procedures. What’s going to be fun for you is seeing that when you do this and then align configuration to that, instead of trying to document configuration as your “process,” your documentation project will be slashed in half.

Initial Process Areas

Don’t go too deep on your first pass. Let’s focus on some key areas that will filter down into your Autotask PSA.

Obviously, the Departments are specific to your MSP, but the three above are quite common. Also notice the Products Used/Offered. Document that. You would be shocked how many MSPs don’t even have a single line of documentation stating “we use VMware for our virtualization,” even though their website lists VMware Certified on the homepage.

Your First Process Document

Next, for each of the above create a single process document that has NO MORE than one diagram/flowchart and consumes a single page. That is 10x what your competitor has, so focus on achieving that goal for each of the areas above first.

For the high-level example, I am going to pick something you would not think to see here: I’ll document Departments. Then, later, I’ll show you how this simple act of creating a one-page document will drive change in your Autotask and how much more easily you can create Autotask Workflow Rules (WFRs), understand WHO should get automatic notices out of Autotask, etc.

Backing into Procedures and Configurations

Earlier, I promised to show you how defining processes first let’s you back into procedures and configurations. We are going to use the Department process doc walk us through that.

So what people often do is try and document every little setting and workflow. Yes, that’s great, but it’s difficult, especially in organizations where there is not a dedicated documentation/QA team. Instead, we’re going to use the strategic approach that our configuration IS the documentation. We can only do that by focusing on processes and definitions upfront.

Note that in the process document above, we include a department code. That gives us a huge amount of “self-documentation power” in Autotask. Instead of having to figure who owns what queues, WFRs, etc., we now have a the department code in our process document to make the configuration the documentation of who owns what.

Here are your new queue names:

• 0003 Sales Inquiries
• 0003 Account Manager Activities
• 0004 Customer Disputes
• 0005 Triage
• 0005 HelpDesk
• 0005 New Deployments
• 0005 RMM Alerts

See a pattern here? Here are some example WFRs:

• 0003 Route website emails to Sales
• 0004 Route accounting@ emails
• 0005 Auto Email Customer ACK of New Ticket
• 0005 Flag Backup Alerts as Critical
• 0005 Push New Tickets into Triage Queue

This may seem small until you realize you NO LONGER have to document who owns which queue, what is the general purpose of a WFR, etc. And, more importantly, when your team looks at any of these, they don’t need to refer to a document: it’s clear as day who owns what. And that’s the best documentation you can have, especially for new hires.

Now, this isn’t to say you should not document things, but, especially in your first pass, if you focus on process and definitions and then align your configuration to that you gain many benefits:

• Reduced documentation/paperwork
• Reduced documentation rewrites (huge)
• Instant training for new hires
• Alignment of human tendencies to maintain the status quo, instead of fighting it

To summarize, focus on easy wins here that deliver big results. Documentation is a lot of work upfront, but 10x more work in maintaining it, so your main goal in documenting a well-run MSP is embedding documentation into the process itself. Once that is done, shift into a more granular approach toward documentation.