Our short orders use the first pockets in sequence. The screen only names the full tray job, so it gives the operator no visible expected count for that run.

That explains one call. For interruptions, what can they see about the last completed transfer? I would not assume the count tells them where a block physically ended up.

Nor that the selected tray is the fitted tray.

Hazel, they see a count but no attempt detail. Victor, tray identity is on the tray, not checked by this saved job. Both omissions are on the review now.

Jamie raises a practical gap. Louis, assign a named support route in the interim handover; an unclear recovery decision should not become an operator's experiment because the programmer is away.

Shift lead now takes those calls and contacts the application maintainer where the transfer state is uncertain. The proposed screen shows expected order count and tray identity. Maintainer is defining the interrupted-attempt view.

Let the covering operator try interpreting that view before polishing the lesson. They should be able to say what is known, what is uncertain and whom to call without somebody pointing at the answer.

Include an unexpected gap, not only a short order.

And make it a defined exercise with the application maintainer and shift lead. Training should use the agreed recovery behaviour, not invent it during a demonstration.

That exercise is booked with both. The operator has reviewed the mock-up but hasn't tried the station cases yet. Thank you, Jamie; naming the interim contact already stopped the calls bouncing between two absent people.

Good. Keep that contact route after the lesson is improved too.