Ownsteps / Guides

IT documentation for MSPs: practical client procedures

Reviewed 14 October 2026.

Useful IT documentation lets another technician find the right client procedure, confirm the environment and finish a task without relying on the usual owner's memory. For a small IT team or managed service provider, the challenge is often a mix of missing steps, scattered documents and client details copied into the wrong place.

Start with procedures people repeatedly ask about: assigning a service ticket, checking a client portal setting, or preparing a routine access request. Separate the general method from each client's approved configuration. This guide covers document structure, storage choices and maintenance; it does not turn a screenshot recorder into a client knowledge base.

Separate the documents that answer different questions

A client overview explains the environment and service boundaries. An asset or system record identifies the system involved. A procedure explains how to perform a task. A secret store holds credentials and recovery material. These records can reference each other without putting every detail into a single screenshot guide.

For example, a procedure can say ?open the approved administration portal listed in the client system record.? It should not paste a privileged password into the page. Document the approved access route and required role, with a reference to the existing credential system. Keep operational secrets outside screenshots and exported instructions.

Distinguish internal and client-facing material. An internal troubleshooting runbook may include escalation routes that a customer's employee should not receive. A client guide should explain their allowed actions and stop points. Do not send an internal export merely because its screenshots happen to be readable.

A small structure for client procedures

Use a predictable title such as ?[client reference] ? verify a portal setting ? [environment].? Include environment information when it prevents confusion between production and test. Use your existing naming convention if one exists. Searchable names and a small index are more useful than a complex folder hierarchy that nobody follows.

Example: verify an approved browser setting

Suppose a technician must confirm a setting in a client portal. Before opening the portal, they need the authorized request, correct client reference and expected value from an approved source. State that this procedure verifies the setting; changing it requires the separate authorization route.

1. Open the portal from the client system record and confirm the displayed tenant matches the request.
2. Navigate to the documented settings area using the actual menu labels. Include a sample screenshot if it makes the location clearer.
3. Compare the visible value with the approved value. Record the observation in the existing ticket without copying unrelated customer data.
4. If the tenant, permissions or value differs, stop and use the documented escalation route. Do not silently correct a mismatch under a verification-only request.

This is a structure example, not an instruction for a specific portal. Test the real labels and behavior before using it. Explain the final state: the setting was checked and the result recorded, with no unintended changes. A screenshot taken before navigation cannot establish that the required verification happened.

Keep reusable methods separate from client differences

A common task may share most steps across clients while differing in portal location, role or approval rules. Keep one general method where it is accurate, with a clear client-specific reference for the differences. If the differences change the actions substantially, maintain a separate client procedure instead of adding many conditional paragraphs.

When copying a guide, treat it as an unreviewed draft. Replace names and screenshots, inspect links, and verify the new client's configuration and access. A find-and-replace operation cannot confirm that two environments behave alike. Mark the procedure's applicability explicitly so a technician does not infer that a generic screenshot proves a client's setup.

Where to store the reviewed master

Use the team's existing approved knowledge base or document store when it supports the access and maintenance you need. Before choosing a destination, check client separation, reader permissions, version history, search, backup and offboarding. Test with a reader account rather than judging access from an administrator's view.

For a very small team, a structured shared folder and index may be workable if permissions and ownership are clear. Separate draft captures, reviewed masters and client deliverables. Give each procedure one authoritative location. A local folder synchronized to a cloud service has a different storage boundary from an unsynchronized local folder.

When importing HTML or Markdown, test a small guide first. Verify image paths, headings, internal references and how an update replaces the old version. For Word or PDF delivery, reopen the exported file and identify the master it came from. This guide does not verify a particular knowledge-base integration or import format.

Keep procedures current as part of the work

Assign a responsible role and record when the procedure was last followed successfully in its stated environment. Choose review intervals according to the task's change rate and importance. Also review when a portal is redesigned, a role changes, a client is migrated, or a technician reports a mismatch.

Let the ticket workflow surface documentation corrections. Record the step that differed, the observed behavior and the applicable environment. Have the responsible reviewer check the proposed revision, then update the master and replace distributed copies. A date change alone does not demonstrate that the steps were retested.

Prioritize documents by operational use. Fix a misleading frequently used instruction before expanding an unused section. Test an important procedure with another technician who has the expected access and background knowledge. Their questions often reveal missing assumptions about client selection, approvals and completion checks.

Browser capture and desktop work need different coverage

Ownsteps records Chrome webpage clicks and builds editable steps with screenshots. It can help prepare browser procedures for portals and web applications. Edit titles and notes, reorder or remove detours, replace images and black out private areas. It does not capture Windows consoles, terminal sessions, native applications or remote desktop actions.

For a mixed task, use manual desktop captures or a desktop recorder and combine the reviewed instructions in an existing editor. Explicitly describe where the workflow leaves the browser. Do not leave an unexplained gap simply because one capture tool cannot cover it. See capture options and Tango alternatives when desktop coverage is a requirement.

Ownsteps does not read what you type into fields, skips password fields and blacks out input boxes in screenshots. Page-rendered text elsewhere can still appear in screenshots or step text. Review both and use the redaction tool to black out any area. Check client names, notifications and URL parameters using the redaction checklist.

For a repeatable starting document, adapt the free SOP template. For short task-level instructions, use the work instruction template. Keep the business rules and client applicability in the reviewed master, regardless of how screenshots were captured.