Handshake changes are how jobs quietly lose money. The work happens. The paper does not. Months later, nobody can show what was directed, what was priced, or what was actually executed.

Procore’s change-event and change-order tools are built to facilitate a process: a potential change is recorded, pricing and documentation are gathered, and an official change document can be generated or tracked through execution. That is the right process: paper first, then the work, whenever the job allows it. You can run the same process with a change-order log, time-and-material tickets, and a folder in Google Drive or Dropbox.

I watched change paper move through enterprise tools, including Procore, at Mortenson Construction on a mission-critical data center project. The platform helped a large team keep potential changes from disappearing. The habit you can borrow is simple: write it down when it is directed, not when it is convenient. This is about a log you control.

What the process has to accomplish

A change-control habit, in any tool, has to:

  • Record a potential change when it is directed or discovered, with a date, a source (RFI, ASI, owner request, field condition), and a short description
  • Keep the backup: sketches, tickets, photos, emails, and pricing
  • Track status: potential, priced, submitted, executed, or withdrawn
  • Tie the executed change back to the current set and to the work, so the field is not building an unwritten direction
  • Make it obvious, later, whether the work was authorized

In a typical Procore project, change events can capture a potential change and feed a change-order workflow. Not every project turns that tool on, and not every contract uses the same change terms, so do not assume the next job is configured like the last.

The simpler equivalent

Use the Change Order Log Template change-order log in a 06_Changes folder. Each row is one potential or executed change. Track a number, date identified, source, description, status, amount if you have it (as a figure from your pricing, clearly labeled, not as a promised invoice), date submitted, date executed, and a link to the backup packet.

Standing rules:

  1. Paper first, then the work, whenever the job allows it. If the work had to start on a verbal direction, write the direction down the same day and follow with the ticket or the proposal. See Change Orders: Paper First, Then the Work and The Handshake Change That Never Got a Paper Trail.
  2. A time-and-material ticket is not a change order. It is backup that still has to land in the log and, eventually, in an executed document. See Time-and-Material Tickets and the Change Order They Become.
  3. File the executed change with the current set if it changes the work, and get it to the field. An executed change that sits in the office is the same miss as an RFI answer that never left the inbox.
  4. Backcharges need their own paper trail, started when the condition is visible, not when someone is angry at the end of the job. See Backcharges: The Paper Trail You Wish You Started Earlier.

When this is enough

A change log will hold if potential changes are entered the day they are directed, and if executed documents actually reach the field. It will not hold if you only open the log when a pay app comes up short. I can set up the log and the folder, or keep change paper filed on a retainer. The files stay yours.

If you want help, not just a checklist

Some jobs run fine on a clean file and a superintendent who gives the log fifteen minutes twice a week. Others do not: revisions are moving fast, closeout is already behind, or the field simply has no hours left for paperwork.

That is where I come in. I set up the job file, run the logs on a retainer, or prepare closeout before the scramble starts. Your files stay yours, and there is no software contract to sign.

Email travis@builtonrecord.com Get the free Job File Kit