Finding a change order form takes about four minutes. Every construction software vendor gives one away, in Word, in Excel and as a PDF, and most of them are perfectly serviceable. The reason change orders still cause arguments has nothing to do with the document. It is that the scope change gets agreed on site or on a call, the form gets filled in afterwards if at all, the signed copy lives in one person's downloads folder, and three months later nobody can produce a list of what was changed and what was agreed. The form is solved. The intake and the record are not.
The template is the part already handled
It is worth saying plainly, because a lot of time gets spent on template selection. Free change order templates are available from eForms, Levelset, Smartsheet, Projul and ProjectManager among others, in every common file format, including variants for fixed sum contracts and for time and materials work. They differ in layout and in how many lines they leave for a description. None of those differences determine whether the process works.
What determines whether it works is whether a change gets captured at the moment it is raised, by the person raising it, into somewhere that everyone involved can see. A template in a shared drive fails that test in a specific way: it requires somebody to remember it exists, open it, fill it in, save it under a sensible name and tell somebody. Five steps, any of which can be skipped without immediate consequence. The consequence arrives at the end of the job.
Turning the template into a form that can be submitted from a phone removes four of those five steps. That is the whole argument for doing it, and it is worth making the change even if the resulting fields are identical to the Word document they replace. The field list is not the improvement. The capture is.
What has to be on the form for it to be usable later
A change order has to answer, without anybody's memory being involved, what changed, why, what it costs, how much time it adds, who asked and who agreed.
| Field | Purpose |
|---|---|
| Project and contract reference | Ties the change to the right agreement |
| Sequential change number | Makes a gap in the sequence visible |
| Date raised | Establishes the order of events |
| Who requested it, and their role | Client, architect, engineer or trade |
| Description of the change | What is being added, removed or altered |
| Reason | Client request, site condition, design error, code requirement |
| Affected scope items or drawing references | Where in the original scope this lands |
| Cost impact, with a breakdown | Labour, materials, equipment, subcontract, overhead |
| Basis of the cost | Quoted, unit rates from the contract, or estimated |
| Schedule impact in days | Added, removed, or none |
| New contract sum and new completion date | The figures after this change |
| Approval | Who agreed, in what capacity, and when |
Two fields on that list are the ones that turn a change order from a note into a document worth having.
The reason field matters because it decides who pays. A change driven by a client request, a change driven by an unforeseen site condition and a change driven by an error in the drawings are three different conversations, and recording which one it was at the time is far easier than reconstructing it later. Offering a short picklist rather than a text box means the answer is consistent enough to sort by.
The new contract sum and completion date matter because they are cumulative. A change order that states only its own delta leaves somebody adding up twelve deltas to answer the question everyone actually asks. Carrying the running totals on each change makes the current position readable from the most recent document.
The handshake change
The genuine failure mode is not a badly designed form. It is a change that never reaches a form at all, because it was agreed verbally and both parties assumed the paperwork would follow.
These changes are not raised by careless people. They are raised because the alternative, at that moment, is to stop work. A client asks on site whether a socket can be moved two metres. The honest answer involves a written change order, a price and an approval, and the socket takes twenty minutes. So the socket moves, and nothing is written down, and the same thing happens fourteen more times.
Two things reduce this, and neither is a rule telling people to use the form.
The first is making the form fast enough to use in the moment. If raising a change takes ninety seconds on a phone, with the photo attached from the camera and most fields prefilled from the project, it competes with the verbal conversation rather than being the thing to do afterwards. A long form on a desktop does not compete, and it is the reason process documents stay unread.
The second is a low friction route for small changes. Some organizations handle this with a field order or a change directive, an instruction to proceed now with the pricing settled afterwards. Whether that is appropriate depends entirely on the contract in use, and it is worth checking the specific wording and taking advice rather than adopting it because a template mentioned it. What matters for the form is that the low friction route still creates a record, so a change agreed in the moment is a logged item with pricing pending rather than nothing at all.
Cost and time impact, the two fields left blank
On most change order forms in circulation, the cost box gets a number and the schedule box gets nothing. That asymmetry causes more disputes than any other part of the document, because time is where the money is on a delayed job.
Three practical points. A schedule impact of zero should be recorded as zero rather than left blank, because a blank field is ambiguous and a zero is a statement somebody made. The days should be stated as an impact on the completion date rather than as the duration of the extra work, since two days of work in the middle of a critical path is not a two day delay. And a change with pricing still to be agreed needs a status for that, rather than a blank cost field that looks like free.
The basis of the cost field does the same job here as on a purchase request. Quoted, contract unit rates, or estimated. An approver reading "estimated" asks a different question from one reading "quoted from the subcontractor", and the difference is invisible if the form only carries a number.
A folder of signed PDFs is not a log
Ask most teams for their change order log and what arrives is a folder. The folder is a storage arrangement and it cannot answer the questions a log exists to answer: which changes are outstanding, what the approved changes total, whether the sequence has gaps, and which changes affect the completion date.
A log is a table with one row per change, and it needs at least the change number, the date raised, a short description, the reason category, the cost impact, the schedule impact, the current status and the date approved. Smartsheet publishes a change order log template alongside its forms, which is a reasonable indication that the log is understood to be a separate artefact from the form.
The difficulty with maintaining a log by hand is the one every manually maintained index has: it is a second copy of the truth, and it drifts. Somebody raises change fourteen, the PDF gets saved, and the log gets updated on Friday, or does not. Within a month the folder and the log disagree and the log stops being trusted.
The way out is for the submission itself to be the row. When changes arrive as form submissions, the list of submissions is the log, with no separate copy to keep current, and each row can carry a status that moves as the change is priced, sent, approved or rejected. Internal notes about the change, such as a note that the client verbally agreed pending pricing, belong on the same record rather than in somebody's email. A tool that treats each response as a record with an owner and a status gives the log for free, which is the main reason to move change orders off a template even when the template is fine.
Signatures, and what a form tool does not do
Approval is where change order forms and form software part company, and it is worth being clear about the boundary before assuming a form solves it.
A form collects a submission. That is not the same as an executed document signed by both parties, and whether a typed name in a form field is sufficient for a given contract is a question about that contract and the applicable law, not about the software. It is worth checking the contract wording and taking proper advice before relying on a form as the execution mechanism, particularly on anything material.
Where the boundary sits in the tools: general purpose form builders collect answers and files, and electronic signature is usually a separate product with its own limits. Jotform, for example, prices signed documents separately from submissions, listing 10 signed documents per month on its free Starter plan, 100 on Bronze at $39 per month, 250 on Silver at $49 and 1,000 on Gold at $129. Teams that expect every change order to be countersigned should check that number rather than the submission allowance, because it is the smaller one.
The practical arrangement many teams end up with is a form for the intake and the record, and a signature step for the changes that need one, with the signed file attached back to the change record so the log still points at everything. That keeps the list complete without pretending the form is the signature.
Telling the field the answer
The last gap is the one that costs money directly. A change is priced, sent, approved, and the person doing the work is not told, so either the work does not start or it started a week ago under the original scope.
Closing that gap needs two things, both cheap. An automatic message to the requester when the status of a change moves, so the client or the project manager is not asking. And a visible list, filtered to approved changes not yet instructed, that somebody looks at daily. The second is what stops an approved change from sitting in an approved state with nobody acting on it, which is a surprisingly common way to lose a fortnight. A status per change that everyone involved can see does more for a change order process than any refinement to the form itself.
What to change first
Move change order intake off the template and onto a form that can be submitted from a phone in under two minutes, with the reason and the schedule impact as required fields. Then stop maintaining a separate log and let the list of submissions be the log, which is what Halict does with a status on each change and a message to the requester when it moves.
Q1. What has to be included on a change order form?
At minimum: the project and contract reference, a sequential change number, the date raised, who requested it, a description of the change, the reason category, the cost impact with its basis, the schedule impact in days, the resulting contract sum and completion date, and the approval. The reason and the running totals are the two most often omitted and the two most useful later.
Q2. Is a free change order template good enough?
For the document itself, generally yes. Free templates are published by eForms, Levelset, Smartsheet, Projul and ProjectManager, including versions for fixed sum and for time and materials contracts. The template is not usually what fails. What fails is that a template in a shared drive needs somebody to remember it, open it, fill it in, name it and circulate it.
Q3. How should a change order log be kept?
As a table with one row per change, carrying the number, date, description, reason, cost impact, schedule impact, status and approval date. Maintaining it as a second copy alongside a folder of PDFs tends to drift within a month. Having change orders arrive as form submissions makes the submission list the log, so there is no separate copy to keep current.
Q4. Can a change order be signed on a form?
A form collects a submission, which is not automatically the same as an executed document, and whether a typed name satisfies a particular contract is a question for that contract and for legal advice rather than for the software. In practice many teams use a form for intake and the record, add a separate signature step for changes that need one, and attach the signed file back to the change record.
Q5. What happens to changes that were agreed verbally on site?
They are the main reason change order processes fail, and a rule telling people to use the form does not fix it. Two things help: making the form fast enough to complete on a phone at the moment the change is raised, and providing a route that creates a record immediately with pricing marked as pending. Whether proceeding before pricing is agreed is acceptable depends on the contract in use.