Assets as a data model
Every asset, device and component carries its own file with master data, location, installed parts and service history.
Blueprint 03
Technical Service Intelligence
The asset file in the technician's hand, network or not
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.
Part of
Technical OperationsStarting point
The problem.
A service technician stands in front of a machine and needs details that sit in the manual, the service history and the technical documentation. Those documents are in a folder in the van, in the scheduler's mailbox, or on a drive that has no connection on site. What actually happens during the visit is transferred into a form later, from memory.
Before · After
The same process, twice.
On the left, the process as it typically runs today. On the right, the same process once an application takes over the repetitive steps.
Today
How the process runs if nobody changes anything.
- 01Job originates in specialist softwareSystem
- 02Job details passed by phoneHuman
- 03Search folders for manualsHuman
- 04Ask the office for historyHuman
- 05Work on site without documentationHuman
- 06Collect notes and photosHuman
- 07Type up the report laterHuman
- 08Transfer feedback into specialist softwareHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Job appears in the appSystem
- 02Asset file available offlineSystem
- 03Work through the check stepsHuman
- 04Capture photos and voice inputHuman
- 05Draft report generated automaticallySystem
- 06Technician approves the reportHuman
- 07Feedback returns to connected systemsSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Interactive
The process, station by station.
The walkthrough stops at the point where a person decides. It continues only once you approve.
Flow
Step 1 of 7
- Jobrunning
- Asset filewaiting
- Offline packagewaiting
- Check sequencewaiting
- Capturewaiting
- Approvalwaiting
- Return pathwaiting
The job appears in the technician's application with asset, location and reason before the drive out begins.
The visualisation runs in your browser along a fixed sequence — nothing is uploaded, nothing is sent and no language model is called.
- The job appears in the technician's application with asset, location and reason before the drive out begins.
- The asset carries its master data, installed components, service history and technical documentation in one place.
- Before departure the device downloads the file together with its documents, so the application stays complete without a connection.
- On site a technical sequence walks through the check steps and asks for the evidence that belongs to each one.
- Photos, readings and spoken notes attach directly to the step they belong to, instead of ending up in a gallery.
- The entries produce a draft service report that only counts once the technician reviews and approves it.
- After approval the report, the evidence and the status change go to the connected systems; without a connection the case waits in a queue.
Features
What the system would need to do.
Every line is a commitment about future work — not a description of something that already exists.
Documents at the asset
Manuals, wiring diagrams and inspection instructions hang on the asset instead of sitting in a folder that is not on site.
Search with source reference
A question in your own words leads to the candidate passages in the documentation, each citing document and page.
Offline operation with sync
The asset file, inspection steps, photos and the draft report are held on the device and work without a connection. Searching the documentation and syncing with the ERP need a network — both are clearly marked as such rather than silently failing. Changes are reconciled once the device is back on the network; conflicts are shown rather than silently overwritten.
Check steps with required fields
A technical sequence walks through the steps in a fixed order and can only be closed once the required readings, confirmations and evidence are present.
Photo documentation with context
Images belong to a step, an asset and a job and are stored with their timestamp, not in the gallery of a private phone.
Voice input for service reports
The technician speaks the findings; together with the time on site and the parts used, that produces a draft service report which is corrected before approval. The same report later carries the invoice and the stock movement.
Integration
What a system like this typically connects to.
Categories rather than vendor names — which product you run is decided by the system landscape you already have.
ERP and inventory management
Maintenance and specialist software
Document management (DMS)
Spare parts and stock systems
Identity and access management
Microsoft 365 for calendar and mailbox
Architecture
How this would be built.
One example structure in layers. Not the only one possible — but one we can justify.
Mobile layer
- Local database on the device
- Synchronisation with conflict rules
- Media buffer for photos and audio
- Encrypted storage on the device
Domain layer
- Asset, job and component model
- Rule set for check steps and required fields
- Role and permission model
- Record of every status change
Document and search layer
- Text extraction from technical PDF documents
- Segmentation with page and section reference
- Full-text and vector search combined
- Answer with a pointer to the source passage
Integration layer
- One adapter per target system instead of direct coupling
- Queue for outgoing feedback
- Retry when a system is unreachable
Metrics
How success would be measured.
These are the figures that would be measured during a project. Deliberately no values are shown — there is no measurement they could come from.
Share of visits with complete documentation
would be taken from the reports that close without anything being requested afterwards
Time between end of visit and approved report
would be calculated from the timestamps of the two events
Number of queries back to the office during a visit
would be counted through the queries raised inside the application
Share of visits completed without a connection
would be derived from the connection status during processing
Usefulness of the document search
would be measured by how often the first passage shown is the one used
Expansion
Start small, then grow.
A project of this kind does not begin with the full build. It begins with the part that carries its weight soonest.
Asset file and offline access
First come the asset model, the asset file and the mobile application with offline operation. That would give the technician master data, history and documents at the asset, even without a connection.
Check sequences and reports
Next come the technical sequences with check steps and required fields, the photo documentation, the voice input and the approval by the technician.
Search and return path
Later come search across the whole technical documentation with a pointer to the source passage, and the return path into ERP, maintenance software and document management.
Do you recognise your own process?
If you have a service process in mind that could look like this, we can walk through it step by step in a first conversation.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.