An operating procedure can be complete on paper and unusable at the desk. The author knows which screen to open, what a supplier's shorthand means and when a manager should be called. A new colleague may know none of those things, yet the document skips them because they seem obvious to the person who wrote it.
Testing a procedure with a new team member is a practical way to uncover those gaps. The aim is to assess whether the instructions support reliable work, while keeping training and live operations safe. This guide sets out an original test method for a small operator or agency, drawing on public procedure and usability guidance. It does not replace required professional training or supervised authorization for specialist activities.
Choose a procedure with an observable outcome
Start with a bounded task such as preparing a private-tour supplier brief, recording an accepted booking change or issuing a checked pickup instruction. Avoid testing “run the operations department” as one task. A clear scope makes it easier to recognize where the procedure succeeds and where it leaves the person guessing.
Write the starting condition, expected outcome and stopping point. For a pickup instruction, the starting condition might be a confirmed booking with a location question. The outcome could be a consistent, approved instruction recorded and communicated through the correct channel. The stopping point should specify what requires escalation.
The US EPA's SOP preparation guidance is a useful reference for documenting repeatable work, although its quality-system context differs from travel operations. The relevant adaptation is to give a procedure enough detail to be followed and reviewed. A document titled “check everything carefully” does not provide an observable method or a testable result.
Separate training, testing and authorization
A new employee may need basic orientation before a procedure test makes sense. Confirm they can access the test tools, understand the role and recognize the business terms required for the task. Otherwise, a login problem can consume the session without revealing much about the procedure itself.
At the same time, avoid teaching the exact answer immediately before the test. If the author walks through every click, the person may reproduce the demonstration while the document remains incomplete. Give enough context to represent their actual stage of onboarding, then observe whether the procedure supports the task.
Passing one test does not automatically authorize independent work. The manager must still decide what the colleague is permitted to do, with what supervision and under which operating rules. Keep those decisions explicit. This is especially important where a task affects payments, capacity, sensitive information or a safety-related judgment. The test can reveal a need for training or specialist review without pretending that a checklist supplies the necessary competence.
Set the questions the test should answer
Choose a few focused questions before writing the scenario. Can the colleague locate the procedure? Can they identify the authoritative source? Do they distinguish a request from an approved change? Can they recognize a missing fact and stop at the right point?
The GOV.UK guidance on planning a research round emphasizes defining what you need to learn. Applied to internal procedures, this prevents an unfocused session that ends with “the colleague seemed comfortable” but no evidence about the important decisions.
Write acceptance criteria in terms of outcomes rather than the author's preferred route. A person may find the correct record through a different legitimate navigation path. What matters is whether the result is accurate, appropriately recorded and within their authority. Reserve strict sequencing for steps where order has a real operating purpose, such as checking approval before communicating a change. Explain that purpose in the procedure itself.
Design realistic cases without using live guest risk
Use dummy data or a clearly isolated test environment. Create a case with the same kinds of detail the colleague would encounter: a date, participant mix, supplier response, booking reference and a small amount of realistic ambiguity. Remove actual personal data unless there is a justified, approved reason to use it.
Include one normal case and one exception. A normal case shows whether the basic sequence works. An exception reveals whether the procedure teaches judgment and escalation. For example, a supplier may confirm a product but leave pickup coverage unanswered. The correct next step should not be to invent a pickup promise so the case can be closed.
Do not make the exception a trick. It should represent a plausible working situation, with the same evidence the employee would normally receive. Tell the participant what outcome they are trying to achieve without naming the exact buttons or page headings. The procedure should provide the route. A test that gives away the route measures instruction-following in the session more than usability of the document.
Prepare the observation method
Assign an observer or note-taker where possible. Use a simple record: time or step, observed action, relevant words, uncertainty, help given and consequence. Distinguish what happened from your interpretation of why it happened. “Opened the old policy page” is an observation; “does not pay attention” is an unsupported judgment.
GOV.UK's guidance on taking research notes offers useful principles for preserving evidence. For this internal adaptation, keep notes proportionate and limit personal information. If you record the session, explain the purpose, obtain appropriate permission and follow the record-handling requirements relevant to your business.
Prepare the procedure exactly as a colleague would normally encounter it, including its title, location and links. Do not leave the correct page open if finding it is one of the questions being tested. Confirm that test accounts can perform the intended actions without affecting production. A short practice run with the facilitator can catch broken test setup before the new employee arrives.
Observe without rescuing the procedure too early
Explain that the document and process are being tested. Ask the colleague to describe what they are trying to do as they work, while allowing quiet concentration when needed. Watch where they search, what they reread and when they hesitate.
The GOV.UK moderated usability-testing guidance supports realistic tasks and neutral observation. In this adaptation, avoid leading prompts such as “Have you checked the notes at the bottom?” A neutral question is “What are you looking for now?”
If the participant becomes stuck, record the point and the assistance you provide. Then help enough to continue learning from the remaining steps. Do not pretend the task was completed unaided. Stop immediately if the test could affect a real booking, expose information or exceed the person's authority. A realistic simulation should reveal operating problems without creating them. Preserve the difference between an issue in the procedure, an access problem and a training need.
A hypothetical booking-change test
Imagine the procedure covers a client's request to move a private activity to the following day. The test pack contains the request, a supplier reply confirming the new date and a booking screen still showing the original date. The supplier reply does not address the changed hotel location.
The new colleague correctly identifies that a request and a supplier response do not mean every required booking update is complete. They follow the procedure to the booking record but cannot tell who is authorized to approve the location-related pickup change. The document says only “update details.” The observer records the ambiguity and the colleague's decision to ask a supervisor.
The task is paused at that boundary rather than marked as a personal failure. The revision should name the approval role, identify the location check and state what evidence must exist before the client receives a final confirmation. A retest uses a different hypothetical date and hotel so that the participant must follow the revised method rather than recall the first case. The useful result is a better instruction and a clearer authority boundary.
Classify problems by their cause
After the session, group findings into findability, missing information, unclear language, incorrect sequence, access, system behavior and training. One observation can have more than one cause, but naming the likely cause helps choose the remedy.
If the colleague could not find the page, adding more detail inside it may not help. If the procedure uses supplier shorthand they have never been taught, add a definition or adjust onboarding. If the instruction says to edit a field their role cannot access, resolve the role or handover design. If the workflow itself is inconsistent, rewriting the document more elegantly will not fix it.
Prioritize by consequence and likelihood within your operation. An ambiguous step that could send a guest to the wrong pier deserves attention before a minor formatting preference. Avoid arbitrary severity scores that imply more precision than the evidence supports. Describe the likely operational effect and the case in which it could happen. That makes the finding understandable to the person deciding what to change.
Write a revision brief that someone can implement
For each important finding, record the task, evidence, defect, proposed correction, owner and retest condition. The brief should explain what the new instruction must allow the colleague to do. Avoid “make it clearer” as the only action.
A useful revision brief might say: “At the supplier-confirmation step, distinguish the date approval from pickup approval. Add the responsible role and a stop rule when the location is unresolved. The tester should be able to identify the missing pickup decision without coaching.” This gives the author a specific design problem.
Have the operating owner review the revision for factual correctness. A tester may suggest a simpler path that conflicts with the actual booking rules, so feedback is evidence rather than automatic approval to change the process. Preserve the previous version where needed, give the new version an effective date and tell affected staff which action has changed. The supplier change log guide provides a related method for tracking changes across dependent material.
Retest the correction and a neighboring case
Repeat the task with fresh dummy details. Check whether the original problem is resolved and whether the revision introduced a new ambiguity. A procedure can fix one exception by making the normal path unnecessarily complicated, so include a neighboring straightforward case.
Where practical, involve another colleague who has not seen the first test. This helps distinguish an improved document from learning by the original participant. If the same employee retests, avoid interpreting familiarity as proof that a completely new starter would succeed.
Use an acceptance checklist:
- The colleague can find the current procedure.
- Required tools and permissions match the stated role.
- The expected outcome and authority boundary are clear.
- Facts and approvals are checked before commitments are communicated.
- Missing information has an explicit next action.
- The result is recorded in the appropriate system.
- Assistance given during testing is visible in the notes.
- Material revisions have been checked and retested.
Do not require an arbitrary perfect score for every minor issue. Make the readiness decision according to the task's consequences and the supervision actually available.
Make procedure testing part of operating maintenance
Retest when the software changes materially, a supplier introduces a new requirement, a role changes or repeated questions show that the instructions no longer fit the work. You do not need to run a formal session after every typo correction. Match the effort to the significance of the change.
For an approved agency using Tripnatic, the agent journey includes activity search, quotes and bookings. Registration is followed by applicable verification and approval before activation. Your internal procedure can explain how the team uses its workspace and handles approvals without implying that a quote reserves capacity or that a test account authorizes live actions.
Choose one procedure this week and observe a colleague using it on a realistic case. Record the first point where they must guess. Resolve that point, retest it and update the working copy. A reliable procedure is demonstrated through use, with explicit ownership and limits. Its value is that a colleague can perform the work accurately when the author is not standing beside them.
