AI IT Documentation for MSPs: Client Runbooks From Screen Recordings

Record the job with narration, turn it into a transcript plus a few reviewed frames, and run a local scrub that strips secrets before any AI tool sees it. Prompt with placeholders such as [[VAULT: entry name]] instead of passwords, draft into a per-client template, and have a second engineer follow the result before it is filed.

A recording holds more than the engineer says out loud: a BitLocker recovery key on screen, a token in the address bar, a notification from another client's ticket. The scrub step is therefore the control, and any wording in the prompt is only a backstop. Developer documentation tools assume code and public APIs. An MSP runbook describes a customer's live network, usually recorded by someone logged in as an administrator, so the habit that matters most is deciding what the AI is never shown.

Follow me on Instagram@sagnikteaches

What a recording captures that the narration never mentions

Ten minutes of an administrator's session carries several kinds of material that have no place in a runbook, and most of it is recorded without anyone deciding to share it.

Connect on LinkedInSagnik Bhattacharya

• Credentials on screen. A password-manager reveal, a show-password toggle, the temporary password a new-user form displays once, a managed local administrator password pulled up during a repair.
• Recovery material. A BitLocker recovery password is a 48-digit number, normally shown as eight groups of six digits, and engineers open it in the portal precisely when something has gone wrong. MFA recovery codes and backup encryption passphrases belong in the same bucket.
• Tokens in places nobody reads. Address bars with a sig= or token= parameter, installer links that carry a site key, API keys visible on an integration settings page.
• Another client. A second browser profile, a tenant name in the corner of the portal, a device list that includes a different customer, a ticket notification.
• People. Names, phone numbers and mailbox contents on a user's profile page.

The narration is the smaller problem because the engineer controls it, though not completely: it is easy to read a temporary password aloud while talking a colleague through a login. The pixels are the larger problem, because they include everything the engineer was not looking at. Two rules follow. Treat every raw recording as a file that may contain secrets (restricted folder, no sharing links, deleted once the runbook is approved), and let nothing reach an AI tool until it has been through the scrub described further down.

Subscribe on YouTube@sagnikteaches

Record so there is less to scrub

Most of the cleaning is cheaper before the recording starts. Give every engineer who records the same short brief.

1. Record one window or one browser tab, not the whole desktop, and switch on the do-not-disturb or focus setting so chat and email banners stay out of the file.
2. Use a clean browser profile with no bookmarks bar, no saved sign-ins and no second client's tenant open.
3. Do the job on a test user or a spare device wherever you can. Record production sessions only for tasks that cannot be reproduced.
4. Pause the recording before anything that retrieves a credential or a recovery key, and say "paused at the vault" aloud first so the transcript shows why the narration jumps. Resume once the screen is clear.
5. Narrate names: the menu, the button, the field, what you expect to see afterwards and why you chose that setting. A transcript made of "and then I click this here" is no use to an AI or to a person.
6. Never read a credential aloud. If you slip, stop the recording, say so in the ticket and delete the file.

The fifth habit pays twice. A line such as "the list should now show three licences" hands the AI the expected result for that step, and it gives the second engineer who tests the runbook later something to check against.

Decide what the AI may see: three tiers

Before choosing a tool, decide what is allowed to leave your machine. Three tiers cover nearly every case.

Tier 1 works because the engineer narrated names. The AI never needs a screenshot to write "open Active users"; it needs the sentence the engineer said. Tier 2 earns its place when the route through a console is hard to describe in words. The command ffmpeg -i recording.mp4 -vf fps=1/60 frames/step_%03d.png writes one frame a minute into a folder that already exists, which is a fair start. Crop each frame to the window that matters, then look at it at full size, because small text in a corner is still readable once zoomed.

Step-capture tools sit between the tiers: they record clicks and screenshots and write the steps for you. The vendor pages I read in November 2026 treat redaction as a plan feature. Scribe lists editing and redacting screenshots on its Pro plans (Pro Team is $13 a seat a month billed annually, or $17 monthly, for five or more seats) and auto-redaction of PII and PHI (personal and health information) on Enterprise. Tango's Pro plan lists blurring sensitive data while capturing, with automatic PII detection on Enterprise, and its Pro Team plan for three or more users is $15 a user a month billed annually, or $20 monthly. Both describe automatic redaction in terms of personal data. A recovery key or an API token is not personal data in the usual sense, so test the tool with a fake one before you rely on it. The Scribe SOP generator tutorial covers the capture-and-edit mechanics.

