Construction quality software holds what has to be checked, when, by whom, and what happened when it was. It carries inspection and test plans, stage checklists, hold and witness points and the notifications they require, test results tied to the work they cover, non-conformances with their disposition and closure, and snag lists through handover. With Pentoggle, a contractor can describe its specifications, inspection stages and approval chains and generate the starting application around them.
Inspection regimes, test frequencies and acceptance criteria come from the specification and differ by client, contract and type of work, so build around what your own contracts require.
Many contractors already run Tally for accounting and job costing and hold specifications as documents. Those tools do not provide the operational quality record of which pour passed, which non-conformance is still open, or how many snags remain in a particular area.
Key takeaways
- A hold point is only real if the work can actually be stopped, which usually depends on notification lead time rather than on the checklist.
- Rework is invisible in most systems because it gets recorded as ordinary production, so quality failures show up as low productivity instead.
- A non-conformance accepted as it stands can be a commercial decision, and the decision should be recorded as one.
- Snags closed without evidence are more likely to be reopened, adding another cycle to the handover process.
- A useful number is the share of inspections passed at first offering, by trade and by crew.
What the checklist file and the site engineer do well, and where they stop
Quality on Indian sites is generally understood better than it is documented. Experienced engineers know what to check before a pour, what a good bar arrangement looks like, and which subcontractor needs watching. Checklists exist, formats are prescribed, and on well run sites they are used.
The limits are in what survives and what can be seen across a project.
Records are filed by type, not by work.
Cube results are in one register, checklists in another, test certificates in a third. Assembling what covers a specific pour means opening all three, which is why nobody does it until an auditor asks.
Open items have no aggregate.
How many non-conformances are open across a site, how long the oldest has been open, and which trade generates most of them are questions the paper cannot answer.
Closure is asserted.
A snag marked closed on a list is closed because somebody wrote that. When the consultant walks the area again and disagrees, the item reopens and the cycle repeats.
Rework leaves no record.
Work redone is done again by the same crew and reported as production. Nothing distinguishes the second attempt from the first.
What quality software holds
Inspection and test plans
What gets checked at which stage, by whom, and which points require notification or attendance.
Stage checklists
Checks completed before a stage proceeds, with the person, the date and photographs where useful.
Hold and witness points
Points requiring inspection before work continues, with notification issued, response received and the resulting release.
Test records tied to work
Cube results, material tests and field tests held against the specific pour, batch or area they cover.
Non-conformances
Raised with description and location, dispositioned as rework, repair, acceptance or rejection, and closed with evidence.
Snag lists
Observations by area, trade and raiser, tracked to closure with photographs, through to handover.
Rework recorded as rework
Work redone identified as such rather than reported as fresh production.
The evidence package
Records assembled against the work they belong to so a handover file is a query rather than a search.
A hold point only works if the work can actually stop
An inspection and test plan defines hold points, where work must not proceed until an inspection has taken place, and witness points, where the inspection is offered and work may continue if nobody attends. This is a sound structure and it is the backbone of construction quality.
It breaks at a specific place. A hold point before a slab pour requires the client's engineer or the consultant to attend. That person may be responsible for four sites, may be an hour away, and may be attending something else. The pour has concrete ordered, labour mobilised and a pump on hire. The cost of waiting is immediate and visible. The cost of proceeding is a risk that may never materialise.
So the pour proceeds, and the checklist is signed afterwards, and everybody involved understands what happened. This is not corruption or negligence. It is a system whose design assumes an availability that does not exist.
Which means the real design question is not the checklist but the notification. How much warning does the inspector get, how is it delivered, and is there a record of when it was given. A notification issued the previous evening, received and acknowledged, changes the situation entirely: either the inspector attends, or the contractor has a documented offer and can proceed under the witness point provisions the contract may allow.
That is a small mechanism and it addresses the actual failure. Notification with a timestamp, an acknowledgement, and a record of attendance or non-attendance, gives the hold point back its force without requiring anybody to be in two places. What your contract permits when an inspection is not attended is a matter for your contracts team, and the record is what makes any such provision usable.
Rework is invisible because nobody codes it
A wall is built badly and taken down. A screed is laid to the wrong level and redone. A finish is rejected and reapplied.
In many construction reporting systems, both attempts are recorded identically. The crew was deployed, the work was executed, the quantity was produced. Nothing in the labour record or the material consumption says that the second occurrence was a repeat.
This has two consequences and both distort the picture.
Quality failures appear as productivity problems. A trade with a rework problem shows low output per person-day and higher than theoretical material consumption, and gets treated as a productivity or a pilferage question. The actual cause is that a proportion of the work is being done twice.
And the cost of poor quality is rarely known. Rework consumes labour and materials, yet many contractors cannot readily state what it cost them last year, which means it seldom competes for attention against costs that are measured.
The fix is a single field. When work is executed, whether it is first execution or rework, and against which non-conformance or observation. That one distinction turns two invisible problems into two visible ones, and it costs a tick box at the point of entry.
It also tells you something more useful than a total. Rework concentrated in one trade is a capability question. Rework concentrated in one crew is a supervision question. Rework concentrated after a particular design change is a coordination question. The response differs completely and the total tells you none of it.
An acceptance is a commercial decision that gets made verbally
When a non-conformance is raised, the outcomes are broadly to redo the work, to repair it, to reject it, or to accept it as it stands.
That last option can be appropriate where the relevant parties agree to accept the deviation. Work that deviates from specification is frequently accepted because the deviation does not matter functionally, or because correcting it costs more than it is worth, or because everybody is under time pressure. In many cases the client agrees.
The problem is that this decision often happens in conversation. An engineer looks at it, says it is acceptable, and work proceeds. Nothing records who accepted what, on what basis, or whether they had the authority to.
The exposure surfaces later. At handover, when a different representative sees the same deviation and does not accept it. During the defect liability period, if something related fails. Or in a final account discussion where a concession granted informally is remembered as a defect tolerated.
Recording dispositions is therefore not bureaucracy. A non-conformance closed as accepted, with who accepted it and when, is a decision on the record and it protects both sides. It also produces a useful pattern, because a project generating many acceptances is telling you either that the specification is unrealistic for how the work is being done, or that quality is drifting and being absorbed rather than corrected.
Snag lists are where projects end slowly
Handover generates a list, then more lists. Area by area, trade by trade, raised by the client, the consultant and the contractor's own team, running to hundreds or thousands of items on a large project.
The list is not the problem. The cycle is. An item is raised, work is done, the item is marked closed, the consultant walks the area and disagrees, the item reopens. Each loop takes days and consumes people who are trying to finish a project, and retention, handover and final payment usually wait on it.
Two mechanics shorten it considerably.
Evidence at closure. A photograph attached when the item is marked closed changes the conversation from an assertion to something reviewable. Evidence at closure makes the work reviewable without requiring another site walk and can reduce unnecessary reopenings.
Structure at raising. Items recorded against a specific area, trade and responsible party can be routed and grouped, so a subcontractor receives their fifty items rather than a list of eight hundred to search through. The same list also shows which trade is generating them, which is worth knowing before the next project.
The pattern to watch is the rate of raising against the rate of closing. Where closure outpaces raising the list is converging and a handover date can be estimated. Where raising continues at pace late in the process, either the work is not ready or the standard is being applied inconsistently, and those need different responses.
Where quality looks different by business type
- Industrial Construction Software, where documentation is heavier and handover depends on a complete records package.
- Facade Contractor Software, where quality checks happen in a factory before dispatch as well as on site.
- Waterproofing Contractor Software, where acceptance of the substrate before starting is as important as inspection of the work itself.
- Infrastructure and Road Contractor Software, where testing frequency follows quantity and each layer covers the last.
- Interior Fit-Out Contractor Software, where visual appearance can be a significant part of acceptance alongside dimensional, functional and specification requirements.
Why contractors choose Pentoggle for quality management
Notification that gives hold points force
Inspections offered with a timestamp and an acknowledgement, which is where the system actually fails.
Records tied to the work
Test results and checklists held against the pour or area they cover rather than filed by type.
Rework identified as rework
One field that stops quality failures from being read as productivity problems.
Snags closed with evidence
Photographs on closure, which is what stops items reopening.
Dispositions on the record
Acceptances recorded with who granted them, because they are commercial decisions.
A useful number for quality management
The share of inspections passed at first offering, by trade and by crew.
Most quality reporting counts failures. This counts whether work is being done right the first time, which is the thing that actually determines cost, and it moves early enough to act on.
Read it by crew rather than by project. First-time pass rate is a habit and it varies between teams far more than between sites, so a crew consistently below the others is a supervision or training conversation with a specific person rather than a general exhortation about quality.
Two cautions. It can be improved by not offering inspection until success is certain, which is not entirely a bad thing but does inflate the figure. And it depends on failed inspections being recorded rather than corrected informally on the spot, which is a culture question more than a system one. A site where a failed check is treated as information will produce a useful number. A site where it is treated as a black mark will produce a perfect one that means nothing.
Ready to build quality management software?
Everybody has the checklist. The question is whether anyone could stop the pour.