The gap between a good job and a profitable one lives in the detail.
Every job in a field service business follows the same arc. A customer calls. An engineer gets dispatched. Work gets done. An invoice goes out. That arc is the same whether you're running five engineers or 50, whether you're in commercial HVAC or facilities management.
What's not the same is how much the business loses between each of those steps — to incomplete preparation, to documentation that doesn't reflect what actually happened, to invoices that go out late against unclear records. That loss is structural. It's built into the way the work has to be done without the right operational support.
BigChange Lightning changes what happens inside the job. Not the arc itself — the system the job runs through. Here's what that looks like in practice.
Here's the same job, before BigChange Lightning and after it. Not a hypothetical job — the kind of job that happens dozens of times a day in a field service business of any size.
Before: The job starts behind
The booking comes in. It gets entered into BigChange. An engineer gets assigned.
The morning before the job, someone — usually the service manager or the engineer themselves — needs to pull up what they know about this site. That means navigating the job history, finding the last few visits, reading through whatever notes were left. If the notes are good, this takes ten minutes. If they're incomplete — and they often are — it takes longer and yields less.
The engineer heads out with the information they managed to find. Not necessarily the information they need.
On site, the work gets done. If something unexpected turns up — an asset the customer forgot to mention, a fault that connects to something from a previous visit — the engineer works through it from memory and experience. The context that might have helped them is sitting in a job record nobody had time to read properly.
When the job is done, the engineer writes up their notes. It's been a long day. The notes capture the main points. Some of the detail — the specific fault code, the conversation about the recommended follow-up, the customer's comment about the other asset in the building — doesn't make it in. Not intentionally. There's only so much a person can reconstruct at the end of a shift.
The invoice goes out a day or two later, once the office has processed the job record. If the notes are unclear, someone has to call the engineer to clarify. Sometimes the invoice is wrong. Sometimes the customer disputes it. On average, incomplete documentation drives billing disputes up by around 40% — and each dispute adds days to payment.
The job is closed. The record is partial. The next engineer who attends this site will start from the same incomplete information.
After: The job starts with everything the business knows
The booking comes in. It gets entered into BigChange. An engineer gets assigned.
Before the job, Cooper — the AI brain of BigChange Lightning — draws together everything BigChange holds about that site: every previous visit, every asset serviced, every note left, every fault recorded, every customer interaction logged. The result is a briefing. Not a data dump. A briefing. The relevant context, organised around what the engineer actually needs to know before they walk in.
What was found on the last visit. What was left unresolved. What the customer has flagged. Which assets are most likely to need attention based on their service history. What parts have been used on similar faults at this type of asset.
The engineer heads out prepared. Not with the information they managed to find — with the information the business holds.
On site, the engineer is working with context. The fault that connects to something from three visits ago isn't a surprise — it's in the briefing. The customer's preference about how they like to be communicated with is noted. The asset that keeps showing a recurring fault has a history that makes the diagnosis faster.
As the work happens, JobScribe is listening and capturing. The fault description. What was done. What was found. What was recommended. The conversation between the engineer and the customer. Structured into the job record in real time — not reconstructed from memory at the end of the day.
When the job is done, the documentation is already done. The engineer doesn't write up notes. The record reflects what actually happened, because it was captured as it happened.
JobBrief generates the customer summary automatically — a clear, professional account of what was done, what was found, and what's recommended next. It goes to the customer the same day. Not because someone in the office had time to write it. Because it was produced the moment the job closed.
The invoice goes out immediately, against a complete and accurate job record. Disputes drop — research puts the reduction from proactive post-job communication at 25–35%. Payment arrives 15–20 days faster on average.
The job is closed. The record is complete. The next engineer who attends this site starts with everything.
The gap isn't visible in any single job
This is the part that matters most.
The difference between before and after doesn't show up dramatically in any single job. An engineer spending ten minutes less on prep in the morning. A note that would have been missed getting captured. An invoice going out a day earlier. A customer receiving a summary they didn't expect.
None of those are transformative on their own. Together, across every job, every day, they are.
One in four jobs in the industry ends in a return visit. The cost of each failed first visit runs between £200 and £500 in wasted labour and vehicle time. For a ten-engineer crew, that's roughly £1 million a year in return trips. A business operating at 90% first-time fix instead of 75% doesn't just improve a metric — it recovers a material amount of margin that was quietly disappearing.
30 minutes of documentation time per engineer per day, at £30 an hour in burdened labour cost, is over £50,000 a year for a ten-person crew. That's time that can go to billable work, or simply be given back to the people doing it.
The billing disputes from incomplete notes, the payments delayed by unclear documentation, the return trips from engineers walking into jobs without context — they don't appear on a single line of the P&L. They're distributed across hundreds of jobs, invisible in isolation, significant in aggregate.
BigChange Lightning doesn't fix the job. It fixes the system the job runs through. And when the system works, every job is a little better — and the aggregate of those improvements is what moves the margin.
The job hasn't changed. A customer still calls. An engineer still gets dispatched. Work still gets done. An invoice still goes out.
What's changed is how much the business loses between each of those steps.
Before BigChange Lightning, that loss was structural — built into the way the work had to be done. After BigChange Lightning, it's not.
