Defect Management: Overview

About Defect Management

Defect management is the recording, delegation and close-out of things that are wrong with built work: a scratched window, a missing fire stop, a door that does not close, a cracked tile. Each defect is recorded once, assigned to whoever has to fix it, given a deadline, fixed, checked and closed. The list of open defects at any moment is the snagging list.

It is the most common use of PlanRadar, and the one the ticket was designed for: a photo, a position on the plan, a responsible person, a deadline and a status.

Where Defects Come From

Defects are recorded at a few typical points in a project, and the process is the same for all of them:

• During construction, by the site manager walking the site or by a trade reporting a problem caused by another trade.
• Before handover, in a pre-handover inspection by the general contractor, often trade by trade.
• At handover, in the acceptance inspection with the client, architect or owner. The result is a formal defect list that the contractor has to work through before final acceptance.
• After handover, within the defects liability period, when the owner or facility manager reports a defect the contractor is still responsible for.

Terminology

The same process has many names, and the name often tells you which market and which contract form you are in.

Whichever term your contract uses, the record has to answer the same questions: what is wrong, where exactly, who has to fix it, by when, and proof that it was fixed.

What PlanRadar Covers

A defect in PlanRadar is a ticket. The ticket carries the description and photos, the position on the plan, the responsible subcontractor as assignee, a due date, a priority and a status. Everyone involved sees the same ticket on the Webapp and on the mobile app, and every change is recorded in the ticket journal.

PlanRadar does not come with a fixed defect process or a fixed defect form. You decide which fields a defect has, which trades and severities exist in your lists, who is allowed to set which status, and what a subcontractor has to provide before a defect counts as fixed. The process can therefore follow your contract and your company standard rather than the other way round.

What PlanRadar does not decide for you is what counts as a defect, who is contractually responsible and which deadline applies. Those come from your contract. PlanRadar records the defect, gets it to the right person, tracks the deadline and keeps the proof.

Roles and Workflow

Roles

Defect management involves four roles. Small companies combine them in one or two people, larger ones split them further. The split below is the one used throughout these articles.

At handover a fifth party often takes part: the client, the architect or the owner's representative who inspects and signs the defect list. They can be a watcher who sees all defects without editing them, or an in-house user who records defects themselves and signs off the list. Read more in User Types and Permissions.

Subcontractors are free of charge in PlanRadar. They see only the tickets assigned to them or to a group they belong to. They can change status and progress, write comments and add photos, and they can set a ticket to Resolved but not to Closed. They cannot create tickets and they cannot edit other fields. If a trade has to record defects themselves, they need an in-house user. Read more in User Types.

Workflow

The process runs in four stages: set up, record, resolve, close. A defect that fails its check loops back through resolve until it passes.

1. Set up. The project manager creates the defect form, the trade and severity lists, the roles and the field permissions once, on account level, and assigns them to each project.
2. Record. The site manager creates a ticket on the plan, takes a photo, picks the trade, sets the assignee, the priority and the due date. The subcontractor receives an email and a push notification.
3. Resolve. The subcontractor fixes the defect, uploads a photo of the result and sets the status to Resolved. If they dispute the defect, they write a comment and set the status to Rejected.
4. Close. The site manager checks the fix, on site or from the photo, and sets the status to Closed. If the fix is not acceptable the status goes back to In Progress with a comment. Reports of open and closed defects go to the subcontractors and to the client.

Each stage is explained step by step in Defect Management: Workflows in PlanRadar.

The Example in These Articles

The example is a general contractor finishing a residential building with twelve apartments. Before handover to the developer, the site manager inspects each apartment and records defects against six trades: drywall, painting, flooring, electrical, plumbing and windows. Each trade is a separate subcontractor company with its own PlanRadar users. The developer's representative takes part in the final acceptance inspection and receives the defect list as a PDF.

The example uses one form named Defect for all trades, one plan per floor, and the standard six ticket statuses. Wherever a decision could reasonably be made another way, a short note points out the alternative.

Planning Your Defect Management Setup

The form itself takes twenty minutes to build. The decisions below take longer, and getting them wrong shows up months later, when someone asks how many defects the painting subcontractor had in building B and nobody can answer. Make these decisions before you build the form.

One Form for All Trades or One per Trade?

Forms are created on account level and assigned to one or more projects, so one form can serve every project of the same kind.

If you do need several forms, use shared fields for the fields you report on across all of them: trade, severity, location, cause. A shared field is defined once for the account and appears as a single column in reports and exports. Read more in Create & Manage Shared Fields.

Which Lists Do You Need?

Every value you want to filter, count or chart has to be a list field, not free text. Three lists cover most defect processes:

• Trade. Which trade is responsible. Drywall, painting, flooring, electrical, plumbing, windows. This is the list you will filter on most, because defect reports go out per subcontractor.
• Severity or category. How serious the defect is and what it means for acceptance. A common three-step list: Minor (cosmetic, does not block handover), Major (must be fixed before handover), Critical (safety or function, work stops). Some companies use the built-in Priority field for this instead and skip the list.
• Cause. Optional. Workmanship, damage by another trade, design, material. Only worth having if you use it to settle who pays.

A list is defined once on account level and can be used by several forms. Keep the values short and stable. Renaming a value later is possible, but deleting one leaves existing tickets with a value that no longer exists in the list. Read more in Create & Edit Lists.

How Do You Record Where the Defect Is?

Location is the field that decides whether the subcontractor finds the defect in two minutes or twenty. PlanRadar offers three ways, and they can be combined:

