A technician arrives at a property that has been visited before. The office can find the customer, but the last repair is buried in a note attached to an invoice. There are two similar units at the site, and nobody is certain which one the note describes. The history exists, yet it cannot safely guide the next visit.
Equipment history needs a structure that follows the physical asset through service, replacement and changes of customer contact. It is not enough to add a large notes field to the CRM. The system must distinguish who requested work, where it happened and what was serviced.
Start with the site and the installed asset
A customer account can have several service sites. A site can have several pieces of equipment, and the person arranging access may not be the billing contact. Keep those relationships separate so a contact change does not move equipment to the wrong place.
Give each installed asset an internal identifier. Record available manufacturer, model and serial information, but do not assume a serial number is always present, readable or unique across every source. A site label such as upstairs unit can help a technician locate equipment, while the internal identifier keeps its history stable if that label changes.
Allow incomplete records without hiding what is missing. A first diagnostic visit may establish the model but not the installation date. Unknown is better than an invented date that later drives a maintenance rule. Show which fields are confirmed and which need checking on site.
A visit can concern more than one asset
Attach work observations to the relevant equipment within a visit. A technician may inspect two units, replace a component on one and recommend a follow up on the other. A single visit note cannot reliably carry those different outcomes into future work.
Use structured fields for facts the business needs to retrieve or compare, and free text for context that does not fit a fixed list. The aim is not to force every sentence into a dropdown. It is to make the next technician able to identify the affected asset, reported issue, action taken and unresolved work without reading every attachment.
Keep customer reported symptoms distinct from technician findings. Both are useful, but they carry different authority. A report that a unit stops intermittently should not become a confirmed diagnosis merely because it appears in a field labelled fault.
Replacements should create a new chapter
When equipment is replaced, close its installed period and create a new asset record linked to the replacement event. Do not overwrite the old model and serial fields. Otherwise earlier service visits appear to describe equipment that did not yet exist at the property.
Preserve the relationship between the old and new assets so staff can explain the site history. Record what was removed, what was installed and which visit or approved work order authorised the change. The new equipment can inherit site context without inheriting the old equipment's faults as if they were current.
The same principle applies to moving equipment between locations. Record the move and effective date, then keep earlier visits associated with the location at the time. Historical reports should not change their meaning whenever today's site record is edited.
Photos need context and controlled access
A photograph should identify the asset or visit it supports. Add a short description explaining why it matters: identification plate, completed installation or a condition requiring review. A collection of unnamed uploads forces the office to guess which image is useful.
Set file limits, permitted formats and access rules. Service photos can accidentally include personal belongings or unrelated information. Give staff a way to remove an inappropriate upload through a reviewed process, and avoid publishing attachment links that remain accessible after the user's permission ends.
Do not rely on a photograph as the only source for important searchable facts. If a model identifier matters to future parts selection, capture it as text with a verification state. Keep the photo as supporting evidence, not as a substitute for a usable record.
Show a brief useful history in the field
Before arrival, the technician needs a compact view: asset identity, location notes, recent relevant work, open recommendations and any access constraints they are authorised to see. Give them a route to deeper history without making it the first screen.
Mark the freshness of downloaded data. An offline device may have yesterday's history while the office has added a new customer message. The interface should show that limitation and merge new information when connectivity returns. It must not present an old unresolved recommendation as newly confirmed work.
For edits, preserve authorship and revision history. A supervisor correcting an asset identifier should not silently rewrite a technician's original observation. Link the correction and explain it so later readers can understand why the record changed.
Migrate existing notes with a review boundary
Start by grouping existing records by site and known equipment reference. Avoid automatically merging records solely because their model names match. Two identical units at one property are still two assets, and an incorrect merge can make their service histories contradictory.
Put uncertain matches in a review list with the evidence available. The office can resolve some; others should become a verification task on the next visit. Preserve the source reference so a reviewer can trace how the imported history was assembled.
Test the result with a technician who did not perform the original work. Ask them to identify the equipment, explain the last action and find the outstanding recommendation. If they still need to call the person who wrote the notes, the migration has moved text but has not yet delivered usable history.