Resources · Manufacturers
Troubleshooting with the service engineer in the thread, not around it
The OEM has lived every failure mode the machine has. The plant knows exactly what happened on Tuesday. Today the phone is the only thing connecting the two, and nothing of the call survives it.
Norlan · · 6 min read
Why the service call is expensive
A machine stops. The plant’s own team spends a shift on it, rules out the obvious, and calls the manufacturer. The engineer on the line asks what happened. The technician tells the story from memory, a colleague forwards photos from a chat group, someone reads error codes off a screen. Fifteen minutes in, the engineer has roughly the picture the plant had that morning, and the diagnosis starts.
The asymmetry is the whole problem. The plant has seen this fault three times; the manufacturer has seen it in forty installations and knows about the batch of boards that causes it. The plant has the context — what changed, what was tried, what the machine did at 06:40 — and the manufacturer has the knowledge. Neither side can see the other’s half until it is narrated over a phone.
And when the call ends, it ends. The fix goes into the manufacturer’s ticket, in a system the plant will never read. The plant’s version goes into a work order that records the hours. The next time — in this plant, or in another customer’s — the story is told again.
The alternative is not a portal
The usual answer from the manufacturer’s side is a customer portal: tickets, manuals, a form. It solves the manufacturer’s filing problem and none of the plant’s. The technician standing at the machine is not going to open a portal; they are going to open the group chat where the photos already are.
The usual answer from the plant’s side is to reduce dependence on the manufacturer: film the engineer during commissioning, write the procedures internally, treat the service call as a failure of self-sufficiency. That is a sensible goal for the routine cases and a poor one for the hard ones, which are exactly the ones where fifteen years of installed-base experience is worth more than any video.
Let the engineer into the record
What changes the call is letting the service engineer into the thread where the incident is being solved — on the machine’s own record, for that thread, for as long as it is open. They see the symptoms as they were reported, the photos, the error log, what the plant’s team already ruled out and why. They answer there, with the bulletin attached. When it is closed, their contribution stays in the plant’s record, attributed to them, and their access ends.
Three things have to be true for a plant to accept this, and none of them is technical. The plant decides who is let in and to what — one thread, not the machine, not the site. The plant owns what is on the record afterwards, including what the manufacturer wrote. And nothing about the plant’s operation leaves it without the plant saying so. A group with permissions, revocable, is the difference between collaboration and exposure.
The plant keeps the context. The manufacturer keeps the knowledge. The thread is where they meet, on the plant’s terms.
What the manufacturer gets, beyond the call
For the service organisation, the immediate gain is the first fifteen minutes of every escalation: the engineer arrives with the machine’s context already attached instead of rebuilding it. The second gain is that the fix, once found, can be written up on the model — not on the customer — so it reaches every unit of that model the next time the fault appears, in any plant that has agreed to receive it.
The third gain is the one that takes longest and is worth the most: seeing the installed base as a whole. Which fault repeats across which model, which fix held and which did not, where the manual and the field disagree. This is the input the manufacturer’s technical writers and design engineers never receive in usable form. It is also the part that requires the most care, because it only works if every plant keeps ownership of its own data, consents to what is aggregated, and can see the provenance of anything that reaches it.
Start with one product family
None of this needs the whole catalogue or the whole customer list. One model range, one service team, a handful of plants that already call often. Measure the time from first contact to a diagnosis, the escalations resolved without a site visit, and how often an earlier fix was reused instead of found again. Expansion is a decision made afterwards, on those numbers.
Where Norlan is on this
The shared thread with an external role, admitted per thread and revocable, and guides attached to the model are in the product. The aggregated view across a manufacturer’s installed base is product direction, and the page for manufacturerssays so next to each piece. The separation of data — each plant’s record its own, nothing pooled without consent — is the precondition, not a feature added later.
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.