What happens between the appointments
The ordinary day is organised around dependencies that are rarely visible together. A vehicle waits for a part. A maintenance team waits for access. A project coordinator waits for a drawing to be accepted before booking the next technical visit. Each party may be busy and each local schedule may look reasonable. The delay belongs to the relationship between them. A waiting-time ledger is a proposed way of recording that relationship: what is waiting, what would allow it to move, who can provide that condition and what is affected meanwhile.
The ledger begins when work cannot advance, not when someone decides that the delay has become serious. It distinguishes planned waiting from an unresolved blockage. A surface treatment may need an intentional settling period; a team may be waiting because an access instruction is missing. Both consume elapsed time, but only one is an information failure. Treating all waiting as waste encourages rushed sequences. Treating all waiting as inevitable prevents the organisation from seeing which intervals can actually be shortened through better preparation.
Record a condition, not a complaint
An entry such as awaiting response is too vague to help the next person. A useful entry states the decision or material required, the request date, the receiving owner and the next review point. It also identifies the work that cannot proceed. This is deliberately narrower than a general issue log. The record exists to resolve a blocked sequence. Once the condition is met, the entry closes with the evidence that allowed work to resume. If the task is abandoned, that is a different closure reason and should remain visible.
The consequence matters as much as the duration. A short delay can prevent a coordinated visit involving several teams. A longer delay may have little immediate effect if it sits outside the current operating window. The ledger should therefore connect each waiting state to the schedule or service promise it affects. This supports sensible prioritisation. It also prevents a dashboard from rewarding the closure of many easy items while a small number of consequential dependencies continue to block the work that users actually notice.
Follow the handoff across organisations
In the Meridian model, an inspection can identify a condition without being able to determine the date of the response. Planning may depend on access, classification, equipment and coordination with other work. The proposed ledger would follow those dependencies without assigning every interval to the inspection team. That matters because a local productivity measure can otherwise encourage the wrong improvement. More inspections are not automatically useful if the unresolved planning queue grows and the operating team cannot distinguish urgent findings from those that can wait.
For Verdan, the equivalent sequence may involve a technical study, an amended drawing and acceptance of a project boundary. The work product moves between people with different responsibilities. A handoff is complete only when the receiving party has what they need to act. Recording a sent email as completion hides the possibility that the package lacked a required view or decision. The ledger should be able to reopen the dependency with a reason, while preserving the first handoff. That makes rework visible without turning the record into an argument about who sent what first.
Read the ledger as a pattern
The review should retain reopened entries. A dependency that appears resolved and then blocks work again often points to an incomplete acceptance rule, rather than a separate delay that deserves a new identifier.
A monthly review should look for recurring types of waiting rather than rank individuals by blocked hours. Repeated parts delays may point to a purchasing threshold, a catalogue mismatch or an inaccurate stock record. Repeated access delays may require clearer preparation instructions. A sequence of late design decisions may indicate that the review is scheduled after downstream work has already been committed. Each explanation implies a different change. The ledger is useful because it preserves enough context to test these explanations against actual cases.
The next step would be a limited trial across one operating sequence, with a small set of agreed states and a weekly review of ambiguous entries. No portfolio-wide reduction in waiting time is asserted in this note. The aim is to establish whether the record helps teams resolve a real dependency sooner and whether its maintenance is proportionate to that benefit. A credible result may be modest: fewer repeated requests, a clearer acceptance point or one recurring delay removed. Everyday efficiency often arrives through exactly that kind of correction.
Sources and data notes
- PTD Capital LLC — Meridian Road Services — current operating file2026 · Primary project record for inspection, intervention classification and aged-queue workstreams. The waiting-time ledger is a proposal in this article, not a reported implementation.