Completion is a status. Acceptance needs a record.
Why a job marked complete is not the same as work that can be approved and paid, and what changes when the record is captured as the work happens.
By Toby Forman
Every field-services business knows the moment. The ticket says complete. The engineer has moved on to the next site. And three weeks later someone is on the phone trying to work out what actually happened.
A completed job is a status. It tells you the engineer believes the work is done. It does not tell you whether the work meets what your customer asked for, whether the extra hour on site was agreed, or whether the invoice can go out without a query. That takes a record.
Where the gap shows up
In 18 years of running field delivery, we kept meeting the same five costs:
- The revisit that could have been avoided, because an acceptance check was missed before the engineer left site.
- The rework nobody can attribute, because nobody recorded what was tested.
- The invoice that has to be reconstructed, because the approval for extra work sits in someone’s inbox.
- The payment waiting for a decision, because acceptance is incomplete.
- The cost of carrying the gap: the working capital tied up between done and paid, which each of the other four makes longer.
None of these is dramatic on its own. Together they are why field services feels harder than it should. We set them out in more detail on our About page and in our white paper, The cost of unproven work.
Capture it once, as the work happens
The fix is not more paperwork. It is capturing the right information once, at the moment it is true, and keeping it connected:
- the requirements and acceptance criteria, agreed before the job is accepted;
- the evidence from site, captured against those requirements;
- any change, with its authorisation, kept with the job;
- the acceptance decision, connected to the invoice.
When those four stay together, the person approving the work can see what they are approving, and the business or engineer who did it can point to the record instead of reconstructing it.
Why we built FortyFive
We built FortyFive because we needed it ourselves. It gives the business accountable to the customer a way to set the standard, manage teams and partners, and see the evidence behind every completed job, and it connects accepted work to invoicing and payment. It runs standalone from the first job, with no integration required.
If any of the five costs sound familiar, we would like to show you how it works. Book a walkthrough.