How to Document Snags So They Can't Be Dismissed

To document snags so they cannot be dismissed, you need four things on every single defect: a clear photo, the date you found it, the exact location, and a plain description - then you compile the lot into one tidy, dated PDF and send it in a way that creates a record. That is the whole game. A developer can argue with a vague complaint and quietly let it slide to the bottom of the pile, but a numbered, photographed, dated list is hard to wave off and easy for a customer care team to action. Good documentation is not busywork - it is the single biggest lever you have for getting snags actually fixed, and it is what every escalation route later runs on.

This guide is the practical method. It walks through photographing each snag properly, capturing the date, pinning the exact location, describing defects consistently, numbering and grouping them, tracking their status, and pulling everything into one clean report you can stand behind. It pairs naturally with how to get your developer to actually fix your snags (what to do with the report) and your new build rights (where you stand if it comes to escalation).

Why documentation is the lever that gets snags fixed

Before the how, it is worth being clear on the why, because it changes how carefully you do this. You are entitled to have genuine defects in a new build put right, at no cost, during the builder period. But that right only turns into a fix if you can show what was wrong, where it was, and when you found it. The right exists on paper. Documentation is what makes it real.

There are two reasons evidence matters so much:

• It gets your list actioned faster. A developer's customer care team is juggling a backlog. A clear, itemised, photographed list is easy to schedule trades against, so it gets dealt with. A rambling email of complaints gets deprioritised because nobody can tell exactly what needs doing or where.
• It wins escalations. If the developer goes quiet and you have to escalate - their formal complaints process, your warranty provider's resolution service, the New Homes Ombudsman - every one of those routes decides on evidence. A dated, photographic, itemised record is exactly what they want to see. A vague verbal complaint gives them nothing to act on.

Evidence is also your protection against the most common pushback: a developer suggesting you caused the damage yourself after moving in. A photo dated within days of getting the keys settles that argument before it starts. That is why you document from day one, and why you never start fixing things yourself - a self-attempted repair muddies who was responsible.

Photograph each snag properly

Photos are the heart of the record. A good snagging photo does two jobs that one shot usually cannot: it proves the defect exists and it shows where it is. So for each snag, take two photos.

A wide shot for location and a close-up for detail

• The wide shot captures the whole wall, the whole window, the corner of the room - enough context that anyone looking can see exactly where the defect is. This is the photo that stops a developer asking "which window?"
• The close-up captures the defect itself in detail - the scratch, the chip, the gap, the bad caulk line, the paint run. Get close enough that the problem is obvious without anyone needing it pointed out.

Take the wide shot first, then move in for the close-up, so the pair reads as "here is the area, and here is the problem within it."

Include something for scale

A scratch in a close-up photo could be 5mm or 50mm - the camera cannot tell. For anything where size matters, put something in the frame for scale: a coin, a tape measure, a ruler, even a finger near (not on) the defect. It instantly communicates how big the problem is and stops a developer downplaying it as trivial.

Get the lighting right

Many real defects only show up in the right light. Poor finishing, dents in plaster, roller marks, marks under gloss paint and uneven surfaces often disappear under flat overhead light and reveal themselves under raking light from the side.

• Shoot in good light. Natural daylight is best where you have it.
• For surface defects, use a torch (your phone torch is fine) held at a shallow angle across the surface to throw the flaw into relief, then photograph it.
• Avoid harsh flash bouncing straight back off glossy surfaces - it washes detail out. Angle yourself or the light instead.
• If a defect genuinely only shows in certain light, capture it both ways so there is no doubt it is real.

Capture the date

The date is the quiet hero of snag documentation. It is what proves a defect existed at or near handover rather than being something you caused later, and it is what underpins any escalation, because every code and warranty route works on timelines and deadlines.

Two practical points:

• Record the date you found each snag, not just the date you sent the list. If you snag over a few days, or spot new items weeks after moving in, the find date on each one matters.
• Make the date verifiable. A date you typed into a document is weaker than a date baked into the evidence. Photos carry a timestamp in their metadata, and an email creates an undeniable dated record of when you reported. Reporting in writing soon after you find things is the cleanest way to lock the timeline in.

The earlier your dated evidence, the stronger your position. Snagging promptly - ideally before completion where you can, and certainly in the first days and weeks after moving in - means your record predates any chance of "you must have done that yourself."

Record the exact location

