Service Feedback for Shop-Floor Improvements

Why tickets do not reduce breakdowns

On many production floors, service tickets are collected carefully, yet the number of stoppages barely changes. Usually the problem is not the number of records, but their quality. A ticket helps get the machine back up quickly, but often adds very little to the review of repeat issues.

Most often, the form holds just one short line: "the machine stopped," "axis error," "tool was not picked up." That is enough for service to come and clear the alarm. It is not enough for the shop floor. From such a note, you cannot tell what happened before the stop, on which part it occurred, after which operation the failure began, or in which shift it keeps coming back.

The value appears only when the ticket has context. If the operator did not note that a long uninterrupted run came before the failure, that the tool changed, that vibration increased, or that the machine had already shown a similar signal, the most useful part of the story is lost. The log fills up with dozens of similar records, but none of them explains the cause.

There is a second problem too. Service fixes the fault, and the shop keeps working the old way. For example, after replacing a sensor, nobody changes the cleaning sequence, the chuck check interval, or the startup order after the night shift. The same unit gets the same load again, and the new failure looks like a separate breakdown, even though the scenario is the same.

On CNC machines, this happens all the time: service removes the symptom, but the conditions that caused it remain. The ticket is closed, the repair is counted, but the process is no more reliable.

Another trap is tied to record keeping. Today a cable was replaced, and two weeks later the signal disappeared again. The new ticket is often opened as a separate case, because formally a different part of the chain failed. That is how repeats get lost, and with them the chance to see the pattern.

Even good service cannot solve this on its own. On EAST CNC machine shops, this works just like everywhere else: production observations need to be added to the repair record. What the operator did, what changed in the working mode, what happened right after the machine returned to the shift - without that, the ticket is too poor for analysis.

When that data is missing, each failure lives on its own. And from separate cases, it is hard to build a clear improvement plan.

What to take from each ticket

One ticket rarely shows the cause. Ten tickets may already show a repeat, but only if the records can be compared with each other. For that, they need a few precise details, not general words.

First, record the stop time and shift number. The difference between 10:15 and 18:40 can be more than a small detail - it can be a clue. If failures happen after a long continuous run, the cause may be overheating. If the failure repeats in one shift, check not only the machine, but also the startup order, cleaning, tool changes, and the habits of a specific crew.

Next, you need not just the fact that the machine stopped, but the unit and the operation where it happened. The same CNC lathe can behave differently during roughing, when changing tools, and while measuring the part. If failures are tied to one operation each time, the search area gets much smaller right away. You no longer need to check the whole machine.

It is also better to keep the error text without paraphrasing it. It helps to add a photo of the screen and briefly note clear signs: noise, vibration, smell, oil traces, overheating, unstable coolant flow. An hour later these details are forgotten, and later they often explain the repeat.

It is just as important to write down what the operator did before calling service. Did they restart the machine, reset the alarm, change the tool, open the guard, jog an axis manually, or adjust the workpiece? These actions change the picture. Sometimes service looks for a fault in one place, while the failure actually began after a simple step that nobody recorded.

And finally, the ticket should make it clear what service actually did. Not "diagnosis completed," but "checked the sensor," "tightened the connector," "replaced the cable," "adjusted the pressure," "corrected the parameter," "ran a test cycle on such-and-such part." If the defect disappeared only after adjustment, that matters too. Otherwise, a month later the shop will pay for the same visit again.

When all tickets follow the same form and have no gaps, they become useful for the work. Then you can see which failures are tied to the shift, which to the operation, and which to the same unit. On that basis, you can build a proper plan: what to check on the floor, what to change in the standard work, and where a repeat machine inspection is needed.

How to see the cause, not the symptom

Noise, overheating, and vibration are usually the first things that make it into a ticket. That is normal: they are easier to notice. But on their own, they explain almost nothing. If the team only fixes the visible effect, the failure returns a few shifts later.

It is much more useful to look at the last 10–15 minutes before the stop. What changed in that moment? Did the operator start a new program, change the tool, load a different part, adjust the feed, switch the machine to another mode, or work after a voltage drop? The cause is often not hidden in the alarm itself, but in the event right before it.

A good note does not start with "the machine overheated". It starts with a short chain of events. For example: after the tool change, vibration began, spindle load rose after 12 minutes, and then the machine stopped with an alarm. That wording already shows what needs to be checked.

