Introducción
Un capataz detecta una grieta en el alicatado de un baño. Saca el móvil, hace una foto y la manda al grupo de WhatsApp de la obra. Llega un "ok, lo miramos" entre veinte mensajes sobre el hormigón que no ha llegado y la furgoneta mal aparcada. Tres semanas después, en la visita de entrega, el cliente señala exactamente esa grieta. Nadie sabe quién tenía que arreglarla, si el subcontratista la repasó, ni cuánto costó. La foto sigue ahí, enterrada en el chat, pero el problema vuelve a empezar de cero, ahora con un cliente delante.
Este es el agujero negro de la calidad en obra: el defecto se ve, se comenta y desaparece. No hay un estado, no hay un responsable, no hay una fecha límite y, sobre todo, no hay forma de demostrar que se cerró. En este artículo recorremos el flujo completo de resolución de incidencias tal como lo hemos construido en Tabiquo: detectar, clasificar por severidad, enrutar al responsable correcto, mover la incidencia por su ciclo de estados hasta cerrarla, y la red de calidad que la rodea —inspecciones, verbales de visita, reclamaciones de garantía, incidencias reportadas por el cliente y las alertas que escalan lo crítico antes de que se convierta en un problema con nombre y apellidos.
De la foto al ticket: registrar y clasificar
Una incidencia con número, no un mensaje suelto
En Tabiquo cada defecto detectado se convierte en una incidencia con identidad propia. Lo primero que recibe es un número correlativo por proyecto —la #14 de esa obra— generado a partir de un contador persistente que nunca reutiliza valores: si borras una incidencia, su número queda retirado, de forma que la #14 jamás apuntará a dos defectos distintos a lo largo del tiempo. Esto parece un detalle menor hasta que estás en una reunión de obra y alguien dice "lo de la incidencia 14", y todos saben exactamente de qué se habla.
La incidencia se puede crear desde la app móvil, en el momento, con el defecto delante: título, descripción, fotos y vídeos subidos directamente desde el dispositivo (con su miniatura), la estancia o la unidad afectada, y la ubicación. Una de las formas de crearla es clavando un pin sobre el plano —marcando con el dedo el punto exacto del defecto sobre el plano de planta—, pero ese gesto visual lo tratamos en profundidad en otro artículo; aquí nos interesa lo que pasa después del pin.
La severidad ordena el trabajo
Toda incidencia se clasifica con una de cuatro severidades: menor, moderada, mayor o crítica. No es una etiqueta decorativa: tiene un orden de prioridad interno (de 1 a 4) que permite ordenar la lista de pendientes por urgencia real, y determina el color con el que la incidencia se representa —en rojo lo crítico, naranja lo mayor, amarillo lo moderado, azul lo menor—. Una fuga de agua en un forjado y una junta de silicona mal rematada no merecen la misma atención, y la severidad es lo que se lo dice al equipo de un vistazo.
El ciclo de vida de la incidencia: de abierta a cerrada
Una máquina de estados, no una bandeja de entrada
El corazón del sistema es un flujo de estados explícito por el que toda incidencia avanza: abierta → asignada → en curso → resuelta → verificada → cerrada. No es una lista de adjetivos sueltos; es una máquina de estados con transiciones controladas. Una incidencia abierta solo puede pasar a asignada o cerrarse directamente; una asignada puede ponerse en curso, devolverse a abierta o cerrarse; una en curso solo avanza a resuelta; una resuelta se verifica (o se devuelve a en curso si la reparación no convence); y solo desde verificada se cierra de forma ordinaria. Las transiciones imposibles —saltar de abierta a verificada, por ejemplo— simplemente no existen.
Cada paso deja rastro de quién y cuándo: quién resolvió, con qué notas de resolución, quién verificó y con qué observaciones, quién cerró. Y si una reparación se da por buena demasiado pronto, la incidencia se puede reabrir: de verificada vuelve a resuelta, o de resuelta vuelve a en curso, sin perder el historial.
Enrutar al responsable correcto: equipo o empresa externa
Aquí está una de las decisiones de diseño que más importa en obra. Una incidencia se asigna a un miembro del equipo o a una empresa externa —un subcontratista, el instalador, el proveedor— pero nunca a los dos a la vez. La asignación es excluyente: si asignas la incidencia a un trabajador interno, se limpia automáticamente cualquier asignación a empresa externa, y viceversa. En cualquier momento hay un único responsable de mover esa incidencia, y el sistema lo refleja con el nombre del asignado, sea persona o compañía.
Esto resuelve el problema clásico del "pensaba que lo hacía el albañil". Cuando enrutas el repaso del alicatado al subcontratista de acabados, la incidencia pasa sola a estado asignada y deja de ser responsabilidad difusa de toda la obra para ser tarea concreta de alguien.
El coste también se cierra
Al resolver una incidencia se puede registrar el coste de reparación y marcar si se repercute al contratista responsable del defecto. Esto convierte la calidad en un dato económico: al final de la obra sabes cuánto te ha costado el control de calidad, qué parte has podido cargar a quién, y dejas de comerte en silencio reparaciones que no eran tuyas.
Compartir sin dar acceso, y documentar el cierre
A veces necesitas que un tercero —un instalador que no usa la plataforma— vea exactamente una incidencia. Para eso cada incidencia puede generar un enlace de visualización temporal (con caducidad, 30 días por defecto) que da acceso de solo lectura en /incidencia/{token}, sin registro. El externo puede incluso acusar recibo, dejando registrada la fecha y la IP de su confirmación.
Y cuando la obra avanza, toda la información se condensa en un informe PDF detallado: una ficha por incidencia con su número, descripción, las fotos de evidencia y el pin dibujado sobre el plano, agrupadas por abiertas, resueltas y cerradas. Se genera desde la ficha de una incidencia, desde el listado del proyecto o seleccionando varias a la vez para imprimir un lote. Las imágenes van embebidas en el propio PDF, así que el documento es autocontenido para enviarlo a la propiedad o a la dirección facultativa.
La red de calidad alrededor de la incidencia
Una incidencia suelta es útil, pero la calidad de verdad aparece cuando esa incidencia vive dentro de un sistema más amplio. En Tabiquo hay tres flujos que la rodean.
Inspecciones y el verbale de la visita
Las inspecciones son controles de calidad con su propio ciclo: borrador → en curso → completada → firmada. Cada inspección lleva una lista de puntos de control, y cada punto se evalúa como conforme, no conforme, N/A o pendiente. El sistema calcula automáticamente la tasa de conformidad —cuántos puntos pasaron sobre los evaluados— y no deja completar la inspección mientras queden puntos pendientes. Cada punto admite fotos y notas.
Hay un tipo especial, la visita de obra (site visit), pensada para los sopralluoghi y recorridos con la dirección facultativa. Desde una inspección completada se puede generar un verbale: un acta formal que vuelca automáticamente la fecha, los asistentes, los resultados de la checklist y, de forma muy práctica, las incidencias detectadas durante la visita, porque las incidencias pueden enlazarse directamente a la inspección que las originó. Ese verbale queda como acta del proyecto, lista para firmarse. Y cuando llega la firma del cliente o de la propiedad, la inspección genera un token de firma (caducidad de 7 días) que permite firmar desde una página pública sin necesidad de cuenta; la firma queda registrada con nombre, fecha e IP.
Reclamaciones de garantía
Cuando la obra ya está entregada, los defectos no desaparecen: se transforman en reclamaciones de garantía. Tienen su propio flujo, más largo porque implica una decisión y una negociación: recibida → en inspección → programada → en curso → completada → firmada → cerrada. Se clasifican por categoría —estructural, impermeabilización, electricidad, fontanería, climatización, acabados, carpintería, electrodomésticos— y por urgencia.
El paso clave es la decisión: pendiente, aprobada, rechazada o parcial, con su motivo y su responsable de coste (la empresa, el proveedor, compartido). Solo las reclamaciones aprobadas o parciales habilitan la programación de la reparación. Igual que con las incidencias, la reparación se asigna a un trabajador interno o a una empresa externa, se desglosa el coste en mano de obra y materiales, y al terminar se genera un token de firma para el cliente que cierra el círculo con su conformidad antes de archivar la reclamación.
Lo que reporta el cliente
El tercer flujo arranca fuera del equipo. Tras la entrega, el cliente puede reportar incidencias desde la app, y esas entran como client issues con su propio ciclo de triaje: reportada → en revisión → aceptada / rechazada / convertida. El responsable revisa, y entonces decide: rechazarla con una explicación (que el cliente recibe, en vez de un silencio incómodo), o aceptarla. Una incidencia de cliente aceptada se puede convertir en una reclamación de garantía con un solo paso —el sistema copia título, descripción, ubicación, la categoría y la urgencia equivalentes y, crucialmente, arrastra las fotos de evidencia— de modo que no se pierde nada en el traspaso del canal del cliente al flujo formal de garantía.
Automatización: que lo crítico no se enfríe
Alertas que escalan solas
Una incidencia puede tener fecha límite y un umbral de días de escalado. A partir de ahí, el sistema trabaja solo. La tarea programada alerts:incident-escalation recorre cada día las incidencias vencidas y no cerradas y genera alertas: una alerta de vencimiento (gravedad de aviso) si simplemente se pasó de fecha, y una alerta de escalado (gravedad crítica) si el retraso supera el umbral configurado. Las alertas se crean para todo el equipo y, además, de forma individual para los observadores (los usuarios que siguen esa incidencia en copia), con el detalle de los días de retraso, la severidad y a quién está asignada.
El efecto es que una incidencia crítica con una semana de retraso no se queda dormida en una lista: sube de tono sola y aparece donde el responsable la va a ver. Es la diferencia entre un sistema que registra y un sistema que persigue.
Trazabilidad para auditoría
Cada cambio relevante —la severidad, el estado, el coste, la fecha de resolución— queda registrado en un historial de actividad. Cuando alguien pregunta "¿cuándo se resolvió esto y quién lo verificó?", la respuesta no depende de la memoria de nadie: está en el registro del proyecto. Lo mismo aplica a inspecciones y reclamaciones de garantía, que llevan su propia bitácora de cambios de estado y decisión.
Conclusión
El defecto que muere en un grupo de WhatsApp no es un problema de comunicación: es un problema de sistema. Mientras una incidencia sea un mensaje, será olvidable. En cuanto se convierte en un ticket con número, severidad, responsable único, fecha límite y un ciclo de estados que termina en "cerrada" verificable, la calidad deja de depender de quién se acuerde de qué. Y cuando ese ticket vive rodeado de inspecciones con sus verbales, de un flujo de garantías con firma del cliente, de un canal donde el cliente reporta y se convierte en reclamación sin fricción, y de alertas que escalan solas lo crítico, lo que tienes no es una lista de tareas: es una red que atrapa los defectos antes de que lleguen a la entrega.
Tabiquo
Tabiquo es la plataforma web y app móvil para estudios de arquitectura y empresas de construcción pequeñas y medianas que quieren dejar de gestionar la obra en WhatsApp. El flujo de incidencias, inspecciones y garantías que has leído está disponible tanto en el panel de gestión como en la app, donde tu equipo registra defectos a pie de obra y la propiedad reporta los suyos tras la entrega. Si quieres cerrar tus incidencias de calidad de verdad —y poder demostrarlo—, descubre cómo Tabiquo encaja en tu forma de trabajar.