Construction communication software holds the formal record of what was said to whom, when, and what followed. It carries incoming and outgoing correspondence by project, notices required under the contract and whether they were issued in time, meeting minutes and the agreements they record, and the view of the project a client or owner can see without having to ask. With Pentoggle, a contractor can describe its correspondence process and reporting obligations and generate the starting application around them.
This is separate from day to day site communication, which happens on phones and should mostly stay there. The site management guide covers that. This page is about the smaller body of communication that has commercial consequences.
Notice requirements, time limits and their effects are contract specific and are matters for your contracts team or legal advisor. What follows describes the operational practice around them rather than what any contract requires.
Key takeaways
- Many contracts attach time limits to notices, and the operational team that identifies an event is usually not the team that would raise one.
- A minute circulated and not objected to may become the record relied on later, whether or not anybody read it carefully.
- Correspondence loses its value when it cannot be found by subject, which is most of the time.
- A client who can see the project is less likely to need repeated update requests, so visibility can reduce communication load rather than increasing it.
- A useful number is open notifiable events where notice has not yet been issued, aged in days.
The notice period is where entitlements are lost
This is one of the more consequential gaps in construction administration, and it is largely procedural.
Something happens. Access to an area is not given. A drawing arrives late. An instruction changes the work. A client-supplied item does not arrive. The site deals with it, because dealing with things is what sites do. The project manager knows about it and is focused on recovering the programme.
Weeks later, when the commercial consequences are being assembled, somebody raises it as a claim. At that point they discover that the contract required notice within a defined period of the event, that period has passed, and what was a strong position has become a weak one.
The structural reason this happens is that the person who witnesses the event and the person who understands its contractual significance are different people, usually in different offices, communicating through a weekly meeting. A site engineer recording that a work front was not available is not thinking about notice provisions. Nobody has asked them to.
The mechanism that closes it is unremarkable. Certain categories of event, defined once with your contracts team for a given contract, are flagged when recorded at site. A hindrance of a particular type, an instruction received verbally, a client-supplied item overdue. The flag routes to whoever handles contractual correspondence, with the date of the event attached and the remaining time visible.
That converts a knowledge problem into a workflow. The site does not need to understand notice provisions. It needs to record what happened, which it is already doing in the daily report and the hindrance record. What is missing is the connection between that record and the person who can act on it while there is still time.
Minutes can become the record by default
Meeting minutes are often circulated by whoever ran the meeting, which on many projects is the client's consultant or project manager, and under some project arrangements they may become an important record if no correction is raised within the applicable period.
Many contractors do not read them with the attention that deserves. The meeting was attended, everyone knows what was discussed, and the minutes arrive among forty other emails.
The risk is specific. A minute may record that the contractor confirmed no delay to the programme, or accepted responsibility for a defect, or agreed to absorb a cost, in a phrasing nobody in the room would have chosen. That is not usually bad faith. It is one person's summary written quickly. But an uncorrected minute is a document the other side will produce later, and correcting it two months on looks like revisionism.
The practice that protects against this is simply reading them against your own record of the meeting and responding in writing to anything mischaracterised, within whatever period applies. It takes twenty minutes and it is almost never done consistently, because nobody owns it.
Holding minutes in a register with a review status and a response deadline makes it somebody's task rather than everybody's assumption. Where your own notes of the meeting sit alongside, the comparison takes minutes rather than requiring recall.
Correspondence you cannot find is correspondence you do not have
A project can generate hundreds of letters, emails and transmittals. On a dispute, or at final account, or when a question surfaces about what was agreed in month four, that body of correspondence is the evidence.
In practice it is unusable. It sits across several people's inboxes, organised by date and sender rather than by subject, with attachments detached from the messages that carried them. Finding everything relating to one issue means asking four people to search their mail, which produces an incomplete set assembled over a week.
A correspondence register is an old idea and it survives because it works. Reference number, date, direction, party, subject, what it responds to, whether a response is required and by when. Held that way, the entire history of an issue is one query, and the ones awaiting a reply are a list rather than a memory.
The part many contractors skip is the response tracking, which is where the operational value sits. A letter sent and left unanswered is a common and consequential thing. Where it is visible as outstanding, it can be followed up or escalated. Where it is not, it becomes a grievance produced during a dispute, which is much less useful than a reply obtained at the time.
A client who can see asks for less
The instinct on many projects is to control what the client sees, on the reasoning that more information invites more questions.
In many projects, the opposite can be true, and it holds across owner types from individual homeowners to institutional clients.
A client without information asks for it. They call, they request reports, they visit, and each interaction consumes somebody senior. A client with a standing view of progress, what is pending with them, and what is coming next, is less likely to need repeated update requests, because the questions they would have asked are already answered.
The second effect matters more. A client who can see what is pending on their own side tends to act on it. Approvals and decisions sitting with a client are usually not being withheld deliberately, they are simply not visible to whoever needs to move them. A list showing what is with them and how long it has been there produces movement without anybody having to make it a confrontation, which is a considerably better dynamic than the alternative.
There is a real caution attached. Visibility only helps where the underlying information is accurate. A client-facing view built on optimistic progress reporting or an incomplete pending list creates a much worse problem than opacity, because it converts a private inaccuracy into a published one. The progress tracking guide covers why self-reported progress drifts, and that has to be sound before anything is exposed.
What communication software holds
The correspondence register
Incoming and outgoing by project, with reference, subject, party, what it responds to, and whether a reply is outstanding.
Notifiable events
Categories of event that carry a notice requirement under the contract, flagged when recorded, with the time remaining.
Notices issued
What was served, when, in respect of which event, and how.
Meeting minutes
Held with attendance, actions, review status and any response issued to what they record.
Instructions received
Verbal and written instructions logged and confirmed, connecting to the variation process.
The client-facing view
Progress, what is pending with the client, and what is coming, presented without needing assembly.
Escalation
Items raised beyond their normal level, with when and to whom.
The project history
The whole record of an issue retrievable by subject rather than by date.
Where communication looks different by business type
- Home Builder Software, where the client is an individual and the update is close to being part of the product.
- PMC Software, where the practice is usually the party writing the minutes rather than reviewing them.
- General Contractor Software, where correspondence runs in two directions at once, upward to the client and downward to subcontractors.
- Infrastructure and Road Contractor Software, where obstructions outside the contractor's control make notice discipline commercially significant.
- Interior Fit-Out Contractor Software, where programmes are short enough that a slow response is itself the delay.
Why contractors choose Pentoggle for communication
Events flagged when they are recorded
Site records what happened, and anything notifiable routes to whoever handles it, with time remaining.
Correspondence findable by subject
The full history of an issue as one query rather than four inboxes.
Replies tracked as outstanding
Letters awaiting a response visible while following up is still useful.
Minutes with a review deadline
Somebody's task rather than everybody's assumption.
A client view built from real records
Progress and pending items shown from what was captured, not compiled by hand.
A useful number for project communication
Open notifiable events where notice has not yet been issued, aged in days.
It is a short list on a well run project and it is worth more than almost anything else on a status report, because every item on it is a position that is currently strong and may not be next week.
Review it whenever it changes rather than weekly, since the whole value is acting inside a window. An item aged three days is routine administration. The same item aged thirty may be nothing at all or may be an entitlement already gone, and which of those it is depends on the contract rather than on the number.
Read it alongside the hindrance and instruction records it comes from, because the flagging is only as good as what site recorded. An empty list on a project that has clearly suffered obstruction usually means events are not being categorised rather than that nothing happened.
What counts as notifiable, what the time limits are and what follows from missing them are contract questions for your contracts team. The software contribution is narrow: making sure the event reaches them while the answer still matters.
Ready to build communication software?
The strongest case you will ever make is the one you wrote down on the day it happened.