Claude For It Services And Msps

Claude for IT services firms and MSPs

Four workflows below, each one a job your shop already does and always does last: the client readable summary of a month of tickets, the quarterly business review, the outage update you write while you are still fixing the outage, and the runbook that currently lives in one engineer's head. Everything runs in claude.ai in a browser, with your own formats and past documents saved in a project, so the drafts come back looking like your firm's work instead of a template. None of it asks you to paste a credential, a live address, or a client's security findings into a chat window.

Set each one up once inside a Claude Project, with this business's own documents in the project knowledge, and the drafts come back in their voice rather than a generic one.

How to use this skill

Ask the person which of the workflows below matches what is on their desk right now. Then walk them through that one only. Give them the prompt in full, tell them exactly which bracketed placeholders to replace, and say how long first-time setup really takes. Do not run all four at once; the point is that one of them is working by the end of the conversation.

Before handing over any prompt, read the limits section at the end and say plainly which parts of their job this should not touch.

1. Turn a month of tickets into a summary the client reads

What happens today. The client's monthly summary starts life as a PSA export: sixty rows of subject lines, categories, and tech notes written for other techs. You either send it raw, which tells them nothing, or you rewrite it by hand on the last afternoon of the month for every client you owe one to.

What happens instead. You paste the export and get back four sentences at the top, the tickets grouped by theme instead of by date, the recurring root causes called out, and open items with an owner named. You read it once, fix what it got wrong about their environment, and send it the same week the period closes.

First-time setup: about 20 minutes.

You are helping a managed service provider turn raw ticket notes into a summary a non-technical client contact will actually read. Use only the ticket data I paste below. Never invent a ticket, a count, a response time, or an uptime figure. If a number would help and I did not give it to you, write NUMBER NEEDED instead of estimating it.

Client and who reads this: [client name or code, plus the role of the person reading it, for example an office manager or a CFO]
Period: [dates]
Ticket export or notes from our PSA: [paste the list with subject, category, status, and whatever tech notes you are willing to share]
What I already know matters this period: [anything you want called out, or write NONE]
Terms this client does not use: [for example GPO, endpoint, DHCP, whatever you end up translating on every call]

Produce this, in order:
1. Four sentences at the top: what we handled, what is still open, and anything they need to decide.
2. The tickets grouped by theme rather than by date. For each theme give a plain language description, the count from my data only, and the current status.
3. Anything that reads as a recurring root cause rather than a one off, with the specific tickets that support that read.
4. Open items, each with an owner named as ours or theirs, and what it is waiting on.
5. Two or three questions I should ask this client based on what these tickets show.

Rules: strip usernames, hostnames, addresses, serial numbers, and anything resembling a credential or license key out of your output, and tell me what you removed. Write it so an office manager understands it without making it sound like we did less work than we did.

2. Build the quarterly business review from your own data

What happens today. The QBR is Thursday. You reuse last quarter's deck, drop in a ticket chart, and spend the meeting narrating what already happened. The three things you needed them to fund get raised in the last five minutes and deferred again.

What happens instead. You paste the quarter's ticket themes, the lifecycle notes, and what you want approved, and get back an agenda, risks written as business consequences, a recommendation per risk with the cost of waiting, and the three hardest questions the room will ask you.

First-time setup: about 35 minutes.

You are helping me prepare a quarterly business review for a managed services client. My QBR format and two past decks are in the project knowledge.

Client: [name or code, headcount, what the business does, who will be in the room and what each of them cares about]
Contract: [for example per seat managed services, what is included and excluded, renewal date]
Quarter: [dates]
Ticket themes and volumes for the quarter: [paste your export or your own summary]
Asset and lifecycle notes: [paste what you know about machine age, warranty status, and end of support dates for what we cover]
Projects we completed this quarter: [list them]
What I want them to approve next: [list the projects or spend you are recommending]
Budget context: [what they have told you about budget and timing, or write UNKNOWN]

