.png)
A 2026 study by the World Maritime University, commissioned by Lloyd's Register Foundation, surveyed 532 seafarers across 64 countries and interviewed 110 stakeholders. One finding should change how every fleet plans a software rollout: just thirteen percent of seafarers say shore-based training consistently matches the systems they encounter onboard. Read that as a base rate. If your adoption plan rests on classroom sessions ashore, the research says you are attempting something that works roughly one time in eight. The study's broader conclusion is that technology adoption is moving faster than training standards, instructor capability and certification frameworks — that innovation is outpacing preparedness — and that if the industry does not invest in people alongside technology it risks creating new safety problems rather than solving existing ones. The most useful sentence in the whole report is this: technology only improves safety when people understand how systems work, trust their outputs, and know when not to rely on them. That last clause is one almost no vendor will say to you, and it belongs in your training material. This page is about what to do instead of relying on training, and where training genuinely helps. Start a free trial of Marine Inspection and test the design before you plan the sessions.
13%
of seafarers say shore-based training consistently matches the systems they encounter onboard
The study
Digital skills in maritime education and training, written by the World Maritime University and commissioned by Lloyd's Register Foundation through the Global Maritime Trends programme. Based on a survey of 532 seafarers across 64 countries and interviews with 110 stakeholders, published in 2026.
What it means for your rollout
Training delivered ashore is the weakest lever you have, not the strongest. It is worth doing and it is not what will determine whether crews use the system. The interventions that actually move adoption are design decisions — how few actions a task takes, where the prompt sits in the working day, and who aboard can answer a question at three in the morning without waiting for an office to open.
Three Levers, Ranked by What They Actually Do
Being honest about the ranking is more useful than treating all three as equally important, because effort tends to go into the weakest one. Book a Marine Inspection demo and spend the evaluation on the first lever rather than on the third.
Strongest
Reduce the number of actions
Research on getting seafarers to adopt new behaviours is consistent: where the behaviour is made simple and accessible, people are more likely to do it, and training should focus on reducing complexity so that people feel capable of performing the task. A job closure that takes three taps needs almost no training. One that takes fourteen fields needs training, reinforcement, chasing, and will still be worked around.
This is a configuration decision, made in week two, by you
Strong
Put the prompt inside the work
The same research describes triggers — prompts that remind people to act, integrated into the ship's daily operations so that the behaviour becomes a routine part of life onboard rather than something remembered separately. A scheduled round that appears on the phone at the time the round happens is a trigger. A reminder in an email nobody reads ashore is not.
This is scheduling and notification design, not instruction
Weakest
Teach people how it works
Necessary, worth doing properly, and the least predictive of the three. Thirteen percent of seafarers report shore-based training matching the systems they meet aboard, and the workforce is described as not keeping pace with the rate of digital adoption — with barriers including limited funding and a shortage of digitally skilled instructors.
Do it, but do not let it carry the plan
The practical implication is uncomfortable for a rollout budget. If a substantial share of your adoption spend is going into training delivery and none of it into simplifying the workflow, you are funding the weakest lever and leaving the strongest one to whoever configured the checklists in a hurry. Watch a real round before writing a single training slide, and cut every item that does not change a decision.
What Training Should Actually Cover
Given that training is not the main lever, it should be spent on the things design cannot solve — and there are four of them. Sign up for Marine Inspection and build the material around these rather than around a feature tour.
01
Why, in terms that matter to that rank
A second engineer does not care about fleet visibility. They care that the next person to open that pump will know what was found last time, and that a job they completed properly will be defensible if somebody questions it in six months. Frame the purpose in the listener's own interest, per rank, or it lands as a shore-side requirement.
02
What good looks like, not what the buttons do
A feature tour teaches navigation. What people need is the standard: a measured value rather than a tick, condition found described in a sentence, a photograph taken at the item rather than reconstructed, a deferral recorded honestly with its reason. Show three good records and three poor ones and let people see the difference.
03
What happens when it does not work
No connectivity, a sync that has not completed, a device that fails mid-round, a job that is not in the list when it should be. These are the moments people abandon a system, and five minutes covering them prevents more abandonment than an hour of feature walkthrough.
04
When not to rely on it
The study's own formulation is that technology improves safety when people understand how systems work, trust their outputs, and know when not to rely on them. A counter that disagrees with the machine, a due date that looks wrong, an interval that does not match the maker's manual — the system is a tool and the engineer's judgement outranks it. Saying so explicitly builds more trust than claiming the system is always right.
Watch one round before you write one slide
Take a phone, hand it to a second engineer at the end of a watch, and watch them close a real job with a measured value and a photograph. Every difficulty you see in that ten minutes is a configuration problem you can fix once, for the whole fleet, before anybody is trained into working around it. Every difficulty you do not see becomes a training topic, then a reinforcement topic, then a reason the data is thin.
The Onboard Champion, and Why the Model Already Exists
Maritime has an established precedent for this that most software rollouts overlook, and borrowing it is more effective than inventing a super-user programme from scratch. Schedule a walkthrough and identify the champion before the pilot rather than after it.
The precedent
Shipping companies are increasingly appointing onboard mental health champions — crew members trained to hold open conversations and reduce stigma, with webinars and ongoing support from shore giving them practical tools. The pattern is proven in maritime: a named crew member, trained slightly deeper, backed by a shore relationship, addressing something the whole crew has to engage with.
Who to pick
Not the most senior and not the most enthusiastic. The person others already ask when something technical does not work — frequently a second or third engineer, occasionally an electro-technical officer. Influence aboard is informal and everybody on the ship knows who has it; ask the master rather than guessing from the crew list.
What they need
Slightly deeper training than everyone else, a direct line to somebody who can actually change something rather than to a ticket queue, and visible recognition that the role exists. The last one matters more than it sounds — an unofficial helper burns out; a named one with a route to the office does not.
What they are for
Answering the question at three in the morning that would otherwise wait until an office opens in another time zone. That single function does more for adoption than any support contract, because the alternative to a quick answer is not a slow answer — it is the person going back to paper and never returning.
Rotation-Proofing: The Constraint Nobody Designs For
Every crew you train leaves. This is the structural fact that separates maritime software adoption from every other industry, and planning for it is straightforward once it is stated. Start a free trial and design for the crew who arrive after go-live rather than the ones present for it.
The arithmetic
On a typical rotation pattern, the people trained at go-live are largely gone within months, and the fleet turns over its trained population several times a year. Any adoption that depends on a training event decays on that schedule. Anything embedded in the interface, the workflow and the handover survives it.
Where the training actually happens
In the handover, by the outgoing crew, in the first days aboard. That makes the quality of what the outgoing crew can demonstrate a real deliverable rather than an afterthought — and it means going live at a crew change, which feels like a clean boundary, hands the vessel to people who have never seen the system.
What survives a rotation
An interface a competent engineer can work out unaided. Short in-app guidance available at the moment of use rather than in a manual ashore. Job cards written well enough to be followed by somebody who has not done that task before. A named champion, replaced deliberately when the incumbent rotates off.
What does not
Classroom sessions, one-off webinars, a PDF on a shared drive, and anything that relies on remembering a conversation. Also, and less obviously, undocumented local conventions — the way this vessel decided to use the priority field, which the next crew will not know and will therefore use differently.
Emerging practice in seafarer training points the same way. Bite-sized, mobile-first modules are described as becoming standard, with providers using analytics to identify gaps and push short targeted modules that seafarers can complete on a phone during rest periods — supporting continuous upskilling between voyages rather than cramming everything into a port call. That model suits a rotating workforce for the same reason a training day does not.
Every rotation
The crew who go live are not the crew who will be using it in six months. Design for the engineer who joins in month four, has never seen the system, and needs to close a job at two in the morning without asking anybody.
The Plan, by Role
Different ranks need different things, in different amounts, at different moments. A single session for everybody wastes most people's time and undertrains the ones who matter. Book a walkthrough and build the schedule from this rather than from a template.
Table 1: Training by Role
| Role | What they need | How long | The thing that actually convinces them |
|---|---|---|---|
| Master | Rounds, findings, signing off, and what shore can see | Under an hour, on the bridge | A signed round produced before leaving the deck |
| Chief engineer | Job closure standard, deferrals, retrieving unit history, oversight of the department | Ninety minutes, in the engine control room | Retrieving the last overhaul on a unit while standing next to it |
| Second engineer | Daily job closure, measured values, raising defects, allocating work | Forty-five minutes, then a real watch | That it is faster than the paper it replaces |
| Third and fourth engineers | Closing jobs, reading job cards, recording what was found | Thirty minutes, at the machinery | A job card that tells them what to expect before they open something |
| Electro-technical officer | Their own systems, plus frequently the informal champion role | Ninety minutes, and deeper if they are the champion | That their work is capturable at all, which it often was not before |
| Deck officers | Rounds, safety equipment, drills, defect raising | Thirty minutes, walking a round | Photographs attaching to items instead of a camera roll |
| Ratings | Reporting a finding, and nothing else | Ten minutes, on their own phone | That reporting takes seconds and something visibly happens afterwards |
| The champion | Everything above, plus configuration awareness and a shore contact | Half a day, plus a standing relationship | Being able to fix something for a colleague rather than escalate it |
| Superintendent | Fleet view, exception reporting, and what the vessel actually sees | An hour, driving it themselves | Answering a question about a vessel without emailing the ship |
Measure Adoption, Not Attendance
Training records tell you who sat through a session. They say nothing about whether the system is being used, and the two diverge quickly. Start a free trial and watch these instead.
Table 2: Adoption Measures That Predict Survival
| Measure | What it tells you | Healthy looks like | What a bad reading means |
|---|---|---|---|
| Distinct users per week | Whether capture reaches the people doing the work | Entries from across the department, not one officer | Access was scoped too narrowly, or it is too slow to bother with |
| Entries per user | Whether use is habitual or occasional | Spread across the week rather than clustered | Batch entry at a desk, which means the record is reconstructed |
| Time of entry | Whether records are made at the work or afterwards | Timestamps matching watch patterns and round times | Everything logged at 1600, which is the paper problem digitised |
| Measured values present | Whether the standard is being met or just the form completed | Numbers in numeric fields on jobs that call for them | Ticks only, so the record will not survive a survey |
| Findings raised per vessel | Whether people trust that reporting produces action | A steady rate, and rising after a visible fix | Near zero, which is suppression rather than a clean ship |
| Rate change after rotation | Whether the handover carried the practice across | A small dip that recovers within a fortnight | A drop that does not recover — the handover is not working |
| Champion query volume | Where the interface is failing people | Questions clustering on one or two things you can then fix | No questions at all, which usually means no use |
| Offline entries syncing | Whether capture is genuinely happening at the work | A meaningful share of entries created offline | Everything created online, meaning people wait until they are somewhere convenient |
| What the crew say | The most predictive measure available | Faster than what it replaced, said by a rating or a third engineer | Polite approval from officers and silence from everybody else |
2026 TRAINING REALITY
The thirteen percent finding comes from a 2026 study of digital skills in maritime education and training, written by the World Maritime University and commissioned by Lloyd's Register Foundation, based on 532 seafarers across 64 countries and 110 stakeholder interviews. It describes shore-based training matching shipboard systems generally rather than software rollouts specifically, and the implication drawn here — that training is the weakest of three adoption levers — is our reading of it rather than a finding of the study. The behavioural guidance is drawn from maritime cybersecurity training research and the principle it describes, that simplifying an action and embedding triggers in daily operations increases adoption, is general rather than software-specific. The champion model is borrowed from an established maritime precedent in wellbeing programmes rather than from software practice. This page is published by a software vendor, and the argument that configuration matters more than training applies to our own product as much as to any other — which is why the strongest recommendation on this page is to watch a real round before committing to anything.
Frequently Asked Questions
How much does training actually determine adoption?
Less than most rollout plans assume. A 2026 study by the World Maritime University for Lloyd's Register Foundation, surveying 532 seafarers across 64 countries, found that only thirteen percent say shore-based training consistently matches the systems they encounter onboard — and concluded that technology adoption is moving faster than training standards, instructor capability and certification frameworks. Training is worth doing properly and it is the third of three levers. The first is reducing how many actions a task takes, which is a configuration decision. The second is placing prompts inside the working day so the behaviour becomes routine. Effort spent on those two returns more than the same effort spent on sessions.
What should training actually cover, then?
The four things design cannot solve. Why, framed in terms that matter to that rank — a second engineer cares that the next person opening that pump will know what was found, not about fleet visibility. What good looks like rather than what the buttons do, shown by comparing three strong records against three weak ones. What to do when it does not work — no connectivity, an incomplete sync, a device failing mid-round — because those are the moments people abandon a system. And when not to rely on it, which the study itself frames as part of using technology safely: understanding how systems work, trusting their outputs, and knowing when not to.
Do we need onboard super-users?
Yes, and maritime already has a proven pattern for it. Shipping companies increasingly appoint onboard champions for wellbeing — crew members trained to hold conversations, supported by webinars and a shore relationship — and the structure transfers directly. Pick the person others already ask when something technical fails, which is usually a second or third engineer or an electro-technical officer rather than the most senior person aboard. Give them slightly deeper training, a direct line to somebody who can change something rather than a ticket queue, and visible recognition. Their real function is answering the question at three in the morning that would otherwise wait for an office in another time zone.
How do we stop adoption decaying at each crew change?
By accepting that the handover is where most training actually happens and designing for it. The crew trained at go-live are largely gone within months, so anything dependent on a training event decays on the rotation schedule while anything embedded in the interface and workflow survives. Practically: an interface a competent engineer can work out unaided, short in-app guidance available at the moment of use rather than a manual ashore, job cards good enough to follow without having done the task before, a champion replaced deliberately when the incumbent rotates off, and local conventions documented rather than held in the outgoing crew's memory.
Should we go live at a crew change?
Usually not, despite it feeling like the natural boundary. Going live at a rotation means you trained the crew who are leaving and handed the vessel to people who have never seen the system. Train mid-rotation instead, with a crew who have several weeks left aboard — they learn it, use it under normal conditions, surface the configuration problems while there is time to fix them cheaply, and then hand over to the incoming crew with the system already working as normal practice rather than as an unfamiliar change. That also gives you a real test of whether the handover mechanism works before you repeat it across the fleet.
How do we know whether it is working?
By measuring adoption rather than attendance, since training records tell you who sat through a session and nothing about use. Watch distinct users per week, whether entries spread across the week or cluster in batches, whether timestamps match watch patterns or all land at the same hour, whether measured values are present on jobs that call for them, whether findings are being raised at a steady rate, and whether a rotation causes a dip that recovers or one that does not. The single most predictive measure is not in any dashboard: whether a rating or a third engineer, asked directly, says it is faster than what it replaced.
Adoption is designed, then taught
Fix the Workflow First. Train Second. Rotate-Proof Always.
Cut every action that does not change a decision, before a single session is scheduled. Put the prompt where the work happens rather than in an email ashore. Name a champion the crew already trust and give them a route to somebody who can change something. Train per rank, briefly, at the machinery rather than in a classroom, and cover the four things design cannot solve — including when not to rely on the system. Then measure use rather than attendance, and treat every crew change as the real test, because the people who will decide whether this survives have not joined the ship yet.
