How do you inform your Users about on-going operations status and issues.

Hello, it was good to see you all in Melbourne. As part of my performance improvement focus, I have some questions about how you inform your Users of on-going operational status and issues.

At ISIS, our main control room updates the ISIS web site with on-going issues during cycles. This may include
explanations as to why the machine is down, length of time until back on, updates of fault progress, machine metrics, etc.

How do you keep you USERS in touch with machine operational status and issues?
Maybe you have a similar web site bulletin board, I Pads, texting or a big screen for all to view?
What do you tell your users and how do you inform them of problems?
What phrases do you use or don't use? who administers this?
What feedback have you had from your Users about what they want to know and the effectiveness of the information you already deliver?

I look forward to your replies.

Julian Brower

Hi Julian,
we have more than one way to inform the users. For the operator it is all combined in one application:
he can enter text lines of 40 chars only. The last entered five lines are shown to the users. Messages are automatically deleted after 24 hours.
The messages are kept short by intention: details are not useful to the users, just rough time estimates are fine.

• A web page shows a 10h current history, some accelerator and beamline status and these text lines (http://abk.web.psi.ch/operation/kr/sls/sls_status.php)
  
• A dedicated application runs at the experiment consoles of the users. This plays a different sound for each event: new message, beam lost, orbit feedback failure.
  The user has to acknowledge the event, this is shown to the control room.
  
• The user can set his beamline to three modes "offline", "attended", "unattended". Only attended beamlines get acoustic event notifications.
  
• The user can relay the event to a mobile phone as SMS. This is useful if a fully automated measurement is running.
  

We store all operator events timestamped in a database and append them in our electronic logbook for each shift.

Hi Julian,

We have a schedule in Outlook that shows the committed users/tasks on our machines. If there is a problem, the Scientist/Operator is involved immediately and work can be rescheduled, depending on what is broken, to other operators/scientists.

Word of mouth is our modus operandi, though we may have to re-think this as the two new machines come on line...