An issue is not a work order

Teams mix these up, then wonder why the board is noisy and the history is thin.

An issue describes the problem. A member says the lat pulldown catches at the top. That is an issue: what is wrong, how serious it is, which machine, and what it looks like.

A work order describes the job. Inspect the stack, replace the cable, record the part, the time, and whether it is finished. The job can start from the issue. It is not the same object.

Why the split matters

• One issue can wait while a part is on order. The work order carries the planned date.
• Several reports can point at one issue. You do not open three repairs for one cable.
• Machine history should show both the complaint and the work, in order.
• Cost belongs on the job: parts, labour, an outside technician. The issue stays about the fault.

Photos help both. A picture on the issue shows the problem as reported. Before-and-after pictures on the work order show what actually changed.

A status you can trust

New, reviewed, planned, in progress, waiting on parts, waiting on a supplier, resolved, closed. You do not need more than that.

What you do need is that "resolved" means someone wrote down what fixed it, and when. A closed issue with an empty resolution is just a hidden message.

A larger operation can add its own categories, assignment rules, and reminders. The register keeps the problem and the job distinguishable. If everything is a ticket, nothing is a plan.