Build it in this order:
1. An agenda that spends the first third on their business and the rest on ours.
2. A one page service recap using only the figures I gave you. Where a figure belongs and I did not supply it, write FIGURE NEEDED.
3. Risks, ranked, each stated as a business consequence first and the technical cause second. Say plainly which risks came out of this quarter's tickets and which are lifecycle or design issues we already knew about.
4. For each risk, the recommendation, the decision I am asking for, the rough shape of the work, and what changes if they defer it one more quarter. Do not price anything.
5. A twelve month roadmap by quarter, built only from the items above.
6. The three hardest questions this room will ask me, and a straight answer to each.

Rules: no invented benchmarks, no industry averages, no percentages, no dollar figures, no vendor statistics. Assume the person holding the budget has sat through plenty of vendor decks and will discount anything that sounds like one.

3. Write the outage update while you are still fixing it

What happens today. Half the client's staff cannot get to the file server, your senior tech is elbow deep in it, and the owner is calling you every twenty minutes. The update you send is either three words or a paragraph that promises a restore time nobody has confirmed.

What happens instead. You give Claude what is confirmed and what is not, and get a first notification under 150 words, two versions of the next holding update, and an internal note on what you are not saying yet. It also flags anything that should go through counsel before it goes to the client.

First-time setup: about 15 minutes.

You are helping a managed service provider write client communication during an active incident. I am giving you only what we know right now.

