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 administrativo se acorta. Si vuelve con una hoja firmada que alguien digitaliza al día siguiente, se pierden días. Multiplicado por todas las visitas del mes, son horas-hombre gastadas en volver a escribir 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. La meta es que cada uno tome pocos toques y que el técnico no escriba nada que el sistema ya sabe.
| Paso | Acción | Qué registra el sistema |
|---|---|---|
| 1 | Check-in con geolocalización | Hora y ubicación de llegada |
| 2 | Confirmar cliente y orden de trabajo | Vínculo visita ↔ OT |
| 3 | Fotos "antes" (mínimo 2) | Evidencia del estado inicial |
| 4 | Registrar tareas ejecutadas | Checklist de la OT |
| 5 | Fotos "después" (mínimo 2) | Evidencia del trabajo terminado |
| 6 | Captura de firma del cliente | Conformidad del cliente |
| 7 | Encuesta NPS (1 pregunta) | Satisfacción de la visita |
| 8 | Check-out con tiempo total | Hora de salida y duración |
Compárese con la versión en papel: se llena en sitio, después alguien la digitaliza en la oficina y luego se envía un correo de validación al cliente. Con la PWA, la visita queda registrada una sola vez, en el momento en que ocurre.
Modo offline: el detalle que define todo
Muchas visitas técnicas ocurren 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 distingue dos tipos (art. 2, letras f y g): la firma electrónica, que en la práctica se llama "simple" y permite identificar al menos formalmente al autor, y la firma electrónica avanzada, que exige un prestador de certificación acreditado. En una OT de servicio técnico se usa firma electrónica simple, y para que sirva como respaldo conviene 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, eso se resuelve con una firma capturada en pantalla y guardada junto a sus metadatos. 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 pocas respuestas voluntarias y honestas que respuestas obligadas.
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.