When he asked why technicians were not logging issues in the maintenance software the company had bought, the answer was simple:
“It takes longer to log the ticket than to actually fix the leak.”
He had a point.
So the company tried a classic change management tactic. They incentivized adoption. Log a ticket, get lunch. Pizza on Friday. Sandwiches on Tuesday. Whatever it took to get people using the system.
It worked. Sort of.
Within weeks, the planners were buried. Hundreds of work orders came in. Some were important. Many were not. A puddle on the floor. A concern that something might fail. A duplicate of something already logged three times.
The system looked active, but it was not useful. The planners could not plan. Teams could not prioritize. And people started blaming the software.
But the problem was not simply the software. It was the way adoption had been designed.
The company had incentivized activity, not outcomes. So it got activity.
That distinction matters.
Pizza can create short-term usage. It cannot create sustainable adoption. If a system makes frontline work harder, incentives may increase activity while making the underlying planning problem worse.
The technicians in that plant were not being stubborn. They were responding rationally to a workflow that slowed them down. When logging takes longer than fixing, people avoid logging. And when people avoid logging, planners lose the data they need to prioritize work, schedule resources, and prevent repeat failures.
Then management tried to buy trust with lunch.
That is the wrong order.
Trust comes first. Adoption follows.
This is an important lesson for any organization considering AI or a major operational shift.
In many conversations about AI adoption, hesitation is understandable. Maintenance and operations teams want to know whether AI will reduce friction, improve decisions, and support safer work — or whether it will become another layer of monitoring, administration, and complexity.
Those concerns are not irrational. Many frontline teams have lived through software rollouts that promised efficiency but added extra steps to already pressured workdays.
That is why adoption cannot be treated as a training exercise at the end of implementation. It has to be designed into the system from the start.
The starting point is not the org chart. It is the reality of the work.
How does a request move from operations to maintenance?
How does maintenance coordinate with health and safety?
How are spare parts consumed?
Who is qualified to complete specific work?
Where do bottlenecks actually occur?
Which steps create value, and which steps create friction?
You have to map how work really happens before you can improve it.
Then you need a path forward. Not a disconnected pilot that proves a concept in isolation, but a maturity roadmap that can scale. Each stage should improve something measurable: work-order quality, planning reliability, data consistency, equipment uptime, safety visibility, or technician adoption.
Some sites will move faster than others because their starting point is different. That is normal. What matters is that every step builds capability, confidence, and trust.
Adoption should be part of that roadmap from day one.
That means designing for the people doing the work.
Maintenance happens on the floor, not behind a desk. A technician should be able to open a work order on a mobile device, scan a QR code, add a photo, capture a note, and complete the task without fighting the system. The workflow should support the job, not interrupt it.
It also means training and support need to be practical. People should be able to build confidence quickly, in the context of their work, without adoption becoming a separate burden.
And when AI is introduced, it needs to be precise, controlled, and useful.
Embedded-AI and digital workers should support people in the flow of work: surfacing relevant information, reducing repetitive admin, helping teams make more consistent decisions, and preserving knowledge that would otherwise stay in someone’s head.
That is the value of Intelligent Asset Management. It is not technology for its own sake. It is people and AI working together to improve decisions, reduce friction, and build operational resilience.
This matters because industrial organizations are under pressure from several directions at once. Experienced workers are retiring. Skilled labor is hard to find. Assets are aging. Teams are being asked to improve uptime, safety, and consistency without adding complexity.
When experienced people leave, their knowledge can leave with them. That creates risk: slower troubleshooting, less consistent work execution, and greater reliance on a small number of people who know how things really work.
A well-designed EAM system helps capture that knowledge as part of daily work. It turns individual experience into shared operational capability. It gives planners better data. It gives technicians better context. It gives managers clearer visibility into risk, performance, and progress.
But none of that happens if people do not use the system.
And people will not use a system just because leadership wants better data.
They will use it when it helps them do their jobs.
That is the lesson from the lunch story.
The company wanted more work orders. It got them. What it needed was better maintenance planning, clearer prioritization, and a system frontline teams trusted enough to use properly.
Those are different outcomes.
For maintenance and operations leaders, the takeaway is simple: adoption is earned. It is earned by listening to the people closest to the work. It is earned by removing friction instead of adding it. It is earned by building systems that fit operational reality.
If you are thinking about AI, EAM, or any major operational change, start there.
Ask your frontline teams what would actually help.
Map where you are today and where you need to go next.
Design the workflow around better outcomes, not more activity.
Make the system useful enough that adoption becomes part of the work, not a campaign around it.
No pizza party required.