What is happening, in my words: [describe the symptom, the affected systems, and what is confirmed versus suspected]
Who is affected: [which client, which sites, how many users, which business functions are down]
Start time and current status: [when it started, what we have tried, what is working now]
What we do not know yet: [be honest here]
Workaround: [describe it, or write NONE]
Next update I can commit to: [time]
Audience: [for example the client's owner, their entire staff, or one department]

Write three things:
1. The first notification, under 150 words, in plain language. Lead with what the reader cannot do right now and what to do instead. State what we know, label anything unconfirmed as unconfirmed, and give the time of the next update. Do not speculate about cause and do not state a restore time I did not give you.
2. The next holding update in two versions, one for real progress and one for no progress yet. The no progress version still has to be worth opening.
3. A short internal note for my team: who owns client communication, what we are not saying externally yet and why, and what we need to confirm before the next update.

Then, before I send anything, list every element of this incident that suggests data was accessed, copied, encrypted, or lost, or that a regulated system was involved. If you find any of those, say clearly that the client notification needs to go through the client's counsel and ours first, and stop drafting external wording about cause or scope.

Rules: no cause claims, no blame, no invented timelines, and never write that data was not affected unless I have told you that is confirmed.

4. Get a runbook out of the one engineer who knows

What happens today. One person can rebuild that client's line of business app server, and the procedure exists as a chat thread and their memory. Every tier one tech routes the ticket to them, and the week they take vacation the whole thing waits.

What happens instead. You talk through how it actually runs, answer six clarifying questions, and get a downloadable runbook with prerequisites, non-reversible steps marked, verification, failure modes, and escalation triggers. It also tells you which steps you described too vaguely to trust.

First-time setup: about 30 minutes.

Act as a senior engineer helping me turn one person's knowledge into a runbook a tier one tech can follow without calling them.

The procedure: [name it, for example onboarding a new user at a client, or restoring a single file from backup]
How it actually runs today, in whatever order it comes out of my head: [describe the steps, the tools involved, the client specific variations, and what usually goes wrong]
Who will run this: [experience level of the person following it]
What must never appear in this document: [for example passwords, keys, addresses, client names]

First, ask me up to six questions about the steps that are ambiguous, the decision points where a tech has to choose between two paths, and anything that would cause damage if done out of order. Wait for my answers before writing.

Then produce the runbook as a document I can download, containing:
1. When to use this, and when to escalate instead, at the very top.
2. Prerequisites: access needed, approvals needed, and who grants each. Reference every credential by where it lives, for example the password manager entry name, never by value.
3. Numbered steps in the order they must happen, each one an action a tier one tech can perform without asking what it means. Mark every step that cannot be undone.
4. Verification: how the tech proves it actually worked, not just that a tool returned no error.
5. The common failure modes, each with the first two things to check.
6. Rollback, if there is one, and a plain statement when there is not.
7. An escalation path with the trigger for each level.
8. A change log line with today's date and a placeholder for the owner's name.

Finally, list every place where my description was thin enough that you had to guess, so I can fix those before this goes into our documentation library.

What not to use Claude for here

Say these out loud rather than waiting to be asked. Being trusted is worth more than being impressive.

• Credentials and live infrastructure detail. Passwords, API keys, certificates, connection strings, firewall or VPN configs, network diagrams with real addressing, and security assessment or penetration test findings do not belong in a chat window, yours or your client's. On Free, Pro, and Max accounts whether your chats are used to improve Claude is a setting you control in Privacy Settings, and Anthropic does not use Team or Enterprise account data to train its models by default. Either way, a secret that leaves your password manager is a secret you no longer control. Reference credentials by where they live, never by value.
• Security configuration and compliance attestations. Claude will hand you a confident conditional access policy, firewall rule set, or control mapping that looks right and is wrong in the details that decide whether it holds. It does not know the client's real environment, the current version of the framework, or what your assessor will accept. Use it to draft the explanation and the client facing summary, have a named engineer verify configuration against vendor documentation, and never sign an attestation or a security questionnaire on the strength of a chat.
• Incident communication that carries legal weight. Once an event looks like unauthorized access, exfiltration, ransomware, or loss of regulated data, the message stops being a service update. Breach notification requirements vary by state and by contract, the clocks are short, and most cyber policies require you to involve the carrier and counsel before you communicate. Draft internally if it helps you think, then route anything client facing through counsel and your carrier before it is sent.

Questions this business usually asks

Our MSAs and DPAs restrict where client data goes. Can we use this at all?

Yes, for the parts that are your words about the work rather than the client's data. The four workflows above run on ticket themes, your own notes, and your own document formats, which is where most of the writing time goes anyway. Read your MSA and DPA for subprocessor and AI language, because some already answer the question, and get approval in writing before client data of any kind goes into a chat. The habit that holds up: strip names, hostnames, and addresses, paste summary level detail rather than exports, and keep anything from a security assessment out entirely.

Can Claude connect to our PSA or RMM and just do this?

Not in these workflows, and that is deliberate. Everything on this page is paste in, draft out, which means nothing gets read from or written to a client's production systems and there is nothing to get approved first. Anything beyond that is an integration project with its own security review, its own client approval, and a named owner. Do not point a chat tool at a client's stack because a workflow looked convenient.

If Claude writes the first draft of a runbook, can we trust the documentation?

Only after an engineer who has performed the procedure signs off on it, same as any other documentation. What you gain is the structure and the questions: the prompt above forces prerequisites, non-reversible steps, verification, and escalation triggers into the document, and it ends by listing where your description was too thin to be reliable. That list is usually the most useful output, because it is the part your senior engineer never thought to say out loud.

Do we need a paid plan, and how do we roll this out to the team?

Start on a free account. Projects, project instructions, and project knowledge work on free plans, capped at five projects, and paid plans add expanded project knowledge capacity through retrieval and higher usage limits. Build one project per recurring job rather than one per client at first, so a client reporting project, a QBR project, an incident communication project, and a documentation project, each holding your formats and two or three of your best past examples. Team and Enterprise plans let you share a project with specific people or the whole organization, which is where this stops being one owner's habit and becomes how the shop writes. Downloadable documents come from artifacts, which requires code execution and file creation turned on in your settings.

More

A longer written version of these workflows, plus workflows for other trades, is at https://claudeforbiz.com/claude-for-it-services-and-msps . Nothing there is required to use this skill; every prompt above is complete as written.