Setting up Autotask PSA correctly from the start is one of the most important investments an MSP can make. A well-configured Autotask runs quietly in the background — routing tickets correctly, billing accurately, notifying the right people at the right time. A poorly configured one creates friction at every step: miscategorised tickets, unreliable SLA data, billing errors, and engineers working around the system rather than through it.
Autotask's Getting Started documentation partially covers the mechanics of each configuration area. This guide covers the order, the reasoning, and the decisions that matter — the things you only learn from having done this repeatedly.
One important caveat before we begin: Autotask is a deep platform. If you find yourself lost in the configuration menus or unsure how a setting will affect downstream processes, it's worth engaging a consultant rather than guessing. Mistakes made during initial setup are significantly harder to correct once the system is live and data is accumulating.
Before touching a single setting in Autotask, invest time in documenting your current operation. How do you categorise work today? How do you bill? What does your team structure look like? What are your SLA commitments?
Every configuration decision in Autotask should be driven by the answer to these questions — not by what the default settings suggest, and not by what another MSP told you they did. The MSPs that get the most out of Autotask are the ones who design their configuration around their operation, not the other way around.
With that in mind, here is the setup sequence that works.
Foundation is where you start because everything else depends on it. Before adding your team, you need to define the structure they operate within. The sequence matters.
This is the true starting point. It covers company holidays, internal locations, departments, ticket queues, and your organisational structure. Getting these right before anything else means every subsequent configuration decision has a solid foundation to reference.
Security Levels define what each user can see, create, edit, and delete within Autotask. The default security levels are a starting point, not a finished configuration — review delete and edit permissions carefully and adjust them based on your company policy. A technician who can accidentally delete a contract or a billing entry is a risk that security levels are designed to prevent. Configure these before you create any user accounts.
Roles are the "hats" your team members wear — Engineer, Project Manager, Account Manager, and so on. In Autotask, Roles are directly tied to billing: each Role carries a standard hourly rate, which forms your default rate card. When a resource logs time against a ticket or project, Autotask uses their Role rate to calculate the billing value.
Client-specific preferential rates are managed separately at the contract level via a Time & Materials contract — but the Role rate is always the baseline everything else references. Define your Roles before you add any resources.
Add your team members last — once Security Levels, Roles, and Organization are in place. Assign each resource a Role, a Security Level, and a default queue. The order matters: these dependencies need to exist before you create the resource record.
Billing Codes are the foundation of Autotask's commercial structure and we’ll cover the two most important types: Material Codes (for physical products) and Service Codes (for recurring services). Every item you sell or bill needs a Billing Code that maps to your accounting system's chart of accounts — the tax category, the general ledger account, the description that appears on invoices. Getting this mapping right before building your catalogue saves significant rework later.
Build your catalogue based on those Billing Codes. Products cover your hardware and software resale items. Service Catalogue covers your recurring offerings — and importantly, your Services are the source from which Recurring Service Contracts are built. Every managed service you offer on a recurring basis needs a corresponding Service item in the catalogue. Think of the Service Catalogue as the commercial menu from which all your contract configurations are drawn.
Ticket Management is the heart of Autotask for most MSPs. The decisions you make here directly affect SLA accuracy, billing correctness, and the quality of your reporting.
Keep them simple and meaningful. Every status should represent a genuine state in your workflow — not a historical artefact or a label that sounds useful but nobody uses consistently. The most important status to configure correctly is your "Waiting …" status: review your contractual agreement to see which pauses the SLA timer, otherwise every ticket set on a waiting status will burn through its SLA target through no fault of your team.
Priorities should reflect your actual service commitments. Most MSPs need four or five — Critical, High, Medium, Low, and optionally Scheduled. Avoid creating more priorities than you can actually operationalise. A ten-tier priority system looks comprehensive and creates confusion in practice.
These are your ticket categorisation taxonomy. Create a structure that's descriptive enough to generate meaningful reports and simple enough that engineers can categorise accurately under pressure. One essential item: always create an "Other / Other" or "Uncategorised" option. Without it, miscategorised tickets accumulate with no way to identify them. With it, "Uncategorised" becomes a metric you can track and reduce over time.
This is where many MSPs make their most consequential setup mistake. SLAs in Autotask are attached to tickets based on a combination of priority, issue/sub-issue, ticket type. Before configuring SLAs, document your actual contractual commitments — what response and resolution times have you promised to which clients under which conditions? Configure SLAs to reflect those commitments, not aspirational targets or generic industry benchmarks. An SLA that doesn't match your contract is a compliance liability.
Work Types deserve more attention than most MSPs give them at setup time. As covered in our guide to Autotask billing, Work Types are the foundation of Contract Exclusions and the mechanism by which engineers' time is routed to the correct billing arrangement. Build a Work Type list that is descriptive enough to guide engineer behaviour without requiring billing knowledge. Start from the activities that are almost always billed separately — Onsite Support, New Installation, Out-of-Hours — and work upward.
Optional but valuable for MSPs with consistent data capture requirements. Form Templates automatically populate multiple fields in Autotask forms, so if engineers are raising the same tickets over and over again, or want to template a response/resolution to a common ticketed issue, this saves more time.
This is where Autotask starts working for you rather than just recording what your team does.
Before anything else in this section, configure your external support email address. This is the address your clients email to raise tickets and the address from which Autotask sends notifications. Getting this wrong means tickets going nowhere and client communications coming from the wrong domain. Do this before you go live with anything else in this section. Be sure to check Domain Settings: administrators with the required permission can validate and optionally DKIM authenticate any domains that will be allowed to send emails from Autotask.
At minimum, you need a ticket creation notification (confirming receipt to the client) and a ticket completion notification (confirming resolution). Beyond these two, build out your notification library based on the events that matter to your clients and your team — SLA warnings, ticket updates, assignment changes. Every notification template should be reviewed for tone and clarity before going live. Generic, template-looking emails undermine client confidence in your service.
At minimum, configure rules for ticket creation (initial routing and acknowledgement) and ticket completion (billing trigger and client notification). A well-designed workflow rule set means tickets arrive in the right queue, get assigned correctly, trigger the right notifications, and flag for billing at the right moment — without manual intervention. For a detailed treatment of how to build workflow rules that scale, refer to the companion guides on this blog.
Configure it to convert incoming emails into tickets and to add notes to existing tickets when clients reply. Redirect your external support mailbox through Autotask's processing rules. Test this thoroughly before go-live — a misconfigured email integration means client emails disappearing silently, which is one of the most damaging things that can happen to an MSP's client relationship.
With the operational configuration in place, you're ready to add your clients and set up their billing arrangements.
When adding existing clients to Autotask, import them as customers — not prospects or leads. The distinction matters for billing and reporting. Pay close attention to how client names are entered: the legal entity name must match exactly how it appears in your accounting system — spaces, punctuation, and abbreviations included. Any mismatch will cause problems when you activate your accounting integration.
Set these up for each client based on their actual service agreement. For MSPs with tiered service offerings, apply the appropriate Exclusion Set to each client's contract. For clients with non-standard agreements, configure Exclusions individually. Do not go live with a client in the system until their contract configuration has been tested — run a sample billing scenario and verify the output before the first invoice cycle.
Optional, but worth evaluating at setup time even if you don't activate them immediately. The Client Portal gives end users a self-service interface for raising and tracking tickets. Taskfire extends this to allow clients to manage their own internal ticket queues. Make a deliberate decision rather than leaving them unconfigured by default.
Before cutting over to Autotask as your primary system, run through this final verification:
Going live is not the end of the configuration process — it's the beginning of the optimisation process. The first 30 days of live operation will reveal gaps and edge cases that no amount of pre-launch testing fully anticipated. Build in time for review and adjustment and treat early issues as configuration problems to fix rather than platform limitations to work around.
A well-configured Autotask is the foundation of an efficient MSP operation. Getting the initial setup right — or correcting a configuration that wasn't done properly — is exactly what we do at Kinesys.
kinesys.it • info@kinesys.it • HaloPSA Official Partner & Autotask Experts