A revisit must reference the fault and previous service while retaining its own diagnosis, materials and conclusion.
Index
Opening a new work order for every return can hide an unresolved issue; merging everything also loses independent visit records.
The rule that changes the scope
A revisit must reference the fault and previous service while retaining its own diagnosis, materials and conclusion.
Standard service software may link orders; custom software supports symptom-level follow-up and verification of the solution.
Link visits through the issue but retain the report received during each contact. The identified cause can change while the symptom described by the customer stays the same. In the demonstration, locate initial evidence and the test performed at each return. Automatically grouping everything by customer is too broad: different equipment or independent faults must not become one service sequence just because the customer is identical.
Specify operational deliverables
- Associate the return with the original issue and the reason reported by the customer.
- Separate a recurring symptom from a new fault identified during the second visit.
- Record solution validation without rewriting the previous visit's diagnosis.
Test the exception before acceptance
In a hypothetical scenario, a customer reports the same symptom but the technician finds another cause; history must show that change without treating the visits as duplicates.
Reference for assessing scope
NN/g: writing task scenarios for usability testing
Prepare your project with Quantum9
Bring a sequence of return visits and the criterion used to declare the issue resolved.