How to Track Rework Separately From New Work

Why rework disappears inside normal job activity

A lot of businesses know rework is happening but still cannot see what it is costing them.

The reason is usually simple: the system records labour, notes and job status, but it does not clearly distinguish between productive delivery and avoidable corrective effort. So the time gets absorbed into standard timesheets, extra site notes, reopened jobs, internal messages or vague admin categories like "general labour" or "completion works".

That creates two problems at once.

First, job profitability becomes harder to trust. A job may appear to have taken longer than expected, but you cannot tell whether the issue was legitimate scope, customer-driven changes, difficult site conditions or preventable rework.

Second, the business loses the ability to improve. If rework is invisible in the data, recurring failures stay anecdotal. Everyone has a sense that "we keep fixing the same sort of issues", but nobody can quantify where it starts, who is affected, how often it happens or what it is costing.

If you want to understand weak margins properly, rework needs to be captured as its own class of operational activity.

Rework is not just extra labour

Rework is any effort spent correcting, repeating or finishing work that should not have been required in its current form.

That does not mean every extra hour is rework. Some additional effort is part of normal delivery. Jobs change. Customers request variations. Unexpected conditions appear. Some exceptions are legitimate and chargeable.

The issue is that many businesses blend together very different types of effort:

original billable delivery work
approved variations
warranty work
defect rectification
internal mistakes
incomplete handovers
missing information follow-up
return effort caused by planning errors
customer-caused return work
supplier-caused correction work

When all of that goes into the same labour bucket, the reporting becomes misleading.

A field technician might spend two hours onsite. One hour may be chargeable installation work. The second hour may be spent fixing something that was installed incorrectly last week, chasing missing parts, or redoing work because the original job was closed too early. If both hours are recorded the same way, the system says "two hours worked". Operationally, those two hours mean very different things.

That distinction matters for pricing, team performance, process design, warranties and margin analysis.

The visible problem is weak margin. The underlying problem is classification

When businesses say "our margins are slipping" or "jobs are taking longer than they should", the first instinct is often to look at staff productivity, pricing or quoting accuracy.

Sometimes those are part of the answer. But often the underlying problem is more basic: the business has no consistent way to classify effort once the work moves beyond the original plan.

Without classification, you cannot answer questions like:

How much labour this month was new revenue-generating work?
How much was warranty work?
How much was internal rework caused by installation errors?
How much was due to bad information at handover?
Which teams generate the most corrective work?
Which job types are repeatedly producing defects?
Which customers, sites or project conditions create unusual levels of rework?
What portion of non-billable time is genuinely unavoidable, and what portion is preventable?

If those questions require manual investigation every time, then the system is not capturing the right operational facts during normal work.

What should count as rework

Businesses often struggle here because "rework" becomes too broad to be useful.

If you want meaningful reporting, define categories that reflect real operational decisions. They do not need to be complicated, but they do need to separate different causes and commercial consequences.

A practical starting structure might include:

Internal defect rework: correcting work that the business delivered incorrectly
Incomplete work reattendance: returning because the original job was closed or handed over before all required work was properly finished
Information failure rework: extra effort caused by missing site details, incorrect scope, absent photos, missing approvals or poor handover
Warranty work: post-completion corrective work covered under warranty terms
Supplier or material-related rework: effort caused by faulty components or supply issues
Customer-caused rework: corrective or repeat work triggered by customer changes, misuse or late requests
Quality assurance rectification: work required after inspection identifies a defect or non-conformance

You may combine or rename these to suit your operation, but the key is to avoid a single generic "rework" bucket if different types need different treatment.

For example, internal install defects and customer-caused callbacks should not be analysed the same way. One points to internal process failure. The other may be chargeable or contractually distinct.

Separate billable from non-billable effort early

One of the biggest costing mistakes is treating rework classification and billability as the same thing.

They are related, but they are not identical.

A piece of work can be:

rework and non-billable
rework and billable
new work and billable
new work and non-billable

For example:

Fixing your own installation error is usually rework and non-billable
Returning because the customer requested a change after approval may be rework in an operational sense, but billable commercially
Training a new staff member onsite may be non-billable, but it is not rework
Performing warranty rectification is rework, though not necessarily attributable to the original installer without further review

