Answer

How do you write a defect description a trade can act on?

Write it for a stranger who has the photo and the room number but was not there: what is wrong, where on the thing, and how much of it. “Grout missing, shower niche, left return, 300 mm run” is a defect description; “tiling” and “bathroom finish poor” are not. Leave the trade, the room and the priority to their own fields, put the symptom before any suspected cause, and mark the fault on the photo instead of describing where it is. In IssuesId the description field takes dictation that adds to what is typed, the room comes from the location tree or a QR label, the photo is pinned, and the trade’s email leads with the site and the room so the description only has to do its own job.

ANSWERED FROM THE PRODUCT DOCS·UPDATED OCTOBER 2026
Before the tool

The reader is a tiler in a van, eleven days from now

A defect description has one reader who matters, and it is not the person writing it. It is the trade who opens the email in a van outside the building, eleven days later, and has to decide what to bring in. If the description makes them ring you, it has failed, and the item has just acquired a phone call, a wait and a second visit. The second reader, less often but more expensively, is whoever is deciding a dispute about the item a year later. Both of them want the same three things: what, where on the thing, how much. Everything else on the record has its own field.

Six rules

What goes in the description, and what does not

01
Say what is wrong, not what trade it is
“Tiling” is a column, not a description. “Grout missing” is what is wrong. The trade is a separate field on the record, so the description does not have to carry it.
02
Say where on the thing
Not the room; the record already knows the room. Where on the thing: “shower niche, left return”, “door, latch side, bottom 200 mm”, “ceiling, above the shower, 400 mm from the wall”.
03
Say how much
A measurement or a count: “300 mm run”, “9 of 40 brackets”, “approx. 4 m²”. The extent decides whether it is a touch-up or a strip-out, and it is the first thing a disputed item argues about.
04
Say what you saw, not what you concluded
“Water mark on the ceiling” is a fact. “Membrane failure” is a diagnosis, and if it turns out to be condensation the record has said something wrong. Put the suspected cause after the symptom, flagged as suspected.
05
Leave out the adjectives
“Poor”, “unacceptable”, “shoddy” tell the trade how you feel and tell the record nothing. They also read badly in a tribunal. The measurement does the work the adjective was trying to do.
06
Mark the photo, do not describe it
A pin or a circle on the photo at the fault is worth a sentence of “to the left of the second tile from the top”. Describe in the text what the photo cannot show: the sound, the smell, what happened when you ran the tap.
Nine words. The tiler knows what to bring and where to kneel. Nothing in the description repeats a field the record already has.
How it runs in IssuesId

The fields do the rest

The capture flow is built so the description only has to describe. The room comes from the location tree or a QR label on the door frame; the trade, priority, type and classification are their own fields; the photo is taken in the app and pinned or circled at the fault. A mic on the description field takes dictation and adds to what is already typed, never replaces it, so “grout missing, shower niche” typed and “left return, about 300 mil” spoken end up as one description. The search box matches the description along with every other field, so a word used consistently is a word you can find later. And the email to the trade names the site and the room first, then the description, then the photos, so the nine words land where the tiler expects them.

Related questions

Asked alongside this one

How do you write a defect description a trade can act on?
For a stranger who has the photo and the room but was not there: what is wrong, where on the thing, and how much of it. “Grout missing, shower niche, left return, 300 mm run.” Leave the room, trade and priority to their own fields, put the symptom before any suspected cause, drop the adjectives, and pin the fault on the photo instead of describing where it is. In IssuesId dictation adds to what is typed, the room comes from the location tree or a QR label, and the trade’s email leads with the site and room so the description only has to describe.
Should a defect description name the trade?
No, the trade is its own field, and so are the room, the priority, the type and the classification. A description that repeats them is spending the reader’s attention on things the record already carries. The description’s job is the part no other field holds: what is wrong, where on the thing, and the extent.
Should you write the cause of the defect?
Write the symptom first, as a fact: “water mark, ensuite ceiling, approx. 400 mm from the wall above the shower.” If you have a view on the cause, add it after and flag it as a view: “suspect membrane; check niche above.” A description that states a diagnosis as fact, and is wrong, has put a false statement on the record and issued the wrong trade.
Can you dictate a defect description?
Yes. In IssuesId there is a mic on the description field on the phone and at a desk, and what you say is added to what is already typed rather than replacing it, so a typed start and a spoken finish come out as one description. Voice captions on photo pins work the same way, and the transcribed text can be edited afterwards.
Read on

Where this answer comes from

The docs behind this answer are defects (the capture flow, dictation, Type and Classification), photos and annotations and notifications. The same rule, applied to a whole spreadsheet, is the Description column of the defect register template; the longer argument is write the defect for a stranger.

IssuesId