Qué hacer cuando el equipo sigue resolviendo tareas con Excel, email o WhatsApp

Cuando el SaaS funciona pero algunas tareas siguen dependiendo de otras herramientas

Es bastante habitual. El equipo trabaja con el software sectorial sin problemas en las tareas del día a día. Los pedidos se registran bien y la facturación funciona. Sin embargo, algunas gestiones obligan todavía a abrir el correo, WhatsApp o una hoja de cálculo.

Las excepciones suelen concentrar ese trabajo. Un cliente pide modificar un pedido ya confirmado. Otra operación necesita autorización antes de registrarse. También llegan solicitudes por canales que el programa no contempla.

Esas gestiones suelen resolverse con herramientas que el equipo ya tiene a mano:

El problema empieza cuando nadie puede resolver el pedido consultando solo el SaaS. La autorización está en un correo y quizá haya una anotación adicional en una hoja. Quien continúa la gestión tiene que abrir ambas cosas antes de tocar el pedido.

En ese momento es fácil culpar al software. Antes de cambiarlo, merece la pena revisar qué tareas obliga todavía a hacer en otras herramientas.

Así se puede saber si falta una función importante en el SaaS o si el trabajo manual aparece porque dos aplicaciones no están conectadas. La decisión entre conservar, conectar o sustituir el software principal requiere un análisis más amplio. Aquí partimos de que el programa principal sigue siendo válido y de que queremos reducir las tareas manuales que aún hace el equipo.

El 80/20 es una forma de explicarlo, no una medida real

Hablar de un SaaS que cubre el 80 % del trabajo sirve solo como ejemplo. Ese porcentaje no pretende medir una empresa real. En cada organización las tareas manuales se concentran en puntos distintos y aquí no estamos utilizando la regla de Pareto como referencia cuantitativa.

Una empresa puede resolver casi todo en el sistema y perder muchas horas con unas pocas excepciones. En otra, habrá más gestiones manuales pero serán rápidas. El porcentaje dice poco por sí solo. Es más útil medir cuánto tiempo consume cada caso y qué ocurre cuando alguien no registra una excepción.

Hay que comprobar qué obliga al equipo a abrir otra herramienta y cuánto tiempo consume. Una excepción poco frecuente a veces obliga a buscar información antes de continuar. Después quizá haya que pedir una aprobación y registrar el cambio.

Al revisar casos reales se repiten varios motivos:

• Casos que necesitan aprobación.
• Cambios de última hora.
• Información que llega escrita de formas distintas.
• Documentos que deben interpretarse antes de registrar algo.
• Coordinación entre departamentos.
• Datos recibidos por un canal que después alguien tiene que registrar en otra aplicación.
• Excepciones que el software contempla de forma muy rígida.

Qué está haciendo realmente el equipo en Excel, correo o WhatsApp

Para detectarlo no hace falta dibujar un mapa técnico. Basta con seguir un caso real y ver qué abre, consulta y actualiza cada persona.

1. Hojas de cálculo

Excel y Google Sheets pueden ser útiles para cálculos o análisis puntuales. La señal de alerta es otra: para saber qué casos siguen pendientes, el equipo tiene que abrir esa hoja. Si no la consulta, algunas gestiones no pueden continuar.

Hay que averiguar para qué se usa esa hoja. La hoja quizá resuelva un cálculo que el SaaS no ofrece. También puede existir simplemente porque alguien sigue copiando datos desde el programa. Para saber cuál de las dos cosas ocurre, hay que ver qué consulta y qué modifica el equipo en esa hoja.

2. Email

El correo es un canal normal para hablar con clientes y proveedores. El problema empieza cuando una respuesta hace de autorización. Si alguien aprueba un descuento con un «OK», otra persona tiene que abrir ese hilo después y registrar la decisión en el programa.

La conversación puede seguir por email. Lo que conviene evitar es que la única prueba de la autorización sea ese hilo. Si la aprobación se registra junto al pedido, la siguiente persona no necesita buscar el correo para saber qué se decidió.

3. WhatsApp

