Cómo es un sistema de incidencias estructurado para administradores de fincas

Un ticket es un registro sencillo. También es la pieza estructural más importante del trabajo operativo moderno, desde la atención al cliente de una aerolínea hasta la gestión de incidentes de un hospital o el mantenimiento de un edificio.

Este artículo explica qué es un ticket (en una comunidad de propietarios, una incidencia), qué hace útil al sistema que lo rodea y qué cambia cuando llevas la administración de fincas con uno.

Un ticket es solo un registro con cuatro propiedades

Quítale la jerga y un ticket es un trabajo pendiente con cuatro datos asociados:

1. Un identificador, normalmente un número como #0042. Para poder referirte a él sin ambigüedad.
2. Un estado, en qué punto del flujo está. Nueva, En curso, Pendiente de confirmación, Cerrada.
3. Un responsable, la persona que ahora mismo tiene que moverlo hacia delante.
4. Un historial, cada cambio que ha hecho cualquiera, con fecha y hora.

Nada más. Todo lo demás (categorías, prioridades, adjuntos, comentarios) es decoración opcional. Esas cuatro propiedades convierten una queja en una tarea con seguimiento en lugar de un mensaje olvidado.

Compáralo con un mensaje de WhatsApp. Un mensaje tiene contenido. Y ya. No tiene identificador (más allá de su posición en el chat), ni estado, ni responsable, ni historial. Por eso no puedes llevar un flujo de trabajo sobre él.

Por qué importa cada una de las cuatro propiedades

Identificador

Cuando dos personas hablan de una incidencia, necesitan saber que hablan de la misma. En un grupo de WhatsApp lo haces citando: “lo del ascensor de ayer” o “la fuga del 4º B que el fontanero dijo que era el latiguillo”. En cuanto tienes más de cinco incidencias abiertas a la vez, eso se vuelve ambiguo.

Un número de incidencia (#0042, #0089) lo resuelve para siempre. Cualquier vecino, administrador o profesional puede referirse a una incidencia por su número sin ninguna duda. Parece una tontería. Elimina alrededor del 15% de toda la confusión de un flujo de administración típico.

Estado

El estado convierte una conversación libre en una máquina de estados:

El vecino no tiene que preguntar “¿se sabe algo?”. Ve el estado. El administrador no tiene que acordarse de qué incidencias están paradas esperando al fontanero. Filtra por estado. Y quien dirige el despacho no tiene que leerse 200 mensajes para saber cuántas incidencias hay abiertas este mes. Las cuenta.

El estado es también donde vive la automatización. Cuando cambia el estado, pasan cosas: salen notificaciones, se avisa a los vecinos, se asignan profesionales. En un grupo de WhatsApp eso es imposible, porque el chat no sabe lo que es un estado.

Responsable

Cada incidencia, en cada momento de su ciclo de vida, tiene exactamente una persona responsable de moverla hacia delante. Cuando el vecino la comunica, el responsable es el administrador de la comunidad (o el profesional al que se ha enviado). Cuando el administrador se la asigna a un profesional, el profesional pasa a ser el responsable. Cuando el profesional la marca como terminada, el responsable pasa a ser el vecino, que tiene que confirmarla o reabrirla.

Es la función que rompe el “que lo haga otro” típico de un grupo de WhatsApp, donde todos ven la incidencia y nadie se ocupa de ella.

Historial

Un registro completo de cada cambio de estado, cada asignación y cada comentario. Es clave por tres motivos:

1. Rendir cuentas. Cuando llega la temporada de juntas, puedes enseñar una cronología precisa de cómo se gestionó cada incidencia.
2. Detectar patrones. A los seis meses descubrirás que el 40% de tus incidencias de fontanería vienen de la misma comunidad: una señal de que toca llevar a la junta la renovación de las bajantes.
3. Incorporar gente. Cuando entra un administrador nuevo en el despacho, puede repasar el historial de cualquier comunidad y entender qué está pasando.

Qué añade “el sistema que rodea a los tickets”

Un ticket por sí solo es un registro. Un sistema de incidencias añade el flujo de trabajo a su alrededor:

• Reparto. Cuando se crea una incidencia, ¿a quién le llega? La mayoría de los sistemas usan reglas: “categoría = fontanería → asignar al fontanero X”. El administrador no tiene que decidir.
• Notificaciones. Cuando cambia el estado, ¿a quién se avisa? Al responsable, a quien la comunicó y, a veces, a quien la sigue.
• Filtros. “Enséñame todas las incidencias Nuevas de la comunidad de la calle Mayor 12, sin asignar, con más de 24 horas.” Dos clics.
• Acciones en bloque. “Cierra las 30 incidencias que llevan más de dos semanas Pendientes de confirmación.” Una sola acción.

Nada de esto existe en un flujo basado en WhatsApp. No hay forma de “filtrar todas las incidencias abiertas de cuatro comunidades” en WhatsApp, porque nada en WhatsApp sabe lo que es una “incidencia abierta”.

El flujo mínimo de incidencias para una comunidad

No necesitas una plataforma corporativa con 200 funciones. El flujo mínimo útil para administrar fincas tiene:

• Título + descripción + categoría opcional + foto opcional. El aviso en sí.
• Un campo de estado con 5 valores como mucho. Nueva, En curso, Pendiente de confirmación, Cerrada, Reabierta. Más que eso es complicarse.
• Asignación a uno de tres roles. Administrador, profesional, vecino.
• Notificaciones push al asignar y al cambiar de estado. Para que nadie tenga que abrir la app para enterarse de que ha pasado algo.
• Separación por comunidad. Cada incidencia pertenece a una comunidad, y cada usuario solo ve las comunidades de las que forma parte.

Ese es todo el núcleo. Si una herramienta te ofrece esto, con una interfaz que los vecinos puedan usar sin formación, tienes lo que necesitas.

Las objeciones que salen siempre

“Mis vecinos no lo van a usar nunca.”

Alrededor del 70% lo usará. El otro 30% le escribirá a un vecino que sí lo usa, y ese vecino subirá la incidencia. No necesitas el 100% de los vecinos para aprovechar las ventajas. Necesitas los suficientes para que la bandeja de incidencias sea la fuente de la verdad.

“Ya lo intentamos con el correo y no funcionó.”

El correo no es un sistema de incidencias. No tiene estados, ni bandeja compartida, ni asignación, ni filtros, ni reparto. Tratar el correo como un sistema de incidencias falla porque no lo es.

“Ya tenemos un Excel para esto.”

Un Excel se parece más a un sistema de incidencias que un grupo de WhatsApp. Tiene identificadores y una especie de columna de estado. Pero sigue sin notificaciones, sin trabajo en tiempo real entre varias personas, sin nada que vean los vecinos y sin automatización. Es un registro del trabajo. No es un flujo de trabajo.

El cambio de mentalidad

Lo más difícil de pasar a un sistema de incidencias es el cambio mental de “el sistema soy yo” a “el sistema es el sistema, y yo lo superviso”. Los administradores que lo interiorizan crecen muy por encima de la cartera que llevaban. Los que no, siguen haciendo de centralita humana hasta que se queman.

La primera semana se hace rara, porque no estás contestando todo el rato. Luego te das cuenta de que las comunidades funcionan sin que intervengas en tiempo real, y el motivo es que el propio flujo hace el trabajo que antes vivía en tu cabeza.