Skip to content

For OEMs and their technical service teams

Every support call teaches your installed base something. Today it teaches one plant.

Your OEM technical service team answers the same questions across hundreds of installations, and most of what they learn stays in the work order or the ticket that closed. Norlan gives them the machine's own record — and gives the plant a way to bring you in without starting from zero.

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.

The asymmetry

The plant has seen this fault a handful of times. You have lived every failure mode this machine has.

That gap is why support calls exist, and why they are expensive: the knowledge is on your side, the context is on theirs, and the phone is the only thing connecting them.

The plant

Runs the machine

Units of this machine2
Times they have seen this fault3
Technicians who know it well2

Their view of this machine ends at their own gate.

You

Built the machine

Units in the fieldhundreds
Years building this machine15
Times your team has seen this faultmany

Every failure mode, every fix, every misuse — already seen somewhere.

Three situations

What a service director recognises.

The support call that leaves nothing behind

The problem

Your engineer solves it in a group chat, on a video call, or on site. The plant is running again. What was found, what was ruled out and what finally worked live in a chat on a phone that will be replaced next year — and in the engineer's head.

How Norlan solves it

The plant lets your engineer into the machine's thread. They see the symptoms, the photos and what the plant already tried, and they answer there. The fix stays on the unit's record, attributed to your team, and your engineer sees that thread and nothing else.

The same fault in five customers, solved five times

The problem

A batch of boards, a firmware version, a format change that always ends the same way. Five plants, five service calls, five engineers rediscovering the K4 relay. The knowledge exists; it is spread across five tickets in a system the plant will never read.

How Norlan solves it

A guide hangs off the model, not the customer. Written once — from the thread where it was solved, reviewed by your team — it reaches every unit of that model, in every plant that runs Norlan, the next time the fault appears. With what each plant agreed to share, and nothing more.

The manual that stopped telling the truth

The problem

After a field modification, a retrofit or a new part supplier, the manual says one thing and the machine needs another. The service bulletin went out by email eighteen months ago. In the plant, the binder is still rev 4.

How Norlan solves it

Bulletins and revisions attach to the model, next to the manual, and the assistant cites the one that applies. Where the field disagrees with the documentation, it shows up as a pattern across the installed base, not as five unrelated complaints.

How it works for a manufacturer

The model is the installed base.

Norlan is the same product the plant runs. The difference is where you stand: on the model, looking at every unit of it, with the boundaries each plant sets.

  • The model is the axis

    A guide on the model reaches every unit in every customer. Where a plant has modified a unit, the exception is pinned to that unit, and only there.

  • The shared thread, with permissions

    The plant decides what your engineer sees: one thread, for as long as it is open. Your engineer's contribution stays in the plant's record, attributed to you. A group with explicit permissions, not an informal chat.

  • Intelligence that rolls up

    What fails on model X across the whole installed base, which fix held and which did not, where the manual and the field disagree — with each plant owning its data, and consent, provenance and anonymisation agreed before anything flows.

One guide, eight machines

Model

Metal detector MD-3000

Guide · Assign the product name

S1-PK-L1-0051

Berlin

S1-PK-L2-0018

Berlin

S2-PK-L4-0092

Munich

S2-PK-L7-0104

Munich

+ 4 more units

Metal detector MD-3000

Installed base · 412 units · 37 customers

Manufacturer view

Recurring across the base · this quarter

  • False rejects after a format change23 threads · 9 plants
    Guide v2 on the model
  • Intermittent reject fault after restart11 threads · 6 plants
    SB-112 attached
  • Belt tension drift7 threads · 4 plants
    No guide yet

Each plant sees its own units and threads. The manufacturer sees the pattern, with what each plant agreed to share.

A different category, on purpose

Both sides work on the same machine's record, with the boundaries you set.

Connected-worker platforms are sold to the plant and see the manufacturer as someone to film during commissioning. Norlan is built so the plant and the manufacturer work on the same machine's record — the plant owning its data, the manufacturer owning the model's knowledge, and each seeing what the other agreed to show.

The argument in full, for a service director: The service engineer in the thread, not around it.

Data separation, before anything else

  • Each customer's data is isolated; one customer's content never influences another's answers
  • What a manufacturer can see is granted per thread, by the plant, and can be revoked
  • Anything aggregated across customers requires explicit consent and keeps its provenance
  • Operational data is not used to train external models

Questions manufacturers ask

Who owns the data?

The plant, always. What happens on a unit belongs to the plant that runs it. What you contribute — a fix, a bulletin, a guide on the model — stays attributed to you and reaches the plants that run that model. Nothing crosses from one customer to another without that customer's explicit consent.

Can a plant refuse to share?

Yes, thread by thread and altogether. A plant can bring you into one thread and nothing else, or run Norlan without you in it at all. The aggregation across the installed base that we describe as product direction is opt-in per plant, with provenance kept and anonymisation available.

Does this replace our field-service software?

No. Your FSM keeps the tickets, the scheduling and the contracts. Norlan keeps the knowledge: what was found on the machine, what worked, and where else it applies. An escalation can start in your FSM and be solved in the thread; the ticket does not move.

How is our operational data handled?

Data is isolated per customer and is not used to train external models. The plant decides what may be read in the first place: filters block documents before anything is indexed.

Book a demo

A 30-minute conversation about one product family, not a canned demo.

We start with your service operation — which failure your engineers solve most often from scratch, how knowledge moves between them today, what the plants you serve would let you see — and then show exactly how Norlan would sit on that model.

What we usually cover

  • Which failure repeats across your installed base, and how many times it was solved from scratch
  • How your engineers hand over knowledge today — tickets, chats, heads
  • What the plant would let you see, and what it would not
  • One product family and one service team to start with, and what a pilot would measure

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.