WhatsApp se utiliza porque es rápido y los clientes ya están allí. Un cambio llega en un mensaje y alguien tiene que interpretarlo antes de registrarlo en el sistema.

La automatización de WhatsApp conectada con CRM, ERP y procesos puede leer el mensaje y preparar los datos. Lo que hay que comprobar es si, después de recibirlo, alguien sigue copiando esa información manualmente al sistema de gestión.

4. Copiar y pegar entre aplicaciones

Copiar datos de una aplicación a otra es una señal clara para revisar. A veces basta con conectar ambos sistemas. En otros casos, antes de escribir el dato hace falta comprobarlo o interpretar la información recibida.

5. La memoria del equipo

Es la parte más difícil de detectar. Hay tareas que funcionan porque una persona recuerda qué hacer ante determinadas excepciones. Ese conocimiento no siempre está documentado en el sistema.

Algunas decisiones pueden resolverse con una regla clara. Otras necesitan que una persona las revise. La automatización debe distinguir unas de otras y avisar al responsable cuando haga falta.

Antes de automatizar, hay que saber por qué esa tarea sigue siendo manual

Encontrar una tarea manual solo indica que merece una revisión. La solución depende de la causa.

Antes de desarrollar nada, hay que comprobar por qué existe la tarea manual. Si el SaaS ya permite registrar el dato que falta, quizá solo haya que configurarlo. Si el dato está en otra aplicación, puede bastar con conectar ambas para que nadie tenga que copiarlo.

También es posible automatizar solo una parte. Una negociación comercial puede seguir en manos de la persona responsable. La automatización prepara la información y, una vez aprobada la decisión, registra el cambio correspondiente.

Dos tareas parecidas pueden necesitar soluciones distintas

Una hoja con pedidos especiales quizá exista porque falta un estado dentro del SaaS. Otra hoja muy parecida reúne información que procede de varias aplicaciones. En el primer caso quizá baste con configurar el sistema. En el segundo puede hacer falta una integración.

También hay que saber para qué se utiliza cada herramienta auxiliar. Una tabla que solo sirve para consultar las excepciones del día quizá pueda sustituirse por una vista. Si contiene cálculos necesarios para tomar decisiones, eliminarla sin entender esos cálculos sería un error.

La mejor forma de decidirlo es seguir un caso real de principio a fin. Hay que ver qué hace cada persona y en qué momento vuelve a escribir un dato que ya existía en otra aplicación.

No dupliques los datos que ya están bien gestionados en el SaaS

Una automatización puede terminar copiando datos que ya existen en el SaaS. Suele empezar con una tabla auxiliar y, poco a poco, se añaden clientes o pedidos completos.

Cuando esas copias no coinciden, alguien tiene que comprobar cuál está actualizado antes de seguir.

Hay que decidir en qué aplicación se mantiene cada dato. Si el pedido se registra en el ERP, la automatización consulta ese pedido y lo actualiza allí. El CRM puede conservar la información comercial sin copiar el pedido completo. Así se evitan versiones distintas del mismo dato.

Lo mismo ocurre con las reglas que ya aplica el software. Si una tarifa se calcula dentro del SaaS, repetir ese cálculo en otra herramienta puede producir diferencias cuando cambie la configuración o se actualice el producto.

La automatización tendrá que guardar cierta información técnica para funcionar. Por ejemplo, un identificador o el registro de una ejecución fallida. Eso es distinto de copiar fichas completas de clientes o pedidos.

En una integración entre CRM y ERP, por ejemplo, hay que decidir dónde se mantiene cada dato. El mismo criterio sirve cuando existe un SaaS principal y varias herramientas auxiliares.

Antes de añadir otra herramienta, revisa qué puede hacer ya el SaaS

Antes de crear una automatización externa conviene revisar el producto actual. Puede haber funciones que no se configuraron durante la implantación o que el proveedor añadió después. Si ya existe una forma razonable de resolver la tarea dentro del SaaS, desarrollarla fuera añade mantenimiento sin necesidad.

A veces la hoja de excepciones solo sirve para marcar pedidos que necesitan revisión. Si el SaaS ya permite crear ese estado y asignar esos pedidos a una persona, quizá baste con configurar esa función.

