How to document a process for new hires

Reviewed 14 October 2026.

A new hire needs more than a record of where an experienced colleague clicked. They need to know when a task applies, which account or customer environment to use, what they are allowed to change, and when to stop. Good process documentation makes those decisions visible alongside the screenshots.

For a small team or an IT managed service provider, begin with one task that a new colleague will actually perform. "Update a service ticket after a support call" is a useful scope. "Everything about the service desk" is too broad for a first guide and is difficult to keep current.

Start with a manual first-task guide

Choose one first-week task and define the new hire's permissions and expected result.
Perform the task with sample data, taking screenshots manually at important actions and checks.
Write instructions that explain prerequisites, decisions, exceptions and escalation routes.
Have a new reader follow the draft in a suitable test environment and revise unclear steps.
Publish the reviewed copy in your team's chosen location and record its owner and review date.

A screenshot tool and an existing document editor are enough for the first version. Write the explanation immediately after each capture while you remember why the action was necessary. Keep the sequence focused on the authorized task, and separate unrelated setup work into its own guide.

Describe the starting state

State which application, role and environment the procedure assumes. For an MSP, include how to confirm the customer or tenant before changing anything. An application that looks familiar can still be the wrong customer's environment. Show a safe example of the context indicator and tell the reader what must match.

Describe the approved route for obtaining access without including credentials. If the task needs a particular permission, name it or describe the capability required. Tell the new hire what to do if the relevant control is missing; they should not guess that a different account or workaround is acceptable.

Identify the input information and where it comes from. For a ticket update, the reader may need the ticket reference, a summary of the support call and the next action agreed with the requester. Explain how to find the correct record rather than using an example identifier as if it were reusable.

Teach the decision, not just the click

Write "Open the ticket that matches the requester and reference" before showing the ticket search screen. Then explain the check that prevents selecting a similar record. This helps the new hire understand the purpose of the screenshot instead of copying a sequence mechanically.

For a status field, explain when each relevant status is appropriate. A screenshot of one selected value is not a general rule. If a ticket must remain open pending confirmation, say so. Put that condition before the save step, and show the state the reader should verify afterward.

Keep application actions and approval decisions distinct. A guide can show how to request a change without authorizing the change itself. For operations that affect customers, access or billing, use your actual organizational approval rules and identify the point where the reader must pause.

A practical ticket-update example

Purpose: record a completed support interaction on the correct existing ticket.
Before starting: confirm the customer environment, ticket reference and authorized access.
Locate: search for the reference and compare the requester with the call record.
Update: add a factual summary, work performed and the agreed next action.
Check visibility: confirm whether the note is internal or customer-visible before saving.
Verify: reopen the ticket and inspect the saved note, status and assignment.
Stop: escalate a mismatched customer, uncertain visibility or missing permission.

This is an example outline, not a procedure for a particular ticketing product. Replace each action with the real controls and policies your team uses. Include screenshots for the context check and note visibility, not only the final save button. Those are places where an inexperienced reader may need extra guidance.

Add the exceptions a new hire will encounter

Ask the experienced operator which situations cause them to stop. Document missing records, unexpected permissions and ambiguous instructions at the step where they matter. Include an escalation route by role or approved channel. Do not invent an individual owner or response deadline if the team has not agreed one.

A useful exception note names the condition, the safe next action and the information to collect. For example: "If the customer name does not match, stop editing and ask the assigned supervisor to confirm the environment." Avoid broad advice such as "contact someone if there is a problem."

Keep secrets and unnecessary customer data out of training examples. Use a test environment or clearly labeled sample records when possible. Check the screenshots, instruction text and filenames before sharing outside the team. A realistic example should teach the task without becoming a copy of a customer's private screen.

Record the browser portion when it repeats

Ownsteps can help prepare the screenshot sequence for tasks performed on Chrome web pages. It records clicks, captures step screenshots and builds a guide you can edit. When available, record the normal browser path with sample data, then stop and review the resulting steps.

Rewrite titles and notes for a beginner. Remove detours, replace incomplete images and add the context and decision checks described above. Ownsteps does not save typed values as step metadata, so explain required inputs yourself. It can permanently redact image regions, but content outside input fields still needs inspection.

The guide and screenshots stay on the recording computer with no account or guide upload. Share a reviewed exported file through your team's chosen system. That makes a file handoff possible without asking the trainee to use Ownsteps, but distribution permissions and replacement of old copies remain your responsibility.

Test with a reader and keep a master

Have a colleague who is unfamiliar with the task follow the draft in a suitable test environment. Watch for unexplained terms, missing starting conditions and uncertainty about success. Revise the exact step where the difficulty occurs. Completing the sequence with extensive verbal coaching does not show that the document stands on its own.

Choose one location for the reviewed master, identify its responsible role and record the review date. Recheck the affected sections after application or policy changes. A trainee should know which version to use and where to report a mismatch. Retire outdated copies instead of leaving several apparently current documents in circulation.

For the actual writing process, use the screenshot SOP guide. If the training document needs comments or client edits, see the editable Word export guide. If your team is choosing between local files and a shared service, see the Scribe alternatives comparison.