El parte se cierra en la sala de máquinas, no dos días después

El desafío

Una empresa de servicio técnico de climatización con 34 técnicos en la calle atendía unos 3.800 equipos instalados en edificios, clínicas, depósitos y oficinas. Cada visita terminaba en un parte de trabajo en papel: el técnico lo completaba en el lugar, lo guardaba en la carpeta y lo entregaba cuando volvía a la base, uno o dos días después. Recién ahí alguien lo cargaba en el sistema de gestión.

El problema no era la carga: era todo lo que pasaba en el medio. Los repuestos usados se descontaban del stock a fin de mes, cuando nadie recordaba bien qué se había puesto dónde. Uno de cada tres partes volvía sin la firma del cliente, y sin firma no había respaldo para facturar. Y cuando otro técnico iba al mismo equipo semanas después, no sabía qué se había hecho la vez anterior: la información estaba en una carpeta, no en la ficha del equipo.

Ya habían probado una app de mercado. Fracasó por una razón simple: los equipos están en salas de máquinas, subsuelos y azoteas, donde no hay señal. La app necesitaba red para guardar, así que el técnico volvía a completar el parte afuera, de memoria, o directamente lo hacía en papel como siempre.

La solución

Construimos una app para técnicos en campo pensada desde el primer día para funcionar sin conectividad, y un panel de despacho para la base. El circuito arranca cuando el despachador carga un pedido —equipo, dirección, urgencia según el contrato— y lo asigna a un técnico. La orden le llega al teléfono con la ficha del equipo: las últimas tres visitas, qué repuestos se cambiaron y qué falló.

El técnico abre la orden, toca "Iniciar visita" y completa el checklist específico del tipo de equipo: para un chiller son seis controles, para un split son cuatro. Carga las observaciones, saca fotos, y agrega los repuestos que usó leyendo el código de barras de la caja. Si está en un subsuelo sin señal, la app lo muestra con una banda ámbar —"Sin conexión · guardado local"— y sigue funcionando exactamente igual: todo queda en la base de datos local del teléfono.

Al terminar, el cliente firma en la pantalla y la orden se cierra ahí mismo, con la hora, la ubicación y el tiempo total de la visita. Cuando el teléfono recupera la red —en el ascensor, en la calle, en el próximo cliente— la cola local se vacía sola: la orden, las fotos, la firma y el consumo de repuestos viajan al servidor sin que el técnico haga nada.

El caso difícil es el conflicto: la oficina reasignó la orden a otro técnico mientras el primero ya estaba adentro trabajando sin señal. Cuando llega la sincronización, el sistema no pisa ninguna de las dos versiones. Aplica una regla explícita —lo que se hizo en campo con firma del cliente gana— y le muestra al despachador las dos versiones lado a lado, con un botón para conservar la de campo o revisar. Nada se pierde en silencio.

Desde el panel, el despachador ve el día completo: cuántas órdenes hay, cuántos técnicos están en la calle, cuáles están sin conexión en este momento y cuáles ya cerraron. Cada fila lleva el estado real de la orden y si tiene o no la firma del cliente, que es lo que administración necesita para facturar sin esperar la carpeta.

Arquitectura de la plataforma

La app corre en Android sobre React Native, con una base de datos SQLite local que es la fuente de verdad mientras no hay red. Cada acción del técnico —abrir la orden, tildar un control, cargar un repuesto, capturar la firma— se escribe primero en esa base y entra a una cola de sincronización con un identificador único por operación. La app nunca espera a la red para responder.

Cuando hay conectividad, un proceso en segundo plano vacía la cola contra una API REST en Node.js. Cada envío es idempotente: si el teléfono manda dos veces la misma operación porque se cortó la respuesta, el servidor la reconoce por su identificador y no la duplica. Las fotos viajan aparte, comprimidas, y la orden puede quedar cerrada aunque las imágenes todavía estén subiendo.

Es el mismo patrón que usamos en el sistema de fichaje con reconocimiento facial, donde la marca también se toma en el lugar y viaja cuando hay red.

Los conflictos se resuelven en el servidor con reglas por campo, no por orden completa: la asignación de técnico la gana la central, pero el contenido del parte, los repuestos y la firma los gana el campo. El panel de despacho muestra el resultado y deja revisar. PostgreSQL guarda las órdenes, la ficha de cada equipo con su historial y el consumo de repuestos, que impacta en el stock al cerrar la orden, no a fin de mes.

La implementación

La decisión que definió el proyecto fue construir el modo sin conexión primero, no después. Arrancamos con una sola familia de equipos —chillers— y un grupo de seis técnicos, con la app funcionando en modo avión desde la primera semana de pruebas. Si el checklist no se podía completar en un subsuelo, no servía, y eso se probó antes que cualquier otra cosa.

La segunda decisión fue no digitalizar el parte de papel tal cual estaba. Se relevó con los técnicos qué controles miraban de verdad en cada tipo de equipo y se armó un checklist por familia, en vez de un formulario genérico con un campo de observaciones donde antes iba todo. Los partes históricos en papel no se migraron: el historial de cada equipo se empezó a construir desde la primera visita con la app, y a los tres meses ya cubría la mayoría del parque.

El resto de las familias de equipo y el resto de los técnicos entraron por etapas, con el papel conviviendo dos semanas en cada grupo como respaldo. El panel de despacho se conectó al sistema de gestión existente por API para que la orden cerrada alimente la facturación sin recargar nada.