I programmed our initial Universal Robots UR5e job for fixture-to-tray unloading with a small aluminum housing in a shared bench handling station and handed it over to the operators. They can start the saved job, but they need me when a pocket is empty or a run is interrupted. I suspect the handover omitted recovery decisions, rather than the operators lacking willingness.
A teach-back could reveal where the handover becomes unclear. What do operators understand the restart instruction to mean when they explain it without prompts?
During a discussion, I asked operators to explain the restart wording and received several different interpretations. That gives us a concrete ambiguity in the handover to address.
Use the conflicting interpretations to revise the instruction into condition, permitted action and escalation criteria.
After the responsible integrator reviews it, check understanding again through an unprompted teach-back.
Because I wrote the ambiguous instruction, I'm concerned that teach-back could feel like blaming the operator. How can I frame it as a check of the handover?
For my own handover, I framed the discussion around locating gaps in the guide I had written. Asking where it required a guess helped operators contribute corrections without defending their interpretation
The revised handover will connect observable conditions to permitted steps and escalation, with integrator review. I've made a successful check of understanding a condition of treating the revision as ready.