If your team only records whether time is billable, you still will not know how much hidden corrective work exists.

If they only record whether something is rework, you still will not know the commercial outcome.

You need both fields.

That gives you much better reporting:

non-billable rework by team
billable rework by customer type
warranty labour by product or service line
internal defects by installer, crew or stage
customer-driven return effort that should influence quoting or contract terms

Capture cause and responsibility, not just the existence of rework

Knowing that rework occurred is useful. Knowing why it occurred is what makes improvement possible.

This is where many businesses stop too early. They add a "rework" checkbox, but not the supporting information needed to make sense of it.

At minimum, rework capture should answer four things:

What type of rework is this?
Is it billable or non-billable?
What caused it?
Who owns follow-up or review?

Cause does not need to become a long free-text essay every time. In fact, too much free text usually makes reporting worse. A structured cause list works better, with an optional note where needed.

Common cause fields might include:

installation error
incorrect scope
quoting omission
scheduling issue
missing materials
faulty materials
incorrect customer information
incomplete documentation
failed quality check
customer change request
warranty claim
approval issue

Responsibility is also important, but should be handled carefully. The purpose is not to create a blame culture. It is to identify where the process failed.

Responsibility may sit with:

sales or quoting
site scoping
operations handover
procurement
scheduling
field execution
quality assurance
supplier
customer

If rework data only tells you that "something went wrong", managers still have to reconstruct every issue manually.

Why reopened jobs usually produce bad data

A common pattern is this: a completed job gets reopened when something has to be fixed.

That is better than ignoring the problem, but by itself it is usually not enough.

When a job is simply reopened:

new work and corrective work get mixed together
labour before and after completion may be indistinguishable
the reason for reopening may only exist in notes
nobody consistently records whether the new effort was chargeable
warranty and defect data become hard to extract later
reopened jobs distort cycle time and completion reporting
the business loses a clean view of original delivery versus corrective effort

A better approach is usually to preserve the original job history while creating a clearly classified rework event, task or work order linked back to the original job.

That way you can still see:

the original job cost and timeline
the existence of follow-up corrective work
the reason for that work
whether it sits under warranty, defect, variation or customer request
who owns review and resolution

This is a workflow design issue more than a software issue. Whatever system you use, the data model needs a way to record corrective activity without burying it inside standard delivery.

What a practical rework workflow looks like

A good rework process does not need to be complicated, but it does need clear rules.

A workable model often looks like this:

A corrective issue is identified A technician, supervisor, customer service team member or quality check identifies that some form of follow-up work is required.
The issue is classified before labour starts The person raising it selects a rework type, initial cause and whether it appears billable, non-billable or under review.
The corrective work is linked to the original job The system ties the rework item back to the original project, customer, crew, service type or product category.
Labour and materials are recorded against the rework item Time should not be booked back into general delivery labour if the purpose is corrective.
Ownership is assigned Someone is responsible not just for doing the work, but for reviewing why it happened.
The outcome is closed with final coding Once resolved, the classification can be confirmed or adjusted. For example, something initially raised as a defect may later be shown to be customer-caused.
The data feeds reporting Rework can then be analysed by source, cost, frequency and pattern.

That process can be implemented in different ways depending on the business. The important part is that the workflow forces the distinction at the time the work is happening, not three weeks later during reporting.

The system should make correct coding easier than vague coding

If staff have to work too hard to classify rework properly, they will default to whatever is fastest.

That usually means:

booking time to the main job
using generic codes
leaving the cause in a note
asking the office to work it out later
not recording the distinction at all

This is why system design matters.

If you want reliable rework visibility, the process has to be operationally realistic. For example:

a technician closing a job can flag "follow-up required"
that flag can require a reason category before completion
office staff can review and convert it into a classified rework item
labour entries can require a work type selection
billability can default based on rework category, then be overridden by authorised staff if needed
warranty-related work can require a linked completion date or original job reference
unresolved corrective items can remain visible until assigned and closed

The point is not to create admin for its own sake. The point is to stop important cost information from disappearing into notes and memory.

Warranties, defects and rework should connect, but not collapse into one thing

Many businesses use "warranty" as a catch-all label for any post-completion problem.

That creates its own confusion.

