Cómo una empresa de servicio técnico de 24 personas puso en marcha una app para empleados en 10 semanas

La empresa que nos llamó no quería una app. Quería dejar de perder una hora cada tarde en la misma conversación: un técnico llama a la oficina, dicta qué trabajos se han hecho, qué materiales se han usado y qué cliente no estaba en casa. Alguien en la oficina lo anota todo, lo teclea en tres sistemas y descubre una semana después que faltan dos partes de trabajo y que una factura está mal. Ese era el problema de verdad. La app fue solo la forma que acabó tomando la solución.

Este es un caso práctico sobre un proyecto real, anonimizado. Se trata de una empresa de instalación y mantenimiento de 24 personas —piense en calefacción, ventilación y los avisos relacionados— que opera por toda una región, con ocho furgonetas en la carretera casi todos los días. Cambiamos algunos detalles identificativos y no pretendemos que las cifras sean ciencia auditada. Pero la historia es cierta, incluidas las partes en las que nos equivocamos y tuvimos que dar marcha atrás. Esas partes suelen ser las más útiles, así que las hemos dejado.

Si dirige un negocio de servicio de campo y le han presupuestado seis cifras y un plazo de nueve meses para una app para empleados, esto es el contraargumento. Diez semanas, un alcance enfocado y una herramienta que los técnicos abrían por su cuenta sin que nadie los persiguiera. Así fue como salió.

El problema: un negocio que funciona a base de papel y llamadas

Cuando nos sentamos con el dueño y la responsable de oficina, la queja superficial era «necesitamos digitalizarnos». Esa frase no significa nada por sí sola, así que la ignoramos y observamos el trabajo. Pasamos un día en la oficina y una mañana de copiloto en una furgoneta. A la hora de comer, el problema real era evidente, y no tenía nada que ver con que la tecnología fuera vieja.

Cada técnico llevaba un portapapeles con partes de trabajo de papel autocopiativo. En el aviso, garabateaba el trabajo hecho, marcaba unas casillas, anotaba los materiales y hacía firmar al cliente. La copia superior volvía a la oficina en algún momento: a veces esa misma tarde, a veces el viernes en un montón arrugado. La oficina tecleaba entonces cada parte en la herramienta de planificación, otra vez en el software de facturación y una tercera vez en una hoja de cálculo que el dueño usaba para controlar qué trabajos eran facturables. Tres veces tecleando lo mismo. Dos de esas veces introduciendo errores nuevos.

El coste no eran solo las horas de oficina. Era el retraso. Un trabajo terminado el lunes podía no facturarse hasta la semana siguiente, porque el papel aún no había aparecido. Había clientes que llamaban preguntando por trabajos que la oficina ni sabía que se habían hecho. Y cuando un parte se perdía por completo —lo cual pasaba más de lo que nadie admitía—, ese trabajo simplemente no se facturaba nunca. Nadie sabía decirnos cuánto dinero se escapaba así, lo cual ya era revelador en sí mismo.

Lo que deliberadamente no construimos

La forma más rápida de reventar un plazo de diez semanas es decir que sí a todo. Así que antes de escribir una sola línea de código, escribimos una lista de cosas que la app no haría, y conseguimos que el dueño la aprobara en voz alta. Esta es la parte menos vistosa de cualquier proyecto y la mayor razón, sin discusión, de que saliera a tiempo.

La lista de deseos, reunida en dos conversaciones, tenía unas treinta funciones. Seguimiento GPS de furgonetas. Un portal de reservas para clientes. Inventario de todo el almacén. Optimización automática de rutas. Un CRM completo. Partes de daños con fotos y anotaciones. Control de presencia con exportación a nóminas. Cada una era una idea razonable. Cada una era también una forma de no terminar nunca.

Recortamos el alcance a una sola frase, igual que le diríamos a cualquier pequeña empresa: un técnico debe poder ver los trabajos del día, registrar lo que ha hecho y que nadie tenga que volver a teclearlo jamás. Todo lo que no servía a esa frase fue a una lista de «más adelante, quizá». Esa lista todavía existe. Casi nada de ella se ha echado de menos.

