Extra work on site is not the exception people pretend it is
A technician arrives to complete a booked job and finds something else that needs doing.
It might be damaged cabling behind a panel, an extra fitting the customer assumed was included, a compliance issue that has to be addressed before the original task can be finished, or another fault that only becomes visible once work starts.
Most field-service businesses treat this as an occasional complication. Operationally, it is not. It is a predictable part of delivery.
The problem is usually not that extra work exists. The problem is that many businesses still handle it through informal judgement:
- the technician mentions it verbally
- the office gets a partial story later
- the customer thinks they already approved it
- the technician does it as a favour to keep the job moving
- the invoice goes out without the extra line items
- someone tries to reconstruct what happened after the fact
That is where margin leaks. It is also where disputes start.
If you want a reliable way to handle additional work found on site, you need a defined workflow from the moment the issue is discovered. That workflow should preserve context, make the approval path clear, and push the commercial outcome back into the main job record.
The visible problem is unbilled work, but the underlying problem is workflow design
When discovered-on-site work goes wrong, the symptom is often obvious:
- extra labour was never invoiced
- materials were used but not recorded
- the customer disputes the charge
- the technician ran over time and the rest of the day blew out
- the office learns about the change after the job has already been closed
But those are downstream effects.
The underlying issue is usually that the business has not defined what should happen when the original scope changes during delivery.
Without that definition, staff are left to improvise around questions like:
- What exactly should the technician capture?
- Can they proceed immediately, or do they need approval?
- Who gives that approval?
- Does the customer need a price first?
- What if the extra work is urgent but not dangerous?
- What if doing the extra work affects the rest of the day’s schedule?
- How does the new scope make its way into invoicing?
- Where is the evidence if the customer later disagrees?
If the answer to those questions lives in people’s heads, the process is not reliable.
What a good workflow needs to achieve
A workable process for discovered-on-site work needs to do five things well:
- Capture what was found clearly enough that others can act on it.
- Route the job into the right approval path based on value and risk.
- Preserve commercial control by attaching scope and pricing decisions to the job.
- Deal with scheduling consequences if the work is accepted.
- Ensure completed extra work flows through to invoicing and reporting.
That may sound straightforward, but it breaks down quickly if even one of those steps is vague.
For example, if a technician can capture photos but not the likely time required, the office cannot price it properly. If the customer approves verbally but nothing records that approval, invoicing becomes awkward. If the extra work is approved but the schedule is not updated, the rest of the day suffers.
This is why the fix is not simply “get technicians to tell the office”. The fix is a standard decision path.
Start with a simple capture path for technicians
When extra work is discovered, the technician should not need to invent a process on the spot.
They need a simple, repeatable capture path that answers the basic operational questions.
In most cases, the minimum useful capture should include:
- what was found
- why it matters
- whether the original scope can still proceed
- whether the extra work is urgent, required, optional or recommended
- photos or other supporting evidence where relevant
- estimated labour, materials or duration impact
- any immediate safety or compliance concern
The key is not to turn technicians into administrators. The key is to make sure the person who first sees the issue captures enough context while they are still there.
If they leave site and someone in the office has to reconstruct the situation from memory, the quality of information drops immediately.
A practical example might look like this:
A technician attends to replace a failed component. Once opened up, they find additional water damage that has affected nearby fittings. They should be able to record the finding against the active job, attach photos, classify the issue, and indicate whether the original task can continue safely without the extra work being addressed.
That is very different from sending a text saying “found more work here, call me”.
Approval should depend on value and risk, not habit
One of the biggest causes of chaos is treating every extra item the same way.
Not all discovered-on-site work needs the same approval process. A sensible workflow should vary based on risk and value.
Low-value and low-risk work
Some businesses allow technicians to proceed with minor extras up to a defined threshold, particularly where the work is obvious, necessary and unlikely to be disputed.
That only works if the rule is explicit.
For example, the business might allow a technician to complete up to a certain dollar value of clearly necessary remedial work without separate office approval, provided the technician captures evidence and the customer agrees on site.
The important part is not the exact threshold. It is that everyone knows the rule.
Higher-value work
Once the value becomes material, the customer usually needs a clear commercial decision before work proceeds.
That means the workflow should create a pause point:
- the finding is captured
- the price or estimate is prepared
- the customer approves or declines
- the job state updates accordingly
If that pause point does not exist, technicians often get pressured into continuing “just to keep things moving”, and the business later tries to invoice work that was never formally accepted.
High-risk or compliance-related work
Some work carries operational or legal consequences if ignored. In those cases, the question may not simply be whether the customer wants it done now.
The workflow may need to distinguish between:
- work required to make the site safe
- work required before the original scope can continue
- work that can be deferred
- work that should be quoted separately
This is where human judgement still matters. A system can route and document the decision, but it should not pretend every site decision is fully automatic.
The job record has to remain the source of truth
A common failure point is that the extra work gets discussed somewhere other than the main job record.
The photos are in a technician’s phone. The approval is in an SMS thread. The revised price is in email. The final labour time sits in a separate app. The invoice is raised from the original job scope anyway.
Once that happens, the business loses control.
The core rule should be simple: if extra work affects scope, price, time, materials or scheduling, it must feed back into the primary job record.
That job record should show, in one place:
- the original booked scope
- the additional work found
- supporting evidence
- customer approval status
- pricing or quote adjustment
- revised time expectations
- whether the work was completed, deferred or declined
This matters for more than invoicing.
It affects handover between field and office, visibility for managers, schedule planning, and any later dispute about what happened on site.
If your team has to chase across messages and memory to understand a change, the system has already failed.
Pricing cannot stay informal
Discovered-on-site work often turns into margin leakage because the commercial step is never properly completed.
The technician does the work. The customer seems agreeable. The office assumes it will be sorted later.
Later is where revenue disappears.
A better process defines how pricing is created once extra work is identified. That might be:
- a pre-defined rate card for common add-ons
- a quick office review before approval is sent
- a revised quote generated from the existing job
- a provisional estimate converted to final billing once actual quantities are confirmed
The exact method depends on the business model. The important point is that pricing should not be a separate, disconnected activity.
If the extra scope is accepted, the commercial record should update inside the same operational flow. Otherwise you end up with delivery happening on one track and billing happening on another.
That separation is what creates missing invoice lines, guessed amounts and uncomfortable conversations with customers.
Scheduling has to be part of the workflow, not an afterthought
Extra work on site does not only affect price. It affects time.
If a technician accepts another two hours of work, the rest of the day may no longer be viable. If a second visit is required, someone needs to create and schedule it. If additional parts are needed, the job may need to pause until they are available.
Many businesses capture the commercial side loosely but fail on the scheduling side completely.
The result is familiar:
- the technician runs late to the next job
- the office does not know why the schedule has slipped
- customers later in the day get poor communication
- incomplete work sits in limbo because no follow-up task was created
A proper workflow should decide what happens operationally once the extra work is accepted.
That may mean one of several outcomes:
- complete it immediately and extend the current job duration
- complete only a safe or essential portion now
- create a follow-up visit
- escalate for resourcing or replanning
- defer until materials, approvals or access are available
The key is that acceptance of extra work should trigger a scheduling decision, not just a billing note.
Undocumented extras usually become either free work or a dispute
When businesses do not formalise this process, they usually drift into one of two bad outcomes.
The first is unbilled work.
The technician helps the customer, keeps the site moving, solves the problem, and nobody captures enough detail to invoice it confidently. The business absorbs the cost.
The second is a disputed invoice.
The work gets done, the office adds a charge later, and the customer says they never approved it, did not understand it, or thought it was included in the original job.
In both cases, the operational failure happened earlier.
It happened when the business allowed extra work to be performed without clear capture, decision points and evidence.
This is why “our technicians just know how to handle it” is not a reliable operating model. Good technicians often compensate for bad systems. That does not mean the system works.
A practical decision path for discovered-on-site work
The simplest reliable approach is to define a standard path that begins the moment additional work is identified.
A workable version often looks like this:
Technician identifies additional work
- Records the issue against the active job
- Captures photos, notes and likely impact
Technician classifies the situation
- Can original work proceed?
- Is the extra work urgent, required, optional or deferrable?
- Is there a safety or compliance issue?
Workflow routes based on rules
- Minor work within delegated authority may proceed with on-site customer agreement
- Larger or riskier work pauses for office review or formal customer approval
- Non-urgent work may be quoted separately
Price or scope update is created
- Revised amount, estimate or variation record is attached to the same job
- Approval evidence is stored with it
Customer decision is recorded
- Approved, declined or deferred
- Date, time and method of approval are preserved
Operational plan updates
- Complete now, return later or escalate
- Schedule and resource impact is reflected in the system
Delivery and invoicing follow the updated job
- Extra labour, parts and line items flow through from the approved change
- The final invoice reflects what was actually accepted and completed
That path does not need to be overly complex. It just needs to be consistent.
Keep the technician workflow simple, even if the back-end logic is more detailed
One common mistake is designing a process that makes sense to management but is too awkward for people on site to use properly.
If a technician has to navigate too many screens, write long explanations or wait on unnecessary internal approvals, they will work around the process. Once that happens, the business is back to phone calls, text messages and missing records.
The front-end experience for the technician should be simple:
- capture the issue
- choose the right classification
- attach evidence
- trigger the next step
The complexity, where needed, should sit behind the scenes in the decision rules, approval routing and job updates.
That is generally a better design principle in field-service systems: keep the site workflow short, but make sure it triggers the right downstream actions.
Decide where human judgement still belongs
Not every case should be automated end to end.
Some decisions are too context-dependent to reduce to a fixed rule. For example:
- whether the customer should be offered a temporary workaround
- whether the site can be left safely until a return visit
- whether the additional work changes the technical approach to the original job
- whether a long-term issue should be handled under a different commercial arrangement
The goal is not to remove judgement. The goal is to stop judgement from being invisible.
A good workflow supports human decisions by making sure they are documented, attributable and connected to the job record.
What good looks like in practice
When this process is working well, discovered-on-site work does not create panic.
A technician finds additional work and knows exactly how to log it. The office receives enough context to act without chasing basic facts. The customer gets a clear approval path. Any price adjustment is attached to the live job. The schedule reflects the real impact. The invoice matches what was approved and completed.
Just as importantly, managers can see what is happening before the end of the week or month. They are not trying to reconstruct lost revenue from incomplete notes and memory.
That is the real benefit of a defined workflow. It is not just cleaner administration. It is commercial control.
If this keeps happening, the process is the issue
If extra work found on site regularly turns into favours, write-offs, late invoice changes or customer arguments, that is usually not a technician problem.
It means the business has a recurring field-service exception with no reliable system around it.
The fix is to define the decision path clearly:
- what technicians capture
- when approval is required
- how pricing is created
- where evidence is stored
- how the job record updates
- what happens to the schedule
- how invoicing picks up the result
If that workflow currently spans messages, calls, spreadsheets and disconnected software, mapping it properly before adding automation is usually worthwhile. That is the kind of operational design work 5M Consulting helps businesses with, especially where field teams, approvals and back-office systems all need to stay aligned.