Give Maintenance a Problem It Can Find

“Machine acting up.”

That may be an honest description of a frustrating morning. It gives the person responding very little to work with.

Which machine? What did it do? What should it have done? When did the difference appear? Is the equipment stopped, running under an approved condition, or waiting for somebody to decide?

If maintenance has to find the reporter, find the equipment, and reconstruct the event before assessing the problem, the request has passed along confusion with the work. The operator gets irritated because nobody has fixed it. The technician gets irritated because the useful details have disappeared. Both spend time recovering information somebody already had.

A better request starts with a simple discipline: describe what you observed before you prescribe what somebody should replace.

You do not need to become a mechanic to report an equipment problem well. You need to make the condition findable. Leadership needs to give people a practical way to do that without turning the request into homework.

Start with the equipment, then the difference

Equipment names can be surprisingly unreliable. One person calls a station the packer. Another calls it Line Two. A third uses the name of a machine that was removed years ago. That works until a new technician arrives or two similar machines develop problems at the same time.

Use the site’s existing equipment identification. Include the location or station when it helps someone distinguish the asset. If the identification is missing or impossible to read from a safe, normal position, fix that problem through the appropriate process. Do not make employees climb, reach into equipment, or enter restricted areas to satisfy a form.

Then describe the difference between the expected operation and the observed condition. “The label is wrong” leaves a lot of interpretation. “The printed date is missing from the label” gives someone a condition to examine. “The conveyor stopped” is more useful when the report identifies which conveyor and the time it stopped.

Keep the language tied to what happened. A fault message visible on the normal operator display can be recorded exactly. A sound can be described without declaring which bearing caused it. A change in output can be reported without deciding that the motor is failing.

People should be able to say, “I don’t know the cause.” That is useful honesty. Filling the gap with a confident guess can send the response in the wrong direction.

Give the event enough context

The technician needs the conditions surrounding the event, within what the reporter already knows and can safely observe. Was this during startup, a normal run, a scheduled product change, or shutdown? Was the problem continuous or intermittent? Had the approved job or material changed? What time did someone first notice it?

These details narrow the question. They do not establish the cause. A problem appearing after a product change does not prove that the change caused it. Record the sequence and let the investigation test the connection.

Separate things the reporter saw from things someone else reported. “I saw the display message at 9:10” is different from “the previous shift said it happened overnight.” Both may matter, but they carry different evidence. Preserve that distinction instead of blending everything into a story that sounds more certain than it is.

Record any action already taken under an approved procedure by an authorized person, along with the observed result. If nothing was attempted, say so. The request does not need a dramatic account of trying everything. It needs an accurate account of what is known.

Do not recreate a fault, repeatedly reset equipment, remove a guard, open an enclosure, touch a suspect component, or enter a hazardous area to make the request more convincing. Reporting never grants permission to investigate or service equipment. Site procedures, energy-control requirements, competence, and authorization still govern the work.

Urgent hazards and conditions requiring an immediate response go through the site’s established response process. They must not wait while somebody finishes a routine request.

A useful request in practice

Consider a fictional packing area. This example illustrates the information in a request. It is not a troubleshooting procedure or a report of a real incident.

The first request says: “Packer keeps messing up. Probably the sensor. Please fix.”

There may be a sensor involved. There may not. The person responding still does not know which packer, what “messing up” means, or what condition they will find on arrival.

A more useful version reads: “Packing station P-02, east packing area. During the approved run for carton type B, the operator display showed ‘carton not detected’ three times between 9:10 and 9:25. The station is stopped and the supervisor has been notified under the site’s procedure. No cause has been confirmed. No inspection or repair has been attempted. Contact the current packing lead for the observations.”

The revised request identifies the asset, describes an observable condition, gives the time and operating context, and states the current reported status. It leaves diagnosis to the person assigned and authorized to do it. It also gives that person a way to recover details without searching the whole building.

The technician may still need to ask questions. Good reporting does not eliminate diagnosis. It gives diagnosis a useful starting point.