• Fuera: seguimiento GPS de furgonetas, un aire a vigilancia que nadie del equipo quería, para resolver un problema que no tenían.
• Fuera: portal de reservas para clientes, un proyecto aparte con un público aparte; meterlo habría duplicado el plazo.
• Fuera: inventario completo de almacén, útil algún día, pero no en la ruta crítica hacia una facturación más rápida.
• Fuera: optimización de rutas, mucha complejidad y poco retorno real para la geografía de esta empresa.
• Dentro: lista de trabajos del día, partes digitales, captura de materiales, firma del cliente, fotos y sincronización instantánea con la oficina.

Lo que la app hace realmente

Reducida a su esencia, la app es casi aburridamente simple, y eso es un cumplido. Un técnico la abre por la mañana y ve sus trabajos del día, en orden, con la dirección, el cliente, el historial de ese sitio y lo que se espera que haga. Toca un trabajo, y todo lo que antes vivía en el portapapeles vive ahora en la pantalla.

Sobre el terreno registra el trabajo hecho desde una lista de comprobación breve, añade materiales desde una lista con buscador (de modo que «codo de cobre de 22 mm» son dos toques, no un juego de adivinar cómo se escribe), saca una foto o dos si hay que documentar algo y le pasa el teléfono al cliente para que firme con el dedo. Pulsa «hecho». Ya está. En cuanto tiene cobertura, todo se sincroniza con la oficina: sin llamada, sin papel, sin volver a teclear.

El detalle que más importó: funciona sin cobertura

Las apps de servicio de campo viven o mueren por una cosa que la demo nunca enseña: qué pasa en el cuarto de calderas de un sótano sin cobertura. Si la app se congela o pierde datos en cuanto desaparecen las barras, los técnicos la abandonarán en una semana y habrá construido un pisapapeles caro. Por eso la construimos offline-first desde el primer día. Todo funciona por completo sin conexión; el dispositivo guarda los datos y los sincroniza en cuanto puede. El técnico nunca piensa en ello, que es exactamente la idea.

El lado de la oficina: una pantalla, sin volver a teclear

La oficina no recibió un panel de control descomunal. Recibió una pantalla que muestra los trabajos a medida que se completan, cada uno con su parte, materiales, fotos y firma adjuntos. Desde ahí, un trabajo completado se convierte en una factura con los datos ya rellenos: la oficina la revisa y la envía, en lugar de teclearla desde cero. La conectamos con el software de facturación que ya usaban en lugar de sustituirlo, porque sustituir software que funciona a mitad de proyecto es como un plazo de diez semanas se convierte en uno de diez meses.

Las diez semanas, con honestidad

Diez semanas no es un número mágico; es lo que costó este alcance con una pareja diseñador-desarrollador y un cliente realmente implicado. Así se repartió el tiempo, más o menos, incluida la semana que perdimos, porque fingir que los proyectos salen perfectos no ayuda a nadie.

1. 1
   Semanas 1–2: observar, no preguntar

   Hicimos las rutas de copiloto, nos sentamos en la oficina y mapeamos el flujo de trabajo real en una pared. Escribimos el alcance de una frase y la lista de «no construimos», y conseguimos el visto bueno a ambos antes de diseñar nada.
2. 2
   Semanas 3–4: una forma con la que clicar

   Construimos un prototipo clicable —sin código real, solo pantallas— y lo pusimos en manos de dos técnicos. Su opinión tumbó tres de nuestras suposiciones pronto, que es el lugar más barato para equivocarse.
3. 3
   Semanas 5–7: construir el núcleo

   La lista de trabajos, los partes digitales, los materiales, la firma, las fotos y el motor de sincronización offline. La sincronización fue la parte difícil y se comió casi toda la semana 7.
