De WhatsApp a una incidencia de comunidad trazable

Un aviso vecinal suele llegar con edificio, zona y descripción repartidos en varios mensajes. El flujo para administradores de fincas los convierte en una incidencia revisable, sin afirmar que ya hay proveedor o reparación. Si el aviso contiene datos de una vivienda particular, aplica permisos diferentes a los de una zona común. La referencia compartida no debe revelar identidad, teléfono ni circunstancias privadas a otros vecinos.

01

01

02

03

Registra lo observado, no la causa

«Hay agua junto al ascensor» describe una situación visible. No demuestra el origen, la responsabilidad ni la solución. La incidencia debe conservar esa diferencia para que el equipo decida cómo comprobarla.

Identifica comunidad, portal o zona común, momento aproximado y material adjunto. Cuando falta la comunidad, el agente puede pedirla; cuando la ubicación es ambigua, la marca como pendiente en lugar de asignar un edificio por contexto. Añade una forma de indicar si el aviso afecta a acceso, ascensor, suministro o seguridad, pero usa categorías operativas aprobadas. El objetivo es dirigir la revisión, no determinar la causa. Fotos y audios permanecen asociados como material aportado, con controles de acceso y conservación definidos.

La prioridad declarada por el vecino también es un dato, no un peritaje. Las reglas de emergencia y escalado deben proceder de la administración y ofrecer canales humanos cuando exista riesgo inmediato.

02

Une avisos sin borrar sus diferencias

Varios vecinos pueden informar del mismo problema con horas y zonas distintas. Agruparlos puede reducir duplicados, pero requiere criterios explícitos: comunidad, ubicación y ventana temporal, además de revisión cuando haya dudas.

No fusiones automáticamente dos incidencias solo porque contienen palabras parecidas. Agua en dos portales puede tener causas y responsables diferentes. Conserva los mensajes asociados y permite separar el caso.

Una referencia común ayuda a continuar la comunicación. Cada nuevo aviso puede añadir contexto a esa referencia sin crear otra cola, siempre que el sistema indique quién lo vinculó y por qué.

03

Derivar no significa asignar un proveedor

El primer destino puede ser gestión de incidencias, presidencia o una persona de guardia según reglas verificadas. El estado «derivada» describe ese handoff interno; no demuestra que un proveedor haya aceptado el trabajo.

Para mostrar «asignado» haría falta una fuente externa real y su respuesta. Para mostrar «resuelto», evidencia de cierre. El sandbox termina antes porque no existe backend profesional persistente ni conexión con proveedores.

El comprobante debe explicar comunidad, zona, descripción, referencia y decisiones pendientes. Así el equipo puede revisar sin reconstruir el chat y el vecino entiende qué se ha registrado.

04

01

02

03

Valida el flujo con incidencias difíciles

Prueba ubicaciones incompletas, mensajes de terceros, avisos repetidos y posibles emergencias. Comprueba que el agente solicita información mínima y ofrece el canal aprobado sin diagnosticar la avería.

05

Mide duplicados evitados, campos corregidos y tiempo de clasificación. No atribuyas al agente el tiempo de reparación: depende de decisiones, proveedores y disponibilidad que quedan fuera del registro inicial.

06

En la demo de administradores de fincas puedes ver una incidencia creada y derivada localmente. El proveedor y la actuación permanecen pendientes de revisión. Tampoco se comunica una reparación inexistente.