"There is a scratch in the lounge" sends a tradesperson hunting. "Deep scratch on the windowsill, lounge, left-hand window, near the catch" sends them straight to it. Precise location does two things: it gets the right defect fixed without a wasted visit, and it removes any wiggle room for a developer to claim they could not find the problem.

For each snag, record:

• The room - and be specific where a house has two of something (en-suite vs main bathroom, bedroom 2 vs bedroom 3).
• Where in the room - which wall, which window, high or low, left or right, near which fixture. Describe it as if directing someone who has never been in the house.

Pin it on a floor plan

The cleanest way to record location is to pin each snag on a floor plan of the home. A pinned plan turns a written description into a picture anyone can read at a glance, leaves zero ambiguity about where each item is, and looks professional in the finished report. It is especially useful when you have several snags in one room - the pins show exactly which is which. If you have the developer's floor plan from your purchase pack, that is ideal. A simple sketch works too. The point is a visual map of where every defect sits.

Describe each snag clearly and consistently

A description has one job: to make the defect unmistakable to someone who is not standing where you are. Keep each one plain, specific and consistent.

• Be specific, not emotional. "Deep scratch across the kitchen worktop, roughly 15cm, to the right of the sink" beats "worktop ruined" every time. State the defect, where it is, and its size or extent.
• Describe what is wrong, factually. Avoid guessing at causes or assigning blame in the description - "gap between skirting and floor, approx 8mm, along the east wall" is stronger than "they didn't fit the skirting properly."
• Stay consistent. Use the same style and the same room names throughout. A list where every entry follows the same pattern reads as careful and credible, which matters when a customer care team or an Ombudsman is forming an impression of you.
• One defect per item. Do not bundle three problems into one line. Separate items can be tracked, referenced and signed off individually.

Good descriptions work hand in hand with your photos. The photo proves it; the words pinpoint and size it. Together they leave nothing to interpret.

Number and group your snags

Once you have your defects captured, organise them so the list is easy to navigate and easy to refer back to.

• Number every snag. Numbering lets you and the developer talk about "snag 14" instead of re-describing it each time. It makes chase emails crisp ("snags 3, 7 and 12 remain outstanding") and makes sign-off precise.
• Group by room. Walk the report room by room. It mirrors how trades work (they fix a room while they are in it), makes nothing easy to overlook, and helps the developer schedule efficiently.
• Keep the numbering stable. Once a snag has a number, it keeps that number even after it is fixed. Do not renumber as items close, or your paper trail stops lining up with earlier emails.

This structure is not cosmetic. A numbered, room-grouped list is the difference between a document a customer care team can work straight off and a wall of text someone has to decode.

Track each snag's status

A snag list is a living document, not a one-off email. From the moment you send it, things start changing: items get acknowledged, scheduled, fixed, or fixed badly and reopened. Tracking status keeps you on top of what is actually outstanding and gives you a clean record of how the developer has performed.

A simple status on each item does the job:

• Open - reported, not yet resolved.
• In progress - acknowledged or scheduled.
• Fixed - completed and, crucially, re-checked by you.

Two habits make this powerful. First, re-check every "fixed" item yourself before you mark it closed - it is common for a repair to be incomplete or to create a fresh snag, so never sign anything off until you are genuinely happy. Second, keep one current version of the list rather than scattering updates across messages, so there is always a single snapshot of exactly what is still open. When you chase or escalate, that live status is what shows precisely where things stalled and for how long.

Compile one clean PDF report

All your captured snags should end up as a single, tidy, dated document - and a PDF is the standard format because it is easy to send, easy to file, looks professional and is hard to argue with. One clean PDF does three jobs at once: it makes the developer's customer care team's life easy so your list gets actioned faster, it is the exact format an Ombudsman or warranty resolution service wants if you escalate, and it timestamps your evidence so nobody can later claim a defect was not there at handover.

A good snag report contains:

• A cover/header with your name, the property address and the date.
• A numbered list of snags, grouped by room.
• For each snag: the number, a plain description, the location (room and where in the room), the date found, and the photos (wide plus close-up).
• A floor plan with pinned locations, where you have one.
• A status against each item, so the current state is clear at a glance.

You can build this by hand in a document or spreadsheet, dropping in photos and typing up each entry. It works, but it is slow and fiddly to keep updated as items get fixed. The alternative is to capture everything in a purpose-built tool as you walk the house and export the finished report in one tap.