En otros casos la función cubre solo una parte. El SaaS marca un pedido como «requiere aprobación», mientras la autorización se realiza en otra herramienta. Ahí quizá baste con conectar ambos pasos.

La decisión debe partir de la tarea concreta. Si el SaaS ya la resuelve bien, repetirla en otra herramienta solo añade mantenimiento.

Cuando una persona sigue copiando datos entre aplicaciones

Hace falta una integración cuando una persona necesita consultar dos aplicaciones para completar la misma tarea. Por ejemplo, un pedido llega desde un portal y después hay que registrarlo en el ERP. Si ambas aplicaciones no se comunican, alguien acaba copiando los datos a mano.

No todas las conexiones se hacen de la misma manera. La opción depende de lo que permita cada aplicación y de cuándo se necesite el dato.

Salesforce Architects documenta distintos patrones de integración según cómo deba intercambiarse la información. AWS recoge también varias alternativas para conectar sistemas. La elección depende de lo que necesite la tarea y de las opciones que exponga el software.

Tener una API solo abre una vía técnica. Después hay que definir qué datos se consultan y cuándo puede escribirse un cambio. También hay que decidir qué hacer cuando la operación falla o uno de los sistemas no responde.

Antes de conectar dos sistemas, hay que decidir quién puede cambiar cada dato

Antes de conectar dos sistemas hay que decidir cuál puede modificar cada dato. También hay que definir qué hacer si una actualización falla. La integración se limita a ejecutar esas reglas.

Por ejemplo, un comercial cambia una condición en el CRM y administración modifica después el pedido en el ERP. Hay que decidir cuál de los dos cambios manda. Sin esa regla, la integración puede copiar datos correctamente y aun así dejar el pedido mal.

Cada parte de la automatización tiene una función distinta

Separar estas funciones deja claro qué hace la IA y qué decisiones siguen necesitando una persona.

Cada empresa puede aplicar reglas distintas. Una condición automática en una compañía quizá necesite aprobación en otra. Eso debe decidirse antes de poner la automatización en producción.

La automatización no debería convertirse en una copia del SaaS

Una automatización pequeña puede crecer demasiado. Empieza guardando la referencia de un pedido y después incorpora una tabla para controlar casos. Si se siguen añadiendo datos, al final contiene información que ya estaba en el SaaS.

Eso puede tener sentido si la empresa necesita una herramienta interna nueva. Si ese no era el objetivo, probablemente se están copiando demasiados datos y la automatización está haciendo tareas que ya resuelve el SaaS.

Para evitarlo, pueden aplicarse estas reglas:

• Guardar solo los datos necesarios para ejecutar y controlar la automatización.
• Consultar el SaaS cuando haga falta conocer el estado actual.
• Registrar el resultado final en el sistema que corresponda.
• Mantener trazabilidad de la automatización sin copiar todos los datos del sistema principal.
• Crear una vista auxiliar solo cuando ayude al equipo a trabajar y no replique innecesariamente el programa existente.

Por ejemplo, una automatización de cambios de pedido guarda la referencia de la solicitud y el pedido afectado. También registra si la actualización terminó correctamente. No necesita copiar todas las líneas y tarifas si esos datos pueden consultarse cuando hagan falta.

Cuando el SaaS ofrece pocas opciones para conectarlo

No todos los programas ofrecen una API completa. Algunos permiten consultar información pero no modificarla. Otros solo admiten determinadas exportaciones o conectores. También hay productos que no ofrecen una vía oficial para automatizar ciertas acciones.

En esos casos conviene empezar por las opciones más estables:

1. Función nativa del propio SaaS.
2. Integración oficial o conector soportado.
3. API pública.
4. Webhook o eventos.
5. Importación y exportación estructurada.
6. Archivos o correos estructurados como intercambio controlado.
7. RPA sobre la interfaz cuando no existe una alternativa razonable.
8. Paso manual cuando automatizarlo sería demasiado frágil.

Mantener un paso manual también puede ser una buena decisión. Si una tarea ocurre tres veces al mes y solo puede automatizarse simulando clics sobre una interfaz que cambia con frecuencia, el mantenimiento puede superar el ahorro.

