Why PolarPath Raises Change Orders From the Field (and Why We Built It That Way)

Extra work gets done on a verbal okay every day on job sites across the GTA. The crew agrees, the customer nods, the work gets done. Then billing day comes and nobody in the office has a written record of what was agreed, what was done, or whether the customer ever formally approved it. The change order either gets invoiced anyway and disputed, or it gets dropped entirely. Neither outcome is good for the contractor.

This is a build note about the design decision behind PolarPath's change order tracking, and specifically about why we put the origination point in the field rather than the office.

The Obvious Alternative, and Why It Fails

The obvious way to build change order tracking is to put it in the back office. A project manager or dispatcher gets a call from the field, logs the extra scope, creates the change order document, sends it to the customer for approval, and eventually flags it for billing. It is a clean, controlled process on a whiteboard.

It fails in practice for one simple reason: the phone call is lossy.

By the time a field technician describes extra work to someone in the office, information is already missing. The rusted out fitting that turned a two hour job into a six hour job is not in front of the person typing the description. The photos are on the technician's phone. The exact scope of what was agreed with the customer on site is a secondhand account. The office person does their best with what they have, but the written record they produce is already one step removed from the actual event.

When that change order is later disputed, the contractor has a document created hours after the fact by someone who was not there. That is not a strong position.

The Design Decision: Originate at the Source

We built change order creation into the field side mobile experience specifically so the record is created at the moment the scope changes, by the person on site, with the supporting evidence attached at the same time.

Here is what that looks like in practice:

1. The technician identifies extra work that is outside the original scope.
2. They open the job in PolarPath on their phone and raise a change order directly against that job record.
3. They add a description of the work and attach site photos before leaving the location.
4. That change order sits in an approval queue, attached to the job, visible to the office immediately.
5. The office can track its status (pending approval, approved, approved and billed) without calling anyone to get the details.

The record is created at the source, by the person with direct knowledge, with photographic evidence, at the time the event occurs. It stays attached to the job so there is no separate tracking spreadsheet, no sticky note on a desk, no email thread to hunt down later.

The Tradeoff We Accepted

Putting change order creation on a mobile device means the technician has to do it on site, while they are still at the job. That is a real ask. Field technicians are not looking for more data entry.

We accepted that tradeoff because the alternative cost is higher. A change order that is never recorded is revenue that is never billed. A change order that is recorded hours later by someone in the office, without photos, without the technician's direct description, is a change order that is hard to defend if the customer pushes back.

The ask to the technician is: document the extra scope before you leave the site, the same way you document your hours and job notes. It is one step in a workflow they are already completing. The payoff is that the office does not have to chase them for details later, and the billing team has everything they need to actually invoice it.

What the Office Sees

Once a field raised change order lands in the system, the office has a clear picture without making a single phone call:

• What extra work was done, in the technician's own words
• Site photos attached at the time of creation
• Which job and which customer it belongs to
• Whether it has been approved or is still pending
• Whether it has been billed or is sitting unbilled

That last point matters. Unbilled change orders are one of the quieter margin leaks in a mixed service and project business. They do not show up as a failed invoice; they simply never become an invoice at all. Tracking change order status through to billing closure is how you make sure the approval queue does not become a graveyard for revenue.

A Simple Way to Think About Change Order Discipline

If you are trying to tighten this up in your own shop without any new software, the principle still applies: the closer the documentation is to the event, the better the record.

A few practical checkpoints:

• At scope change: the crew documents what changed and why before leaving the site, even if it is a photo and a voice memo.
• Within 24 hours: the office has a written description attached to the job record, not sitting in someone's inbox.
• Before the next invoice run: every change order has a status (pending, approved, or rejected) so billing knows what to include.
• At invoice: the change order line is attached to the invoice with the original documentation available if the customer questions it.

The gap that hurts contractors most is usually between "scope change" and "written record." Closing that gap is the whole job.

How PolarPath Connects This

PolarPath's change order tracking is built to close that gap at the field level. The technician raises the change order on the job, attaches the photos, and the record exists from that moment forward, tied to the job, visible to the office, trackable through approval and into billing. QuickBooks handles the accounting; PolarPath owns the operational record from the moment the scope changes to the moment the invoice goes out.

If unbilled change orders are a recurring problem in your shop, the fix is almost always about where and when the record gets created. Getting that step to happen on site, by the person who knows what happened, is the design decision that makes everything downstream easier.

See how it fits your operation at polarpath.ca.