What to compare

One ticket is not enough. It should be compared with at least four things: the setup for that operation and the latest changes to it, the tool condition, the material batch, and the power quality in the same period.

This simple set is often enough to rule out extra guesses. If the problem appeared only with one metal batch, there is no need to replace the bearing right away. If the error repeats after the same setup change, the cause may be in the adjustment, not in the mechanics.

Another common mistake is to lump different kinds of causes into one group. Operator error, unit wear, and power failure all end in downtime, but they need different actions. In the first case, a clear instruction and a short pre-start check help. In the second, you need a plan to replace the unit based on actual service life. In the third, you need to look at power quality and equipment protection.

A simple example: a CNC lathe goes into alarm several times at night. The tickets mention overheating and noise. The log shows that before each stop, the operator installed a new tool from another batch, while the setup stayed the same. Load increased, vibration appeared, and then the protection tripped. The symptoms were the same, but the cause was the link between tool and mode, not the spindle.

When service, the setter, and the shop supervisor build this picture for each repeat, the actions become precise. Not "reduce vibration," but "check the setup sheet, set the allowed tool overhang, and note the material batch change separately in each ticket."

How to build an improvement plan step by step

You do not build an improvement plan from the supervisor's memory or from the biggest breakdown of the week. You build it from at least one quarter of tickets. Over three months, it becomes clear what fails by chance and what keeps coming back again and again.

First, export all service tickets into one table. Do not take only the big breakdowns. You also need minor stoppages, frequent adjustments, and repeat calls after repairs. Those are often the ones that eat up working hours, even though each individual record looks "not too serious."

How to sort the tickets

After that, group the repeats using a few matching tags. Usually it is enough to use the machine unit, shift, type of work, stop cause, and result: did the problem go away or return within a month.

This kind of review quickly shows unpleasant truths. The same sensor may not fail "in general," but only on two machines after the night shift. Or repeat failures may grow not because of a weak unit, but because nobody checks the feed setting after replacement.

After grouping, look not only at the number of tickets, but at the time loss. Five short 15-minute stoppages can sometimes be worse than one large breakdown, because they break the rhythm of the whole shift. If the cause appears often and creates clear downtime, it should be the first item in the plan.

Next, each problem needs one specific action. Not "improve maintenance," but "add daily filter cleaning," "add backlash check once a week," or "train the night shift on startup after setup change." Put a deadline and one owner next to it right away. If there are three owners, there is effectively no owner.

How to check whether the actions worked

A month later, come back to the same tags and compare the picture. Look at the same units, shifts, and types of work. If the number of repeats has dropped, the action worked. If not, either the cause was identified incorrectly, or the action itself is too weak.

On a shop floor with lathes, this looks very simple: service sees that after the night shift there are again tickets about hydraulic overheating, production checks the work mode and care routine, and the supervisor adds two measures to the plan with clear deadlines. A month later, you see not an opinion, but a result based on the same data.

Example: the failure returns after the night shift

The night shift stops the machine twice in one week with the same alarm. The operator writes briefly: "Stopped again with the same error, restart did not help." During the day, service comes, clears the alarm, checks the unit, and the machine runs again.

If you look only at the error code, it is easy to think the problem is in the drive or the sensor. But the log shows an important detail: both cases happened almost at the same time, right after the same setup change to another part.

The engineer pulls the old tickets, and the shop supervisor compares them with the tool log. It turns out the night shift changes the same set of inserts each time and re-enters the offsets.

Then the picture becomes clear. After the setup change, the operator starts the first part without a short check of the actual tool overhang. During roughing, the load rises sharply, the system gives the same alarm, and everything looks like a repeat breakdown. In fact, the failure is caused not by a unit failure, but by an error in the sequence of actions after setup.

After that check, there is no need to replace equipment. The routine needs to change. It is enough to introduce a short check after each night setup change: match the tool number in the turret with the setup sheet, check the length and radius offsets, run a dry pass of the first transition, and note in the log who confirmed the check.

It takes only a few minutes, but the result changes noticeably. The next tickets no longer repeat the same scenario: small remarks remain, but the same alarm after the night shift disappears.

That is how proper communication between service and the shop floor works. If the ticket includes not just the error code, but also the shift, setup change, tool, and events before the stop, the repeat is visible right away. If that data is missing, the case once again looks like "the same breakdown," even though the cause is already known.