The documentation platforms are adding the same thing. IT Glue's home page describes a Smart SOP Generator that captures "every click, keystroke and action", and its Copilot page names an AI assistant called Kaseya Assist. Hudu's plan page lists an AI assistant beside its password vault, and its AI page says the AI "only sees what your role allows" and lists a connection that lets external assistants read and write documentation. None of those pages says whether password entries are inside or outside the AI's reach. Ask each vendor in writing how password fields and vault entries are handled, treat any connector like a new user with the narrowest role that works, and store a dummy entry with a fake password to confirm it never surfaces before real client data goes near the feature.

Placeholders instead of passwords: a vault-reference habit

A runbook should say where a credential lives, never what it is. Four kinds of placeholder do the job.

Name vault entries so a stranger can find them: client code, system, account purpose. List every entry a client's runbooks may cite in that client's profile, so the AI picks from a list instead of inventing a name. If the transcript mentions a credential with no matching entry, the AI writes [[VAULT: ENTRY NEEDED]], and that becomes a job for the engineer: create the entry, or decide the step should not need a shared credential at all.

Here is the habit it replaces. The engineer says, on the recording, "log in as the admin, the password's in the spreadsheet, the one ending in 22." After the loop, the runbook line reads: "Check out [[VAULT: CLA / Microsoft 365 / break-glass admin]] only if your named admin account cannot sign in, and leave a note in the ticket." The second version names the account, says when to use it and leaves a trail, none of which the narration did.

A local scrub script that runs before any prompt

Patterns catch most of what slips through, and a script catches them more reliably than a tired engineer scanning a transcript. The script below needs only Python. It reads subtitle files from one folder, replaces matches with [[REMOVED]], swaps client names for placeholders using a small per-client file, and exits with an error if anything looked like a secret, so a wrapper script or a person has to look before the next step.

First get the text without sending audio anywhere. Whisper is open source under the MIT licence and runs from the command line on your own machine, so the audio never leaves it. A cloud recorder's built-in transcript means the audio has already gone to that vendor, which is acceptable only if the tool is approved for client sessions. The two commands below pull the narration out of the video and write a subtitle file with timestamps; the project page for Whisper lists the other model sizes.

ffmpeg -i recording.mp4 -vn -ac 1 -ar 16000 narration.wav
whisper narration.wav --model turbo --output_format srt --output_dir transcripts

import json, pathlib, re, sys

RULES = [
    ("password-phrase", r"(?i)\b(?:password|passcode|passwd|pwd)\b\s*(?:is|was|=|:)\s*\S+"),
    ("token-or-key",    r"(?i)\b(?:api[_ -]?key|secret|token|bearer)\b\s*(?:is|=|:)?\s*[\w./+=-]{12,}"),
    ("jwt",             r"\beyJ[\w-]{10,}\.[\w-]{10,}\.[\w-]{10,}"),
    ("private-key",     r"-----BEGIN [A-Z ]*PRIVATE KEY-----"),
    ("aws-key-id",      r"\bAKIA[0-9A-Z]{16}\b"),
    ("bitlocker-key",   r"\b(?:\d{6}-){7}\d{6}\b"),
    ("product-key",     r"\b[A-Z0-9]{5}(?:-[A-Z0-9]{5}){4}\b"),
    ("sas-signature",   r"[?&]sig=[\w%+/=]{20,}"),
    ("one-time-code",   r"(?i)\b(?:code|otp|mfa|2fa|pin)\b\D{0,15}\b\d{6,8}\b"),
]

def scrub(text, entities):
    hits, out = [], []
    for n, line in enumerate(text.splitlines(), 1):
        for label, rx in RULES:
            line, k = re.subn(rx, "[[REMOVED]]", line)
            hits += [(n, label)] * k
        for real in sorted(entities, key=len, reverse=True):
            line = re.sub(re.escape(real), entities[real], line, flags=re.I)
        out.append(line)
    return "\n".join(out), hits

def restore(draft, entities):
    for real, token in entities.items():
        draft = draft.replace(token, real)   # [[REMOVED]] and [[VAULT: ...]] stay as they are
    return draft

