Repair handoff: what to put in the note
A useful handoff lets the next technician distinguish the customer’s report from your findings and any theory about the cause. Record relevant dates, exact status text, approved changes, side effects, and the check performed afterward. State what remains unresolved, and omit credentials and unrelated private details.
Updated November 11, 2026
- Write the reported symptom Use the customer’s words where useful. Include when it began, how often it occurs, and what task was affected, without turning the report into a diagnosis.
- List the checks and findings Name the read-only views or logs reviewed and record the relevant result, date, or displayed status. Mark uncertainty instead of filling gaps with a guess.
- Record each change Describe only changes that were actually approved and made. Include who approved them and when, plus any expected side effect or remaining question.
- Say how you checked the result Write what was repeated or observed after a change and whether the original symptom was present. Do not claim a fix worked if the check did not cover the reported condition.
- Note what to watch for Tell the customer which symptom, warning, or recurrence should prompt a return visit. Avoid guarantees or advice beyond what the observed result supports.
- Remove unnecessary sensitive details Do not place passwords, recovery keys, tokens, or unrelated private data in the note. Keep the handoff limited to information needed for the next safe step.
What did the customer report?
Record the customer’s symptom, affected task, when it began, and how often it occurs. Keep their report distinct from your interpretation. Add relevant operating system or recent-change context, not unrelated private details.
What did I find?
List checks and relevant evidence, including the built-in view, status, date, or log area. Quote warnings as shown. Separate observations from possible causes and label uncertainty so a theory is not mistaken for a conclusion.
What changed, and who approved it?
Record only the changes actually made, when they happened, and who approved them. If nothing changed, say that the visit was diagnostic only. Note relevant side effects, such as a service interruption, and any step that remains pending.
Do not write passwords, recovery keys, tokens, or secrets in the note. If a credential or protected detail is relevant, follow the shop’s approved secure process rather than copying it into a general ticket field.
How did I check the result?
Describe the check performed after a change and whether it matched the customer’s original condition. If the symptom did not occur during the check, say so. Do not say a problem is fixed when only a different or shorter check was possible.
What should the customer watch for?
Name the specific symptom or warning that should prompt follow-up, plus the question or step still open. Keep the note tied to what was observed; do not guarantee the issue will not return or claim data is safe without evidence. If the result check did not reproduce the customer’s condition, say that plainly.
A technician can copy what CommandGate’s scan showed into the note, alongside what was actually run and how each result was checked.
When should I stop?
Stop and ask for guidance rather than filling a gap with a guess, copying a credential, or claiming a result the checks did not establish. If a next action could affect customer data, leave it pending until backup needs and customer approval are documented.