Where useful data is most often lost

Useful data is usually lost not during the repair, but when the ticket is closed. The machine is started, the shift moves on, and the card only says "error cleared" or "sensor replaced." That is enough for accounting. For the shop floor, it is almost nothing.

The cause is what gets lost most often. If you do not record exactly what caused the stop - loose mounting, contaminated coolant, sensor failure, setup mistake, repeat wear of a unit - then you cannot group similar cases later. A month later, it looks like a series of unrelated small incidents, even though they have the same root cause.

A lot of meaning is also lost when service does not record the machining context. For a lathe, knowing the alarm code is not enough. At minimum, you need the part material, cutting mode, and tool number. Without that, it is hard to understand why the failure happened on that operation. On steel and stainless steel, the same unit can behave differently. A dull tool and too high a feed are also often mistaken for a "machine breakdown."

Where the record breaks down

Confusion starts when everything gets mixed into one pile. An emergency failure, planned wear, and a small adjustment are not the same type of event. If the spindle stopped because of overheating, that is one story. If the guides reached replacement time, that is another. If the operator corrected an offset and kept working, that is not a failure at all. When these cases are all thrown together, the statistics start to lie.

Another mistake is not comparing the new case with old tickets. The supervisor sees the current problem and solves it locally. But if you pull the older records, you may find that the same machine already stopped after a similar night shift, with the same material and the same tool. Then it is no longer a one-off issue, but a repeat.

Chats are convenient for urgent communication, but they do a poor job of holding history. Photos, voice notes, short comments, and part numbers get spread across different conversations. Two weeks later, nobody can put the full picture together. One table, even a simple one, is almost always more useful than several chats.

Usually, data is lost in the same places: the ticket is closed with the phrase "issue fixed," the material, mode, and tool are not recorded, wear, breakdown, and setup are mixed together, past similar cases are not checked, and the details stay only in messages.

If you remove these gaps, tickets start working for the shop floor instead of just recording the repair. Then you can already see what to change first: the mode, the tool, the inspection routine, or the unit itself.

A short check before the new month

Five minutes on the ticket log often gives more than a long meeting. If the records are in order, the shop can see faster where the failure repeats, who should remove the cause, and what to check first.

The problem is usually not that there are too few tickets. The problem is that they are written in different ways. One line says "won't start," another says "drive error," and a third says "axis X fault." Later, nobody notices that it is the same unit and the same story.

Before a new month begins, it helps to open all tickets from the last 3–4 weeks and quickly review them using one template. It is enough to check five things:

• does each ticket have a date, machine number, unit, and a short cause in simple words;
• can the repeat be seen through one tag instead of several different wordings;
• is one owner assigned to each action;
• does the shift know what to write down besides the error code;
• does the supervisor review the result at least once a week.

If even one point is missing, the data quickly loses meaning. For example, four tickets came in for the chuck in one month, but two do not name the unit, one has no shift, and the last one lists the cause as "poor machine performance." On paper, the tickets exist. In practice, they are almost impossible to compare.

A simple rule works well: one cause, one tag. If a lubrication failure on the ways is called the same thing every time, the repeat is visible right away. If the tags keep changing, the shop starts from zero each month.

What to do next

Do not try to rebuild the whole shop floor at once. Pick one machine where the failure comes back more often than the others, or one type of fault that has already taken many hours. At that scale, it is easier to see which ticket data helps you make a decision and which just fills the form.

If the ticket is too heavy, people start writing it in a formal way. Keep only the fields that really allow the supervisor or service to change something: stop time, shift, unit, events before the fault, employee actions, and whether the failure repeated after startup. That is already enough to see the repeat instead of drowning in extra lines.

Next, you need a simple rhythm: once a month, hold a short review with the shop supervisor and service, and for each repeat choose one action, one deadline, and one owner. That format is more useful than a long report that nobody opens later.

For shops where one supplier handles both commissioning and maintenance, this setup is especially convenient. For example, EAST CNC supplies CNC lathes, carries out startup and commissioning, and provides service, so the startup history, maintenance history, and repeat failures are easier to bring into one picture. That helps separate an operating mistake from unit wear or a wrong setting more quickly.

Do not wait for a perfect system. If the form got shorter after a month, the discussion takes half an hour, and one repeat failure disappears, the process has already started to work.