Send it the right way and keep a copy

Documentation only protects you if it creates a record, so how you send the report matters as much as the report itself.

• Send it in writing. Email or the developer's customer portal, never by phone alone. A phone call you cannot later prove is worth almost nothing if things go wrong. Written reporting gives you a timestamped, undeniable record of what you reported and when.
• Send it to the right place. The developer's customer service or aftercare team, not just the site manager. The care team is set up to log and track defects; lists handed to a site manager get misplaced and that person may have moved on by next month.
• Keep your own copy of everything - the PDF, the email you sent it with, and every reply. This is your audit trail.
• Keep one running thread. Reply on the same email chain each time rather than starting fresh, and re-send the updated PDF as items are fixed or new ones appear, with closed items marked. That way the whole history sits in one place and there is always a single current snapshot.

What you do next - deadlines, chasing, and escalation if they go quiet - is covered in full in how to get your developer to actually fix your snags.

Common mistakes that weaken your evidence

A few habits quietly undermine an otherwise solid record. Avoid these:

• One photo per snag. A single shot rarely proves both the defect and its location. Always take the wide shot and the close-up.
• No scale on size-dependent defects. Without a reference, a developer can downplay a real flaw as trivial. Put a coin or tape in the frame.
• Vague descriptions. "Bathroom not right" gives nobody anything to act on. Be specific about defect, location and size.
• Reporting by phone only. If it is not in writing, it did not happen as far as any escalation is concerned.
• No dates. Undated evidence is weak evidence. Record when you found each snag and report promptly so the timeline is verifiable.
• Letting the camera roll do the organising. A folder of unlabelled photos is not a snag report. Each photo needs to be tied to a described, located, numbered item.
• Marking things fixed without re-checking. A repair is not done until you have confirmed it. Re-check before you close any item.
• Fixing snags yourself. A DIY repair on a genuine defect hands the developer an argument that you caused the problem, and it destroys the evidence. Report it and let them fix it.

Frequently asked questions

How many photos should I take per snag?

At least two: a wide shot showing where the defect is in the room, and a close-up showing the defect in detail. Add a third with something for scale (a coin, a tape measure) wherever the size of the problem matters. The wide-plus-close-up pair is what proves both that the defect exists and exactly where it is, which is what stops a developer querying it.

Do I really need dates on my snags?

Yes. The date is what proves a defect existed at or near handover rather than being something you caused later, and every escalation route runs on timelines and deadlines. Record when you found each snag, not just when you sent the list, and report in writing soon after so the date is verifiable. Photo timestamps and dated emails do this for you automatically.

What should a snag report actually contain?

A header with your name, property address and date; a numbered list of snags grouped by room; for each snag a plain description, the exact location, the date found and photos (wide plus close-up); a floor plan with pinned locations where you have one; and a status against each item. Compiled into a single, dated PDF, that is a report a developer cannot easily dismiss and an Ombudsman can act on.

Is a PDF really better than just emailing photos?

Yes. Loose photos in an email body force the developer to piece together which photo is which defect, where it is and when you found it - so it gets deprioritised. A single dated PDF presents everything in order, numbered, located and described, which gets it actioned faster and is the exact format a warranty resolution service or the New Homes Ombudsman wants to see if you escalate.

What is the easiest way to document snags properly?

Capture each one in a purpose-built app as you walk the house: photograph and annotate the defect, tag the room, pin the location on a floor plan, write a short description, then export the whole lot as a dated PDF. SnagPal does exactly this for free, offline, with no account, so you build a developer-ready report in real time instead of assembling one from a messy camera roll afterwards.

The bottom line

Documenting snags so they cannot be dismissed comes down to discipline on every single item: a wide photo and a close-up (with scale where it matters and good light), the date you found it, the exact location pinned on a floor plan, and a plain, consistent description. Number them, group them by room, track each one's status, and compile the lot into a single, clean, dated PDF. Then send it in writing to the developer's customer care team and keep a copy of everything.

Get that right and the rest of the process gets far easier, because evidence is the thread running through all of it - from getting your first list actioned to winning an escalation if a developer goes quiet. If you are documenting a new build, for new build buyers ties the evidence together with your rights, what is snagging and new build snagging explained cover the wider process, the snagging period explained covers your timelines, and how to get your developer to fix your snags covers what to do once your report is built.