Pending change-order aging: find what is holding up the decision

Use age to open the right question

A list of old change-order requests can make a meeting feel urgent without making the next step clearer. One request may be missing an internal cost record. Another may be accepted in principle but waiting for formal documentation. A third may involve a genuine scope disagreement. Sending the same reminder to all three does not address the reason each remains open.

Treat age as a signal that points to a decision. For every material item, ask what is unresolved, who has authority or information to resolve it and what observable action should happen next. “Follow up with GC” is too broad. “Ask the designated reviewer to confirm whether the revised labor backup resolves comment two” gives the next contact a purpose.

Use the report to coordinate work across project and commercial roles, not to assign blame from a single number. An old request can contain several handoffs and legitimate review cycles. Preserve that history while making the present action visible. The strongest weekly report explains both how long the request has existed and why it is still unresolved today.

Define the clock before comparing projects

Put the snapshot date and clock definition beside the report. A practical management convention is calendar days between the original documented submission date and the snapshot date while the request remains unresolved. Use date-only values consistently, define the timezone used for source timestamps and decide how same-day submissions appear. This convention is a reporting choice, not a universal contract requirement.

Other clocks answer other questions. Time since the field event shows how long the whole process has taken. Time since the latest revision can help monitor a correction cycle. Time since assignment shows how long the current person has held an action. Keep those fields distinct rather than changing the meaning of “age” from one project to another without explanation.

Clearstory's documented aging report provides an existing product example: it starts at submission and continues for specified open states, including approved-to-proceed requests awaiting a formal change. Your own status model may differ. Record the start, included states and resolution events explicitly, then apply them consistently to every row included in the comparison.

Sources: Clearstory help: Days Aging Report and clock definition

Give every row a current state and a responsible action

The core register needs the project, stable request identifier, title, current revision, original submission date, requested amount and currency, status, blocker, current responsible person, next action and next review date. Add source links to the current packet and the relevant correspondence. A summary dashboard can hide detail, but the underlying row must remain inspectable.

Separate the owner of the overall request from the person responsible for its next action. A subcontractor project manager may own the request while an internal estimator supplies missing support or an external reviewer assesses a revised scope. Record the current handoff rather than changing the request owner every time a different person needs to respond.

Use a short, controlled blocker list that reflects your work. Suggested categories include internal backup missing, submission receipt unconfirmed, scope clarification, quantity or rate review, formal change pending and disputed or escalated. Keep a short factual note beside the category. If a category does not explain what the next person should do, refine the note before adding another status label.

Read a fictional four-request backlog

The following example uses a snapshot of October 29, 2026 and calendar-day age from original submission. It contains four fictional requests totaling $67,000. The dates and amounts are teaching data. They do not describe a customer, establish a collectible balance or predict a financial outcome. All four remain unresolved under this example's management definition.

Two requests are more than 30 days old: $35,000 at 70 days and $18,000 at 45 days. Together they represent $53,000, about 79% of the example's requested backlog. Their blockers differ. The first needs a formal document after a recorded proceed instruction; the second still needs support from the sender's own team. An age-only email campaign would miss that distinction.

The 20-day request has a scope question and the five-day request is in an initial review. They still need next actions, but the report should not portray each as an equally overdue external response. Establish review expectations using the project's actual process. A 30-day management bucket is a sorting convention; it is not proof that a contractual deadline was missed.

Summarize without losing the underlying requests

Choose nonoverlapping ranges and show both count and amount. For this example, use 0–30, 31–60, 61–90 and over 90 days. The first bucket contains two requests totaling $14,000, the second one request at $18,000 and the third one request at $35,000. There are no requests over 90 days. Those bucket totals reconcile to four requests and $67,000.

Allow the meeting owner to trace a bucket to its rows. An impressive summary is of limited use if nobody can identify which request caused the amount to change. Keep the snapshot, filters and underlying export together. When comparing weeks, explain whether a difference comes from a new request, an amount revision, a status transition or a change to the report's scope.

Do not combine different currencies into one unlabeled total. Keep currency-specific summaries or use an explicitly defined conversion convention for a management view. Likewise, separate requested value from approved value and other commercial states. A large pending total is a reason to investigate the workflow; it is not automatically a measure of earned revenue, accounting treatment or cash available.

Preserve the original age through revision cycles