• Plan position. The ticket is pinned on the floor plan. This is the standard for defects and the reason most customers use PlanRadar. Upload one plan per floor or per apartment. Read more in Set, Change or Delete the Plan Position of a Ticket.
• Layers. Plans are organised in layers, for example one layer per building or per floor. The layer gives you the coarse location for filtering and reports without an extra field. Read more in Layers.
• A Location list or text field. Room number, apartment number or element. Use a list where the values are known in advance, for example the twelve apartments in the example. Use text only where they are not.

Where a plan is available, use the plan position and skip the location field. Where work is recorded before plans exist, or on sites without plans, use the list.

Who Sets Which Status?

PlanRadar has six ticket statuses: Open, In Progress, Resolved, Feedback, Rejected and Closed. They cannot be renamed or extended, so the process has to be mapped onto them. The mapping used in the example is the most common one:

The decision that matters is who may set Closed. If the person who fixes a defect can also close it, you have no check and no proof. For subcontractors PlanRadar enforces this: a subcontractor user can set Resolved but never Closed. If your trades work with in-house users instead, give their role the ticket edit permission "All tickets, but only the ticket author can set the status to closed", which has the same effect. Read more in Set Status & Progress of a Ticket and Permissions.

What Must the Subcontractor Provide Before a Defect Counts as Fixed?

Without a rule, a subcontractor sets Resolved and the site manager walks to the apartment to find nothing was done. Decide what proof is required and how you check for it:

• A photo of the fixed work. Add an attachment field named Proof of completion to the form. Custom attachment fields are the one kind of field a subcontractor can fill, so they upload the photo there and the site manager sees at a glance whether proof exists. Keep the field optional on the form, because a mandatory field would also block the site manager when recording the defect. Use the Ticket Completeness Agent or a saved filter to catch Resolved tickets without a photo.
• A short note where a photo does not prove anything, for example a re-torqued connection. Subcontractors cannot edit text fields, so the note goes into a comment.
• Where the check is contractually required on site, for example for anything that will be covered by follow-on work, no photo replaces it. Plan the re-inspection.

Whatever you require, require it on every defect. A rule that is applied to some subcontractors and not others is not a rule. Read more in Edit Field Permissions.

Deadlines

The due date on the ticket is the contractual deadline to remedy. Decide how it is set:

• By severity: Critical 24 hours, Major 5 working days, Minor before handover. The site manager sets it on creation.
• By trade or contract: some subcontracts fix a remedy period. The site manager applies it.
• By inspection: all defects from one inspection get the same deadline, for example the date of the re-inspection.

The assignee receives reminder emails before and on the due date, and overdue tickets are marked in every list. Filter on overdue tickets per subcontractor for the weekly site meeting. Read more in Set a Due Date or Extension Date for a Ticket and Configure E-Mail Notifications.

What Should Subcontractors See?

A subcontractor should see their own defects and nothing else. The standard subcontractor role does this: view tickets assigned to the user or a group they belong to, edit those tickets. Two decisions on top:

• Assign to a user group per subcontractor company rather than to one person, so that anyone in that company can pick up the defect and a change of foreman does not orphan the tickets. Read more in Create & Manage Groups.
• Decide who records defects. Subcontractor users cannot create tickets, so on most sites the defect list stays with the site manager, which is usually what you want. If a trade has to report damage caused by another trade, they either report it to the site manager or they get an in-house user with a role that can create tickets and view only their own.

Numbering

Enable the numbering sequence on the form so that every defect gets a running number such as D-1, D-2, D-3 in addition to the ticket ID. Defects are referred to by number in site meetings, in the acceptance record and in correspondence with the subcontractor, and the sequence gives you a stable reference that survives filtering and reassignment. Read more in Edit Form Settings.

What to Avoid

• A form per project. One form, assigned to every project.
• Trade in the title instead of in a list field. "Painting: scratched door frame" cannot be counted. A Trade list can.
• Letting subcontractors close their own defects.
• Recording several defects in one ticket. One defect, one ticket, one assignee, one status. A ticket with "5 defects in bathroom" cannot be assigned to two trades, half closed or counted.
• Photos without a plan position. The photo shows what is wrong. The plan position shows where. The subcontractor needs both.
• Mandatory fields nobody looks at. If the proof photo is never checked, it costs the subcontractor time and buys you nothing.

AI Support for Defect Management

AI features take repetitive steps out of recording and closing defects. They do not decide what is a defect or whether a fix is acceptable.

An AI agent only ever creates a ticket, a comment or an email. It cannot change, close or delete a defect. It reacts to events in one project and runs with the permissions of the person who created it. Read more in Create & Manage Your AI Agents.

Steps to Manage Defects in PlanRadar

Defect Management: Workflows in PlanRadar explains each stage: set up the form, lists and roles in the office, record and assign defects on site, resolve and prove the fix, check and close, and produce the defect lists for subcontractors and client.

Additional Possibilities

• Record defects on a 360° image of a SiteView run, so the subcontractor sees the defect in its surroundings. Read more in Add Tickets to 360° Images in the Webapp.
• Record defects offline. The mobile app stores defects and photos without signal and syncs when back online. Read more in Working Offline.
• Sign the defect list at the acceptance inspection. A signature on the ticket locks it together with who signed and when. Read more in Sign a Ticket.
• Have the client or architect formally accept the closed defects with ticket approvals. Read more in Approvals.
• Send each subcontractor their open defects as a PDF, the Mängelanzeige, and the client the full list as PDF or Excel. Read more in Ticket Reports.
• Track open, overdue and closed defects per trade, per building and per project in Statistics. Read more in Statistics.
• Carry defects found after handover into warranty management with the same form.
• Automate the weekly defect report to each subcontractor with PlanRadar Connect or the Open APIs.