AWS señala que las capacidades del sistema existente condicionan las opciones de integración. En la práctica, hay que utilizar los mecanismos que el proveedor mantenga y documente.

Después de enviar un cambio, hay que comprobar qué respondió el SaaS

En una demo es fácil dar por hecho que una actualización terminó bien. En producción hay que comprobar qué respondió el sistema antes de continuar. Que una llamada no devuelva un error tampoco garantiza que el dato se haya registrado exactamente como se esperaba.

Una respuesta correcta indica, como mínimo, que el sistema recibió la petición. Según el software, todavía puede ser necesario consultar el registro actualizado o comprobar el identificador devuelto.

Si la actualización falla, hay que avisar a una persona para que revise qué ocurrió. Tampoco debería informarse al cliente de que el cambio está hecho hasta comprobarlo.

Volvamos al ejemplo inicial. El cliente pide por WhatsApp cambiar las cantidades de un pedido. La IA localiza la referencia y prepara la solicitud. Después se comprueba si el pedido admite cambios. La integración registra la modificación y, cuando el SaaS confirma el resultado, se responde al cliente.

En ese caso ya no hace falta anotar la excepción en una hoja. El pedido se actualiza en el sistema que utiliza la empresa y la automatización conserva el registro necesario.

Cuándo debe detenerse la automatización y avisar a una persona

También hay que definir cuándo debe detenerse la automatización. Si faltan datos o no se puede comprobar la operación, continuar puede registrar información incorrecta. En ese caso debe avisarse a una persona y adjuntar lo que ya se haya podido identificar.

La automatización deja preparado lo que ya se haya podido comprobar. La persona que revisa el caso recibe la operación identificada y el motivo por el que se detuvo, sin tener que empezar desde cero.

Cómo elegir un primer caso para automatizar

Antes del piloto, sigue un caso real hasta el final

En una reunión es fácil quedarse con frases como «esto lo llevamos por Excel» o «los cambios llegan por WhatsApp». Para diseñar una automatización hace falta seguir un caso concreto. Es mejor escoger uno reciente y revisar qué hizo el equipo desde que recibió la solicitud hasta que actualizó el dato.

Al seguir un caso aparecen tareas que el equipo hace casi de memoria. Quizá alguien compruebe una referencia o pregunte a otra persona antes de continuar. Esos detalles indican qué se puede automatizar y en qué momento debe intervenir alguien.

Un buen primer candidato se repite con frecuencia y empieza de una forma reconocible. También debe tener un resultado que pueda comprobarse. Así se compara cuánto trabajo hacía antes el equipo y cuánto sigue haciendo después del piloto.

Qué merece la pena medir antes y después

Antes del piloto conviene medir cuánto trabajo manual existe. Se puede contar cuántos casos obligan a abrir una hoja o buscar un mensaje y cuánto tarda el equipo en resolverlos. También interesa saber cuántas veces hay que abrir otra aplicación para completar la tarea.

Durante el piloto hay que registrar los errores de integración y los casos que una persona tiene que revisar. Si se utiliza IA, también conviene medir cuántas interpretaciones necesitan corrección. Después se comprueba si el equipo puede dejar de utilizar alguna hoja o lista paralela. Si sigue manteniéndola, hay que averiguar qué información consulta todavía allí.

También merece la pena comprobar si el equipo encuentra cada caso con menos esfuerzo. No todo el beneficio se mide en minutos. Evitar que una autorización dependa de localizar un correo antiguo también reduce errores y consultas internas.

Qué evitar como primer piloto

Una tarea que nadie puede explicar de forma consistente suele ser un mal primer candidato. También lo es aquella en la que casi cada caso necesita una decisión distinta. Si todo depende de una interfaz inestable, es mejor empezar por otro problema.

Si la empresa todavía está decidiendo cómo quiere trabajar, primero debe resolver esa cuestión. Automatizar un procedimiento que cambia cada semana obliga a rehacer la solución continuamente.

Preguntas frecuentes sobre tareas que se siguen resolviendo con otras herramientas