Se puede automatizar mucho. ¿Qué merece la pena?

Un formulario envía sus datos a una hoja de cálculo. Un sistema prepara una respuesta. Otro crea un presupuesto y programa un mensaje. Cada paso puede parecer convincente en una demostración.

Si el equipo pierde tiempo una y otra vez en los mismos pasos, es natural buscar una solución. Para elegir bien, también hay que saber qué seguirá habiendo que comprobar después de automatizar, para que el tiempo ganado no se lo coman las correcciones.

El trabajo real incluye casos incompletos: un precio desactualizado, una solicitud poco clara, una integración que no responde o un cliente que pide algo fuera de la oferta estándar. Juzga también la automatización por lo que pasa en esos casos.

«Podemos automatizarlo» describe una posibilidad técnica. La empresa todavía tiene que conocer el beneficio, los costes y quién la hará funcionar.

Partir del proceso existente.

Anotamos qué entra en el proceso, qué tiene que salir y quién lo usa. Después identificamos las reglas estables, los datos necesarios y las excepciones frecuentes.

Si dos personas definen de forma distinta una «solicitud cualificada», la automatización puede reproducir la confusión más rápido. Si los precios no tienen una fuente actualizada, una respuesta bien redactada puede seguir siendo errónea.

Para operaciones con reglas fijas, una integración estándar puede bastar. La IA puede ayudar a interpretar un texto o a preparar una variante de respuesta. La elección parte de la tarea y de cómo se comprobará el resultado.

En sus recomendaciones para construir sistemas de IA, Anthropic aconseja empezar por la solución más sencilla que cubra la necesidad y añadir complejidad solo cuando esté justificada. El principio también es útil en los proyectos de marketing. Anthropic: construir agentes eficaces (en inglés)

No todos los pasos necesitan el mismo nivel de autonomía

Imagina una empresa de muebles a medida. Algunos mensajes preguntan el horario del showroom, otros describen medidas y materiales, y otros piden un precio final o una excepción a las condiciones habituales.

Podemos organizar el proceso en tres niveles. Esta clasificación es un modelo de trabajo para este ejemplo, no una regla universal para todas las empresas.

Un acuse de recibo no debe prometer automáticamente disponibilidad, un precio final ni una fecha de entrega. El mensaje tiene que mantenerse dentro de lo que el sistema puede comprobar.

El ahorro se calcula después de las comprobaciones y las excepciones

Supongamos que una actividad lleva 12 horas al mes. Después de automatizarla, quedan tres horas de seguimiento y dos horas de gestión de excepciones. El ahorro neto de tiempo es de siete horas.

En el modelo hipotético siguiente, la puesta en marcha cuesta 2500 RON, con la configuración, las pruebas y la formación inicial incluidas. El coste recurrente adicional es de 200 RON al mes, por las herramientas y el mantenimiento externo supuestos. Las cantidades son sin IVA y no representan precios ni propuestas de NOT MORE.

El cálculo es 7 × 100 − 200 = 500 RON al mes, y después 2500 / 500 = 5 meses. Suponemos el mismo volumen de actividad y costes estables. El modelo no tiene en cuenta el valor temporal del dinero y no es una promesa de recuperar la inversión.

Las horas ahorradas no son automáticamente dinero cobrado ni costes salariales eliminados. Si el equipo no puede dedicarlas a un trabajo útil, el beneficio económico supuesto no se convierte en un ahorro de caja. El gasto directo adicional, en cambio, sigue siendo real.

El volumen cuenta. Con las mismas hipótesis de precio, ahorrar solo dos horas al mes tendría un valor de 200 RON, igual al coste recurrente. En ese escenario, el modelo no recupera la inversión inicial gracias al ahorro de tiempo.

¿Qué pasa cuando falta información?

Antes del lanzamiento, define qué ocurre cuando el sistema no encuentra un producto, recibe información contradictoria o no puede confirmar un envío. Puede pedir una aclaración, marcar un caso para revisión o interrumpir esa acción y avisar a su responsable.

Si una solicitud se registra pero la notificación falla, un nuevo intento no debe crear un duplicado. El sistema tiene que reconocer la misma solicitud y repetir solo el paso que falló.

Definimos quién puede detener la automatización, dónde se ven los errores y cómo toma el relevo el trabajo manual. Son condiciones prácticas de funcionamiento, sobre todo cuando el proceso se comunica directamente con los clientes.

La misma disciplina se aplica a las automatizaciones publicitarias

Cuando una plataforma puede combinar recursos o generar variantes, acordad qué fuentes puede usar, qué tiene que mantenerse exacto y quién revisa los resultados disponibles. Una oferta caducada en la web se convierte en un problema si alimenta la publicidad en curso.

Prevé la comprobación de las fuentes, la revisión de los ajustes y la corrección de las variantes inadecuadas, dentro de los límites de la herramienta. La automatización reduce el trabajo repetitivo; el equipo todavía tiene que comprobar el resultado frente al producto y la promesa aprobados.

Probar situaciones parecidas al trabajo real.

Un piloto útil incluye solicitudes normales, información que falta, duplicados y casos que tienen que volver a una persona. Comparamos el resultado con el requisito y medimos el tiempo total, correcciones incluidas.

