One memory for the whole plant. No third system to feed.
Not a CMMS. Not a chatbot over the manuals. Not a connected-worker platform. Not a knowledge base somebody has to fill. Norlan sits above the systems the plant already runs and holds the part they were never designed for: the troubleshooting reasoning that solved the problem, attached to the machine it belongs to.
85 Nm, in a cross pattern. After the gearbox was swapped on this unit the original spec no longer applies — use the M12 bolts.
Service bulletin · p. 8Intervention · SepGuide · Coupling swap
And for the old bolts?
That spec isn't in this machine's record — I won't guess. The manual covers the current M12 configuration only.
What it connects
Everything about a machine, and none of it in the machine.
The knowledge that keeps a line running already exists. It is just spread across places that do not talk to each other.
Documented knowledge
Manuals
Drawings and schematics
SOPs
Spare parts
CMMS and ERP
Work orders
Interventions
Incidents
Unstructured
Emails
WhatsApp and calls
What the technician knows
The manufacturer
Service know-how
Bulletins
Their engineer
One record, on the machine itself
And on its model, so every identical unit inherits it
Nothing is migrated. Each of those places stays where it is; what changes is that the machine now has a record that reaches all of them.
The Norlan difference
Most tools help find an answer. Norlan is where the answer gets created.
Knowledge is a by-product of the work
Nobody sits down to document. Symptoms, checks, decisions and outcomes are kept from the thread where the incident was solved.
It knows where a fix applies
A resolution is attached to a component, a unit, a model — not to “a similar case”. That is what lets every other unit of the model inherit it.
Evidence and a person, not a confident machine
Answers cite the document page, the intervention or the guide. Procedures are published because someone reviewed them.
Nothing to migrate
Assets and locations imported from the ERP or CMMS, documents loaded as they are. The systems of record stay exactly where they are.
It works on day one, without content
Load the manuals as they are and import the installed base. The assistant answers from the first afternoon and says where it is thin.
How it compounds
The eighth time this fails, nobody works it out again.
The same failure, three times, with nobody writing a document in between. What changes is how much of it was already in the machine's record.
First time
Four hours
Nobody has seen it. The thread is the work: the photos, the manual, everything that was tried.
Second time
Forty minutes
Another line, another shift. Norlan answers with the thread that solved it in March.
Eighth time
Twelve minutes
It is a guide on the model by now. The new technician runs it without asking anyone.
The loop behind it
It gets fixed
A thread opens on the machine because something failed or a round was due. Nobody is documenting: they are working.
It stays
Closing writes the problem, the cause and what held. The field note comes out of that, not out of a second task.
It spreads
It attaches to the machine and to its model, so every identical unit knows it too.
It answers
The next question on the night shift is answered from it, with the source. If it repeats, it becomes a guide.
And the next one starts here, not from scratch.
Outcome
Recover faster from breakdowns
Every hour of unplanned downtime is mostly diagnosis. MTTR starts when the technician starts looking, not when they arrive.
Unplanned downtime and slow diagnosis
The problem
A fault fires at 03:00 on the metal detector in Berlin. The technician on shift has not seen it. The one who has is asleep, on leave, or left in March. The binder is two revisions old. Forty minutes go to finding out what was already tried once, in March, on this same unit.
How Norlan solves it
The technician asks the machine. Norlan answers from that unit's own record — the March intervention, the approved guide, the manual page — with every source cited, and says plainly when the record holds nothing. No one gets phoned, and the diagnosis starts where the last one ended.
What a pilot measures: Time to understand an open incident · interruptions to a senior technician avoided
The shift handover that explains nothing
The problem
An incident is still open at shift change. What arrives is one line in a work order. What is missing is what was already checked and ruled out — belt tension, head calibration — so the next person checks it again.
How Norlan solves it
The thread is the handover. Symptoms, photos, what was ruled out and why are already on the machine when the next shift opens it. Closing means saying what it was: a cause and a fix, not just the hours.
What a pilot measures: Repeated checks on a failure the plant has already seen
The same fault, already solved, and nobody knew
The problem
The incident opens in Munich. Three weeks ago the same failure was closed in Berlin — or on the same model in a third plant. Nobody on this shift was there, and nobody asks, because nobody knows there is something to ask about.
How Norlan solves it
At open, before anyone answers, Norlan shows what the record already holds: the earlier thread on this unit or on any unit of this model, how it was closed, and the guide if there is one. It searches full threads and the whole model, not a ticket title.
Similar · before anyone answers
Solved on S1-PK-L1-0051 · 3 weeks ago · Berlin
Belt slack after the format change; re-tensioned, K4 checked. Verified on machine.
What a pilot measures: Similar-issue suggestions shown, and how many the technician opened
Outcome
Keep the knowledge in the plant
Decades of experience walking out the door
The problem
One person holds the exceptions for half the plant — the manifold that needs re-torquing after the first hour, the reset switch under relay K4 that is not in any manual. It does not take a retirement to lose it: a long sick leave, or a change of maintenance contractor, is enough.
How Norlan solves it
The exceptions get captured where they surface: in the thread, as the work happens, by the person who knows them, without freeing anyone for two months to record videos. A field note becomes part of the guide, reviewed and versioned, and Norlan shows where the plant's knowledge is one person deep, so the plant can act before the absence.
What a pilot measures: Assets or models that depend on a single expert, before and after
New technicians who take months to get up to speed
The problem
A new hire joins and phones the same senior for every failure they have not seen. The senior fixes it and moves on; the answer lives in nobody's record, and the next new hire phones again.
How Norlan solves it
They learn the line from the map the plant already keeps: what each machine does, what is critical and where to look first when it misbehaves. The guides they need run step by step at the machine, written by the people who fixed it.
What a pilot measures: Time to find the relevant manual passage or prior intervention
Outcome
The same standard on every line and site
Every site, its own version of the same procedure
The problem
The same machine runs in several sites, and each one keeps the procedure written by whoever was there. An audit finds three ways to change the same belt, and nobody can say which one holds.
How Norlan solves it
The approved guide sits on the model, so every unit on every line and site runs the same one. Where a procedure is only true for one unit, after a retrofit or on a different line, it is pinned to that unit and nobody else sees it.
What a pilot measures: Units running the approved guide for their model
Procedures that drift out of date
The problem
The manual says one torque. The machine, after a gearbox swap, needs another. The correction is in a group chat from March and in one technician's head; the procedure on the floor is rev 4 and the approved one is rev 6.
How Norlan solves it
Procedures are written by the people who use them and corrected by the people who find the exception. A field note from the floor becomes a new version, pending review; the old one is superseded, not deleted. A person publishes, never the model alone.
What a pilot measures: Knowledge promoted from an intervention into an approved guide
Outcome
Work with the manufacturer, not around them
The service call that starts from zero
The problem
The manufacturer's engineer arrives, or dials in, and asks what happened. Everything is in an informal chat and in the technician's head; the CMMS has the hours. The first part of every call goes to rebuilding the story.
How Norlan solves it
The plant lets the engineer into the thread. They see the symptoms, the photos and what was ruled out, on the unit's own record. They add the fix; it stays in the plant, attributed to them. They see that thread, and nothing else.
Intermittent reject fault after restart
Metal detector MD-3000 · Berlin · open
Open
Maintenance · 3Vantor service · L. Nguyen · this thread only
T. Walker · Maintenance
@Vantor already ruled out: product name, calibration, belt. Photos and the error log are above. Fault returns ~20 min after every restart.
L. Nguyen · Vantor service
Check the K4 relay seating — the 2024 batch of this board has a known issue. Service bulletin SB-112 attached, page 3.
SB-112 · attached to the model
The fix stays in the plant's record, attributed to the manufacturer.
What a pilot measures: Time from first contact with the service engineer to a diagnosis
The fix the manufacturer already knows
The problem
The same failure was solved last year in another customer's plant. The manufacturer knows; the plant cannot. So the team spends a shift rediscovering something that already has a service bulletin.
How Norlan solves it
A manufacturer running Norlan on its installed base carries the lesson from the model to every unit, with each plant's data staying its own. What reaches the plant is the guide on the model, not another plant's record.
What a pilot measures: Cases where a model-level guide from the manufacturer was used in a plant
Norlan vs the alternatives
How Norlan compares with the tools on the table.
Compared on what decides whether a plant ends up with a memory: where the knowledge comes from, where it applies, who stands behind it, and what has to exist before any of it is useful. Categories rather than brands, because the products in each move faster than a web page does.
Compared on
The copilot in the CMMS
AI over the documents
The connected-worker platform
Norlan
Where the knowledge comes from
Work orders and manuals already in the system
Documents someone took the time to write
Work instructions the plant wrote and approved
The intervention itself, as it happens — and the manufacturer's manual as it is
When nothing was written down
Nothing to answer with
A gap flagged for someone to fill later
The issue thread is there; someone converts it into a guide later
The thread that solved it is the record; Norlan drafts the guide from it
How far a lesson reaches
That asset's record
Wherever the document is tagged
The plant hierarchy the content was filed under
Component → unit → model → every equivalent machine, in any plant
Who stands behind an answer
The model
The model, over approved sources
An approval workflow on the instruction
A cited source and a named person who approved it
Who it is built for
The planner
Whoever searches
The operator and the trainer
The technician at the machine, and the manufacturer when the plant lets them in
What it needs before it is useful
Work orders
Documents
Weeks of content creation
The manuals the plant already has and one open incident
The fine print we would rather write ourselves
A comparison table written by one side is worth what one would expect.
Where each of them is genuinely better
A CMMS copilot knows the work orders, the planning and the compliance history, and it should. A document assistant is the cheapest way to search a large library. A connected-worker platform standardises how operators work — instructions, checklists, skills, huddles — and does it across an entire enterprise, with a decade of product behind it. None of that is what Norlan is for.
Where the comparison stops being fair
All four of these do AI over manuals, voice input, asset context and procedures. Those are table stakes now and a feature checklist will make everything look the same. The question that separates them is the one in the last row: what has to exist before anyone gets an answer.
No. The CMMS stays where it is and keeps doing what it does — work orders, planning, assets, traceability. Norlan holds the part it was never designed for: the reasoning behind the intervention, attached to the machine it belongs to.
Does Norlan capture what people call tribal knowledge?
That is the knowledge it is built for: the check the manual does not mention, the part that works loose on this model, the order the steps have to follow. It is captured where it is used — in the thread where the failure is solved — and kept on the machine and its model, attributed to the person who found it. Nobody is asked to sit down and document it.
We are already evaluating one of these. Is it either-or?
Usually not. Norlan sits next to a CMMS copilot or a connected-worker platform the same way it sits next to the CMMS, because each answers a different question. The one case where it is either-or is budget, and then the question is which problem is costing the plant more this year.
Do our technicians have to document more than they do today?
Less, in the moment that matters. The thread where the incident is being solved is the record, and a voice note counts as much as typing. Writing up a guide is a deliberate act, but it happens once, by whoever solved it, and the AI does the tidying.
What happens when the AI does not know?
It says so. Every answer is grounded in the machines' actual record — manuals, procedures, approved guides and past activity — and cited to its source. If the record does not contain the answer, Norlan does not invent one.
How disruptive is deployment?
Deliberately not. The installed base is imported from the ERP or CMMS as a tree of locations, the document library goes in as it is, and Norlan proposes which documents belong to which models. It starts on one site and one workflow.
Book a demo
Bring a failure that repeated. Judge every option on that one case.
We start with the operation — which failures repeat, who gets called when something breaks, what the CMMS does not hold — and then show how Norlan would work on it.
What we usually cover
How an incident flows today, from detection to fix
Where the conversation actually happens: the systems, or calls and WhatsApp
What takes longer — the diagnosis, or getting the right people and information together
How much of what a technician knows is written down, and what happens when they are away
Which tools are really in play: CMMS, ERP, mobile, paper
What a pilot would measure, and how
Pick a time that suits the plant. Bring one failure that keeps coming back.
The call is with the people who build the product, with no qualification call first. Norlan is pre-general-availability and shaped with maintenance teams in pharma and food processing.