if __name__ == "__main__":
    src_dir, dst_dir, ent_file = map(pathlib.Path, sys.argv[1:4])
    entities = json.loads(ent_file.read_text(encoding="utf-8"))
    dst_dir.mkdir(exist_ok=True)
    total = 0
    for f in sorted(src_dir.glob("*.srt")):
        clean, hits = scrub(f.read_text(encoding="utf-8"), entities)
        (dst_dir / f.name).write_text(clean, encoding="utf-8")
        total += len(hits)
        for n, label in hits:
            print(f"{f.name} line {n}: {label}")   # the match itself is never printed
    print(f"{total} possible secrets: check the recording first" if total else "clean")
    sys.exit(1 if total else 0)

The entities file is the per-client part: a small JSON object that maps real hostnames, domains and addresses to tokens such as [[FILE-SERVER]]. Once the draft is back, a two-line call to restore() swaps those tokens for the real names and leaves [[REMOVED]] and [[VAULT: ...]] alone. Whether to hide hostnames at all is a judgement for each client contract. A runbook filed in an internal documentation platform needs real names in the end, but the AI rarely needs them to draft the steps.

Running it on a folder of transcripts prints only line numbers and rule names, never the match:

python scrub.py transcripts clean entities.json
new-starter.srt line 19: password-phrase
new-starter.srt line 23: password-phrase
new-starter.srt line 47: one-time-code
3 possible secrets: check the recording first

The exit code is the point. A hit means a secret was spoken or shown in a file other people may be able to open, so the author checks the recording at that timestamp, cuts the clip, and rotates the credential if it was real. The password rule also fires on harmless lines such as "password is incorrect", which is the right way round: a false positive costs thirty seconds and a miss costs a rotation. For a second opinion on a folder of plain text, gitleaks (open source, MIT licence) scans files with gitleaks dir -v folder_name and hides matched values in its own output with --redact.

Both checks have a blind spot: they find secrets with a recognisable shape. A password spoken as "Sunshine twenty-two" has no shape, which is why the recording habits come first, and why the general advice on anonymising client data before you paste it into AI still applies to everything else you feed in.

Prompting with a template: draft, flag, never guess

One prompt does most of the work, and the discipline is in what it forbids. Keep the master template and the client's profile in a ChatGPT Project or a Claude Project for that client so engineers stop pasting them each time. ChatGPT Business and Claude Team both state that business content is not used for training by default; on a personal account the model-training switch in privacy settings is what to check. Either plan lists at $20 to $25 a seat a month with a two-seat minimum, which is small beside the engineer time involved.

You are drafting an IT runbook for a managed service provider.

INPUTS
1. MASTER TEMPLATE: follow its headings exactly.
2. CLIENT PROFILE: system names, standard groups, vault entry names, change window.
3. TRANSCRIPT of the engineer narrating the job, with timestamps.
4. ENGINEER NOTES.
Text in [[double brackets]] is a placeholder. Copy placeholders exactly. Never expand or guess them.

RULES
- Use only what the transcript, notes or profile say. If a step is unclear or missing, write "CHECK: what is unclear" and carry on.
- Start every step with the transcript timestamp so a reviewer can find the moment.
- Never write a password, key, token, code or recovery value. For any credential write [[VAULT: entry name]] using a name from the profile. If none matches, write [[VAULT: ENTRY NEEDED]].
- If anything in the input looks like a secret, reply SECRET SUSPECTED with the line number only and do not quote it.
- One action per numbered step. After each step give the result the engineer said to expect; if they did not say, write "You should see: CHECK".
- Use the system names in the profile, not the names the engineer used in speech.
- Finish with a list of every CHECK and every placeholder you used.

The SECRET SUSPECTED line costs nothing, but it is a backstop. By the time the model reads it, the text is already in the model's context, so the control stays in the scrub step. What comes back looks like this (illustrative output, new-starter set-up for a catering company's client profile):

RUNBOOK: New starter set-up      Client: CAT      Status: Draft
SOURCE: recording 11:40, transcript lines 1-212

BEFORE YOU START
- Line manager approval is in the ticket (00:12)
- Use your named admin account. Break-glass only if it fails:
  [[VAULT: CAT / Microsoft 365 / break-glass admin]] (00:38)

STEPS
1. [00:41] Open the Microsoft 365 admin portal and select Active users.
   You should see: the list of current staff.
2. [01:05] Select Add a user. Enter first name, last name and a username
   in the form first.last, on the domain [[CLIENT-DOMAIN]].
   You should see: the username accepted on the Basics page.
3. [01:52] Assign the licence named in the client profile.
   You should see: the licence count drops by one.