Seguimos los procesos que se completan correctamente, la frecuencia de las intervenciones necesarias, el número de errores y su impacto. Una tasa de procesamiento alta no basta si hay mensajes con precios erróneos o que pierden información importante.

Después del lanzamiento, revisamos las fuentes de datos, los costes y las excepciones. Una automatización construida para una oferta antigua puede necesitar una actualización cuando la empresa cambia de productos o de proceso comercial.

¿Cómo saber si la experiencia ha mejorado?

Un proceso más rápido para el equipo puede volverse más difícil para el cliente. Si el asistente cierra una conversación cuando la persona todavía no tiene respuesta o tiene que repetirlo todo por teléfono, el número de conversaciones terminadas describe la actividad del sistema sin demostrar una resolución.

Antes de un piloto, definiríamos el resultado esperado para cada recorrido. Para una pregunta sobre un producto, comprueba que la respuesta es correcta y suficiente. Para una cita, comprueba que la reserva existe. Para una solicitud compleja, un traspaso completo a la persona adecuada puede ser el resultado útil.

Valorar el efecto real de una acción por separado de lo que afirma el agente también se trata en los recursos de Anthropic sobre la evaluación de agentes (en inglés). Aplicado aquí, un mensaje de confirmación tiene que comprobarse frente a la operación que describe.

Valoraríamos cuatro elementos juntos: la exactitud, el esfuerzo que se pide al cliente, el tiempo total del equipo y el avance hacia el objetivo. Las respuestas aceptadas, la información corregida, los traspasos necesarios y las operaciones fallidas tienen que poder distinguirse. Que un compañero tome el relevo puede ser el resultado correcto para un caso, y no un fallo de la automatización.

La comparación también necesita contexto. Las personas que eligen usar un asistente pueden tener otras preguntas o intenciones que el resto de visitantes. Una tasa de conversión más alta en ese grupo no demuestra que el asistente haya causado la diferencia. Para valorar su efecto, diseñaríamos una prueba con grupos comparables y decidiríamos de antemano qué medir y a partir de cuándo los datos permitirían una decisión.

Mantendríamos el acceso directo a la información y al equipo. Los visitantes tienen que poder corregir un detalle, entender el siguiente paso y elegir otro camino. La confianza crece cuando el sistema ayuda sin convertir una conversación en una condición para avanzar.

Cómo hacemos la elección en NOT MORE.

Partimos de la actividad repetitiva y de su coste real. Podemos proponer una regla sencilla, una integración, una asistencia con IA o mantener un paso manual. Explicamos qué se automatiza, qué se comprueba y qué sigue siendo responsabilidad de una persona.

Para nosotros, una implementación útil es una implementación que el equipo que la usa puede hacer funcionar y entender. El beneficio se comprueba en todo el proceso, una vez incluidos el seguimiento y el mantenimiento.

Tres preguntas antes de la implementación

• ¿Cuánto tiempo y cuántos errores podríamos ahorrar con la carga de trabajo real?
• ¿Qué puede hacer el sistema de forma autónoma y cuándo tiene que tomar el relevo una persona?
• ¿Cómo comprobamos el beneficio una vez descontados los costes, las correcciones y las excepciones?

¿Qué actividad repetitiva te gustaría simplificar?

Describe los pasos actuales, el volumen mensual y las situaciones que exigen una intervención. Podemos ver juntos si una regla sencilla, una integración o una asistencia con IA merece valorarse en un proyecto bien definido.

De una regla de trabajo a una automatización utilizable

NOT MORE. puede diseñar el proceso, elegir las herramientas y construir una automatización o una integración. Partimos de la información, las decisiones y las excepciones necesarias, y después configuramos o desarrollamos la solución adecuada. Una herramienta existente puede cubrir la necesidad; un desarrollo a medida tiene sentido cuando los requisitos lo justifican.

En un ejemplo ficticio, las solicitudes de presupuesto se copian a mano del correo a una hoja de cálculo. Podríamos construir el envío a un CRM y la regla de asignación. Pero también hay que comprobar los mensajes duplicados, los campos que faltan, los compañeros ausentes y los fallos de integración. Una alerta solo es útil si llega a alguien que sabe qué hacer.

El cliente aprueba las reglas de negocio y designa a los usuarios. Implementamos, probamos y documentamos los componentes acordados, y podemos incluir formación. Establecemos quién puede detener el proceso, cómo trabajar de forma manual durante un tiempo y cómo confirmar la vuelta al funcionamiento normal.

El seguimiento, el mantenimiento y los informes dependen de la función de la automatización y del impacto de un error. En un proyecto puntual, entregamos la solución y las comprobaciones acordadas. En una colaboración continua, seguimos las ejecuciones, las excepciones y los cambios necesarios. El avance se valora por el trabajo útil realizado y los errores reducidos en las condiciones reales del equipo.

El equipo tiene que poder adoptar la solución

Las personas que usan una automatización tienen que entender qué cambia en su jornada de trabajo. Las implicamos en las pruebas de las situaciones relevantes y acordamos la formación, la intervención manual y a quién pueden pedir ayuda. Una primera fase limitada puede mostrar si las reglas y la interfaz se pueden usar antes de ampliar. El tiempo necesario para adaptarse a la solución y administrarla forma parte de la valoración del proyecto; no debe desaparecer detrás de una promesa de eficiencia.