El servicio técnico en terreno tiene un costo oculto que pocos miden: el tiempo entre la firma del trabajo y el cierre administrativo. Si el técnico cierra el servicio en sitio con el cliente y vuelve a la oficina sin papeles, el ciclo se acorta entre 2 y 5 días. Si vuelve con una hoja firmada que la secretaria digitaliza al día siguiente, se pierden 24-72 horas. Multiplicado por 20 técnicos al mes, son cientos de horas-hombre tiradas en re-pegar tareas que ya estaban hechas.
Una PWA (Progressive Web App) mobile-first resuelve esto: el técnico cierra la visita en sitio, con firma del cliente, fotos antes/después, encuesta NPS y comentarios opcionales. Todo se sincroniza solo apenas hay conexión. No hay app que descargar, no hay tienda que aprobar, no hay versiones que actualizar en flota.
En esta guía revisamos qué hace una buena PWA de servicio técnico, qué errores matan la adopción, y cómo lo implementa Lahr Nexa FIELD para empresas de mantenimiento, climatización, seguridad electrónica, equipamiento médico y servicios industriales chilenos.
En esta guía
Por qué PWA y no una app nativa
Para un servicio técnico distribuido en flota, la PWA tiene 5 ventajas concretas sobre una app nativa iOS/Android:
- No requiere instalación. El técnico abre el link y empieza a usarla. Si tienes 100 técnicos en distintas empresas (subcontratistas, casa matriz, freelancers), el onboarding pasa de horas a minutos.
- Funciona en cualquier teléfono. Android viejo, iPhone nuevo, tablet con Android, no importa. Mientras tenga navegador moderno, corre.
- Actualizaciones automáticas. No hay versiones obsoletas en flota. El próximo refresh trae la nueva versión.
- Sin tienda. No esperas la revisión de App Store o Play Store (que puede tardar semanas).
- Trabaja offline. Con service workers bien implementados, el técnico puede cerrar visitas sin señal.
Las desventajas son menores en este caso de uso: no necesitas acceso a hardware específico (NFC, Bluetooth profundo), no necesitas push notifications agresivos, y la UX puede ser tan buena como una app nativa si el desarrollo está bien hecho.
Flujo ideal de una visita técnica
Una visita técnica bien instrumentada en PWA tiene 8 pasos. Cada uno debe demorarse menos de 30 segundos en condiciones normales.
| Paso | Acción | Tiempo objetivo |
|---|---|---|
| 1 | Check-in con geolocalización | 5 s |
| 2 | Confirmar cliente y orden de trabajo | 10 s |
| 3 | Fotos "antes" (mínimo 2) | 30 s |
| 4 | Registrar tareas ejecutadas | 1-3 min |
| 5 | Fotos "después" (mínimo 2) | 30 s |
| 6 | Captura de firma del cliente | 20 s |
| 7 | Encuesta NPS (1 pregunta) | 10 s |
| 8 | Check-out con tiempo total | 5 s |
Total overhead administrativo: 3-5 minutos por visita. Compárese con la versión en papel: 5 minutos en sitio + 15-20 minutos de digitalización posterior por administrativo + correo de validación al cliente. La diferencia anual para una flota de 10 técnicos haciendo 6 visitas/día es enorme.
Modo offline: el detalle que define todo
El 30% de las visitas técnicas chilenas ocurre en lugares con señal mala o nula: subterráneos, bodegas frigoríficas, mineras, edificios con jaula de Faraday, galpones rurales. Si la PWA solo funciona online, los técnicos vuelven a usar papel y pierdes el caso de uso.
Qué tiene que pasar offline
- Abrir la lista de visitas asignadas (cargadas la última vez con señal).
- Capturar fotos, firma y formularios.
- Persistir todo en almacenamiento local (IndexedDB).
- Cuando vuelve la señal: sincronizar en background sin que el técnico haga nada.
- Notificar al técnico solo si hay un conflicto que requiere su atención.
Cómo implementarlo
El patrón estándar es Service Worker + IndexedDB + Background Sync API. En Lahr Nexa FIELD se hace así:
- Service worker intercepta requests y los enruta a una cola si no hay red.
- IndexedDB guarda cada visita en formato JSON con sus blobs (fotos, firma).
- Cuando window.online vuelve a true, una promesa de retry vacía la cola en paralelo controlado (max 3 visitas simultáneas para no saturar).
- El backend valida idempotencia con un UUID por visita (evita duplicados si la sincronización se reintenta).
Firma del cliente con validez legal en Chile
La Ley 19.799 sobre documentos electrónicos y firma electrónica en Chile distingue entre firma electrónica simple (FES) y firma electrónica avanzada (FEA). Para una OT de servicio técnico, la FES es suficiente siempre que:
- Identifique a la persona que firma (nombre, RUT, cargo).
- Sea atribuible (capturada en un dispositivo conocido, con sello de tiempo).
- Mantenga la integridad del documento (hash del documento + firma).
En la práctica, una firma capturada en canvas HTML5 con los metadatos correctos cumple. El cliente firma con el dedo en la pantalla del técnico, se guarda en PNG, se ata al PDF del cierre y se hashea con SHA-256 + timestamp.
El PDF resultante se manda por email al cliente como respaldo y queda en el sistema para descarga. Si el cliente reclama en 6 meses que "yo nunca firmé esa visita", el sistema reproduce el PDF con todos los metadatos (IP, geo, hora, foto del técnico, hash).
NPS en sitio: cómo y cuándo preguntarlo
NPS (Net Promoter Score) en servicio técnico se mide con una sola pregunta: "¿Cuán probable es que recomiendes nuestro servicio a un colega?" (escala 0-10). Las claves para que funcione en mobile:
- Preguntar al final, no al principio. Después de la firma del cliente, no antes.
- Que aparezca al cliente, no al técnico. El cliente toca el número en la pantalla del técnico. Si el técnico marca por él, la data no sirve.
- Comentario libre opcional. Si dio <7, mostrar campo de texto opcional pidiendo qué mejorar.
- No bloquear el cierre si no responde. Mejor tener 70% de respuesta voluntaria que 100% obligada.
Cálculo del NPS
Para servicio técnico industrial chileno, un NPS entre 30 y 50 es bueno; entre 50 y 70 es excelente. Si está bajo 20, hay un problema sistémico que ni capacitación en sitio resuelve.
¿Tus técnicos siguen cerrando con papel y la oficina digitaliza después?
FIELD digitaliza el cierre en sitio: firma, NPS, fotos, offline-first. El cliente recibe el PDF al instante.
Probar FIELD →Errores que matan la adopción
Error 1 — Forzar al técnico a llenar 30 campos
Si la pantalla del técnico tiene 30 inputs obligatorios, vuelve al papel a las dos semanas. Diseña el flujo con lo mínimo indispensable + campos opcionales que suman puntos en su KPI.
Error 2 — No considerar guantes y calor
El técnico industrial chileno trabaja con guantes, en plantas a 35°C en verano y con dedos transpirados. Botones de 20px no funcionan. Mínimo 48px de altura y áreas de toque generosas. Probar con guantes puestos.
Error 3 — Login que expira a diario
Si la PWA cierra sesión cada 8 horas, el técnico va a tener que loguearse otra vez en su primera visita del día, posiblemente sin señal. Solución: sesión larga (30 días) con refresh tokens y autenticación local rápida (PIN o biométrico).
Error 4 — Cargar todas las visitas históricas en el dispositivo
Si la PWA descarga 5.000 visitas históricas al hacer login, el storage del teléfono se llena. Cargar solo el horizonte útil (próximas 2 semanas + últimas 2 para consulta).
Error 5 — No diferenciar foto "antes" de "después"
Si el técnico solo sube fotos sin etiqueta, la oficina no puede armar el reporte de cierre para el cliente. Forzar etiquetado antes / durante / después al subir cada foto. Una vez incorporado en el hábito, deja de ser fricción.
La PWA no es la magia. La magia es que el técnico cierre la visita en sitio con el cliente delante. La tecnología solo debe quitarse del medio. Si lo logras, el ciclo de cobro se acorta días, los reclamos bajan y los técnicos no odian el sistema.