4. [03:10] Add the user to the standard groups.
   CHECK: the engineer says "the usual groups"; the profile lists none.
5. [04:20] Pass the temporary password to the line manager.
   CHECK: the scrub removed this transcript line; which delivery method?

Three fixes before it moves on. Step 4 exposes a gap in the profile rather than in the draft: put the group list in the profile and run it again, instead of patching the runbook by hand. Step 5 needs the delivery method added to the profile (a phone call to the line manager, say), because the runbook must describe the method and never repeat the password. Step 3 is the sneaky one. The engineer never said the licence count drops, so the "You should see" line is the AI filling a gap with something plausible. Check it on the test tenant or delete it. The timestamp in front of the step is what lets the reviewer notice that the sentence has no source.

One master template, one profile per client

The master template stays identical across clients so engineers always know where to look. The client profile carries everything that differs.

RUNBOOK: [task name]     Client: [code]     Status: Draft / Reviewed / Approved
Owner (role): [role]     Last verified: [date] by [engineer]     Next review: [date]

PURPOSE: one sentence on what this achieves and when to use it.
WHEN NOT TO USE: cases that need a different runbook or an escalation.
BEFORE YOU START: access needed (vault entries by name only), approvals, change window, backups to confirm.
STEPS: numbered, one action each, with the result to expect after each.
IF IT FAILS: the three likeliest failures, each with a fix or an escalation.
ROLLBACK: how to undo the change, in order.
CHECK IT WORKED: independent tests with expected results.
CLIENT-SPECIFIC NOTES: anything that differs from the standard version, and why.
SOURCE: recording date, transcript reference, reviewer.

A filled-in profile for one client, here a courier firm, shows how much the AI needs and how little of it is secret:

The same template serves very different clients. A catering company with a seasonal hiring peak needs new-starter and leaver runbooks at volume, so its profile lists the seasonal group names. A translation agency full of freelancers cares about guest accounts and when they expire. A small manufacturer has shop-floor PCs and an old ERP server that only one machine can reach, so its profile says what must never be patched before the Friday backup. Resist the urge to hide client quirks inside the master template. When one client's runbook needs a step the others do not, it goes under CLIENT-SPECIFIC NOTES with a reason, so the next engineer can tell a quirk from a mistake.

Eleven minutes of recording, one approved runbook: the numbers

Take a job every MSP repeats: setting up a new starter for a catering company with 40 staff. The figures below are illustrative, not measured, so time ten of your own jobs before you quote them to anyone.

The transcript ran to about 1,640 words. The scrub flagged three lines: the engineer had read the temporary password aloud twice, at 04:12 and 04:19, and a one-time code appeared at 07:31. Because it was a test user, the fix for the password was to delete the user. The AI draft had 17 steps, three CHECK lines and two vault gaps. The cold run caught one error the author had missed: the step that adds the user to the all-staff mailing list sat before the step that assigns the licence, and the list would not offer the new user until the mailbox existed. Swapping the two steps fixed it.

Typing the same runbook from scratch had taken about 70 minutes of the author's time in the past, and the cold run and approval would still be needed, so 89 minutes in all against 50. That is 39 minutes saved per runbook. A backlog of 120 runbooks therefore frees about 78 hours, or roughly $4,700 at an assumed loaded cost of $60 an hour. Four engineers on a business AI plan at $25 each cost $100 a month. The drafting is cheap; the time that matters is the review, which is why the loop below never gets skipped.

The review loop that keeps a bad runbook out of the vault

Three people touch every runbook, and none of them is the AI.

The cold run is the step that earns the runbook its "Approved" label. Someone who did not make the recording will trip on every unexplained shortcut. Give the reviewer this checklist and nothing more:

• Every step traces to a timestamp, or has been confirmed live since.
• Searching the runbook for "password", "key", "token" and long digit strings finds nothing but vault references.
• Every vault entry cited exists today and is the right one.
• Portal and menu names match what the console says now, checked by opening it rather than from memory.
• The rollback has been read by someone who did not write it.
• The "check it worked" tests do not reuse the steps: sign in as the new user in a private window, for example, rather than looking at the same admin page again.

Four numbers tell you whether the loop works: the share of runbooks that pass the cold run first time, minutes from recording to approval, scrub hits per month (it should fall as engineers learn) and the number of tickets where an engineer used a runbook and still had to ask for help. Report them quarterly alongside the rest of the service review; the tutorial on quarterly business reviews shows where documentation coverage fits.

