What a Maintenance Management System Does With Your Notes

Why this matters

A facilities department runs on a computerized maintenance management system, a CMMS, which is a database of assets, tickets, hours and codes. Your completion note goes into it and then gets used for things nobody tells you about: deciding whether to repair or replace a unit, changing how often it gets serviced, and justifying next year's budget request to a board. The note you write in ninety seconds at the end of a call becomes evidence in a decision made eighteen months later by someone who never met you. Written one way it makes the case for the work you have been recommending. Written another way it disappears entirely, and so does your recommendation.

This article owns one claim: a CMMS can only act on what its coded fields capture, so a note whose substance lives only in free text is invisible to every automated decision downstream. Sibling articles cover the ticket as an authorization object and the asset tag as a join key; this one is about what happens to the words.

What the system actually stores

Three layers, and they have different afterlives.

Coded fields are the ones with a dropdown or a lookup: asset, failure code, cause code, action code, trade, labor hours, parts, priority, downtime. These are queryable. Every report, every chart, every budget exhibit is built from these and only these.

Structured free text is your completion note, the requester's description, and any comment threads. It is searchable if somebody knows to search it, and it is read at close-out by one person. After that it is read only when someone is investigating a specific asset.

Attachments are photos, meter readings, submittals, reports. They are almost never opened again unless the file name says what they are.

The consequence: a failure you describe beautifully in the note but code as "other" is a failure the system cannot count. Ten of those over three years produce a repair history that says nothing, and an asset with a history that says nothing does not get replaced. It gets repaired again, by you, at your cost of dispatch and their cost of downtime.

The three codes that carry the weight

Most systems ask for some version of failure, cause and action, and most technicians fill them the same way every time because the list is long and the field is mandatory. Learn the three well enough to be accurate, because they are what your note becomes.

• Failure code describes what stopped working, from the asset's point of view: no output, reduced output, leak, noise, will not start, nuisance trip. It answers what the operator experienced.
• Cause code describes why: worn component, contamination, control fault, installation defect, wear-out, external condition, operator action, deferred maintenance. This is the field that decides whether a repair history reads as bad luck or as a pattern.
• Action code describes what you did: replace, repair, adjust, clean, lubricate, calibrate, inspect only, no fault found.

The pairing matters more than any single code. A run of five tickets on one air handler coded failure "reduced output", cause "contamination", action "clean" is a maintenance interval problem and reads as one on any report. The same five tickets coded cause "other", action "repair" read as an unreliable machine, and the department's conclusion will be replacement rather than a cleaning schedule change. You have just moved a large capital request onto a budget where a schedule change would have solved it, or you have watched the replacement get denied and the same five tickets recur.

Where your note is actually read

Four readers, in order of how often they appear.

The verifier reads it once, to close the ticket. They want to know that the reported symptom is gone and that nothing is outstanding. A note that does not clearly say the symptom is resolved sits in Complete instead of Closed, which is a cash event for you.

The planner reads the aggregate, not your note, when setting preventive maintenance intervals. They see codes. If you want an interval changed, the code has to say so.

The budget owner reads a repair history when building a capital request, usually the total hours and ticket count against one asset over three to five years. Your hours only count if they are attached to the asset rather than to a location.

The next technician, possibly yours, possibly the in-house shop's, reads the last two or three notes on the asset before walking to it. This is the only reader who benefits from prose, and it is the reader most worth writing for, because they are the one who can avoid repeating your diagnosis.

What a usable note contains

Six elements, and the whole thing fits in a short paragraph.

• The asset, by its tag, not by its location. Location changes meaning when a unit is swapped.
• The measured condition, with the value and the unit. Not "pressure was low" but the reading, the unit, and what it should have been.
• The finding, stated as a cause you would defend.
• What you did, stated as the action you coded.
• What you did not do, and why. This is the element most often left out and the one that protects you. Deferred work with a reason is a record. Deferred work with no record is, later, work you missed.
• The condition to watch, with the observation that would trigger a return.

Worked example: two notes on the same unit, eighteen months apart

A district's rooftop unit has been serviced by the same shop for four years. In March the technician writes:

Unit not cooling. Found low charge. Added refrigerant, unit operating. Recommend leak search next visit.

Correct, honest, and coded failure "reduced output", cause "other", action "repair". Eighteen months later a different technician on the same unit writes:

RTU-4 (tag 118-RTU-04). Suction pressure read below the target for the ambient and superheat ran high, consistent with undercharge. Third charge addition on this asset in 18 months per history. Located oil residue at the suction service valve. Did not repair: requires unit shutdown, needs an outage window and a purchase order for the valve. Deferred with facility engineer, ticket split to WO-final for the valve replacement. Watch: if suction drops again before the outage, the unit will short-cycle and the compressor is at risk.

Coded failure "reduced output", cause "installation defect", action "inspect only" with a split ticket.

Now the arithmetic the second note enables and the first one does not. The asset history, once the codes are consistent, shows 3 charge additions in 18 months, each averaging 2.2 labor hours plus refrigerant. That is 6.6 labor hours over 18 months, or about 4.4 hours a year on repeated symptom treatment. The valve repair is estimated at 3.5 labor hours plus an outage window. Against a recurring 4.4 hours a year, the repair pays back its labor in under a year on labor alone, before counting the refrigerant, the callbacks or the risk to the compressor.

That comparison is what a budget owner needs and it is not available from the first note, because "cause: other" does not aggregate. The information was in the first note's prose the whole time. It just was not in a field anybody queries.

One thing worth being precise about: the payback figure above compares labor hours to labor hours, which is a fair comparison. It is not a claim about total cost, because the outage window has a cost to the building that no labor figure captures, and the refrigerant is not in either number. Say that out loud when you present it, because a facilities engineer will notice if you do not.

The preventive maintenance ticket, where most of your notes actually go

On a service agreement, corrective tickets are the minority. Most of what you write goes onto scheduled PM tickets, and those get handled worse than corrective ones for a predictable reason: the PM ticket arrives with the work already described, so there is nothing obvious to write. Technicians close them with "completed as scheduled" and the system records that a task happened and nothing else.

That is a wasted field, and it is the field that governs the interval. A planner deciding whether a quarterly PM should move to semi-annual, or the reverse, is looking for one thing: what condition did the technician find at the scheduled visit. "Completed as scheduled" says nothing about condition, so the interval never changes, and it never changes in either direction. The unit that was clean every quarter for three years keeps getting four visits a year it does not need, and the unit that was already fouled at every visit keeps getting two.

So put a condition on every PM close, in one line: what state you found it in relative to what you would expect at that interval. Found clean, found at expected wear, found fouled early, found past due condition. Four values, chosen deliberately, are enough to make an interval argument later. Where the system has a condition or as-found field, use it rather than the note, because the note does not aggregate.

The other thing PM notes do is establish that a deferred item was visible before it failed. A PM note from March recording a bearing noise is what turns a July failure into a documented progression rather than a surprise, and it is what makes the next PM budget defensible.

What changes if the system is thin

Not every institution runs a mature CMMS. Small districts and municipal buildings sometimes run a shared spreadsheet or a work-order email box, and the coding layer does not exist at all. The method inverts: when there are no coded fields, your prose is the only record, so the asset tag and the measured value have to be in the first line of the note where a search will find them, and consistency of wording matters more than it does in a coded system. If you write "RTU-4" once and "rooftop 4" the next time, no search finds the pattern, and there is no dropdown to save you.

The other case that changes the answer is a system where the facility, not the vendor, enters the ticket close. There, your note is transcribed by someone else, and anything ambiguous is lost in transcription. Write shorter, with the codes named explicitly in your own words, so the transcriber has nothing to interpret.

How to check that your notes are landing

Ask the facility for the repair history on one asset you have worked on repeatedly, over the last two or three years. Any CMMS will produce it in a minute and most facilities will share it, because it is their data about their building and they generally want vendors to look at it.

Read it as a stranger would. Can you tell what has been wrong with that asset? Do your tickets share a cause code with each other? Does the total labor attached to the asset match roughly what you know you have spent on it? If your hours are attached to a location or a generic "building services" entry rather than to the asset, that is the finding, and it is worth fixing before the next capital cycle rather than after.

The failure mode to look for specifically is the asset with many tickets and no pattern. That is almost never a genuinely random machine. It is usually a coding habit, and it is usually yours.

References

• See related: The Work Order System and Why the Ticket Is Your Only Record
• See related: Asset Tags and Equipment Lists and Why They Matter to You
• See related: How to Close a Work Order So It Survives an Audit
• Trade-standard practice for failure, cause and action coding in maintenance management systems