Automate in this order: ticket summaries (hours to set up), triage and routing (one to three days), quarterly business review drafts (a day or two), client onboarding (three to five days) and documentation (two to six weeks, ongoing). The order reflects set-up time and risk. Anything client-facing needs a human approval step before it leaves the building.
These are planning estimates for a small MSP of roughly five to twenty technicians using a mainstream PSA (professional services automation, the ticketing and billing system), not vendor promises or measured results. They assume your tools already have the AI features switched on or you use an automation service to connect them. Your data quality moves them more than anything else: a ticket system full of blank categories turns a one-day triage job into a week of cleaning.
The five workflows at a glance, ranked by effort
| Rank | Workflow | Set-up time (estimate) | Risk | First number to track |
|---|---|---|---|---|
| 1 | Ticket summaries | 1 to 4 hours | Low: a technician reads each one | Minutes per ticket touched |
| 2 | Triage and routing | 1 to 3 days plus a two-week shadow run | Medium: wrong priority delays a fix | Share of tickets routed correctly |
| 3 | QBR drafts | 1 to 2 days | Medium: client-facing numbers | Prep hours per review |
| 4 | Onboarding | 3 to 5 days | Medium to high: access and credentials | Days from signature to first login |
| 5 | Documentation | 2 to 6 weeks, then ongoing | High if secrets leak into text | Percentage of client environments documented |
Each section below says what the workflow is, how to build it, an example, and what goes wrong. The hours saved are illustrative sums for an imagined shop, so replace them with your own ticket counts.
1. Ticket summaries: the one you can switch on this week
Long ticket threads cost minutes every time someone picks one up: three technicians' notes, a client's rambling email, a screenshot. A summary at the top ("Issue, what has been tried, what is blocked, next step") lets whoever opens the ticket start instantly. Many PSA and remote-management tools already offer this: ConnectWise says its Sidekick for PSA assistant can summarise a ticket and add the summary as a note, and Atera's pricing page lists AI Copilot, which summarises tickets among other jobs, as included in all plans. Confirm current availability and plan terms on each vendor's page before you rely on either.
Build it: switch on the vendor's feature, or use an automation tool to send the ticket thread to an AI step and write the result back as an internal note. Keep it internal at first. A prompt for the DIY route:
Summarise this IT support ticket thread for the next technician. Use these headings only:
Issue | Affected user or device | What has been tried | Current blocker | Suggested next step.
Use only the text provided. Do not include passwords, keys or personal details, and write
"redacted" if any appear. If something is unclear, write "unclear".
THREAD: ...An illustrative reply for a ticket about intermittent VPN drops: Issue: VPN disconnects every 20 to 30 minutes for one remote user; Affected: one laptop; Tried: reboot, re-enter credentials, switch Wi-Fi; Blocker: no logs from the firewall yet; Next step: pull the VPN client log and compare with the firewall's session log. What you check: that the summary does not invent a "next step" the thread never hinted at, and that nothing sensitive was copied. Mark the next step "suggested" so nobody treats it as a decision.
Time sum: say a shop handles 1,200 tickets a month and one in four is picked up by a second person after an escalation or shift change, so 300 handovers. If a summary saves four minutes on each, that is 20 hours a month. What goes wrong: summaries that smooth over uncertainty ("resolved") when the thread says "seems fixed". Add a rule that a summary can never mark a ticket as resolved.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy now2. Triage and routing: categories, priority and the right queue
Triage is the step where a ticket gets a category, a priority and an owner. AI can propose all three from the subject and body. ConnectWise describes Service Desk Agents that classify and prioritise tickets and assign the workflow, and you can build a lighter version yourself with an automation tool. Zapier's ConnectWise and Autotask apps both offer a new-ticket trigger plus Create Ticket, Update Ticket and Create Ticket Note actions, so a flow can catch each new ticket, send it to an AI step to classify, and write the proposed category back as an internal note for a technician to accept. Check the equivalent for your own PSA before you promise a build date.
Build it, in order:
- Clean your categories. Fifteen well-defined categories beat sixty overlapping ones. Merge duplicates and write a one-line definition for each.
- Export two hundred closed tickets with their human-assigned categories and priorities as test data.
- Write the classification prompt with your category list, definitions and priority rules, such as "any mention of a server down, ransomware or all users affected is P1".
- Run it in shadow mode for two weeks: the AI proposes, technicians still triage, and you compare.
- Switch to assist mode only when agreement passes your bar (say 90% on category, 95% on P1 detection).
Classify this ticket. Return JSON: {"category": one of [list], "priority": P1-P4,
"reason": one sentence quoting the words that decided it, "needs_human": true/false}.
Rules: P1 if the text indicates a server outage, security incident, or many users
affected. If you are unsure between two categories, set needs_human to true.
Never guess a P1 downgrade. TICKET: ...A worked check: you test 200 closed tickets and the AI matches the human category on 172 (86%) and flags 18 of 20 real P1s. The two misses are "sluggish email for the whole office" (classed P3) and "CEO cannot print" (classed P4, though the client treats it as urgent). The fix is a rule, not a bigger model: add "whole office affected counts as P2 at least" and a list of client VIP names that bump priority. Re-run and check again. What goes wrong: a silently wrong priority on a real emergency. Always keep a keyword-based safety net for the words "ransomware", "breach" and "down" that forces human review regardless of the AI's answer. For the cost-benefit of this kind of automation in a small shop, see is AI ticket automation worth it for a small IT support shop?.
3. QBR drafts: quarterly reviews written from your own data
A quarterly business review pulls ticket counts, response times, patching, backup status and project updates into a client-friendly story. The prep is mostly assembling numbers and writing similar paragraphs each quarter. AI is good at the writing and poor at the arithmetic, so give it a table of figures you have exported and ask it to narrate. The longer treatment is in how MSPs use AI to write quarterly business reviews; here is the short version for sizing the job.
Build it: create a one-page data sheet per client, with tickets opened and closed, average first response, tickets by category, patch compliance, backup success rate and open recommendations. Write one prompt that takes the sheet and last quarter's QBR and drafts three sections: what we did, what the numbers say, what we recommend.
Draft the "what the numbers say" section of a quarterly review for a small-business client.
Use only the figures in the table. Compare with last quarter where both exist. Do not
calculate any figure that is not in the table; if a comparison needs a calculation,
write "CHECK" next to it. Plain English, no jargon, under 180 words. Do not promise results.
THIS QUARTER: tickets opened 94, closed 91, first response median 18 min, patch compliance 96%
LAST QUARTER: tickets opened 118, closed 120, first response median 24 min, patch compliance 92%A sensible illustrative reply notes that ticket volume fell from 118 to 94, response time improved from 24 to 18 minutes, and patch compliance rose from 92% to 96%, with "CHECK" next to any percentage change it was not given. You compute the drop (24 fewer tickets, about 20%) yourself. Time sum: if prep goes from three hours to ninety minutes across 20 clients a quarter, you save 30 hours a quarter. What goes wrong: a flattering misreading of a bad quarter, or a number carried over from another client. Always have an account manager read the draft against the data sheet before it goes out, and never let AI choose which metrics to show.
4. Onboarding: from signed agreement to first login
Onboarding a new client is a checklist that technicians recreate each time: collect user lists, create accounts, deploy agents, enrol devices, set backups, send welcome emails, book training. The automation target is the paperwork and the messages, not the access itself. Credentials and administrator rights should remain a manual step with a named approver.
Build it: write the master checklist once as a template; use your PSA's project template or a task tool to create the tasks when a deal is marked won; have AI draft the client-facing emails and the user-list request from the contract details, for a coordinator to review and send. A before and after:
Before: a coordinator writes each welcome email from scratch and chases the client for a user list three times, over about nine days.
After: a template sends the request on day one with a spreadsheet to fill in, a reminder on day three and day six, and a second AI-drafted email, edited by the coordinator, confirming what happens next; the time to a complete user list falls to about four days in this illustrative shop.
What goes wrong: AI-drafted emails that reference services the client has not bought, or an automation that creates accounts from an unchecked spreadsheet. Keep a manual approval before anything creates a user, and add a "services in scope" field that every drafted message must draw from.
5. Documentation: the biggest payoff and the biggest set-up
Documentation is why technicians waste time: the one person who knows how a client's firewall is configured is on holiday. AI can turn rough material (screen recordings, ticket resolutions, engineer notes) into structured runbooks. It is also the workflow where risk is highest, because documentation tends to contain secrets, and where the effort never fully ends. AI IT documentation for MSPs covers the screen-recording method in detail, and turning fixed tickets into a searchable knowledge base covers the ticket-mining approach.
Build it in slices:
- Pick your five most common recurring tasks (new-user setup, password reset, printer mapping, VPN setup, mailbox permissions).
- For each, take two recent resolved tickets and a recorded walkthrough, and ask AI to draft a runbook with steps, prerequisites and a "how to confirm it worked" line.
- A senior technician edits the draft once and marks it approved.
- Store approved runbooks in your documentation platform with a review date.
- Repeat for client-specific environments, one client at a time, starting with the largest.
Turn this resolved ticket and technician note into a runbook. Sections: When to use,
Prerequisites, Steps (numbered), How to confirm it worked, Known problems.
Remove any password, key, IP address, serial number or personal name; write [REDACTED].
Do not add steps that are not in the source. If a step is vague, write "CLARIFY".Time sum: a runbook that takes a technician forty-five minutes to write from scratch might take fifteen to review when drafted, so 30 minutes saved on each. Documenting fifty procedures saves about 25 hours, but add the up-front cost of choosing and editing them. What goes wrong: a draft that quietly includes an internal IP range or a default admin password copied from a ticket. Run a search for patterns (password, key, secret, long random strings) over every draft before filing it, and keep credentials in your password manager, never in the runbook.
A ten-week build plan for a ten-technician shop
Say a ten-technician MSP wants all five workflows within a quarter. Spread them out so the team absorbs one change at a time, and keep a note of the number each is meant to move.
| Weeks | Workflow | Activity | Owner |
|---|---|---|---|
| 1 | Summaries | Switch on, internal notes only, collect technician feedback on ten tickets | Service desk lead |
| 2 to 4 | Triage | Clean categories, build test set, shadow run, compare weekly | Service desk lead |
| 4 to 5 | Triage | Move to assist mode if thresholds met, keep the keyword safety net | Service desk lead |
| 5 to 6 | QBR drafts | Build data sheet and prompt, draft for three clients, account manager reviews | Account manager |
| 6 to 8 | Onboarding | Master checklist, email templates, approval step, trial on the next signed client | Operations manager |
| 8 to 10 | Documentation | Top five procedures drafted and edited; begin the largest client | Senior engineer |
Notice that triage overlaps with the next workflow's preparation. That is deliberate: shadow mode needs two weeks of waiting, and the wait is free time to start the data sheet. Notice also that each row has a person, not a team. A workflow without a named owner is the first one to quietly stop.
A rough payback sum
Take the illustrative time savings from the sections above for a shop of this size: summaries 20 hours a month, triage perhaps 15 (about a minute saved on each of 900 tickets that no longer need manual sorting), QBR prep 10 hours a month averaged across quarters, onboarding 6 hours a month on two new clients, and documentation 8 hours a month once built. That totals around 59 hours a month. Value those hours at your own loaded cost per technician hour, say $45, and you get roughly $2,650 a month. Against that, set the tool costs (some features are included in your PSA, others billed per seat or per use, so check each vendor's page), plus the one-off build time of perhaps 80 to 120 hours across the quarter. At a $45 internal rate the build costs $3,600 to $5,400, a payback of about two months on these assumptions. Treat this as a template for your own sum, not a forecast: the first months usually deliver less than the table, and a shop with fewer tickets will see smaller numbers.
A mistake that looks like success: the helpful auto-reply
A realistic failure comes from a team that, pleased with triage, lets the AI send an acknowledgement to the client: "We have seen your ticket and an engineer will call within 15 minutes." The AI got the priority right and the promise wrong, because the on-call engineer was already on a P1 elsewhere. The client waited forty minutes and escalated. The fix has three parts: acknowledgements use fixed templates that state the contractual response target, not a time the AI chose; the AI may fill in the ticket number and category only; and any message that includes a time commitment is a human's job. Lesson: triage is internal, and promises belong to people.
Telling clients what you are doing
Clients who buy managed services care about outcomes and confidentiality, so say plainly what changes. A short paragraph in your next service update works: "We now use AI to summarise ticket histories and suggest categories, so your requests reach the right engineer sooner. A person still handles every ticket and approves every message sent to you. Your data is not used to train AI models under the terms we have chosen." Say the last sentence only if your vendor's terms say so, and keep a copy of the terms. Some clients, especially in regulated sectors, will ask for a written description of your AI use and their opt-out; build that into your contract template once, rather than answering ad hoc.
Choosing your order
The ranking is a default, not a law. Change it if your pain points differ:
- Drowning in tickets: go summaries, then triage, then a deflection layer such as deflecting password resets and routine requests.
- Losing clients at review time: start with QBR drafts, since one good review protects a contract.
- Growing quickly: onboarding first, because every new client multiplies the manual work.
- Key-person risk: documentation first, in thin slices, accepting the longer timeline.
Whichever you pick, set a four-week trial with one number, a named owner and a stop condition. If the number has not moved and the owner is not using it, stop, and ask why before adding the next workflow. A busy small MSP does better with two workflows that technicians actually use than with five that nobody trusts. Tool choice is a separate question; ConnectWise AI agents against HaloPSA AI looks at two of the big platforms.
Guardrails that apply to all five
- Client data: check each client's contract before sending any of their data to an AI service, and prefer vendor features or business plans whose terms say content is not used for training.
- Secrets: never put passwords, keys or full configuration dumps in a prompt. Strip and redact first.
- Human approval: anything client-facing waits for a named person's click for the first fifty outputs, and indefinitely for anything touching money, access or security.
- Logging: keep a record of what the AI produced and who approved it, so you can answer a client's question later.
- Fallbacks: if an automation fails, tickets must still reach a technician. Test by turning the AI step off.
- Review dates: vendor features and prices change; re-check yours each quarter, and keep model names generic in your own documents.
If you would like help choosing and building the first workflow for your own tools and client mix, that is what my AI implementation consultation covers.
Questions MSP owners ask before automating with AI
Which workflow should an MSP automate first?
Start with ticket summaries. They live inside tools you already pay for, take hours not weeks, and a technician reads each summary before acting, so the risk is low. Triage comes second once you trust the summaries and have clean categories to sort into.
Do I need a developer to build these?
Not for the first two. Many PSA and RMM platforms now ship AI features you switch on, and automation tools such as Zapier or Make connect the rest. Documentation and onboarding flows may need a few days of scripting or a consultant if your stack is unusual.
How do I stop AI sending something wrong to a client?
Keep a human approval step on anything client-facing: QBR text, ticket replies and onboarding emails. Let AI draft and queue, and let a named person release. Review the first fifty outputs of each workflow before loosening anything.
Is client data safe to send to an AI tool?
It depends on the tool and your client contracts. Use business plans or vendor-built features whose terms say content is not used for training, strip credentials and personal data before prompts, and check your agreements. Never paste passwords, keys or full configuration dumps.
How do I measure whether a workflow is worth keeping?
Pick one number per workflow before launch, such as minutes per ticket touched, QBR prep hours, or days from signature to first login. Measure for four weeks before and after, and drop or fix anything that does not move its number.
Further reads
- Automate Client Onboarding With AI: Forms, Contracts, and Emails — Forms, contracts and emails for any client onboarding.
- How to Measure Whether Your AI Chatbot Is Actually Working — Ways to measure whether an AI workflow works.
- Turning Hours Saved by AI Into Advisory Work Clients Pay For — Turn hours saved into advisory work clients pay for.
- AI Receptionist for an MSP: Cost and After-Hours Ticket Logging — Logging after-hours calls as tickets.
- Automated Managed Service Provider: Hardware Refresh Plans From Asset Lists — Hardware refresh plans built from asset lists.
- How Small IT Support Businesses Use AI to Resolve Tickets Faster — How small support teams resolve tickets faster.
- How to Onboard New Hires Onto Your AI Tools and Rules — Getting your own technicians using the tools.
- Best AI Help Desk Tools for Small MSPs (2026) — Help-desk tools compared for a small MSP.
- Copilot Readiness Assessment Pricing: What an MSP Should Charge — Fixed-fee bands for a Copilot readiness assessment by user count, the five deliverables, the hours behind each price and a worked quote.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: ConnectWise's AI and Sidekick for PSA pages, Atera's pricing page, and Zapier's ConnectWise and Autotask integration pages (checked 4 November 2026).