Introduction
A site foreman spots a crack in the bathroom tiling. He pulls out his phone, takes a photo, and drops it in the project WhatsApp group. Someone replies "ok, we'll look at it" between twenty messages about the concrete that never showed up and the van blocking the gate. Three weeks later, at the handover walkthrough, the client points at that exact crack. Nobody knows who was supposed to fix it, whether the subcontractor ever touched it, or what it cost. The photo is still there, buried in the chat, but the problem starts over from zero — now with a client standing in front of you.
This is the black hole of on-site quality: the defect gets seen, gets mentioned, and disappears. There's no status, no owner, no due date, and above all no way to prove it was closed. In this article we walk through the complete incident resolution workflow the way we built it in Tabiquo: catch the defect, classify it by severity, route it to the right owner, move it through its status machine until it's verifiably closed, and the wider quality net around it — inspections, site-visit minutes, warranty claims, client-reported issues, and the alerts that escalate critical items before they turn into a problem with your name on it.
From photo to ticket: logging and classifying
An incident with a number, not a stray message
In Tabiquo, every defect becomes an incident with its own identity. The first thing it gets is a per-project sequential number — #14 on that job — drawn from a persistent counter that never reuses values: if you delete an incident, its number is retired, so #14 can never point to two different defects over time. That sounds like a minor detail until you're in a site meeting and someone says "the thing with incident 14" and everyone knows exactly what's on the table.
An incident can be created straight from the mobile app, on the spot, with the defect in front of you: title, description, photos and videos uploaded directly from the device (with their thumbnails), the affected room or unit, and the location. One way to create it is by dropping a pin on the floor plan — tapping the exact spot of the defect on the drawing — but that visual gesture is covered in depth in a separate article; here we care about what happens after the pin lands.
Severity drives the queue
Every incident is classified with one of four severities: minor, moderate, major, or critical. It isn't a decorative label. Each severity carries an internal priority order (1 to 4) so the open list can be sorted by real urgency, and it drives the color the incident is shown in — red for critical, orange for major, amber for moderate, blue for minor. A water leak in a slab and a badly finished silicone joint don't deserve the same attention, and severity is what tells the team that at a glance.
The incident lifecycle: from open to closed
A state machine, not an inbox
The heart of the system is an explicit status flow every incident moves through: open → assigned → in progress → resolved → verified → closed. It isn't a loose list of adjectives; it's a state machine with controlled transitions. An open incident can only go to assigned or be closed outright; an assigned one can move to in progress, drop back to open, or be closed; an in-progress one only advances to resolved; a resolved one is verified (or sent back to in progress if the repair doesn't hold up); and only from verified does it close in the ordinary path. Impossible jumps — open straight to verified, say — simply don't exist.
Every step records who and when: who resolved it and with what resolution notes, who verified it and with what observations, who closed it. And if a repair is signed off too early, the incident can be reopened: verified drops back to resolved, resolved drops back to in progress, without losing the history.
Routing to the right owner: team member or external company
This is one of the design decisions that matters most on a real job. An incident is assigned either to a team member or to an external company — a subcontractor, the installer, the supplier — but never to both at once. The assignment is exclusive: if you assign the incident to an internal worker, any external-company assignment is automatically cleared, and vice versa. At any moment there is exactly one owner responsible for moving that incident, and the system shows that owner's name, whether it's a person or a company.
This kills the classic "I thought the bricklayer was doing it." When you route the tiling rework to the finishes subcontractor, the incident moves itself to assigned and stops being the diffuse responsibility of the whole site, becoming one specific person's concrete task.
Cost closes too
When you resolve an incident you can record the repair cost and flag whether it's charged back to the contractor responsible for the defect. That turns quality into a financial figure: by the end of the job you know what quality control cost you, how much of it you were able to charge to whom, and you stop quietly absorbing repairs that were never yours to pay.
Share without granting access, and document the close
Sometimes you need a third party — an installer who doesn't use the platform — to see exactly one incident. For that, each incident can generate a temporary view link (with an expiry, 30 days by default) giving read-only access at /incidencia/{token}, no account required. The external party can even acknowledge it, recording the date and IP of their confirmation.
And as the job progresses, everything condenses into a detailed PDF report: one card per incident with its number, description, evidence photos, and the pin drawn over the floor plan, grouped into open, resolved, and closed. It's generated from a single incident's view, from the project list, or by selecting several at once to print a batch. Images are embedded into the PDF itself, so the document is self-contained for sending to the owner or to the project supervisor.
The quality net around the incident
A standalone incident is useful, but real quality shows up when that incident lives inside a wider system. In Tabiquo, three flows surround it.
Inspections and the site-visit minute
Inspections are quality checks with their own lifecycle: draft → in progress → completed → signed. Each inspection carries a checklist, and each item is scored as pass, fail, N/A, or pending. The system automatically computes the pass rate — how many items passed out of those evaluated — and won't let you complete the inspection while any item is still pending. Each item takes photos and notes.
There's a special type, the site visit, built for walkthroughs with the project supervisor. From a completed inspection you can generate a minute (verbale): a formal record that automatically pulls in the date, the attendees, the checklist results, and — very practically — the incidents detected during the visit, because incidents can be linked directly to the inspection that originated them. That minute becomes part of the project record, ready to sign. And when the client's or owner's signature is needed, the inspection generates a signature token (7-day expiry) that lets them sign from a public page with no account; the signature is stored with name, date, and IP.
Warranty claims
Once the job is handed over, defects don't vanish — they become warranty claims. They have their own, longer flow, because they involve a decision and a negotiation: received → inspecting → scheduled → in progress → completed → signed → closed. They're classified by category — structural, waterproofing, electrical, plumbing, HVAC, finishes, carpentry, appliances — and by urgency.
The pivotal step is the decision: pending, approved, rejected, or partial, with its reason and its cost responsibility (the company, the supplier, or shared). Only approved or partial claims unlock scheduling the repair. Just like incidents, the repair is assigned to an internal worker or an external company, the cost is broken down into labor and materials, and on completion a client signature token is generated to close the loop with the client's sign-off before the claim is archived.
What the client reports
The third flow starts outside the team. After handover, the client can report issues from the app, and these come in as client issues with their own triage cycle: reported → under review → accepted / rejected / converted. The responsible person reviews and then decides: reject with an explanation (which the client actually receives, instead of an awkward silence), or accept. An accepted client issue can be converted into a warranty claim in a single step — the system copies the title, description, location, the equivalent category and urgency and, crucially, carries the evidence photos across — so nothing is lost in the handoff from the client channel into the formal warranty flow.
Automation: don't let the critical ones go cold
Alerts that escalate on their own
An incident can have a due date and an escalation threshold in days. From there, the system works on its own. The scheduled alerts:incident-escalation task runs daily across overdue, non-closed incidents and generates alerts: an overdue alert (warning severity) if it has simply passed its date, and an escalation alert (critical severity) if the delay exceeds the configured threshold. Alerts are raised team-wide and, on top of that, individually for the watchers (users following that incident in copy), with the detail of how many days overdue it is, the severity, and who it's assigned to.
The effect is that a critical incident a week late doesn't sit dormant in a list: it raises its own voice and surfaces where the owner will see it. That's the difference between a system that records and a system that chases.
Traceability for audit
Every meaningful change — severity, status, cost, resolution date — is captured in an activity log. When someone asks "when was this resolved and who verified it?", the answer doesn't depend on anyone's memory: it's in the project record. The same applies to inspections and warranty claims, which keep their own log of status and decision changes.
Conclusion
The defect that dies in a WhatsApp group isn't a communication problem — it's a system problem. As long as an incident is a message, it's forgettable. The moment it becomes a ticket with a number, a severity, a single owner, a due date, and a status cycle that ends in a verifiable "closed," quality stops depending on who remembers what. And when that ticket lives surrounded by inspections with their signed minutes, by a warranty flow with the client's signature, by a channel where the client reports and it converts into a claim without friction, and by alerts that escalate the critical ones on their own, what you have isn't a to-do list: it's a net that catches defects before they reach handover.
Tabiquo
Tabiquo is the web platform and mobile app for small and medium architecture studios and construction firms that want to stop running the job out of WhatsApp. The incident, inspection, and warranty flow you've just read about is available both in the management panel and in the app, where your team logs defects on site and the owner reports theirs after handover. If you want to actually close your quality issues — and be able to prove it — see how Tabiquo fits the way you already work.