Electronic Shift Handover and Operator Logbook Software: What the Night Crew Forgot to Tell the Day Crew

Why shift handover is where process plants lose control of their own equipment state

06:45 in a control room. The night shift board operator has twelve minutes to hand over to a man who has been off for four days. He talks through the night: the reflux pump tripped at 01:20 and they swapped to the spare, the coker heater pass three thermocouple is reading strangely and instruments have a job in, they are running one product cooler because the other has a leaking gland, and the number two column level controller has been left in manual since 23:00 because it was hunting.

The incoming operator writes some of that on a notepad. The paper log has entries for the pump trip and the cooler. The controller in manual is not written anywhere, because the man who did it intended to put it back and then got busy. At 11:00 a feed change comes through, the level runs away, and the shift that inherits the problem has no idea the loop was in manual.

None of this is unusual and none of it is negligence. It is a known and studied failure mode. The Cullen inquiry into Piper Alpha found that a pressure safety valve had been removed for maintenance and that the permit status was not effectively communicated across the shift change before the pump was started. Every process safety curriculum since has treated handover as a control, not a courtesy. The regulator's position is that handover should be structured, two way, and recorded. What most plants actually operate is unstructured, one way, and remembered.

Problem 1: the paper log is a diary and what you need is a state

What an operations organisation actually runs on is a set of open conditions: equipment out of service, controllers in manual, alarms inhibited, temporary repairs in place, samples awaited, deferred work, permits live on plant. Every one of those has an owner, an expected resolution, and a risk if forgotten. A diary cannot represent them. A crew's collective memory can, right up to the point where the crew rotates.

What a custom build does is separate the two. Chronological entries stay chronological. Open items are a distinct object with a state, an owner, an age, and a required review at every handover, so the incoming shift lead cannot complete acceptance without seeing every unresolved condition and its age. An abnormal condition that has been open for nine days is visible as a nine day old condition, which is often the first time anyone realises it. In our experience that ageing view is the feature operations managers notice first, because it exposes conditions the organisation had silently normalised.

Problem 2: the handover is verbal, so its quality depends on the person and the day

A good operator gives a thorough handover. A tired operator at the end of a fourth night gives a shorter one. A handover into a crew that has been off for four days needs to cover more ground than one at a shift change within the same rotation. And a handover that happens while a shift is dealing with a live problem gets compressed to nothing.

A structured handover forces coverage by section: process condition and any deviation from target, equipment out of service and why, control loops off normal, safety systems inhibited or bypassed with authorisation reference, work in progress and permits live, environmental status such as flare or effluent excursions, and outstanding actions for the incoming crew. The incoming operator reviews, asks questions, and signs acceptance. Both signatures are recorded with time.

Problem 3: the context lives in four systems and the operator retypes it

The information an operator needs at handover is already electronic and sitting in systems that do not talk to each other. The trend that shows the temperature drifting is in the historian. The alarm burst at 01:20 is in the alarm system. The instrument job is a work order in the maintenance system. The permit for the cooler gland is in the permit to work system. The last laboratory result is in the LIMS.

What a custom build must include is context by reference rather than by retyping. A log entry tagged to equipment automatically carries the relevant trend window, the alarms in that period, and the open work orders and permits against that tag. The operator writes the judgement, which is the part only they have, and the system attaches the evidence. That is also what makes the log genuinely useful in an investigation, because the entry and the data behind it are already joined.

Problem 4: the log is a legal and technical record kept in a paper book

Control room logbooks get pulled into environmental excursion investigations, incident investigations, insurance claims, and regulatory inspections. In a plant covered by process safety management requirements, the log is evidence about how operating procedures were followed and how abnormal conditions were handled. In pharmaceutical and specialty operations under electronic records rules, any electronic replacement has to satisfy signature and audit trail requirements rather than simply being a database with a login.

A paper book has one advantage, which is that it is hard to alter without leaving a trace, and one fatal weakness, which is that it is not searchable, not reportable, and only exists in one control room. The electronic replacement must therefore be append only for entries, with corrections recorded as visible amendments carrying a reason and an author rather than as edits. Any plant that already runs regulated electronic records needs the signature model designed in from the start, not retrofitted, because retrofitting audit trails onto a mutable data model is a rewrite.