Notice what the request does not do. It does not order a replacement sensor, declare the equipment safe, or approve a restart. The request records the reported condition. The people responsible must verify the equipment’s actual state and follow the applicable process before acting.

Separate consequence from volume

“Urgent” is easy to type. If every request says it, the word stops helping anybody decide.

Describe the consequence. Is the affected operation stopped? Is there a suspected quality problem being handled through the existing containment process? Is an approved temporary arrangement in place? Is another task waiting on the equipment? What information does the person making the priority decision need?

Use the site’s priority definitions and escalation route. The reporter should describe the effect without inventing a risk rating or bargaining for attention. The person assigning priority should own that decision and explain material changes to the people affected.

Do not reward exaggeration. If the only requests that get attention are the ones written in capital letters, you are teaching people how to compete for maintenance rather than how to report problems. Then the quieter work becomes invisible until it becomes louder work.

Maintenance capacity is real. A clear request does not create another technician or make a needed part appear. It helps leaders make the tradeoff with better information. If the work cannot be addressed immediately, somebody still needs to communicate the current disposition and the appropriate next step.

Make the reporting method fit the job

Before adding required fields, watch someone submit a request during an ordinary shift. Where is the equipment identifier? Can the person reach the system they are supposed to use? Does the screen demand information they cannot reasonably know? Is the same description being copied into a message, a spreadsheet, and a maintenance system?

Remove avoidable duplication. Use the existing work-management system when it serves the job. A short, structured description may be enough. A photo may help when site rules permit it and it can be captured safely, but a photo is not a substitute for identifying the condition. Do not collect images of people or confidential material that the task does not need.

Make critical information easy to supply. Make unknown information easy to mark as unknown. A form that forces a guessed cause has designed guessing into the record.

Technology can help with asset lookup, timestamps, or pulling the correct equipment record. It can also create a polished request with the wrong asset and a made-up diagnosis. Check what the tool filled in. Automation should reduce the effort of recording facts, while leaving responsibility for those facts clear.

Do not introduce a second reporting route just because a new tool is available. People need to know which request is the actual work request, where its status lives, and how urgent exceptions are handled. Otherwise the new convenience becomes another place where information can wait unnoticed.

Teach reporting by working through real requests

People learn this faster when the coaching uses their work. Take a recent request with the reporter and the person who received it. Remove identifying or sensitive details when sharing examples beyond the people who need them.

Ask what information let the responder get started. Ask what they had to go find. Then improve that one request together. Keep the useful language the employee already uses. The goal is clear information, not making every operator sound like a technical writer.

Have the employee prepare the next request and explain what each part tells the receiver. Watch for the difference between an observation and a conclusion. Give feedback on the actual work, then revisit it after the person has used the method. Attendance at a short training session does not show that the reporting habit changed.

The receiver has a responsibility too. If every incomplete request comes back with “insufficient detail,” people have learned very little. Ask for the missing fact: which asset, what observed condition, when, or what current status. Repeated omissions may reveal a training gap, a poor interface, or missing equipment identification. Correct the cause you can verify.

Useful maintenance information is a shared operating skill. Operations should help capture what happened. Maintenance should explain which observations matter. Leadership should remove the barriers that keep those two groups from working together.

Use the response to improve the next request

When work is assessed or completed, connect the finding to the original report in the existing record. Preserve the initial observation and distinguish it from the later diagnosis. Do not rewrite history so that the reporter appears to have known the answer all along.

If the reported condition could not be confirmed, record that accurately and state the next step permitted by the site’s process. An intermittent condition is not disproved simply because it was absent when someone arrived. Equally, a report of a problem does not prove a particular component failed.

Look for recurring information gaps. If technicians repeatedly lose time locating assets, improve identification. If operating context is usually missing, coach that field. If requests are clear but wait without disposition, work on priority and capacity. Better wording cannot repair every part of work management, and it should not become a convenient reason to blame the requester.

Start with one equipment area this week. Read a handful of recent requests with the people who sent and received them. Choose the most common missing piece, make it easier to supply, and check the next requests for that specific improvement. Use the system you already have.

Give maintenance a problem it can find. Then give the people doing the work the support to resolve it.