Warranty is usually a commercial or contractual status. Rework is an operational activity. A defect is usually a quality issue. These concepts overlap, but they are not identical.

For example:

A warranty claim may reveal an internal installation defect
A warranty claim may actually be customer misuse
A defect may be identified before handover and never become a warranty issue
A non-defect post-completion visit may still be rework if the business failed to complete required documentation or setup properly

If all of these get grouped into "warranty", you lose the ability to see what is actually driving cost.

It is usually better to track separate fields such as:

work classification: new work, rework, support, variation
rework type: defect, warranty, information failure, supplier issue, customer-caused
billable status: billable, non-billable, pending review
responsibility area: quoting, operations, field, supplier, customer

That gives you better visibility without forcing one label to do too much work.

What you should be able to report once rework is tracked properly

Once rework is separated cleanly from new work, your reporting becomes much more useful.

You should be able to see rework by:

team or crew
individual technician or installer
customer
site
job type
service line
product category
project manager
original quote type
stage of work
cause category
responsibility area
billable versus non-billable status
warranty versus non-warranty

That does not mean every business needs every report. But at a minimum, you should be able to answer:

How much labour last month was spent on corrective work?
What share of that was non-billable?
What causes appear most often?
Which job types produce the most rework?
Where is rework increasing?
What categories are being written off under warranty?
Which issues are operationally preventable?

Without that, profitability review stays too high-level. You can see the symptom, but not the mechanism.

Rework data should lead to process fixes, not just better reports

The purpose of tracking rework separately is not to produce another dashboard nobody uses.

The purpose is to expose recurring failure points clearly enough that the business can fix them.

For example, if rework reporting shows a high volume of non-billable follow-up work tied to missing site information, the answer is probably not "work harder". The answer may be:

improve site-scope checklists
require photos before quoting
tighten sales-to-operations handover
stop jobs moving forward without mandatory details
clarify who confirms measurements and site conditions

If rework is concentrated in a particular installation stage, the answer may involve:

better work instructions
QA checks before handover
more consistent completion evidence
clearer ownership between crews and supervisors

If warranty-related labour is concentrated around one product or supplier, the answer may sit in procurement, specification or installation method rather than staff utilisation.

Good rework data changes the conversation from opinion to pattern.

Common mistakes when trying to track rework

A few issues come up repeatedly.

Treating rework as an after-the-fact reporting exercise

If staff do normal entries and someone in the office tries to reconstruct rework later, the data will usually be incomplete. Rework needs to be captured during the workflow, not guessed after the event.

Using one vague rework code for everything

A single "rework" label is better than nothing, but it quickly becomes too blunt to support decisions. If the categories do not reflect meaningful causes, the reporting will not help much.

Confusing blame with responsibility

If classification is used to punish people, staff will avoid coding issues honestly. The objective is to identify where the process broke down, not create defensive data entry behaviour.

Mixing job status with work classification

A job can be complete and still have linked corrective work. Reopening or extending statuses too loosely often makes the whole reporting structure muddy.

Leaving billability unresolved

If rework is recorded but nobody decides whether it is chargeable, written off, supplier-claimable or warranty-covered, profitability still remains unclear.

What good looks like operationally

A business with good rework visibility usually has a few characteristics in place:

labour for corrective work is not buried inside standard delivery entries
rework has defined categories
billable and non-billable status are recorded separately
warranty and defect handling are linked but not conflated
corrective work is tied back to the original job or project
cause and responsibility are captured in a structured way
unresolved issues have visible ownership
reporting can show where rework is coming from and what it is costing
managers use the data to fix the workflow, not just explain poor margins after the fact

That is when rework stops being a hidden drain and starts becoming a useful operational signal.

If margins are weaker than expected, there is a good chance some of the answer is buried inside ordinary labour records and vague job notes. Separating rework from new work is one of the simplest ways to make hidden cost visible.

And once that visibility exists, process improvement becomes much more concrete. You can see whether the problem is quoting, handover, quality control, supplier reliability, field execution or warranty handling, and respond accordingly.

If your current workflow spans multiple systems or relies on staff remembering how to code these situations manually, it is usually worth mapping the process properly before changing the reporting. That is often where the real visibility problem starts, and where 5M Consulting can help.

How to Track Rework Separately From New Work So You Can See the Real Cost