Problem 5: operator rounds are still on a clipboard

Outside the control room, field operators walk rounds and record readings on a paper sheet that gets filed and never read again. Those readings are the earliest indicator of a developing problem you have: a bearing temperature creeping up, a seal pot level falling, vibration on a pump that is not instrumented.

Bringing rounds onto a handheld, with the route defined per plant area and readings validated against expected ranges as they are entered, does three things. It stops out of range values being written down and forgotten, because the device challenges the operator at the moment of entry. It builds a history for equipment that has no instrumentation, which maintenance can use. And it links naturally into the logbook, so an abnormal reading on rounds becomes an open item that carries across shifts rather than a number in a filing cabinet. Offline capability is not optional here, since the far end of a tank farm does not have coverage.

Where eschbach, j5 and AVEVA actually stop

We should be straightforward: eschbach Shiftconnector and j5 International are purpose built for this problem and they are good. Shiftconnector in particular has been doing structured shift handover in chemical and pharmaceutical plants for a long time, and j5 has genuine depth in operations logbooks, permits and rounds across oil and gas. AVEVA brings the advantage of sitting alongside its own historian and operations portfolio, which matters if you are already an AVEVA site. If you run one plant with one control room and your requirement is a structured handover with carry forward, buy one of these. Building would be spending six figures to arrive where a licence gets you in eight weeks.

Where the calculation changes is at multi plant scale and at the integration boundary. Handover structure is genuinely plant specific: a refinery's unit based handover, a specialty batch plant's campaign based handover, and a mine's per face handover are not variations on one template, and configuring one product to serve all three across a group tends to converge on the lowest common denominator. Integration to your specific historian tags, your maintenance system's work order model, and your permit system is bespoke work in every case, whichever route you choose. Per user licensing is awkward when you want every field operator on rounds. And if the logbook is intended to become part of a wider operations platform holding production accounting, deviations and shift performance, embedding it in a product you do not control constrains everything you build afterwards.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering structured logging with equipment tagging, open items with carry forward and ageing, a configurable handover template per area, and review with recorded acceptance runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding historian trend and alarm context, maintenance and permit integration, operator rounds with offline handhelds, deviation and abnormal condition workflows, shift performance reporting, and regulated electronic signatures runs $150,000 to $380,000 phased over 6 to 12 months.

What drives cost up specifically here: the number of distinct handover structures across the group, since each is a template with its own required sections and rules. Historian integration, which depends on whether you have a supported interface or an older system that needs a bridge, and which will involve your controls engineer and a security review before anything crosses from the process network. Regulated electronic signature requirements. Offline field devices in classified areas, where intrinsically safe hardware costs real money. And translation, since operators log in the language they speak, not in the corporate language.

Build versus buy, and when buying is the right call

Buy if you have one plant, one or two control rooms, a stable crew, and you want structured handover without a project. Buy if your requirement came out of an audit finding and you need something running this quarter. Buy if you are already deep into one vendor's operations stack and the logbook sits naturally inside it.

Build when two or more of these are true. You run several plants whose handover structures genuinely differ and a single template would degrade all of them. You want the logbook joined to production accounting, deviations and shift performance in one operations platform you own. Your integration requirements to historian, maintenance and permit systems are the bulk of the work regardless. Every field operator needs a device and per user licensing makes that unaffordable. Or you operate under electronic records regulation and need the signature and audit model designed around your own quality system.

The tipping point is whether handover is the whole requirement or the front door to one. If it is the whole requirement, buy. If your operations director is describing a system that will eventually hold rounds, deviations, production numbers and shift performance, start with handover and build it, because you will not be able to add the rest to somebody else's product.

How to choose a developer for shift handover and logbook software

Ask them to explain the difference between a log entry and an open item before you discuss anything else. A developer who has built one of these will describe two related but distinct objects, one chronological and immutable, one stateful with an owner and an age. A developer who describes a searchable diary has built a notes application and your controller will still be left in manual.

Ask what happens to a rounds entry made in a tank farm with no signal, and to a handover attempted during a plant upset when nobody has twelve minutes. Offline storage and the ability to complete a partial handover with the outstanding sections flagged are both real requirements, not edge cases.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. A logbook that becomes evidence in an incident investigation is not a system to hold hostage to a licence renewal.