Five ways a recording misleads the AI

These failures turn up most often once a team starts producing runbooks this way, each paired with the habit that catches it.

The pattern across all five is that the AI writes fluent text that fills gaps, and a fluent gap is harder to spot than a blank one. The CHECK rule converts silent guesses into visible questions. If your first batch of drafts contains no CHECK lines at all, treat that as a warning about the prompt, not as proof the drafts are complete.

Keeping runbooks true after sign-off

A runbook is accurate on the day it is approved and drifts from then on. Put the last-verified date at the top of every page and set the next review by risk: restores, offboarding and anything that changes a firewall rule every quarter, routine tasks every six months. Add three triggers that override the calendar. A vendor changes the console the runbook walks through. The client changes the system it describes. Someone uses the runbook during a ticket and it fails; fix it within the week, with the ticket number in the revision note.

Keep the scope clear. Runbooks describe how to perform a planned task for a named client. The searchable record of what fixed a past incident is a different asset, and turning fixed tickets into an AI knowledge base is its own job with its own risks. Treat the two as separate shelves: the runbook tells an engineer what to do during a Tuesday evening change, the knowledge base tells them what usually causes an error code.

If recording cleanly is the part your team finds hardest, start smaller. Pick one repeatable task per client, record it once on a test account, and run the whole loop before expanding. The general method for turning screen recordings into SOPs covers the parts that are not specific to MSPs, and if you would rather map the whole process with someone, that is what my AI implementation consultation covers; you can get in touch here.

Questions MSP teams ask before they start

Can I upload the raw video to an AI tool?

You can, but every frame goes with it, including notifications, other tabs and any credential that was revealed on screen. Keep raw video for test tenants with dummy data. For production work, send the scrubbed transcript and a few cropped frames you have looked at yourself. Use video-capable tools on client sessions only once their data terms are covered by your client contracts.

What if a credential turns up in a transcript?

Treat it as exposed to everyone who can open that file. Rotate it, delete the clip and the transcript, note the event in the ticket, and tell the engineer which habit caused it. Deleting the line from the text does not undo the recording. If the credential belonged to a test user, deleting the test user is the whole fix, which is why recordings are best made on test accounts.

Should I use IT Glue's or Hudu's built-in AI instead?

It may suit you, because the content stays near your credential vault, but test it before trusting it. The AI pages I read for both vendors did not explain how passwords are kept out of the AI features. Ask in writing, then store a dummy entry with a fake password and check that it never appears in an answer.

How long should raw recordings be kept?

Treat the recording as scaffolding. Keep it until the runbook has passed its cold run, then delete it and the transcript together. Pick a fixed limit such as 14 days, write it into your documentation standard and check that it matches your client contracts. The approved runbook is the record, and it contains no secrets to leak.

Do clients need to know I use AI on their documentation?

Read the data-handling and sub-processor clauses in each contract, since many require notice of any third party that touches client information. Even where they do not, telling clients which tool you use, what goes into it (scrubbed text, no credentials) and what stays out will shorten security questionnaires and build trust.

Further reads

• Best AI Help Desk Tools for Small MSPs (2026) — Compare the AI help desk tools a small MSP can run alongside runbooks.
• MSP Automation Ideas: Five AI Workflows and Their Set-Up Time — Other MSP workflows worth automating, with set-up time for each.
• Shadow AI: How to Stop Staff Pasting Client Data Into Free Tools — Stop engineers pasting client material into free AI tools.
• How Small IT Support Businesses Use AI to Resolve Tickets Faster — Where AI helps resolve tickets once runbooks exist.
• AI Receptionist for an MSP: Cost and After-Hours Ticket Logging — Monthly cost bands for four AI receptionists, the ticket fields to capture, urgent-escalation rules and the test calls to run before a client rings at 2am.
• ConnectWise AI Agents vs HaloPSA AI: Which Fits a Small MSP? — What ConnectWise's AI agents and Halo's AI claim on the vendors' own pages, plus a 60-ticket test set, scoring rule and break-even sum for a small MSP.
• Automated Managed Service Provider: Hardware Refresh Plans From Asset Lists — How a small managed service provider groups a client's asset list into replace-now, next-year and later buckets, then builds the budget table.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Scribe, Tango, IT Glue and Hudu pricing and product pages (read November 2026); gitleaks and Whisper project pages on GitHub; Microsoft Learn BitLocker recovery overview; OpenAI and Anthropic business-plan data-use statements.