El técnico termina una intervención, apunta lo que ha hecho en un papel y fotografía una avería. La foto se envía por WhatsApp, el parte firmado vuelve a la oficina y alguien copia después las horas y los materiales al programa de gestión. Si falta un dato, hay que llamar para reconstruirlo. Una pantalla con los mismos campos que el papel puede ahorrar la transcripción, pero deja intacto gran parte del problema.
Digitalizar partes de trabajo significa conseguir que la información de cada intervención avance con el trabajo: desde que se solicita y asigna hasta que se revisa y se utiliza en oficina. El parte digital es una pieza de ese recorrido. Para diseñarla bien, primero hay que entender el recorrido completo.
Digitalizar un parte no es convertir el papel en un formulario
Imagina una empresa que instala y mantiene equipos en las instalaciones de sus clientes. Sus partes en papel tienen casillas para fecha, dirección, horas, materiales y firma. La solución más rápida parece evidente: reproducir esas casillas en el móvil y añadir un botón «Guardar».
Es un avance si antes alguien tenía que descifrar la letra y volver a teclear el contenido. Pero el formulario, por sí solo, no responde a preguntas que condicionan el trabajo diario: ¿sabe el técnico a qué equipo va?, ¿aparecen ya los datos del cliente?, ¿qué pasa si encuentra otra avería?, ¿quién revisa el resultado?, ¿cómo llegan los materiales a facturación? Si esas decisiones siguen resolviéndose por llamadas, mensajes y hojas aparte, hemos cambiado el soporte del parte sin ordenar el proceso.
- Parte en papel
- Mismos campos en una pantalla
- Archivo o PDF
El documento cambia de formato; las decisiones y los traspasos siguen fuera.
- Trabajo solicitado y asignado
- Técnico consulta y registra la intervención
- Responsable revisa lo ocurrido
- Oficina recibe datos utilizables
La información acompaña al trabajo y llega a quien debe actuar después.
Esto no significa que el papel anterior no sirva para nada. Sus campos pueden revelar qué necesita conocer la empresa y qué suele pedir el cliente. Conviene conservar esa experiencia, pero también observar lo que el documento no muestra: una visita aplazada, una fotografía sin identificar, un material que se agotó o un trabajo terminado que nadie ha validado todavía.
Una forma sencilla de empezar es seguir una intervención real durante un día. Anota quién la crea, qué sabe cada persona al recibirla, qué información se genera en campo y qué hace oficina al final. Señala cada vez que alguien vuelve a escribir un dato, busca una foto o pregunta por el estado del trabajo. Esos puntos muestran dónde debe ayudar la herramienta; todavía no obligan a elegir entre un formulario, una aplicación o una función del sistema que ya utilizas.
Si el recorrido tiene muchas excepciones o participan varias personas, conviene definirlo antes de encargar pantallas. El análisis de requisitos de software sirve precisamente para ordenar usuarios, pasos y reglas a partir del trabajo real. El primer acuerdo que conviene alcanzar es qué representa exactamente un «parte de trabajo» en vuestra empresa.
Primero define qué es realmente un «parte de trabajo» en tu empresa
Dos empresas pueden llamar «parte de trabajo» a cosas distintas. Para una, es la constancia de una visita al cliente; para otra, describe una reparación concreta. También puede documentar una instalación, una inspección o la actividad de una jornada. Antes de elegir campos o pantallas, hay que decidir qué hecho representa cada parte.
Imagina que un técnico acude a un edificio para revisar tres equipos de climatización. En el primero no encuentra problemas; en el segundo cambia una pieza; el tercero queda pendiente porque falta un repuesto. ¿Debe rellenar un parte por la visita o tres partes, uno por equipo? Las dos opciones pueden funcionar. La respuesta depende de lo que la empresa necesite consultar y continuar después.
Resulta útil si se revisa y se entrega el trabajo como una sola visita. Dentro del parte, cada equipo necesita conservar su resultado para no mezclar «completado» con «pendiente».
Permite seguir y cerrar cada actuación por separado. La herramienta debe mantener visible que las tres pertenecen al mismo desplazamiento.
Fíjate en la decisión que aparece debajo: ¿qué unidad necesita un resultado propio? Si una actuación puede quedar pendiente mientras las demás se cierran, quizá deba distinguirse dentro del parte o registrarse en uno independiente. Si un responsable necesita aprobarla por separado, localizar sus fotografías o volver otro día solo para terminarla, esa separación se vuelve aún más importante.
El papel actual puede dar una pista, pero no debería dictar la respuesta. A veces hay un formulario por técnico porque así se archiva desde hace años, aunque cada hoja reúna varias visitas. O se crea una hoja nueva cada vez que alguien vuelve al mismo cliente, aunque todo forme parte de una intervención todavía abierta. Copiar esa costumbre sin examinarla puede dejar una aplicación llena de registros difíciles de relacionar.
Prueba con diez trabajos recientes, incluidos uno sencillo, uno que requirió una segunda visita y otro con varias actuaciones. Para cada caso, pregunta: «Si busco este trabajo dentro de seis meses, ¿qué necesito encontrar junto y qué necesito distinguir?». Revisa si debe verse por cliente, instalación, equipo, visita o actuación. No hace falta convertir todas esas palabras en apartados de la aplicación: sirven para descubrir cómo trabaja realmente la empresa.
Una definición breve ayuda a fijar el criterio: «En nuestra empresa, un parte describe [esta unidad de trabajo] y se considera terminado cuando [ocurre esto]». Si la frase no sirve para los casos habituales, todavía falta concretarla. Con esa base podremos separar, en el siguiente paso, el trabajo que se pide del trabajo que finalmente se realiza.
Parte de trabajo y orden de trabajo no son necesariamente lo mismo
La oficina recibe una llamada: «La cámara frigorífica no enfría; necesitamos que la revisen hoy». Ese mensaje describe lo que se pide. Cuando el técnico llega, encuentra una fuga, toma fotografías y anota que necesita un repuesto para terminar. Eso describe lo que ocurrió. Si guardamos ambas cosas en el mismo campo, al final no sabremos si «reparar la cámara» era una instrucción, una tarea pendiente o un trabajo ya realizado.
En muchas empresas resulta útil distinguir una orden de trabajo, que organiza lo solicitado, de un parte de trabajo, que deja constancia de una actuación. La orden puede reunir cliente, ubicación, equipo, prioridad, descripción inicial y persona asignada. El parte recoge lo que se comprobó, lo que se hizo y el resultado de una intervención concreta. No son listas universales de campos: la diferencia importante es separar la intención del hecho.
El cliente comunica el problema y oficina asigna la intervención.
Se localiza la fuga; falta un repuesto y el trabajo sigue pendiente.
Se sustituye la pieza, se comprueba el equipo y se registra el resultado.
La segunda visita del ejemplo no debería convertir retrospectivamente el primer parte en «reparación completada». En aquella primera intervención la reparación no se completó: hubo un diagnóstico y quedó pendiente un material. Conservar esa diferencia permite responder a preguntas muy concretas: ¿cuándo se detectó el problema?, ¿qué se hizo en cada desplazamiento?, ¿por qué hubo que volver? También evita que la orden aparezca cerrada solo porque un técnico terminó de rellenar un parte.
La relación entre ambos registros no obliga a crear una pantalla adicional por principio. En una empresa pequeña, una solicitud sencilla puede resolverse en una sola visita y el usuario puede percibirlo como un único flujo. Aun así, conviene que la información conserve dos significados: qué se encargó y qué se realizó. Así se puede registrar una segunda actuación sin sobreescribir la primera cuando el caso deja de ser sencillo.
También hay trabajos que empiezan sin planificación formal: una urgencia recibida directamente por el técnico, por ejemplo. La herramienta debe permitir registrar ese origen real y vincularlo después con la solicitud o el expediente correspondiente, si la empresa los utiliza. Forzar a inventar una orden anterior solo para rellenar una casilla daría una apariencia de orden a un dato falso.
Quizá tu empresa no emplee la palabra «orden». Puede hablar de aviso, incidencia, ticket o solicitud. Mantén los nombres que el equipo entiende; lo que hay que comprobar es si podéis distinguir la petición inicial de cada actuación y saber cuándo el trabajo completo queda resuelto. Con esa distinción clara, ya se puede dibujar el recorrido que sigue cada uno desde que entra el aviso hasta que oficina lo da por cerrado.
Dibuja el proceso actual antes de diseñar la aplicación
Después de distinguir la petición del trabajo realizado, llega una pregunta menos vistosa que elegir una app: ¿qué ocurre hoy, paso a paso, con una intervención real? No dibujes todavía el proceso que te gustaría tener. Si una fotografía se manda por WhatsApp o una persona vuelve a escribir el parte en el ERP, inclúyelo. Es precisamente ahí donde la digitalización puede resolver algo concreto.
Sigamos con una empresa de mantenimiento ficticia. Un cliente avisa de una avería; oficina prepara el trabajo; un técnico acude, registra lo que encuentra y consigue la conformidad del cliente; después, otra persona revisa los datos para facturar. Sobre el papel parece un recorrido corto. Al seguirlo de cerca aparecen los traspasos que una pantalla nueva podría dejar intactos.
-
OficinaRecibe el aviso
Cliente, ubicación y problema comunicado.
-
OficinaPrepara y asigna el trabajo
Entrega los datos que el técnico necesita para salir.
-
TécnicoConsulta e interviene
Comprueba el equipo y resuelve o documenta lo pendiente.
-
TécnicoRegistra el resultado
Parte, fotografías, materiales y conformidad si procede.
-
OficinaRecibe y revisa
Comprueba si falta información o hace falta otra visita.
-
AdministraciónPrepara la facturación
Traslada al sistema los datos del trabajo validado.
El mapa es útil cuando anotas también cómo pasa la información de una persona a otra. ¿La orden sale impresa o llega al móvil? ¿Las fotos llevan el número del trabajo o quedan en una conversación? ¿El parte vuelve el mismo día? ¿Administración puede utilizar sus datos o tiene que preguntar qué material se instaló? Esas respuestas explican más sobre el futuro sistema que una lista inicial de funciones.
Para hacerlo en tu empresa basta una hoja con cinco columnas: paso, quién actúa, información que recibe, qué hace y qué entrega al siguiente. Recorre primero un trabajo habitual y luego uno que no salió como se esperaba. Si alguien dice «esto lo resolvemos por teléfono», no lo elimines del dibujo: anota qué decisión se tomó y dónde quedó registrada. Un proceso real tiene atajos, esperas y excepciones; ocultarlos solo hace que reaparezcan fuera de la aplicación.
Marca con un círculo los puntos donde un dato se copia de nuevo, un documento espera a alguien o se pierde el estado del trabajo. No todos necesitan una automatización. A veces basta con mostrar la información correcta al técnico; otras, con dar a oficina una forma clara de revisar lo recibido. El resultado de este ejercicio no es el diseño de las pantallas: es un recorrido compartido sobre el que después podremos decidir quién necesita hacer qué.
Identifica quién interviene en cada paso
En el mapa anterior hay una casilla llamada «oficina». Pero puede esconder a quien atiende el aviso, a quien organiza las visitas y a quien comprueba lo realizado. Si diseñamos una única pantalla «para oficina», quizá nadie sepa qué tarea le toca cuando el técnico devuelve un parte incompleto.
Conviene describir responsabilidades, no puestos en un organigrama. En una empresa pequeña, una persona puede coordinar las visitas y preparar las facturas. En otra, esas tareas se reparten entre departamentos. El proceso debe seguir siendo comprensible en ambos casos: para cada paso, alguien recibe información, toma una decisión o realiza una acción y entrega algo a la siguiente persona.
Cliente
Explica la necesidad, facilita el acceso y, cuando corresponde, recibe o confirma el resultado. No tiene por qué entrar en la herramienta interna.
Coordinación
Comprueba los datos de la solicitud, asigna el trabajo y reorganiza la visita si surge un imprevisto.
Técnico
Consulta lo necesario antes de salir, registra lo ocurrido en campo y señala lo que queda pendiente.
Responsable
Revisa las intervenciones que requieren criterio o aprobación. En algunos negocios esta revisión solo existe para determinados trabajos.
Administración
Recibe los datos ya revisados para preparar facturación, archivo o seguimiento, sin reconstruir el trabajo a partir de mensajes sueltos.
La utilidad de esta lista se ve cuando algo no sale según lo previsto. Si falta el repuesto de la cámara frigorífica, el técnico debe poder dejar constancia de lo que encontró; coordinación necesita saber que hay que organizar otra visita; quizá un responsable deba decidir si se pide una pieza distinta; administración necesita evitar tratar ese trabajo como definitivamente cerrado. No todos necesitan recibir la misma alerta ni ver la misma pantalla.
Para cada participante, prueba tres preguntas con un caso real: ¿qué necesita saber antes de actuar?, ¿qué puede decidir o registrar?, ¿quién necesita lo que produce? Si la respuesta es «alguien de oficina lo mirará», vuelve a concretarla. Esa indefinición suele convertirse en partes esperando revisión, avisos que nadie atiende o trabajos que parecen terminados hasta que llega la factura.
Esto también ayuda a no pedirle al técnico que resuelva asuntos ajenos a su intervención. Puede describir que utilizó una pieza y que no pudo terminar la reparación; decidir el precio final o emitir la factura quizá corresponda a otra persona. Del mismo modo, una firma o conformidad del cliente no debería obligarlo a navegar por el sistema interno. Cada intervención debe pedir a cada persona solo lo que puede aportar en ese momento.
Deja escrita una frase por responsabilidad: «Cuando el técnico marca un trabajo como pendiente, coordinación recibe el aviso y decide la siguiente visita». Más adelante concretaremos los permisos con los que cada persona puede consultar o modificar los datos. De momento, el objetivo es saber quién toma el relevo y desde dónde llega el primer trabajo.
Define dónde empieza realmente el trabajo
El parte se rellena al intervenir, pero el trabajo suele empezar antes. Puede nacer de una llamada, un correo, un formulario de la web, una incidencia registrada en el programa de gestión o una revisión periódica ya planificada. Incluso puede descubrirlo un técnico mientras atiende otra avería. Si la herramienta solo comienza cuando alguien abre el parte, todo lo que se decidió antes tendrá que explicarse otra vez.
La primera distinción útil es entre recibir una señal y crear un trabajo que ya se puede asignar. Un mensaje como «la cámara hace ruido» todavía puede necesitar una ubicación, un contacto o una comprobación para saber si hay que enviar a alguien. Un mantenimiento programado, en cambio, quizá ya tenga fecha, equipo y tareas previstas. No conviene exigir a ambos la misma información en el mismo momento.
Volvamos a la cámara frigorífica. Si el cliente ya tiene una ficha en el programa de gestión, no debería volver a escribir su dirección completa en un formulario ni hacerlo después el técnico en el parte. Conviene recuperar o seleccionar el cliente y la instalación correctos, y añadir solo lo nuevo: qué sucede, desde cuándo y a quién llamar para acceder. Si alguno de esos datos no se conoce todavía, es mejor marcarlo como pendiente de confirmar que inventarlo para pasar de pantalla.
También hay que decidir qué entrada se convierte en el registro de referencia. Un cliente puede enviar un correo y llamar cinco minutos después para asegurarse de que lo han visto. Eso no son necesariamente dos trabajos. Alguien debe poder reconocer que ambos contactos hablan del mismo problema, conservar la información útil y evitar que salgan dos técnicos para una sola avería. No hace falta automatizar esa decisión desde el primer día; sí definir quién la toma y dónde queda visible.
Para descubrir el punto de partida real, toma cinco trabajos recientes y sigue el primer rastro de cada uno: ¿dónde apareció la necesidad?, ¿quién la recibió?, ¿qué datos existían ya?, ¿cuándo se decidió actuar?, ¿qué tuvo que completar la persona que lo asignó? Si el trabajo entra por un canal informal, inclúyelo. El objetivo es que la futura herramienta se adapte a una entrada que ocurre de verdad y no obligue a mantener un segundo registro paralelo.
Cuando esas vías de entrada están claras, cada trabajo puede conservar su origen y continuar sin perderse entre mensajes, fichas y partes. El siguiente paso será darle una identidad estable para relacionar todo lo que ocurra después.
Asigna un identificador único desde el principio
«La reparación de García del martes» puede bastar en una conversación, pero deja de servir cuando ese cliente tiene varios equipos, trabajan dos técnicos o hace falta volver la semana siguiente. Un identificador único permite decir «hablamos de este trabajo» aunque cambien la fecha prevista, la persona asignada o la descripción inicial.
Sigamos con la cámara frigorífica. La solicitud queda registrada como OT-2841. La primera visita produce el parte PT-5628: se localiza la fuga y se documenta la pieza que falta. La segunda produce PT-5639: se instala el repuesto y se comprueba el funcionamiento. Son códigos inventados para el ejemplo, pero la relación importa: una orden puede reunir varias actuaciones y cada parte debe seguir siendo reconocible por sí mismo.
Revisar la cámara frigorífica del cliente.
Diagnóstico, fotografías y material pendiente.
Repuesto utilizado, prueba y resultado final.
La fotografía del equipo averiado debe quedar asociada al parte de la primera visita, no solo guardada como «foto_camara.jpg» en una carpeta. Lo mismo ocurre con materiales, observaciones, documentos y comunicaciones. Si alguien consulta la orden meses después, debe poder recorrer sus actuaciones y entender qué evidencia corresponde a cada una. También podrá generar un documento o consultar una factura sin tener que adivinar a qué intervención se refieren.
La identidad del registro no debería depender de datos que pueden cambiar. La dirección puede corregirse; una visita puede aplazarse; el técnico asignado puede ser sustituido. Tampoco es buena idea utilizar solo «cliente + fecha»: una empresa puede atender al mismo cliente dos veces en el mismo día. Un código legible ayuda a hablar del trabajo, mientras que el sistema puede mantener internamente su propia referencia estable. Lo importante para quien lo usa es que ambos conduzcan siempre al mismo registro.
El identificador debe aparecer cuando nace el trabajo o el parte, no al generar el PDF al final. Así puede acompañar desde el principio a la fotografía tomada en campo, a la nota sobre un repuesto o a una llamada a oficina. Si el aviso llega dos veces —por correo y por teléfono—, primero hay que comprobar si se refiere al mismo trabajo; añadir ambos contactos a una referencia existente evita duplicarlo sin borrar cómo se comunicó la incidencia.
Para revisar tu proceso, toma un parte reciente y pregunta: «Si elimino el nombre del cliente y la fecha, ¿puedo seguir relacionando sus fotos, materiales y visitas con el trabajo correcto?». Si la respuesta depende de que alguien recuerde la historia, falta una identidad compartida. El siguiente paso será distinguir qué información ya conocía la empresa antes de la visita y cuál se generó durante ella.
Separa los datos que ya conoces de los que nacen en la intervención
Cuando el técnico abre un trabajo, la empresa suele saber ya a qué cliente va, dónde está la instalación y qué equipo debe revisar. Pedirle que vuelva a escribirlo en el móvil añade tiempo y abre la puerta a tres formas distintas de nombrar el mismo equipo. El parte debería empezar con ese contexto disponible y reservar la escritura para lo que se descubre o sucede durante la visita.
A los datos compartidos que se mantienen entre trabajos —cliente, instalación, equipo, contacto o catálogo de materiales— se les suele llamar datos maestros. El parte, en cambio, produce datos de una actuación concreta: qué se encontró, cuánto tiempo se empleó, qué material se utilizó, qué fotografías se tomaron y cómo terminó el trabajo. El catálogo puede contener «filtro modelo X»; el parte registra que en esta visita se instalaron dos unidades.
- Cliente y persona de contacto
- Dirección e instalación
- Equipo que se va a revisar
- Catálogo de materiales disponibles
- Horas y desplazamiento realizados
- Materiales y cantidades utilizados
- Observaciones y fotografías
- Resultado y pendientes
La distinción parece simple hasta que un dato conocido está mal. Imagina que la orden indica la cámara frigorífica A, pero al llegar el técnico descubre que la averiada es la B. No conviene obligarlo a fingir que trabajó en la A, ni cambiar silenciosamente la ficha general del cliente desde el parte. Necesita poder señalar la discrepancia, registrar dónde intervino realmente y dejar a la persona responsable la corrección del dato compartido.
También importa conservar lo que se sabía en aquel momento. Si un cliente cambia de dirección meses después, el parte de la visita anterior debe seguir mostrando dónde se hizo el trabajo. La ficha actual del cliente puede evolucionar; el histórico de una intervención no debería reescribirse como si hubiera ocurrido en la dirección nueva. Esta pequeña precaución evita confusiones cuando se consultan fotos, documentos o trabajos antiguos.
Para revisar los campos de tu parte, haz dos columnas: «esto existe antes de salir» y «esto solo puede saberse al intervenir». Junto a cada dato previo, anota dónde se mantiene y quién puede corregirlo. Junto a cada dato nuevo, anota quién lo registra y quién lo utilizará después. Si el técnico copia a mano algo que ya figura en la ficha del cliente, has encontrado una repetición. Si todos escriben una observación libre para describir materiales o resultados que luego hay que contar, el siguiente paso será decidir qué tipo de dato conviene pedir en cada caso.
No todos los campos deben ser texto libre
Un campo llamado «Observaciones» parece una solución cómoda: el técnico escribe lo que quiera y puede terminar el parte. El problema aparece después, cuando oficina necesita saber cuántos filtros se han instalado, qué trabajos siguen pendientes o cuánto material debe anotarse en el sistema de gestión. Si toda la respuesta está escondida en frases diferentes, una persona tendrá que volver a leer e interpretar cada parte.
Piensa en esta anotación: «Cambiado motor y 2 filtros; el conector antiguo no encaja bien». Para quien estuvo allí puede ser suficiente. Para quien prepara materiales, consulta el histórico o revisa la facturación, mezcla al menos tres datos: el trabajo realizado, las cantidades utilizadas y una incidencia que merece explicación.
«Cambiado motor y 2 filtros; el conector antiguo no encaja bien»
Se entiende al leerlo, pero cuesta buscar, contar o trasladar cada dato por separado.
- Trabajo
- Sustitución
- Materiales
- Motor × 1 · Filtro × 2
- Observación
- El conector antiguo no encaja bien.
La observación sigue existiendo para explicar lo que una lista no puede anticipar.
El tipo de campo debería responder al uso posterior del dato. Una cantidad necesita un número y, cuando corresponda, una unidad. Un material que ya existe en catálogo se puede seleccionar en lugar de escribir su nombre de cinco maneras. Una fecha merece un campo de fecha si después hay que ordenar visitas. Una fotografía debe quedar asociada al trabajo y a lo que muestra, no perdida en una conversación. El texto libre conserva su valor para diagnósticos, matices e imprevistos.
Incluso una casilla aparentemente sencilla puede necesitar más cuidado. «Equipo revisado: sí/no» no deja expresar que no se pudo comprobar porque el cliente no permitió el acceso. Si esa situación ocurre, conviene ofrecer una opción «no comprobado» y permitir explicar por qué. Forzar un «sí» o un «no» para poder cerrar el parte no mejora la calidad de la información; la disfraza.
Tampoco se trata de convertir cada frase en veinte menús. Demasiados selectores ralentizan una intervención y pueden obligar al técnico a elegir algo que no describe el caso. Empieza por aquello que se repite, se consulta o alimenta un paso posterior. Deja espacio para registrar excepciones y revisa las opciones con quienes trabajan en campo: una lista creada solo desde oficina puede omitir precisamente los casos que más tiempo consumen.
Un ejercicio útil es leer una muestra de partes recientes y subrayar qué elementos aparecen una y otra vez: tipo de actuación, resultado, materiales, cantidades o motivo de una segunda visita. Pregunta después quién necesita consultar o sumar cada dato. Esa respuesta orienta el formato del campo. Una vez elegido, queda otra decisión igual de importante: cuándo es realmente obligatorio rellenarlo y cuándo debe poder quedar pendiente.
Qué campos deben ser obligatorios y cuáles pueden esperar
«Pongámoslo todo obligatorio para que no falte información» parece una buena medida hasta que el técnico necesita guardar una visita que aún no ha terminado. Si la aplicación exige las horas finales, una firma y un material utilizado antes de conocerlos, puede acabar introduciendo un cero, eligiendo cualquier opción o dejando el parte fuera del sistema. La pantalla quedará completa; la información, no.
La pregunta útil no es solo si un dato es importante, sino en qué momento puede conocerse y para qué paso hace falta. Un contacto o una ubicación pueden ser necesarios para asignar la intervención. El resultado no se conoce hasta después de trabajar. Una cantidad de material solo tiene sentido si se ha utilizado material. La obligatoriedad debe acompañar el recorrido, no imponerse por igual desde la primera pantalla.
Qué se necesita revisar, dónde y con quién coordinar el acceso. Si falta un dato, queda visible como pendiente de confirmar.
El técnico registra hallazgos y puede conservar un borrador aunque todavía no sepa el resultado final.
Resultado o motivo por el que sigue pendiente, junto con los datos que oficina necesita para revisar el trabajo.
También cambia el requisito según el trabajo. En una instalación puede ser esencial identificar el equipo colocado y su número de serie. En una visita de diagnóstico quizá todavía no exista material consumido. Una fotografía puede ser necesaria para documentar una avería concreta y no aportar nada en otra actuación. La firma del cliente, cuando forme parte del proceso, no debería impedir registrar que estaba ausente: en ese caso, lo importante es conservar el motivo y el estado del trabajo.
Conviene distinguir tres respuestas que un formulario mal diseñado suele mezclar: «cero», «no aplica» y «aún no lo sé». Cero materiales utilizados es un dato; no aplica puede significar que esa clase de trabajo nunca consume materiales; desconocido indica que falta comprobarlo. Si todos terminan guardados como una casilla vacía, oficina tendrá que preguntar qué quiso decir el técnico.
La validación tampoco tiene que ser siempre un bloqueo. Puede avisar de que falta una foto antes de cerrar el parte, permitir guardar un borrador o exigir una explicación cuando se marca un trabajo como pendiente. Bloquear solo lo que realmente impide el siguiente paso reduce los atajos y hace más fiables los datos. Si una situación excepcional no encaja, debe existir una forma explícita de comunicarla, no una invitación a inventar la respuesta esperada.
Para decidirlo, toma cada campo propuesto y pregunta: «¿quién lo necesita, para hacer qué, y en qué momento?». Después pruébalo con un trabajo normal y otro interrumpido. Si la misma lista de obligatorios funciona únicamente en el caso perfecto, aún no representa el trabajo real. La siguiente decisión será qué campos comparten todas las intervenciones y cuáles deben cambiar según su tipo.
Formularios diferentes para trabajos diferentes
Una empresa puede instalar equipos, revisarlos cada seis meses y reparar averías. Las tres visitas comparten cliente, lugar, técnico y resultado, pero no necesitan las mismas preguntas. Pedir el número de serie de un equipo nuevo en cada revisión, o mostrar una lista de comprobaciones de mantenimiento durante una reparación urgente, convierte el parte en una pantalla larga que el técnico aprende a saltarse.
La solución no tiene por qué ser una aplicación distinta para cada trabajo. Puede haber una base común y apartados que aparezcan cuando aportan información útil. Así, oficina conserva una forma coherente de localizar todas las intervenciones, mientras cada técnico recibe un formulario que corresponde a lo que va a hacer.
Equipo colocado, número de serie y comprobación de puesta en marcha.
Revisiones previstas, hallazgos y próxima actuación si corresponde.
Avería encontrada, trabajo realizado y resultado de la prueba.
Normalmente el tipo de trabajo se conoce al prepararlo: «instalación», «revisión» o «reparación». Esa elección puede cargar una plantilla inicial, pero no debe convertirse en una trampa. Si se programó un mantenimiento y el técnico descubre una avería, necesita registrar el hallazgo. Según cómo trabaje la empresa, podrá añadir una actuación de reparación al mismo trabajo o abrir otra relacionada. Lo que no debería hacer es esconder la avería en una observación genérica porque el formulario no ofrece otro lugar.
Tampoco todas las reparaciones son iguales. Puede haber comprobaciones que solo se piden para ciertos equipos o resultados que exigen una fotografía. Conviene empezar con unas pocas diferencias que ya existen en el trabajo real y ampliar solo cuando se observe una necesidad repetida. Crear veinte tipos de parte desde el primer día puede resultar tan difícil de usar como un único formulario interminable.
Para encontrar la estructura adecuada, reúne varios partes de instalación, mantenimiento y reparación. Señala en un color lo que aparece en todos y en otro lo que solo tiene sentido en uno. Después pregunta a quien trabaja en campo si esos campos específicos se conocen siempre, en qué momento y qué hace cuando el encargo cambia al llegar al sitio. Esa conversación evita diseñar categorías perfectas sobre el papel que no encajan con la intervención.
La prueba final es sencilla: un técnico debe poder abrir un trabajo habitual y reconocer enseguida qué se le pide; oficina debe poder comparar los datos comunes sin reconstruir tres documentos incompatibles. A partir de esa estructura, podemos tratar con más cuidado uno de los contenidos que más se acumulan en los partes: las fotografías.
Fotografías: no basta con permitir adjuntar imágenes
Una carpeta con treinta fotos de máquinas puede parecer un buen historial hasta que alguien necesita saber cuál muestra la avería, cuál corresponde al equipo reparado y si se tomó antes o después de intervenir. Permitir abrir la cámara desde el parte es útil; dar sentido a cada imagen es lo que permite utilizarla más tarde.
En la reparación de la cámara frigorífica, por ejemplo, tres fotos podrían responder a preguntas distintas. Una vista general ayuda a reconocer el equipo y su ubicación. Un detalle muestra la fuga o la pieza dañada. Una imagen posterior enseña el resultado de la sustitución. No todas las visitas necesitan las tres: la secuencia sirve para decidir qué debe poder reconocer otra persona sin haber estado allí.
Una vista suficiente para identificar el equipo o la zona intervenida.
La avería, la pieza o la condición que motivó la actuación.
Una imagen posterior cuando ayuda a comprender el trabajo realizado.
La herramienta debería asociar la foto al parte sin que el técnico tenga que inventar nombres de archivo. Puede pedir una descripción breve cuando no sea evidente lo que muestra y permitir indicar si corresponde al estado inicial, a un hallazgo o al resultado final. Si hubo dos visitas para el mismo trabajo, la foto de la primera no debe aparecer como si documentara la reparación de la segunda.
También hay que decidir cuándo pedirla. En ciertas reparaciones una fotografía puede ayudar a revisar el diagnóstico o a preparar la siguiente visita; en otras, no añade información. Hacerla obligatoria para todo invita a adjuntar imágenes irrelevantes. Si era necesaria y no pudo tomarse —por falta de acceso o porque el equipo estaba en una zona donde no se permitía fotografiar—, conviene registrar el motivo en vez de sustituirla por una imagen cualquiera.
El uso en campo impone condiciones prácticas. La imagen debe conservar suficiente detalle para leer una placa o distinguir una pieza; comprimirla demasiado la vuelve inútil. Pero enviar archivos enormes desde una conexión inestable puede retrasar el cierre del parte. Conviene comprobar la calidad antes de guardar y mostrar claramente si la foto se ha enviado o sigue pendiente de carga. El funcionamiento sin cobertura merece un diseño propio que veremos más adelante.
Por último, piensa en el archivo que se va formando: cómo se localizan las fotos, cuánto espacio ocupan, quién puede verlas y qué copias se conservan. Evita capturar personas, documentos o espacios ajenos al trabajo cuando no aportan nada. Una prueba sencilla: abre un parte antiguo y pide a alguien de oficina que encuentre la foto relevante, explique qué muestra y diga a qué visita pertenece. Si necesita preguntar al técnico, el problema no es la cámara: falta contexto alrededor de la imagen.
Las fotos pueden ayudar a comprender una intervención, pero no sustituyen por sí solas otras decisiones del proceso. La siguiente es aclarar qué significa realmente que el cliente firme el parte.
Firma del cliente: qué significa dentro del proceso
Al terminar la visita, el técnico acerca el móvil y pide una firma. ¿Qué está confirmando la persona que firma? Puede ser que el técnico acudió, que recibió una copia del parte o que está conforme con un trabajo terminado. Son cosas distintas. Si la pantalla solo dice «Firme aquí», el trazo se guarda, pero su significado queda abierto a interpretaciones.
Antes de añadir un recuadro para dibujar con el dedo, decide qué hecho necesitas dejar claro y en qué momento. En nuestra cámara frigorífica, la primera visita terminó con un diagnóstico y una reparación pendiente. Pedir una firma que parezca confirmar «trabajo completado» daría una impresión equivocada. Si se solicita constancia de esa visita, la persona debería poder leer que el equipo sigue pendiente de un repuesto.
Confirma que hubo una actuación en un lugar y una fecha.
La persona tuvo acceso a lo que el técnico registró.
Requiere dejar claro con qué trabajo o resultado se expresa esa conformidad.
La persona necesita ver un resumen legible antes de firmar: qué intervención se hizo, qué quedó pendiente y qué observaciones constan. El sistema debería asociar la acción al parte concreto y a la versión que se mostró, además de registrar cuándo ocurrió y a quién se presentó. Si después se corrige una cantidad o se añade un trabajo no incluido, no conviene modificar silenciosamente el contenido anterior como si fuera exactamente el que se enseñó en ese momento.
También deben existir salidas reales para los casos en los que no hay firma. El cliente puede estar ausente, no querer firmar o discrepar de la descripción. El técnico debe poder registrar cuál de esas situaciones ocurrió y continuar con el estado apropiado. Bloquear el parte hasta obtener cualquier garabato incentiva una captura que no explica nada; permitir indicar la causa conserva información útil para oficina y para la siguiente comunicación con el cliente.
Un trazo dibujado en una pantalla, un acuse de recepción y un proceso de firma electrónica con requisitos específicos no se diseñan como si fueran lo mismo. Si el proyecto necesita formalizar una aceptación contractual o cumplir una exigencia concreta de identificación y firma, hay que definir ese alcance por separado y elegir el mecanismo adecuado. El Reglamento europeo eIDAS distingue tipos de firma electrónica; no basta con llamar «firma digital» a una imagen del trazo para resolver esa necesidad.
La pregunta práctica para tu empresa es esta: «Si la persona firma —o no firma—, ¿qué debe poder entender oficina sin llamar al técnico?». La respuesta define el texto que se muestra, las alternativas y el paso siguiente del trabajo. Con esa claridad, podemos pasar a otro dato que suele acabar en una nota ilegible si no se diseña bien: los materiales utilizados.
Materiales y repuestos utilizados: registra lo que pasó, no una lista vaga
«Dos tubos, tornillos y cosas varias» puede recordar al técnico qué llevó a una visita, pero deja a oficina sin saber qué se instaló, qué volvió a la furgoneta y qué hay que pedir para terminar. Si el parte debe ayudar a preparar otra intervención, revisar existencias o facturar, los materiales necesitan algo más de estructura que una frase al final.
Primero distingue material previsto o transportado de material realmente utilizado. El técnico puede salir con tres filtros y colocar solo dos; el tercero no debería aparecer como consumido por el mero hecho de haber viajado en la furgoneta. También puede descubrir que necesita un motor que no llevaba: ese motor queda pendiente de conseguir, no instalado.
Material disponible al empezar la visita.
Unidades que sí se colocaron en esta intervención.
Repuesto necesario para poder terminar en otra visita.
Para cada material que se registra, suele ayudar elegir una referencia reconocible del catálogo, indicar cantidad y unidad, y aclarar qué ocurrió con él. «Filtro × 2» es más útil que «unos filtros»; «tubo × 2 metros» no equivale a «tubo × 2 unidades». Si un artículo no está en catálogo, debe poder describirse sin elegir otro parecido para salir del paso. Después alguien podrá revisar si esa descripción merece incorporarse como referencia habitual.
Hay casos que requieren más detalle: el número de serie de un equipo instalado, un lote determinado o la pieza retirada. No hace falta pedir esos datos en cada parte; sí identificar en qué trabajos permiten continuar el servicio o reconocer exactamente el componente intervenido. El formulario debe ajustarse al material y al uso posterior de la información, no convertir cada tornillo en un expediente.
El técnico sabe qué utilizó y qué encontró. El precio final, la repercusión al cliente y la emisión de la factura pueden corresponder a otra persona. Por eso conviene separar el registro de consumo de las decisiones comerciales. Cuando partes, existencias y facturación forman una misma operativa, el caso se acerca al software de gestión y ERP; primero hay que dejar claro qué dato nace en campo y quién lo valida antes de actualizar el resto.
Revisa tres partes recientes y pregunta a administración: «¿Podrías saber, sin llamar al técnico, qué se llevó, qué se utilizó, qué hay que reponer y qué queda pendiente para la siguiente visita?». Si la respuesta depende de interpretar una nota libre, ya sabes qué diferencia debe recoger el parte digital. Con los materiales claros, toca hacer lo mismo con otro dato que suele reducirse a «tres horas»: el tiempo de trabajo y desplazamiento.
Horas, desplazamientos y tiempos: «tres horas» no cuenta toda la intervención
Un técnico sale a las 9:00, llega a las 9:30, trabaja hasta las 10:15, espera una autorización y termina a las 12:00. Si el parte solo dice «3 horas», oficina no puede saber cuánto se dedicó al trabajo, cuánto al trayecto ni por qué se detuvo la intervención. Antes de añadir un cronómetro a la aplicación, hay que decidir qué tiempos necesita entender la empresa y para qué.
La hora de inicio y la de fin sitúan la intervención en el tiempo, pero su diferencia no equivale necesariamente a horas de trabajo. Un desplazamiento puede registrarse aparte; una espera puede deberse al acceso a la instalación, a una autorización o a una pieza; una interrupción puede dividir el trabajo en dos tramos. Solo pide esa distinción cuando tenga una consecuencia útil para planificar, revisar el servicio o preparar la facturación. Registrar cada minuto sin propósito solo crea carga y datos poco fiables.
Conviene decidir también qué marca cada botón. «Iniciar» puede significar que el técnico sale hacia el cliente o que empieza a trabajar en el lugar. «Finalizar» puede significar que deja de intervenir, que sale de la instalación o que cierra el parte después de escribir observaciones. Si dos personas interpretan esos eventos de manera diferente, un reloj automático dará cifras precisas en apariencia, pero difíciles de comparar. Etiquetas claras y la posibilidad de corregir un olvido con motivo registrado suelen ser más útiles que un cronómetro rígido.
Los tiempos de varios técnicos en una misma visita tampoco deben fundirse en una única cifra. Una intervención de dos horas con dos personas puede representar dos horas de duración del servicio y cuatro horas-persona de dedicación. Si hay varias visitas para una misma orden, conserva el tiempo de cada una y permite obtener el total de la orden sin perder cómo se repartió. Así la oficina puede explicar la intervención y preparar la siguiente sin reconstruir agendas y mensajes.
Hay una frontera importante: el parte describe la ejecución de un trabajo para un cliente. El control horario laboral persigue otra finalidad y puede exigir su propio proceso, reglas y tratamiento de datos. Que ambos utilicen horas no significa que el tiempo anotado en una intervención deba sustituir automáticamente al registro de jornada. Si la empresa necesita ambas cosas, hay que definir por separado qué registra cada sistema y si algún dato puede compartirse con sentido.
Como prueba sencilla, toma una intervención con trayecto o espera y pregunta: «¿Podemos distinguir cuánto duró la visita, cuánto se trabajó, qué interrumpió el servicio y qué tiempo corresponde a cada persona?». El parte digital debe responder según las decisiones reales de tu empresa. Una vez capturados esos datos, el siguiente paso es saber en qué situación queda el trabajo: pendiente, en curso, finalizado o listo para revisión.
Los estados convierten el parte en un proceso
El técnico termina la intervención y guarda el parte. ¿Ya puede facturarse? Quizá falta revisar una fotografía, confirmar un material o comprobar si el cliente aceptó el trabajo. Un documento guardado no responde por sí solo a esas preguntas. Los estados indican en qué punto está el trabajo, quién tiene la siguiente acción y qué falta para darlo por cerrado.
- 01PendienteHay trabajo por organizar.
- 02AsignadoUn técnico sabe qué debe atender.
- 03En cursoLa intervención se está realizando.
- 04FinalizadoEl técnico ha terminado su parte.
- 05RevisadoOficina comprueba los datos.
- 06FacturableEstá preparado para el siguiente trámite.
- 07CerradoNo quedan acciones pendientes.
La distinción más útil suele estar entre «el técnico ha terminado» y «la empresa ha dado el trabajo por bueno». Si ambos momentos se llaman «cerrado», los partes incompletos pueden llegar a administración como si ya estuvieran listos. Separarlos permite que quien revisa vea qué trabajos esperan su decisión sin tener que abrir todos los documentos uno a uno.
Un estado debe tener una consecuencia clara. Al pasar de «pendiente» a «asignado», alguien recibe el trabajo. Al pasar de «en curso» a «finalizado», puede exigirse la información indispensable de esa intervención. Al pasar a «revisado», se confirma que el parte puede continuar. La pregunta no es cuántos nombres caben en un menú, sino qué cambia al hacer cada transición: permisos, avisos, campos disponibles, responsabilidades o acciones posteriores.
También conviene definir quién puede mover el trabajo y cuándo puede volver atrás. El técnico puede corregir un borrador; después de entregar el parte, una rectificación quizá requiera explicación o revisión. Si oficina detecta una fotografía ausente, puede devolverlo con una indicación concreta en lugar de editar silenciosamente el relato de la intervención. Así cada persona sabe si le toca actuar y qué información necesita para hacerlo.
No todas las empresas necesitan siete estados. En una operativa pequeña quizá basten «pendiente», «en curso», «por revisar» y «cerrado». En otra, «facturable» puede ser decisivo porque la revisión y la emisión de la factura recaen en personas distintas. Empieza con los puntos donde hoy un parte se pierde, se queda esperando o avanza antes de tiempo; esos puntos revelan los estados necesarios.
Prueba a tomar cinco trabajos recientes y preguntar para cada uno: «¿Quién tenía que hacer algo después y cómo lo supo?». Si la respuesta depende de una llamada o de recordar qué WhatsApp llegó primero, el proceso necesita una señal visible. Y si el trabajo no se pudo completar, no basta con marcarlo «finalizado»: hay que representar qué ocurrió y qué paso queda pendiente.
Una intervención no siempre termina bien
El técnico llega y no puede entrar. O abre el equipo y descubre que la avería es otra. Si el parte solo ofrece «finalizado» y «pendiente», cualquiera de las dos opciones es engañosa: la visita sí ocurrió, pero el trabajo previsto no quedó resuelto. Esa diferencia determina qué debe hacer la oficina y qué conviene contar al cliente.
Registrar el intento y acordar una nueva cita.
Identificar quién puede facilitar la entrada.
Indicar cuál es y quién debe conseguirla.
Describirla y decidir si requiere otro alcance.
Conviene ofrecer motivos reconocibles —cliente ausente, dirección incorrecta, acceso imposible, equipo distinto al previsto, material insuficiente o nueva avería— y dejar sitio para describir lo que ocurrió. Un selector facilita ver patrones; la observación evita que un caso real se fuerce dentro de una categoría que no le corresponde. No hace falta crear cincuenta opciones: empieza por las causas que hoy obligan a llamar al técnico para entender el parte.
Después de la causa viene la acción pendiente. Si falta una pieza, anota qué referencia o característica se necesita y quién la solicitará. Si el cliente no estaba, indica cómo se reprogramará. Si el trabajo realizado fue solo una parte del previsto, conserva qué quedó resuelto y qué no. Así la siguiente persona no vuelve al lugar con la misma información incompleta.
Una segunda visita puede continuar la misma orden, pero debe tener su propio registro de lo que sucedió ese día: técnico, fecha, fotografías, materiales y tiempo. Si se mezcla todo en un único parte editable, se pierde la secuencia y cuesta explicar por qué hubo dos desplazamientos. El vínculo entre orden y partes permite ver el trabajo completo sin borrar la historia de cada visita.
La interfaz no debería castigar estas situaciones. Si «cerrar» exige marcar el trabajo como resuelto o conseguir una firma imposible, aparecerán respuestas de compromiso. Es mejor permitir terminar la visita como no completada y mantener el trabajo pendiente de una decisión. Esta distinción enlaza con los estados del apartado anterior: el parte puede estar entregado a oficina mientras la orden sigue abierta.
Haz una prueba con los últimos casos que acabaron en otra visita. ¿Puede saberse desde el parte por qué ocurrió, qué se hizo ya, qué falta y quién debe mover el siguiente paso? Si no, el proceso digital todavía está diseñado solo para cuando todo sale según lo previsto. Y la siguiente dificultad suele aparecer incluso antes de poder enviar el parte: trabajar donde no hay cobertura.
Qué ocurre cuando no hay cobertura
El técnico termina el trabajo en un sótano, toma fotografías y pulsa «Guardar». La pantalla vuelve al listado. Para él, el parte está entregado; para oficina, todavía no existe. Esa diferencia es el verdadero problema de trabajar sin cobertura: guardar en el dispositivo y recibir en el sistema no son el mismo hecho.
El técnico puede seguir trabajando, pero oficina aún no lo ve.
La aplicación intenta transmitir datos y fotografías.
El sistema confirma qué parte y adjuntos han llegado.
Hay varias respuestas posibles, y no todas requieren una aplicación plenamente offline. Si las intervenciones se hacen siempre donde hay conexión fiable, se puede exigir conexión para enviar el parte. Si la cobertura falla de forma ocasional, quizá baste con guardar un borrador local y permitir enviarlo después. Si el trabajo habitual transcurre en naves, sótanos, zonas rurales o instalaciones sin red, el modo sin conexión pasa a ser parte central del diseño: el técnico debe poder consultar lo necesario, registrar la intervención y continuar sin que se pierda nada.
Antes de prometer «funciona offline», concreta qué estará disponible. ¿Podrá abrir una orden asignada antes de perder señal? ¿Verá la dirección, el equipo y las instrucciones? ¿Podrá añadir materiales del catálogo o solo escribirlos? ¿Se guardarán también las fotografías y la firma? Una pantalla que se abre sin red pero necesita consultar al servidor para cada selector no resuelve una intervención real. También hay que decidir cuánto tiempo permanecen esos datos en el dispositivo y qué ocurre si este se pierde.
El envío posterior necesita una confirmación comprensible. La aplicación debería distinguir guardado localmente, enviando, recibido y error que requiere atención. Si una foto pesada falla pero el texto llega, el usuario debe saberlo; de lo contrario, oficina verá un parte aparentemente completo y pedirá la imagen días después. Tampoco conviene borrar la copia local en cuanto empieza el envío: primero hay que comprobar que el destino recibió el contenido esperado.
Esta decisión influye en la herramienta que se elija. Que una solución sea accesible desde el móvil no garantiza trabajo sin conexión; una web, una PWA o una app pueden ofrecerlo en distintos grados si se diseñan almacenamiento, sincronización y recuperación. La elección técnica viene después de observar dónde trabajan los técnicos, cuánto duran los periodos sin señal y qué información deben llevar consigo. El desarrollo de aplicaciones tiene sentido cuando la operativa de campo necesita ese comportamiento y no basta con un formulario conectado.
Haz una prueba antes de decidir: acompaña una intervención real, activa el modo avión en el momento habitual de trabajo y sigue el recorrido completo hasta que oficina confirme la recepción. Anota qué datos faltan, qué mensajes generan dudas y qué pasa con los adjuntos. En el siguiente paso aparece otra pregunta: si oficina cambia una orden mientras el técnico trabaja sin conexión, ¿cómo se reconcilian ambas versiones?
Sincronización y conflictos: cuando dos personas cambian el mismo trabajo
Oficina corrige la dirección de una orden a las 10:05. El técnico, sin cobertura, sigue viendo la anterior y añade al parte fotografías y observaciones a las 10:20. Cuando vuelve la conexión, ambos cambios llegan al mismo trabajo. Si la aplicación decide que «gana la última versión», puede borrar una corrección útil o sustituir el relato de la visita. Sincronizar no consiste solo en enviar lo que quedó pendiente: también hay que saber qué cambió mientras tanto.
Corrige la dirección de la orden.
Añade fotos y observaciones con la copia que tenía.
La primera distinción es sencilla: dos cambios diferentes no tienen por qué competir. Si oficina actualiza la dirección y el técnico incorpora fotografías, normalmente se pueden conservar ambos. El conflicto aparece cuando los dos modifican el mismo dato —por ejemplo, la dirección, el equipo atendido o el estado del trabajo— o cuando un cambio invalida una decisión tomada con información anterior.
Para reconocerlo, cada parte y cada orden necesitan identidad estable, una versión conocida al empezar la edición y un registro de cuándo se hizo cada cambio y por quién. Las horas ayudan a reconstruir la secuencia, pero no deberían usarse como única regla para decidir qué valor es correcto. Una modificación realizada más tarde puede basarse en datos desactualizados; «último en llegar» tampoco significa «mejor informado».
Las reglas deben adaptarse al dato. Algunas adiciones, como fotografías identificadas de forma individual, pueden enviarse sin reemplazar el resto del parte. Si dos personas corrigen una misma observación, quizá convenga mostrar ambas versiones para que alguien elija o conserve una nota de rectificación. Si oficina cancela la orden mientras el técnico trabaja offline, al volver la señal no basta con incorporar el parte y marcarlo cerrado: hay que avisar de que la intervención se hizo sobre una orden cuyo estado cambió.
El usuario necesita una salida comprensible. «Error de sincronización» no explica si sus datos siguen guardados ni qué debe hacer. Un mensaje útil puede indicar: «Tu parte está guardado en este dispositivo; la orden cambió mientras estabas sin conexión. Revisa la dirección antes de enviarlo». Mientras se resuelve, el trabajo local debe seguir disponible y el sistema debe impedir que un reintento duplique materiales, fotografías o partes completos.
En una prueba de campo, edita una orden desde oficina mientras un dispositivo está sin conexión; cambia en ambos lados primero datos distintos y después el mismo campo. Reconecta y comprueba qué se conserva, qué se señala para revisión y qué ve cada persona. Si la respuesta depende de cuál fue el último dispositivo en enviar, aún falta diseñar la regla de negocio. Con los datos sincronizados, la siguiente prioridad será que el técnico pueda terminar el parte sin pelearse con la pantalla.
El técnico debe poder terminar el parte rápidamente
Una pantalla puede funcionar perfectamente en el despacho y resultar desesperante delante de una máquina, con una mano ocupada, guantes, reflejos en el móvil y el cliente esperando. Si terminar el parte exige recorrer veinte campos pequeños y escribir lo que la empresa ya sabe, la herramienta no ha digitalizado el trabajo: ha trasladado la carga administrativa al final de la visita.
Cliente, equipo, tarea y datos que faltan para cerrar.
Fotografía, material, resultado y observación en el momento adecuado.
Borrador claro, errores visibles y confirmación del envío.
La primera pantalla debería responder a «¿dónde estoy y qué tengo que hacer?». Un técnico necesita reconocer la orden, el cliente, el lugar y el equipo antes de registrar nada. Después, conviene presentar los datos según la secuencia del trabajo: observaciones y fotografías cuando se producen; materiales cuando se usan; revisión final cuando la intervención acaba. Es más fácil completar una información breve en su momento que reconstruirla al llegar a la furgoneta.
Los controles importan. Un botón que hay que acertar con precisión de escritorio, un selector con cien opciones sin búsqueda o un campo que abre el teclado para elegir una fecha ralentizan el parte. Etiquetas legibles, áreas táctiles cómodas, contraste suficiente y acciones principales claramente visibles ayudan también cuando hay reflejos o se trabaja con una sola mano. Si se usan guantes, hay que probar la interacción en esa situación: ningún diseño puede compensar por sí solo un dispositivo que no detecta el toque.
«Rápido» no significa esconder toda la información en una sola pantalla. Un recorrido corto por pasos reconocibles puede resultar más ágil que un formulario interminable, siempre que permita volver sin perder lo escrito. El técnico debe saber qué falta para terminar y por qué. Un error mostrado solo después de pulsar «Finalizar», lejos del campo afectado, obliga a buscarlo entre páginas y fomenta respuestas de relleno.
También hay interrupciones: una llamada, una comprobación adicional, un cambio de lugar o la pérdida de señal. El parte debe conservar el avance y permitir retomarlo sin empezar de cero. Si contiene fotografías o una firma, la pantalla tiene que confirmar que se han guardado antes de que el técnico se marche. La sensación de rapidez desaparece en cuanto alguien tiene que repetir una visita para recuperar una imagen que la aplicación parecía haber aceptado.
La prueba más reveladora es observar a un técnico cerrar tres partes reales desde su dispositivo habitual, en el lugar y condiciones de trabajo. Cuenta dónde se detiene, qué dato busca en otro sistema y qué escribe de memoria después. Esas fricciones indican qué precargar, qué simplificar y qué dejar como excepción. El siguiente paso será reducir escritura sin perder la calidad de la información.
Reducir escritura sin perder calidad de información
Si el técnico visita por quinta vez el mismo equipo, no debería volver a escribir a mano el nombre del cliente, la dirección, el modelo y la referencia de la máquina. Pero tampoco conviene rellenar todo automáticamente y darlo por cierto: quizá el equipo instalado ya no coincide con el que figura en la ficha. La buena solución ahorra escritura sin ocultar qué datos se han reutilizado y cuáles se han comprobado en campo.
Se muestran desde la orden para reconocer el trabajo, con una vía clara para comunicar un error.
Opciones buscables y recientes evitan teclear, pero permiten escoger el dato correcto.
Una observación breve conserva los detalles que ningún catálogo puede anticipar.
La primera fuente de rapidez son los datos ya disponibles. Abrir el parte desde una orden puede incorporar cliente, instalación, equipo y trabajo previsto. Si la empresa dispone de un catálogo de materiales, el técnico puede buscar una referencia en lugar de inventar un nombre nuevo en cada visita. Las opciones recientes ayudan cuando se utilizan a menudo las mismas piezas, siempre que no se conviertan en una selección automática difícil de detectar.
Las plantillas sirven para trabajos repetitivos, como una revisión periódica con comprobaciones conocidas. Deben preparar la estructura, no marcar todas las comprobaciones como correctas antes de realizarlas. Un valor por defecto razonable puede ahorrar pasos; uno que simula una inspección hecha degrada el parte. La pregunta es si el técnico está confirmando un hecho observado o simplemente aceptando lo que apareció en pantalla.
Un código QR o una etiqueta NFC pueden ayudar a identificar una instalación o un equipo cuando existe un inventario fiable y las etiquetas se mantienen. No resuelven por sí solos las diferencias entre lo que figura en el sistema y lo que el técnico encuentra. Si el código está dañado o lleva a una ficha equivocada, debe existir una búsqueda manual y una forma de registrar la discrepancia sin escoger un equipo parecido para avanzar.
El dictado puede ser útil para una observación larga, pero hay que probarlo en entornos ruidosos y revisar el texto antes de cerrar. Los catálogos, el autocompletado y el dictado son ayudas para capturar un hecho, no sustitutos de su comprobación. Cuando un dato no encaja en las opciones, es mejor permitir una descripción excepcional que forzar una respuesta falsa solo para terminar el formulario.
Para decidir qué simplificar, observa qué campos repite el técnico en varios partes y cuáles corrige después oficina. Los primeros son candidatos a precarga o selección; los segundos señalan que la ayuda actual puede estar introduciendo errores. El objetivo no es ganar una competición de clics: es que el parte se complete con menos esfuerzo y siga sirviendo para planificar, revisar y facturar. Con esa información preparada, toca definir qué ocurre exactamente al pulsar «Finalizar».
Qué ocurre cuando el técnico pulsa «Finalizar»
«Finalizar» parece un botón sencillo. En la práctica, puede ser el momento en que el técnico declara terminada su intervención, el parte deja de ser un borrador y otra persona empieza a trabajar con esos datos. Si la aplicación solo guarda el formulario y muestra «Hecho», nadie sabe si faltan fotografías, si oficina debe revisarlo o si llegó a los demás sistemas. El botón debe iniciar una transición visible, no esconder varias decisiones bajo una palabra.
Resultado, observaciones o evidencias que realmente se necesitan.
El técnico ve si el parte queda enviado, local o pendiente.
Revisión, aviso, documento o integración cuando corresponda.
La primera comprobación debe ser contextual. Una instalación puede requerir el número de serie y una prueba de puesta en marcha; una visita sin acceso necesita el motivo y el próximo paso, pero no una fotografía del equipo que no se pudo ver. Si falta algo obligatorio, la pantalla debe señalar exactamente qué es y permitir volver allí sin borrar lo ya escrito. Pedir los mismos campos para todos los resultados del trabajo produce datos inventados.
Después hay que definir qué cambia. ¿El parte queda bloqueado para el técnico? ¿Puede corregirse una errata? ¿Debe conservarse una versión anterior si se rectifica? ¿La orden sigue abierta porque falta otra visita? Estas decisiones dependen del proceso de la empresa. Lo importante es que «finalizado» describa un hecho operativo reconocible: el técnico ha terminado de registrar lo que ocurrió en esa intervención.
El sistema puede encadenar otras tareas, pero no debe confundirlas con el cierre del técnico. Puede avisar a oficina, preparar un documento para el cliente, dejar el parte en una cola de revisión o enviar datos a un ERP. Cada una puede fallar por separado. Si el parte se guardó pero la conexión con otro sistema no respondió, la pantalla y oficina deben verlo como intervención finalizada, envío pendiente; pedir al técnico que repita todo el parte convertiría un fallo técnico en trabajo duplicado.
La confirmación final debería responder a tres preguntas: «¿Se ha guardado lo que hice?», «¿Quién lo verá ahora?» y «¿Queda algo que deba hacer yo?». Una respuesta útil puede ser: «Intervención finalizada; pendiente de revisión por oficina». Si aún está en el dispositivo, debe decirlo con la misma claridad. Y si el técnico cerró una visita incompleta, el mensaje debe conservar la acción pendiente en vez de celebrar un trabajo resuelto.
Para probar este paso, termina un parte normal, otro con un dato imprescindible ausente y otro sin conexión. Observa qué mensaje aparece, qué estado queda registrado y qué ve oficina. Si el resultado solo puede explicarse mirando la base de datos o preguntando al desarrollador, el cierre todavía no está diseñado para las personas que dependen de él. El siguiente apartado profundiza en una de esas transiciones: revisar y aprobar antes de facturar.
Revisar y aprobar antes de facturar
El técnico puede haber descrito correctamente lo que hizo y, aun así, el parte no estar listo para una factura. Quizá hay un material pendiente de valorar, una visita cubierta por mantenimiento o una observación que cambia lo acordado con el cliente. Terminar la intervención y aprobar su tratamiento administrativo son decisiones distintas; mezclarlas obliga a corregir a posteriori documentos o importes que se dieron por buenos demasiado pronto.
Deja constancia del trabajo, los materiales y las incidencias.
Contrasta el parte con la orden y resuelve lo que falta.
Aplica acuerdos, precios y condiciones del cliente.
La revisión necesita un criterio concreto. Puede comprobar que la intervención corresponde a la orden correcta, que el resultado se entiende, que las fotografías requeridas están presentes y que los materiales utilizados se distinguen de los pendientes. Si hubo una segunda visita, conviene ver qué se hizo en cada una. La pregunta no es «¿están rellenos todos los campos?», sino «¿podemos continuar sin inventar ni preguntar de nuevo qué pasó?».
Cuando algo no cuadra, debe poder devolverse con un motivo. «Falta identificar el repuesto instalado» permite al técnico responder; «parte rechazado» solo abre una conversación por teléfono. La devolución no debería borrar la versión entregada ni convertir la corrección en una edición invisible. Así se conserva qué información recibió oficina y qué se aclaró después.
La aprobación administrativa tampoco equivale a cobrar todas las líneas que aparecen en el parte. Una pieza puede estar incluida en un contrato, una visita puede corresponder a garantía o una espera puede no repercutirse al cliente. El técnico registra hechos; la persona autorizada aplica las condiciones comerciales. Separar ambos planos evita que una casilla «facturable» en el móvil sustituya decisiones que dependen del acuerdo con cada cliente.
El sistema debería mostrar una cola de partes por revisar, con el motivo de atención cuando exista, y dejar claro quién aprobó o devolvió cada uno. Solo después puede pasar a «listo para facturación», si ese estado resulta útil en la empresa. Si la factura se genera en otro programa, el dato que viaja debe ser el aprobado, no una copia prematura del borrador de campo.
Para comprobar si el proceso está bien definido, toma un parte que necesitó una llamada antes de facturar. ¿Qué duda surgió, quién la resolvió y cómo quedó registrada la respuesta? Si el sistema permite repetir ese recorrido sin depender de la memoria de las personas, la revisión ya cumple su función. El siguiente paso es decidir si, además de los datos estructurados, alguien necesita recibir un PDF del parte.
¿Hace falta generar un PDF del parte?
«El programa tiene que sacar el parte en PDF» suele aparecer al principio de una reunión porque hoy existe una hoja que se imprime o se envía por correo. A veces el PDF sí es necesario; otras, se conserva por costumbre aunque nadie lo consulte. Antes de diseñar su aspecto, conviene preguntar quién necesita ese documento, en qué momento y para hacer qué.
Orden, visita, resultado, materiales, tiempos, fotografías y estado.
Un cliente puede necesitar una copia clara de lo realizado; un contrato puede pedir un justificante; un proveedor puede solicitar un formato concreto. En esos casos, el documento debe responder al destinatario: identificar la visita, explicar qué se hizo, qué quedó pendiente y, si procede, mostrar las evidencias adecuadas. No conviene volcar todos los campos internos ni incluir notas que solo sirven a oficina.
También importa cuándo se genera. Si el técnico lo envía al terminar, quizá deba reflejar que la intervención está pendiente de revisión. Si se entrega después de aprobar el parte, puede incorporar datos validados. En ambos casos es útil reconocer la versión presentada: un cambio posterior en materiales o descripción no debería reescribir silenciosamente el documento que recibió el cliente. Puede generarse una nueva versión o una rectificación identificable.
El PDF no debería ser la única fuente para buscar o reutilizar información. Si materiales, tiempos y estados viven solo dentro de archivos, oficina tendrá que abrirlos uno a uno para saber qué facturar o qué trabajos están pendientes. El parte digital conserva esos datos en campos utilizables; el documento se compone a partir de ellos cuando alguien lo necesita. Así pueden convivir un justificante cómodo de leer y una gestión que no depende de copiar datos desde el PDF.
Las fotografías merecen una decisión propia. Incluirlas todas puede producir archivos pesados y poco claros; omitirlas siempre puede quitar valor al justificante. Selecciona cuáles sirven para explicar el resultado al destinatario y conserva el resto asociado al parte. La firma, cuando exista, también debe acompañarse del contexto de qué se presentó y aceptó, según lo definido en el apartado dedicado a su significado.
Haz la prueba con tres destinatarios reales: cliente, administración y sistema de gestión. Pregunta qué información necesitan y cómo la usarán. Si solo uno requiere un documento, crea esa salida sin obligar a los otros dos a trabajar desde un PDF. Y si el programa de gestión necesita datos, el siguiente paso será decidir cómo conectarlo con el parte.
Cómo conectar el parte con el ERP o software de gestión
Oficina crea una orden en su programa de gestión. El técnico la atiende desde el móvil. Al volver, alguien copia a mano las horas y los materiales para preparar la factura. Hay dos herramientas digitales, pero el proceso sigue roto en el punto donde la información cambia de una a otra. Conectar el parte con el ERP empieza por decidir qué sistema conoce cada dato y en qué momento debe compartirlo.
Cliente, instalación, trabajo previsto e identificador.
Resultado, tiempos, materiales, fotos e incidencias.
Datos útiles para seguimiento, stock o facturación.
Lo primero es identificar el origen fiable. Si el ERP mantiene los clientes, sus direcciones y condiciones comerciales, el parte debe recibir esa información al abrir la orden, no crear una segunda ficha de cliente independiente. Si el equipo instalado se mantiene en otro sistema, hay que saber cuál manda cuando una referencia cambia. Y si el técnico descubre que la dirección o el equipo son incorrectos, debe poder comunicarlo sin sustituir silenciosamente el dato maestro.
También importa conservar los identificadores. La orden, la visita, el cliente, la instalación y cada material necesitan referencias que permitan reconocerlos en ambos sistemas. «Filtro azul» escrito a mano puede ser suficiente para una nota, pero no para descontar automáticamente la referencia correcta del almacén. Si no hay correspondencia, el dato debería quedar pendiente de revisión, no enlazarse al primer producto parecido.
Después se decide cuándo viaja cada cosa. Una orden puede llegar a la aplicación de campo al asignarse. Las fotografías y observaciones se generan durante la visita. Los materiales utilizados pueden necesitar comprobación antes de afectar al stock o a una factura. El estado «técnico finalizó» no tiene por qué disparar todos los movimientos administrativos: la revisión puede ser la condición para enviar el resultado aprobado.
Conviene describir los intercambios con frases verificables: «cuando oficina asigna una orden, el técnico recibe cliente, lugar y trabajo previsto»; «cuando se aprueba el parte, gestión recibe las líneas de material validadas y el resultado». Así aparecen preguntas que una integración genérica oculta: ¿qué pasa con una segunda visita?, ¿cómo se representa un material no catalogado?, ¿quién corrige una dirección?, ¿cómo se evita enviar dos veces el mismo parte?
Si las herramientas no ofrecen una conexión directa, todavía puede existir una solución intermedia: importaciones controladas, archivos estructurados o un desarrollo de integraciones y automatizaciones entre sistemas. La elección depende de volumen, frecuencia, capacidades reales de cada programa y coste de mantener el intercambio. Antes de construir nada, dibuja el recorrido de una orden real desde su creación hasta su factura y marca cada dato que hoy alguien vuelve a teclear. En el siguiente apartado veremos qué hacer cuando una de esas transferencias falla.
Qué hacer cuando la integración falla
El técnico finaliza el parte. La aplicación lo guarda, genera el justificante y trata de enviarlo al ERP, pero este no responde. Si todo se presenta como «error», el técnico puede creer que perdió su trabajo y repetir la intervención en la pantalla. Si todo se presenta como «completado», oficina puede intentar facturar sin saber que el ERP nunca recibió los datos. El fallo de una transferencia no debe borrar ni disfrazar lo que sí salió bien.
La intervención sigue disponible.
El justificante conserva su versión.
Oficina conoce el fallo y puede resolverlo.
Para ello, el envío necesita un estado propio: pendiente, en curso, confirmado o fallido y requiere revisión. Ese estado no sustituye al del parte. Un parte puede estar aprobado y seguir pendiente de pasar al ERP. La pantalla de oficina debe mostrarlo con su identificador, la fecha del intento y una explicación útil, no enterrarlo en un registro técnico que nadie consulta.
Algunas incidencias se resuelven reintentando, como una caída temporal del servicio de destino. Otras requieren corregir un dato: un cliente sin correspondencia, una referencia de material inexistente o una orden que ya fue cerrada en el ERP. Repetir automáticamente una petición inválida cien veces no ayuda. El sistema debe distinguir los errores recuperables de los que necesitan una decisión humana y dejar claro quién debe tomarla.
El reintento, sea automático o manual, no puede crear otra factura, descontar dos veces una pieza o duplicar la visita. Para evitarlo, cada intercambio debe conservar una identidad reconocible y poder comprobar si el destino ya recibió esa operación antes de enviarla otra vez. Esta precaución importa especialmente cuando la aplicación perdió la respuesta del ERP: el envío pudo haberse realizado aunque la confirmación no llegara.
Resolver el aviso tampoco consiste solo en hacer desaparecer una etiqueta roja. Conviene reconciliar los sistemas: verificar que el ERP contiene la orden o el parte esperado, con las líneas y el estado correctos, y registrar cuándo quedó confirmado. Si hubo una corrección manual, debe quedar visible para que otra persona no vuelva a enviar la versión antigua. El técnico no tendría que rehacer el parte para reparar un problema que ocurrió después de su trabajo.
Una prueba útil consiste en cortar la conexión con el ERP justo después de aprobar un parte. Comprueba qué ve el técnico, qué ve oficina, cuántas veces puede intentarse el envío y qué aparece finalmente en el ERP. Después repite con un material que no existe en el catálogo de destino. Si ambos casos se resuelven de la misma manera genérica, la integración necesita reglas más precisas. A partir de ahí, toca decidir quién puede ver, modificar y resolver cada parte del proceso.
Seguridad y permisos: cada persona debe acceder a lo que necesita
Una aplicación de partes puede reunir direcciones de clientes, teléfonos, fotografías del interior de instalaciones, observaciones y condiciones de cada trabajo. Que todos esos datos estén en el móvil del técnico o en una misma pantalla de oficina no significa que cualquiera deba verlos o modificarlos. Los permisos deben seguir las responsabilidades del proceso: realizar, coordinar, revisar, facturar y administrar no son la misma tarea.
Empieza por las acciones reales. Un técnico puede necesitar ver una dirección y un teléfono para llegar al cliente, pero quizá no el historial completo de otros clientes. Puede corregir su borrador y añadir una fotografía; después de entregar el parte, una rectificación puede requerir motivo o aprobación. Quien factura necesita los datos validados y los acuerdos comerciales, pero no necesariamente todas las imágenes tomadas durante la visita. Esta separación reduce errores y evita exponer información sin utilidad para el trabajo de cada persona.
Los permisos deben aplicarse al dato y a la acción, no solo al menú. Ocultar el botón «Aprobar» no basta si un usuario puede llamar a la misma operación por otra ruta. La aplicación debe comprobar en el servidor quién solicita cada cambio, sobre qué parte y en qué estado está. También conviene definir sustituciones: si el responsable habitual no está disponible, ¿quién puede reasignar una orden o desbloquear una revisión sin compartir su cuenta?
El acceso desde dispositivos de campo exige pensar en sesiones y pérdidas. Si se extravía un móvil, la empresa debe poder retirar su acceso y evitar que una sesión antigua siga abriendo partes. Los datos almacenados para trabajar sin cobertura merecen especial atención: hay que decidir qué se descarga, cuánto permanece en el equipo y cuándo se elimina. Una copia local útil para trabajar no debería convertirse en un archivo indefinido de clientes anteriores.
Las cuentas compartidas parecen ahorrar tiempo, pero impiden saber quién realizó una acción y dificultan revocar solo un acceso. Cada usuario debería entrar con su propia identidad y recuperar el acceso sin pedir la contraseña a un compañero. Si participan colaboradores externos, sus permisos pueden limitarse a los trabajos asignados y retirarse al terminar su intervención.
Para comprobar el diseño, elige tres partes reales y prueba con perfiles distintos: uno de un técnico asignado, otro de un técnico ajeno a la visita y otro de administración. ¿Qué puede ver cada uno? ¿Quién puede cambiar materiales, reabrir o aprobar? ¿Qué ocurre al desactivar una cuenta o perder un dispositivo? Las respuestas deben poder explicarse antes de programar la pantalla. El paso siguiente será dejar constancia de quién hizo cada cambio y cuándo.
Trazabilidad: quién hizo qué y cuándo
Una semana después de la visita, el cliente pregunta por qué el parte indica una pieza distinta de la que aparece en la primera fotografía. El técnico recuerda haber anotado otra referencia; oficina recuerda haberla corregido antes de facturar. Si el sistema solo conserva el valor actual, ninguno puede reconstruir qué pasó. La trazabilidad sirve para seguir la historia del trabajo sin depender de la memoria de las personas.
- Orden asignadaCoordinación → técnico
- Intervención iniciadaTécnico
- Parte finalizadoTécnico
- Parte recibidoSincronización
- Material corregido y aprobadoRevisión
No hace falta registrar cada pulsación. Lo útil son los acontecimientos que cambian el estado o el significado del parte: asignación, inicio, finalización, firma o ausencia de ella, recepción tras trabajar sin conexión, devolución para corregir, aprobación y envío a otro sistema. Para cada uno conviene conservar qué ocurrió, cuándo y bajo qué usuario o proceso. Si una integración automática actuó, debe aparecer como tal, sin atribuirla a quien estaba usando el móvil.
En las correcciones relevantes también importa saber qué cambió. No basta con anotar «editado a las 12:03» si se sustituyó una referencia de material o se modificó la descripción del resultado. Mostrar valor anterior, valor nuevo y motivo permite entender si fue una errata, una comprobación de oficina o un cambio de alcance. Según el dato y su sensibilidad, la interfaz puede mostrar un resumen y reservar el detalle a las personas autorizadas.
La línea temporal debe reflejar la realidad del trabajo sin conexión. El técnico pudo añadir una foto a las 10:40 y enviarla a las 11:25. Son dos momentos distintos: cuándo se realizó la acción y cuándo la recibió el servidor. La aplicación debe conservar ambos cuando esa diferencia importa para reconstruir el proceso. Un reloj de dispositivo mal ajustado también puede producir incoherencias; por eso no conviene basar toda la secuencia en una única hora local sin contexto.
Un historial no debe ser una forma de dejar abierto todo indefinidamente. Si un parte aprobado necesita una rectificación, conviene conservar la versión que se aprobó y crear una corrección identificable, en lugar de cambiar el pasado a escondidas. Esto ayuda a explicar diferencias entre el parte, el PDF entregado y los datos enviados al ERP.
Para comprobar la trazabilidad, elige un parte que haya pasado por dos personas y una corrección. ¿Puede alguien ajeno a la visita entender el recorrido, saber quién está pendiente de actuar y localizar la versión que vio el cliente? Si solo hay una lista de fechas sin explicación, falta contexto. Si la respuesta exige entrar en logs técnicos, falta una vista útil para el trabajo diario. Con esa historia clara, el siguiente paso es decidir qué recorrido mínimo debe funcionar en la primera versión, sin intentar construir todas las funciones a la vez.
No construyas todas las funciones en la primera versión
Cuando se describe una aplicación de partes, aparecen enseguida ideas razonables: inventario, firma, presupuestos, facturas, avisos, paneles, rutas, ERP y estadísticas. El problema no es que sobren necesidades; es intentar resolverlas todas antes de comprobar que el recorrido principal funciona. Una primera versión útil permite completar una intervención real de principio a fin, aunque todavía no automatice cada consecuencia.
Materiales conectados con almacén · firma · integración con ERP · facturación · cuadros de mando · automatizaciones
Ese recorrido mínimo no es una maqueta ni una colección de pantallas sueltas. Debe funcionar con un trabajo verdadero: oficina lo crea o recibe, asigna a alguien, el técnico encuentra la información, registra lo ocurrido y termina, y oficina puede leer el resultado sin pedirle que lo copie por otro canal. Si el trabajo exige una fotografía para entender el resultado, esa captura pertenece al primer recorrido. Si una firma es imprescindible para prestar el servicio contratado, también. «Mínimo» significa lo suficiente para completar el proceso, no eliminar piezas esenciales.
Elige primero una familia de intervenciones frecuente y reconocible. Una reparación estándar puede servir para aprender cómo se asigna, qué datos consulta el técnico y qué necesita oficina al cierre. Después prueba una excepción cercana, como una visita sin acceso o una segunda visita por falta de material. Si la herramienta solo funciona cuando todo sale bien, aún no está lista para sustituir el papel en esa operación.
Hay capacidades que pueden incorporarse más tarde sin romper el recorrido: estadísticas avanzadas, automatizaciones de avisos secundarios o ciertas integraciones. Mientras tanto puede existir un paso manual explícito y medible. Por ejemplo, oficina puede revisar el parte y trasladar una línea al ERP durante la primera fase; así se observa qué datos faltan y qué errores conviene resolver antes de automatizar el intercambio. Esa transición debe estar descrita, no quedar escondida como una tarea que nadie asumió.
Otras decisiones no conviene aplazarlas aunque su interfaz sea sencilla: identidad de órdenes y partes, permisos básicos, conservación de lo registrado, confirmación de envío y una salida para errores. Sin ellas, la primera versión puede parecer rápida de construir y resultar imposible de usar con confianza. La prioridad se decide por lo que hace viable el trabajo, no por lo vistoso de la función.
Para ordenar el alcance, pregunta por cada propuesta: «Si esta función no existe el primer mes, ¿podemos terminar una intervención real y saber qué hacer después?». Si la respuesta es sí, anótala para una fase posterior junto con el problema que resolverá. Si es no, concreta el caso que la vuelve imprescindible. Una vez definido ese primer recorrido, todavía queda elegir dónde construirlo: sobre una solución existente, en el ERP actual o mediante desarrollo específico.
SaaS existente, módulo del ERP o desarrollo a medida: ¿qué camino encaja?
Una vez entendido el recorrido del parte, llega la pregunta habitual: «¿Compramos una aplicación o la construimos?». Falta una tercera opción que a menudo se pasa por alto: el programa de gestión que ya usa la empresa quizá tenga un módulo suficiente. Elegir bien no depende de cuál tiene más funciones en una demostración, sino de cuánto del trabajo real puede resolverse sin obligar a técnicos y oficina a mantener dos procesos paralelos.
Un SaaS especializado suele ser una buena primera opción cuando cubre sin grandes rodeos la asignación, el trabajo desde móvil, las evidencias y la revisión que la empresa necesita. Conviene probarlo con una intervención completa, una excepción y un día sin cobertura si ese escenario existe. La pregunta decisiva no es «¿tiene un campo para fotos?», sino «¿puede nuestro técnico cerrar este trabajo y puede oficina continuar sin volver a teclearlo?». Hay que comprobar también cómo salen los datos y qué ocurre si más adelante se cambia de proveedor.
El módulo del ERP puede evitar duplicar clientes, órdenes, materiales y condiciones comerciales. Merece investigarse antes de añadir otra herramienta. Sin embargo, estar integrado en gestión no garantiza una buena experiencia en campo: quizá la pantalla móvil sea lenta, el formulario no admita distintas intervenciones o el trabajo sin conexión sea imposible. Si funciona para oficina pero los técnicos terminan usando papel o WhatsApp, la integración nominal no ha resuelto el proceso.
El desarrollo específico empieza a tener sentido cuando el trabajo exige reglas que las soluciones existentes no pueden representar de forma razonable: formularios diferentes según intervención, aprobaciones particulares, dispositivos especiales, uso offline exigente o conexión con varios sistemas. Permite ajustar la herramienta al recorrido real, pero también implica asumir diseño, mantenimiento y evolución. No conviene construirla solo porque una pantalla estándar resulte poco atractiva o porque sea posible hacerlo técnicamente. Si ese camino está justificado, el desarrollo de software a medida debe partir de necesidades verificadas, no de una lista de tecnologías.
A veces la mejor respuesta es mixta. Un producto existente puede cubrir el registro de campo y necesitar una integración acotada con el ERP. O el ERP puede seguir siendo dueño de órdenes y facturación mientras una aplicación específica resuelve el trabajo del técnico. En ambos casos hay que definir qué sistema mantiene cada dato y quién atenderá los cambios futuros; una combinación barata de poner en marcha puede salir cara si nadie sabe sostenerla.
Antes de elegir, ejecuta el mismo caso de prueba en cada opción: una orden real, una visita normal, otra no completada, fotografías, revisión y paso a facturación. Anota qué funciona sin adaptar el negocio a la herramienta, qué necesita configuración y qué quedaría como tarea manual. La siguiente sección convierte esa prueba en una lista concreta para comparar soluciones sin dejarse llevar por una demostración vistosa.
Cómo comparar soluciones de partes de trabajo sin dejarse llevar por la demo
Dos aplicaciones pueden enseñar en pantalla «fotos, firma y materiales» y comportarse de forma muy distinta durante una visita real. Una permite guardar sin señal y recuperar el parte; otra solo mantiene abierta la pantalla hasta que vuelve la conexión. Una exporta los datos de cada intervención; otra entrega únicamente un PDF. La comparación debe basarse en tareas comprobadas con tus propios casos, no en una lista de funciones marcadas con un sí.
¿Puede el técnico terminar una visita normal y otra incompleta desde su dispositivo habitual?
¿Puede oficina revisar, corregir y continuar sin volver a escribir lo que ya se registró?
¿Se pueden recuperar datos, documentos y relaciones si cambian las necesidades o el proveedor?
En campo, prepara una orden de cada tipo relevante y comprueba si los formularios permiten diferencias sin obligar a rellenar apartados ajenos. Prueba la búsqueda de clientes y equipos, la captura de fotos, la firma si se necesita y el registro de materiales con cantidad y unidad. Repite la visita en un móvil real, con cobertura limitada si forma parte del trabajo. «Tiene app» o «funciona en el navegador» no responde a cómo se comporta en esas condiciones.
En oficina, revisa quién puede ver, devolver, aprobar y reabrir un parte. Pide que te muestren una visita no completada y una corrección posterior: ¿queda claro qué cambió y quién lo hizo? Comprueba si los estados permiten seguir trabajos pendientes, si las fotografías quedan vinculadas a la intervención correcta y si materiales y tiempos se pueden consultar sin abrir un PDF por cada parte.
Para la integración, distingue «dispone de API» de «puede intercambiar los datos que necesitamos con nuestro ERP». Pide identificar el origen de órdenes, clientes y catálogo de materiales; qué datos regresan; en qué momento; y qué ocurre si el envío falla. Si se propone un conector ya hecho, ensaya también una segunda visita y una referencia de material que no existe en el sistema de destino. La compatibilidad se demuestra con esos casos, no con los logotipos de una ficha comercial.
El control de los datos merece una prueba aparte. Solicita una exportación de ejemplo y comprueba si conserva identificadores, fechas, estados, materiales, observaciones y enlaces a documentos, además de los archivos. Pregunta cómo se hacen las copias de seguridad, cómo se recupera un parte borrado por error, qué histórico quedará disponible y cómo se obtiene una copia al terminar la relación con el proveedor. Un archivo de PDFs puede servir como archivo visual, pero no sustituye necesariamente a los registros que permitirían continuar el proceso en otra herramienta.
Por último, compara el mantenimiento real: quién cambia formularios y permisos, cómo se atienden incidencias, qué ocurre cuando el ERP modifica su integración y qué coste tiene incorporar técnicos, almacenamiento o nuevas funciones. Anota por cada solución «resuelto», «requiere configuración», «requiere desarrollo» o «no encaja», junto con la evidencia observada. No hace falta un ranking de marcas: hace falta saber qué opción permite trabajar mañana y seguir evolucionando dentro de un año.
Una buena selección todavía no garantiza la adopción. La siguiente fase consiste en implantar el proceso con personas reales, probarlo en campo y acompañar el cambio hasta que el parte digital sea la forma habitual de trabajar.
Implantación: el problema no termina cuando funciona el software
La aplicación puede pasar todas las pruebas técnicas y seguir sin resolver nada si, durante una visita, el técnico vuelve al papel porque no encuentra dónde registrar una incidencia. Implantar un parte digital implica cambiar una costumbre compartida por técnicos, coordinación y oficina. El estreno debe comprobar el proceso completo con personas y trabajos reales, no limitarse a entregar usuarios y contraseñas.
- 01Piloto acotado
Unos pocos usuarios y tipos de trabajo frecuentes.
- 02Prueba en campo
Visitas normales, excepciones y cobertura irregular.
- 03Ajustes y formación
Resolver fricciones observadas y practicar el recorrido.
- 04Ampliación
Incorporar al resto con apoyo y una referencia clara.
El piloto necesita usuarios que hagan el trabajo habitual, no solo a quien aprobó la compra o a quien más cómodo se siente con la tecnología. Incluye a alguien de oficina que recibe y revisa los partes, porque un formulario fácil para el técnico puede producir información imposible de usar después. Elige una familia de intervenciones suficientemente frecuente para observar varios casos y anota desde el principio qué se hará con los trabajos que todavía queden fuera.
Las pruebas deben ocurrir donde se presta el servicio. Observa cómo se abre una orden, qué consulta el técnico, cuándo toma fotografías, cómo termina una visita incompleta y qué sucede si pierde cobertura. No basta con preguntar «¿te gusta la app?» al final del día. Registra dónde alguien se detuvo, qué dato buscó en otro canal, qué campo dejó sin entender y qué tuvo que corregir oficina.
La formación funciona mejor sobre casos reconocibles: una visita terminada, otra sin acceso y una que requiere segunda intervención. Cada rol debe practicar lo que hará: el técnico registra; coordinación asigna; oficina revisa y devuelve; administración continúa. Una guía breve para las dudas frecuentes ayuda, pero no sustituye la posibilidad de pedir apoyo durante las primeras jornadas ni un mecanismo claro para comunicar errores.
El soporte inicial debe separar tres tipos de mensaje: no sé cómo hacerlo, la pantalla no permite representar lo que ocurrió y el sistema ha fallado. El primero puede resolverse con formación; el segundo señala una regla de proceso mal diseñada; el tercero requiere una corrección técnica. Si todo acaba en «el usuario se resiste al cambio», se pierden datos valiosos sobre el producto.
Antes de ampliar, revisa algunos partes completos con quienes los generaron y con quienes los usan después. ¿Llegan a oficina a tiempo? ¿Se entienden los resultados? ¿Puede resolverse una excepción sin recurrir al papel? Cuando el recorrido habitual funciona y las dudas tienen respuesta, se incorporan más personas o tipos de trabajo. La siguiente decisión será retirar progresivamente los canales duplicados: mantener papel, WhatsApp y parte digital a la vez de forma indefinida impide que exista una referencia fiable.
No mantengas dos procesos indefinidamente
Durante un piloto es normal que convivan el sistema nuevo y una forma de trabajo conocida. El problema aparece cuando esa convivencia no tiene fecha ni reglas: el técnico rellena el parte digital, firma un papel «por si acaso» y envía las fotos por WhatsApp. Oficina recibe tres versiones incompletas de la misma visita y vuelve a preguntar cuál es la buena. Digitalizar de verdad exige definir dónde queda el registro de referencia.
Fotos separadas, datos repetidos y dudas sobre qué versión está completa.
Los canales auxiliares remiten al mismo trabajo y no crean otro parte paralelo.
La transición necesita una decisión concreta: para los trabajos incluidos en el despliegue, ¿dónde se anota el resultado, dónde se guardan las fotos y qué consulta oficina? Si una imagen llega por mensajería porque el técnico no pudo adjuntarla, debe incorporarse al parte o quedar señalada como pendiente; no basta con confiar en que alguien recuerde el mensaje. Un canal auxiliar puede avisar, pero no debería convertirse en un archivo alternativo de intervenciones.
Mantener el papel «por seguridad» puede ser razonable durante unos días de prueba o en un procedimiento que todavía lo exija. Debe quedar claro por qué se usa, quién lo conserva y cuándo deja de ser necesario. Si el papel sigue siendo la versión que administración considera válida, los técnicos aprenderán que la aplicación es una tarea adicional. Si el digital es el registro principal, oficina no debería pedir una segunda transcripción del mismo trabajo para continuar.
También hace falta una salida cuando la herramienta falla. Puede ser un procedimiento excepcional para registrar la visita y cargarla después, con el número de orden, la persona responsable y el motivo. Esa contingencia no equivale a mantener dos procesos cotidianos. Si se usa con frecuencia, revela un problema de cobertura, interfaz o fiabilidad que debe resolverse en la aplicación.
Una retirada progresiva puede empezar por un tipo de intervención y un grupo de técnicos. Cuando el recorrido se comprueba, se deja de pedir el parte en papel para esos trabajos; después se amplía a otros. Comunica la regla a técnicos y oficina al mismo tiempo, porque basta con que un área siga exigiendo la hoja anterior para reinstalar la duplicidad. Revisa durante las primeras semanas cuántas visitas necesitaron un canal alternativo y por qué.
La prueba final es sencilla: elige una visita reciente y pregunta a dos personas dónde encontrarían la versión completa y actual. Si responden con lugares distintos, todavía no hay una fuente de referencia. Una vez resuelto el flujo nuevo, queda decidir qué hacer con los partes anteriores: no todo el archivo histórico necesita convertirse en registros digitales completos.
Cómo migrar los partes anteriores sin rehacer años de trabajo
Al estrenar la herramienta suele surgir una petición comprensible: «Metamos todos los partes antiguos». Pero una caja de documentos firmados, carpetas con fotografías y hojas de cálculo no se convierten automáticamente en intervenciones estructuradas. Antes de emprender una importación grande, pregunta qué necesita consultar o continuar la empresa a partir de ese histórico. La respuesta puede ser distinta para un trabajo abierto y para una visita cerrada hace cinco años.
Orden, estado, cliente y datos necesarios para la siguiente acción.
Identificador, fecha, cliente y vínculo al documento original.
Mantenerlo localizado sin reconstruir cada campo.
Los trabajos todavía abiertos merecen prioridad: alguien tendrá que terminarlos, revisar su estado o facturarlos después del cambio. Para ellos puede ser necesario crear la orden en el sistema nuevo, relacionarla con el cliente correcto y trasladar lo que falta por hacer. El documento anterior puede adjuntarse como antecedente, sin fingir que cada acción histórica se registró originalmente en la nueva herramienta.
Para el histórico que se consulta, a menudo basta con una ficha localizable: número antiguo, cliente, fecha, tipo de intervención y enlace al parte escaneado o al archivo original. Esto permite responder «¿qué se hizo en esa instalación?» sin convertir a mano todas las líneas de material y horas. Si ciertas familias de trabajos se consultan a menudo para mantenimiento o garantías, pueden recibir un tratamiento más detallado que el resto.
También es válido no importar parte del archivo si existe una forma fiable de conservarlo y encontrarlo. La decisión debe incluir quién mantendrá ese repositorio, cómo se buscará y qué ocurrirá cuando cambie el equipo o el proveedor. «Está en una carpeta del ordenador de administración» no es un plan de acceso duradero. A la vez, cargar miles de PDFs sin nombres ni relación con clientes puede trasladar el desorden al sistema nuevo.
Si se importan datos, prueba primero una muestra heterogénea: un parte reciente, uno antiguo, uno con segunda visita y otro con fotografías separadas. Comprueba identificadores duplicados, clientes escritos de varias formas, fechas ambiguas y documentos sin correspondencia. La lectura automática de un escaneo puede ayudar a localizar información, pero no conviene convertir un texto reconocido con errores en materiales o importes validados sin revisión.
Antes del cambio definitivo, define cómo se busca un trabajo durante la transición: los nuevos partes en la aplicación, los antiguos en el archivo identificado y los abiertos trasladados con su referencia anterior. Pide a alguien de oficina que encuentre cinco casos conocidos sin ayuda de quien hizo la migración. Si puede hacerlo y continuar los trabajos pendientes, el histórico ya cumple su función. El siguiente paso será medir si el nuevo proceso realmente mejora los problemas que motivaron la digitalización.
Cómo saber si la digitalización de partes ha funcionado
«Ahora tenemos una app» describe una herramienta, no una mejora. El cambio funciona si permite terminar y continuar los trabajos con menos dudas, retrasos o transcripciones. Para comprobarlo, elige primero los problemas que motivaron el proyecto y mira qué ocurría antes con trabajos comparables. Sin ese punto de partida, cualquier cifra nueva puede parecer buena sin decir si el proceso mejoró.
Tiempo desde que el técnico termina hasta que el parte está disponible para revisar.
Cuántos requieren pedir una aclaración o corregir información imprescindible.
Cuántos datos se vuelven a escribir o buscar fuera del parte.
Una primera medida útil es el tiempo desde la intervención hasta que oficina puede actuar. Define los dos momentos con precisión: «el técnico pulsó Finalizar» no equivale a «el servidor recibió el parte», y «recibido» no siempre significa «listo para facturar». Si la empresa quiere reducir demoras de facturación, puede medir también el tiempo entre la visita y la aprobación administrativa. Conviene mirar varios casos, no solo una media que esconda partes que pasan semanas pendientes.
La calidad de la información se ve en las devoluciones y las preguntas posteriores. Cuenta los partes que necesitan una llamada para identificar un material, entender el resultado o localizar una foto; distingue una aclaración legítima de un campo que la herramienta no supo recoger. Si disminuye el tiempo de rellenado pero aumentan esas llamadas, la rapidez del técnico se ha trasladado como carga a oficina.
Observa también las tareas repetidas: líneas que se vuelven a teclear en el ERP, fotografías que hay que pedir por mensajería, clientes que se buscan otra vez o documentos que alguien renombra y archiva manualmente. Se puede registrar una pequeña muestra de intervenciones y anotar cada repetición. No hace falta medir cada clic para descubrir dónde sigue rota la continuidad del proceso.
Los partes pendientes revelan otros problemas. Una cola que crece puede indicar que falta tiempo para revisar, que las validaciones son confusas o que la integración está fallando. Mirar solo cuántos partes se crean al día no cuenta esta historia. También importa saber cuántos llegan a revisión, cuántos se aprueban, cuántos quedan bloqueados y cuánto tiempo llevan allí.
Compara periodos y trabajos parecidos: una instalación compleja no debería evaluarse como una visita rutinaria. Anota cambios externos, como más técnicos, una campaña de mantenimiento o un nuevo criterio de facturación. Y combina las cifras con conversaciones breves: un técnico puede explicar por qué evita un campo; administración puede mostrar dónde sigue copiando datos. La mejor señal no es un porcentaje aislado, sino que ambos puedan completar su parte del trabajo con información más clara.
Una vez identificadas las medidas, revísalas tras el piloto y de nuevo cuando se amplíe el uso. Si mejoran la recepción y la calidad, pero la facturación sigue retrasada, quizá el cuello de botella está en la revisión y no en la captura. El siguiente apartado reunirá todo el recorrido en un ejemplo completo de una empresa con técnicos de campo.
Ejemplo completo: una empresa con técnicos de campo
Imaginemos una empresa ficticia que mantiene equipos de climatización para comercios. Un cliente avisa de que una máquina enfría mal. La empresa necesita enviar a un técnico, saber qué encontró, preparar una segunda visita si falta una pieza y facturar lo que corresponda. La necesidad no es «tener una app»: es que la información acompañe al trabajo desde el aviso hasta su cierre.
El motivo de la segunda visita puede quedar en la memoria del técnico o en un mensaje separado del parte.
Visitas, fotos, materiales y pendientes permanecen asociados al mismo trabajo.
Antes, oficina recibe la llamada y apunta cliente, dirección y avería en su programa. Después llama al técnico para darle detalles. Él anota algo en papel, fotografía la máquina y envía las imágenes por mensajería. Descubre que necesita una pieza que no lleva; escribe «pendiente repuesto» y se marcha. Al día siguiente, oficina busca las fotos en la conversación, llama para saber qué referencia hace falta y prepara la segunda visita. Cuando regresan ambos papeles, alguien vuelve a introducir tiempos y materiales en el ERP. Cada traspaso es una oportunidad para perder contexto.
Después, oficina crea la orden con un identificador único y asigna al técnico. En el móvil, él ve cliente, dirección, equipo y motivo de la visita sin volver a escribirlos. Al llegar, registra la inspección y toma una fotografía vinculada a ese parte. Selecciona «trabajo no completado» porque falta una pieza, identifica cuál necesita y deja una observación sobre la máquina. La primera visita queda terminada, pero la orden sigue abierta con una acción pendiente visible para coordinación.
Cuando llega el repuesto, se programa una segunda visita dentro de la misma orden. El nuevo parte conserva su propia fecha, técnico, tiempo, fotografías y material utilizado. El técnico comprueba el funcionamiento y finaliza. Si trabaja sin cobertura, la pantalla indica que el parte está guardado localmente hasta confirmar su recepción. No mezcla ambas visitas ni presenta la primera como si nunca hubiera ocurrido.
Oficina revisa los dos partes juntos. Puede ver por qué fue necesaria la segunda visita, comprobar el material instalado y resolver una observación antes de aprobar. Solo entonces se trasladan al ERP los datos que corresponden para facturación, aplicando las condiciones del cliente. Si el envío falla, el parte aprobado sigue disponible y la transferencia queda pendiente con una acción concreta. El técnico no repite su relato para reparar un fallo entre sistemas.
La versión final no tiene por qué incluir todas las funciones desde el primer día. Puede comenzar con orden, visita, fotos, resultado y revisión; la conexión con el ERP puede llegar después si el paso manual está identificado. Lo decisivo es que la primera versión ya permita entender qué se hizo, qué falta y quién debe actuar. Ese ejemplo ayuda también a reconocer los errores habituales: copiar el papel tal cual o diseñar solo para visitas que terminan sin contratiempos.
Errores habituales al digitalizar partes de trabajo
La mayoría de los tropiezos no se descubren al instalar la aplicación, sino en la primera visita que no encaja en el recorrido previsto. Un técnico no tiene cobertura, otro no puede entrar, oficina no encuentra una fotografía y alguien acaba completando el papel «para salir del paso». Estos son los errores que conviene buscar antes de extender la herramienta a toda la empresa.
Define qué ocurre antes, durante y después de cada visita.
Solicita solo lo necesario y estructura lo que habrá que reutilizar.
Prueba móvil, cámara, interrupciones y zonas sin señal.
Determina qué sistema guarda cada dato y cuál es la referencia.
Copiar literalmente el papel convierte una hoja difícil de usar en un formulario difícil de usar. Antes de trasladar campos, separa orden y parte, identifica quién inicia el trabajo y decide qué información ya existe. Si además no se definen estados, «guardado», «finalizado», «revisado» y «listo para facturar» acaban significando cosas distintas para cada persona.
Pedir demasiados datos no garantiza partes mejores: puede fomentar respuestas de relleno. El extremo contrario, dejarlo todo en texto libre, impide buscar materiales, distinguir causas o preparar la siguiente visita. Cada campo debería responder a una necesidad concreta. Los datos repetidos del ERP se consultan desde su origen; los hechos de la intervención se registran en campo; y las excepciones tienen una salida clara cuando no encajan en las opciones habituales.
Olvidar el lugar donde se trabaja produce pantallas que parecen cómodas en el ordenador y fallan con una mano ocupada, reflejos o guantes. La cobertura tampoco debe asumirse por costumbre: si es necesaria, hay que comprobarla; si no está garantizada, hay que decidir cómo guardar y sincronizar. Una visita sin acceso o una pieza ausente debe poder cerrarse como visita realizada sin fingir que el trabajo quedó resuelto.
Tomar el PDF como producto final deja pendientes las decisiones importantes: quién revisa, qué se envía al ERP y cómo se encuentran trabajos por completar. Mantener a la vez papel, mensajería y aplicación crea otras tantas versiones. Define dónde queda el dato de referencia y qué procedimiento excepcional se seguirá si algo falla, sin convertir la excepción en el proceso habitual.
Finalmente, no probar con técnicos reales permite que todos los errores anteriores sobrevivan a la puesta en marcha. Un piloto útil incluye una visita normal, una no completada, una corrección y, si procede, una zona sin señal. Observa también qué recibe oficina. Si alguien tiene que llamar para entender el parte o volver a escribirlo, aún hay trabajo de diseño. La siguiente lista reúne las preguntas que conviene responder antes de dar por preparado el proyecto.
Checklist: antes de digitalizar tus partes de trabajo
Esta lista sirve para detectar decisiones pendientes antes de comparar programas o pedir un desarrollo. No todas las respuestas tienen que ser «sí»: quizá tu empresa no necesita firma, trabajo sin conexión o migrar el archivo antiguo. Lo importante es saberlo y poder explicar qué hará cada persona cuando ocurra una visita real.
1. Qué trabajo estamos representando
- ¿Qué representa cada parte: una visita, una intervención, una jornada u otra unidad?
- ¿Quién crea o recibe el trabajo y de dónde llegan sus datos?
- ¿Quién lo realiza y qué necesita conocer antes de salir?
- ¿Qué información ya existe sobre cliente, instalación y equipo?
2. Qué ocurre en campo
- ¿Qué hechos debe registrar el técnico para que oficina pueda continuar?
- ¿Qué campos cambian según el tipo de trabajo?
- ¿Cuándo hacen falta fotografías y cómo se vinculan al parte?
- ¿Necesitamos firma y qué significa en este proceso?
- ¿Debe poder utilizarse el parte sin conexión?
3. Cómo se termina y se revisa
- ¿Qué excepciones existen: cliente ausente, falta de material o segunda visita?
- ¿Qué estados tiene el trabajo y qué cambia al pasar de uno a otro?
- ¿Quién revisa o aprueba lo que entrega el técnico?
- ¿Qué sucede al pulsar «Finalizar» y qué recibe el cliente?
- ¿Hay que actualizar un ERP o programa de gestión? ¿Con qué datos?
4. Cómo se sostiene el proceso
- ¿Qué hacemos si falla el envío o la sincronización?
- ¿Quién puede consultar, cambiar, aprobar o descargar cada dato?
- ¿Qué histórico anterior necesitamos consultar o migrar?
- ¿Cómo comprobaremos que el proceso mejora para técnicos y oficina?
Si una respuesta sigue abierta, anota quién la decidirá y con qué ejemplo real se probará. Una visita normal y otra que termina con trabajo pendiente suelen revelar más que una reunión dedicada a enumerar funciones. Con estas decisiones claras, la conversación con un proveedor deja de ser «queremos una app de partes» y pasa a ser «necesitamos que este trabajo recorra estos pasos sin perder información». Las preguntas frecuentes de la siguiente sección resuelven las dudas que suelen aparecer al aplicar la lista.
Preguntas frecuentes sobre partes de trabajo digitales
Estas respuestas recogen las decisiones más habituales antes de implantar una herramienta. Cada empresa puede resolverlas de forma distinta según sus visitas, técnicos y sistemas; la prueba es que el recorrido funcione con un trabajo real.
¿Cómo digitalizar partes de trabajo?
Empieza dibujando cómo nace una orden, qué hace el técnico y qué necesita oficina al terminar. Después define los datos, estados y excepciones, prueba un recorrido completo con usuarios reales y elige la herramienta que mejor lo soporte. Pasar la hoja de papel a una pantalla es solo una parte del cambio.
¿Qué debe incluir un parte de trabajo digital?
Lo necesario para identificar la intervención y entender qué ocurrió: orden y cliente, lugar o equipo, técnico, fecha, resultado, trabajo realizado y pendientes. Horas, materiales, fotos o firma se añaden cuando el tipo de servicio y su uso posterior lo justifican. Los campos pueden variar entre una instalación, un mantenimiento y una visita sin acceso.
¿Necesito una app para los partes de trabajo?
No siempre. Un módulo del ERP, una solución SaaS o una aplicación específica pueden resolverlo. La elección depende del trabajo en campo, la conexión disponible, los formularios, los permisos y el intercambio con oficina. Prueba el proceso completo antes de decidir por el nombre o el formato del producto.
¿Puede utilizarse desde el móvil?
Sí, si la solución está diseñada para el dispositivo y las condiciones de uso. Comprueba que el técnico pueda consultar la orden, registrar datos y adjuntar fotos con una pantalla legible y controles manejables durante la visita. Abrir un formulario de escritorio en el navegador del móvil no garantiza una experiencia útil.
¿Puede funcionar sin conexión?
Puede hacerlo si se ha previsto qué datos se descargan, qué se guarda en el dispositivo y cómo se envía después. Una herramienta accesible desde el móvil no es necesariamente offline. Al recuperar la cobertura debe mostrar si el parte y sus adjuntos llegaron a oficina o siguen pendientes.
¿Se pueden adjuntar fotografías?
Sí. Conviene definir para qué sirven, cuándo se toman, cómo se distinguen las imágenes de antes y después y a qué visita pertenecen. También hay que comprobar su tamaño, almacenamiento y confirmación de envío. Una carpeta de fotos sin relación clara con el trabajo resulta difícil de consultar.
¿Se puede firmar desde el móvil?
Es posible capturar una firma en pantalla, pero antes hay que aclarar qué significa en el proceso: recepción del parte, conformidad con una descripción u otra aceptación. La firma debe relacionarse con el contenido que se mostró y el momento de la visita. Si se necesita un tipo específico de firma electrónica, ese requisito se define por separado.
¿Puede conectarse con un ERP?
Sí, cuando ambos sistemas permiten intercambiar los datos necesarios. Hay que decidir cuál mantiene clientes, órdenes y materiales, qué devuelve el parte y cuándo se envía tras la revisión. La integración también debe contemplar errores, reintentos y referencias que no coinciden, para no duplicar trabajos o movimientos.
¿Puedo generar automáticamente un PDF?
Sí, si un cliente, contrato o proceso interno lo necesita. Decide qué versión se entrega y qué información debe mostrar. Los datos del parte deberían permanecer estructurados para poder buscar, revisar e integrar la intervención; el PDF es una salida legible, no necesariamente la fuente principal.
¿Cuál es la diferencia entre orden y parte de trabajo?
La orden indica qué trabajo se solicita o planifica. El parte registra lo que ocurrió realmente en una visita o intervención. Una orden puede necesitar varios partes si hay más de una visita, por ejemplo cuando falta material o el cliente no permite acceder.
¿Un parte de trabajo sustituye al control horario?
No debe asumirse. El parte describe la ejecución de un trabajo para un cliente; el registro de jornada responde a otra finalidad y puede requerir reglas propias. Aunque ambos utilicen horas, define por separado qué significa cada dato y si tiene sentido compartir alguna información entre sistemas.
¿Conviene comprar un programa o desarrollar uno?
Compara primero un SaaS especializado y las funciones del ERP actual con tus intervenciones reales. El desarrollo específico tiene sentido cuando las reglas, formularios, trabajo sin conexión o integraciones no encajan de forma razonable en esas opciones. También puede bastar con una herramienta existente y una integración acotada.
¿Qué hago con los partes antiguos?
Prioriza los trabajos abiertos que deberán continuar en el nuevo sistema. Para el histórico cerrado, quizá baste con una búsqueda por cliente, fecha e identificador que lleve al documento original. No es obligatorio convertir cada parte anterior en un registro estructurado si nadie necesita usar esos campos.
¿Cómo evito que se siga usando WhatsApp y papel?
Primero comprueba que el parte digital resuelve los casos cotidianos y las excepciones; después acuerda qué canal será la referencia para los trabajos incluidos. Da formación y una salida excepcional para fallos reales, pero evita mantener tres registros permanentes. Si los técnicos siguen usando otro canal, observa qué necesidad no cubre todavía la herramienta.
Si todavía hay dudas, toma una orden reciente y sigue su recorrido con la lista de decisiones anterior. El mejor criterio es comprobar si técnico y oficina pueden explicar qué ocurrió y continuar el trabajo sin reconstruir mensajes y papeles.
Conclusión: el parte debe seguir el trabajo, no copiar el papel
El cambio importante no es sustituir el bolígrafo por una pantalla. Llega cuando la información de cada intervención nace de forma utilizable, conserva lo que ocurrió —también cuando algo queda pendiente— y llega a las personas y sistemas que deben continuar el trabajo sin volver a transcribirla.
Empieza con una orden reciente. Sigue su recorrido desde que entra hasta que se revisa y se factura, localiza dónde se pierde o se repite información y prueba una solución con quienes hacen ese trabajo cada día. Ese recorrido concreto dirá qué herramienta necesitas y qué debe mejorar de verdad.