4. 4
   Semana 8: la semana que perdimos

   La integración con facturación se nos resistió. La interfaz del software existente era más caprichosa de lo que decía su documentación, y quemamos una semana haciendo que los campos encajaran limpiamente. Mereció la pena: volver a teclear era todo el problema que estábamos resolviendo.
5. 5
   Semanas 9–10: piloto y pulido

   Dos furgonetas usaron la app de verdad mientras las otras seis seguían con papel. Arreglamos lo que sacó a la luz el piloto y luego la desplegamos para todos con una sola sesión de formación breve.

Conseguir que el personal de campo la use de verdad

Puede construir la mejor app de servicio de campo del mundo y verla morir porque un técnico de 55 años, con veinte años de memoria muscular de portapapeles, decide que no es para él. La adopción no es un problema técnico y no se resuelve con funciones. La tratamos como el proyecto real que es.

Tres cosas hicieron el trabajo de fondo. Primera, hicimos que el flujo sobre el terreno fuera más rápido que el papel, no solo digital: menos toques que garabatos, materiales que se seleccionan en lugar de deletrear, una firma en vez de perseguir una que sea legible. Si la app hubiera sido aunque fuera un poco más lenta que el portapapeles, habría fracasado, con razón. Segunda, elegimos con cuidado a los dos técnicos del piloto: uno respetado en silencio por los demás, otro abiertamente escéptico. Ganarse al escéptico valió más que cualquier campaña de marketing.

Tercera, a nadie se le hizo sentir tonto. La formación duró veinte minutos, la app era deliberadamente obvia y la responsable de oficina se convirtió en el punto de referencia durante las dos primeras semanas para que ningún técnico se sintiera tirado. En tres semanas los partes de papel habían desaparecido: no prohibidos, simplemente abandonados, porque la app era de verdad el camino más fácil.

Lo que cambió: los resultados

Aquí seremos prudentes, porque a los casos prácticos les encanta citar números precisos que se desmoronan en cuanto se preguntan. Estas cifras son de la propia empresa, tomadas unos meses después del despliegue, y son orientativas más que de laboratorio. Pero la dirección es inequívoca y coincide con lo que el dueño siente en el día a día.

Pero el titular que le importaba al dueño no estaba en esa tabla. Era la tesorería. Cuando las facturas salen el mismo día en lugar de una semana después, el dinero entra aproximadamente una semana antes en todo el negocio, en cada uno de los trabajos. Para una empresa de 24 personas que opera con márgenes ajustados, ese desplazamiento en el tiempo importó más que cualquier eficiencia aislada. Las horas de oficina recuperadas estuvieron bien. Cobrar una semana antes, cada vez, fue el verdadero premio.

Lo que le diríamos si está pensando en lo mismo

La mayoría de las lecciones de aquí no son específicas del servicio de campo. Es lo que le diríamos a cualquier pequeña empresa tentada de encargar software a medida, y valen más que la propia app.

Recorte el alcance sin piedad, y escriba su lista de «no construimos» antes que la de construir. Observe el trabajo real antes de diseñar nada: los dueños describen el proceso que les gustaría tener, no el que de verdad llevan. Pilote en pequeño y deje que los escépticos convenzan al resto. Y conéctese a las herramientas que ya usa en lugar de sustituirlas, al menos al principio. Nada de esto es ingenioso. Todo esto es lo que hizo posibles diez semanas en lugar de diez meses.

Una más, la silenciosa: la app nunca fue el objetivo. El objetivo era cobrar antes y dejar de teclear los mismos datos tres veces. Podríamos haber resuelto una parte con herramientas estándar, y para algunas empresas esa es la decisión correcta. Para esta, la mezcla revuelta de captura sobre el terreno, realidad sin conexión y un sistema de facturación existente hizo que un desarrollo a medida enfocado se amortizara rápido. La respuesta honesta a «¿app o estándar?» es: depende, y quien responde al instante le está vendiendo algo.

Preguntas frecuentes