A revision often improves the packet without resolving the request. Preserve the original submission date and record the latest revision date separately. If every resubmission resets the only clock, an old request can repeatedly appear new. The team loses sight of the overall elapsed process and cannot distinguish fresh work from rework on a long-running item.

Link superseded versions to the current request rather than counting each as another open amount. If EC-14 revision two replaces revision one at the same $18,000, the pending backlog should not become $36,000. Retain the historical record and identify which version is current. If a request is genuinely split, document the relationship and reconcile the remaining amount across the resulting records.

Define partial resolution as carefully as full resolution. If an authorized process resolves only part of a request, identify that portion and the unresolved remainder without silently removing the entire row. Keep the decision source and date. Have the responsible commercial team confirm the status so the management report reflects the actual decision rather than a coordinator's assumption.

Prioritize using age, value and the missing decision

Start with requests where a concrete internal action can remove a known obstacle. In the fictional backlog, EC-14's estimator can supply material support; another external reminder cannot substitute for that work. Assign the task, agree when it will be checked and record the source once supplied. A manageable internal correction may unlock review more readily than a broad escalation.

Next examine substantial requests waiting on a formal decision or document. For EC-11, confirm who prepares and issues the formal change and whether any stated prerequisite remains. Preserve the existing instruction and ask a focused question about the next step. Do not describe a proceed instruction as equivalent to final commercial resolution without checking the actual record and authority.

Route disputed scope differently from routine administration. EC-18 may need a comparison of baseline scope and revised work, with the appropriate project representatives involved. Keep the disagreement explicit and preserve the correspondence. An automated nudge can deliver a request for clarification; it cannot decide the contractual interpretation or promise that persistent reminders will secure approval.

Run a weekly review around changes and commitments

Prepare the snapshot before the meeting and ask action owners to update their rows with source links. Begin by reconciling the opening backlog to new items, revised amounts and resolved items. This keeps the meeting from turning into an argument about competing exports. Record the agreed scope and date so participants know which version they are discussing.

Review the largest or oldest unresolved decisions, then the actions due before the next meeting. Ask three questions per item: what changed since the last review, what exact decision is needed now and who will perform the next action? Read back the commitment and its date. If the answer is unknown, assign the task of identifying the correct decision maker.

End with a short action list tied to request identifiers. Record missed commitments factually and investigate whether the underlying blocker changed. Avoid simply moving every due date forward. A useful meeting produces a clearer next action or an explicit escalation path. The purpose of the report is to make decisions easier to coordinate, not to generate another presentation for its own sake.

Automate collection and routing with visible exceptions

Start automation with the repetitive administrative work your team can define clearly: requesting a missing source, collecting a status response, reminding an assigned person or routing a reply to a reviewer. Use the stable request identifier and current revision in the workflow. Stop or change the reminder when the state changes so a resolved item does not keep receiving the old message.

Keep original responses linked to any extracted summary. A message saying “looks fine, awaiting owner” should not automatically become a formally issued change. Route ambiguous responses for human review and preserve the unresolved state. Caltrans' specific force-account process illustrates that record support and payment authorization are distinct steps; it should not be copied as a universal private-project approval rule.

Test failures before scaling. Use a reply from an unexpected person, a bounced address, a duplicate event and an inaccessible attachment. Confirm who sees the exception and how the register is corrected. Buildalytic's custom-workflows offering provides a starting point for mapping follow-up around existing systems. A demo should show the actual routing and review boundaries proposed for your configuration.

Sources: Caltrans Construction Manual: Section 3-9 payment and force-account records; Buildalytic custom workflows

Prove the process on a small live register

Choose a defined set of active requests and reconcile their starting records with the responsible team. For each one, confirm the original submission, current amount, revision, included state, blocker and next action. Keep a snapshot before introducing a new workflow. Otherwise, a cleanup effort may look like a product effect when the team simply corrected the baseline data.

Measure useful process changes: actions with named owners, missing records supplied, receipt confirmations obtained, corrections returned to the preparer and decisions documented with a source. Track coordinator effort if that is part of the business case. Do not promise faster approvals from reminders alone; outcomes also depend on evidence, authority, negotiation and the receiving organization's process.

For a Buildalytic demo, bring a redacted aging export and three contrasting requests: one missing internal support, one awaiting review and one awaiting formal documentation. Ask to map the next action for each, preserve the source response and show what happens when the reply is ambiguous. Confirm the implementation scope and success criteria before expanding to more projects.

Sources: Buildalytic custom workflows