Cuando un equipo copia información entre herramientas, busca mensajes y reconstruye pendientes, aparece una pregunta razonable: ¿qué parte de ese trabajo podría automatizarse? Elegir una herramienta antes de describir el proceso deja sin resolver quién responde por el resultado y qué debe ocurrir cuando falta información.
Una primera automatización puede comenzar con un recorrido pequeño que tenga entradas, responsables y una salida verificable. La IA puede ayudar en algunas partes; otras pueden resolverse con reglas acordadas e integraciones. Esta guía propone cómo separar ambas y dónde colocar una revisión humana. El ejemplo que la recorre es hipotético y demostrativo: no describe un cliente ni acredita ahorros o resultados de ADN Dev Labs.
Describe el trabajo como ocurre hoy
Escoge una tarea repetida y observa su recorrido completo. ¿De dónde llega la información? ¿Quién la revisa? ¿Dónde se registra? ¿Qué decisión permite seguir? Incluye las interrupciones habituales: un dato incompleto, una consulta duplicada o una solicitud que nadie sabe clasificar. Esas situaciones también pertenecen al proceso.
Escribe los pasos con verbos concretos. “Gestionar consultas” es amplio. “Revisar el mensaje, identificar el servicio, asignar un responsable y preparar una respuesta” permite discutir qué puede cambiar. Conserva un ejemplo sin datos privados para que todas las personas hablen del mismo caso.
Si el proceso cambia según la persona que lo atiende, anota esas diferencias. Antes de conectar herramientas puede ser necesario acordar una regla de trabajo. Automatizar una ambigüedad la traslada al flujo y hace más difícil saber por qué una solicitud terminó en un estado determinado.
Elige una primera frontera de automatización
Busca un tramo cuyo resultado puedas revisar. Puede ser trasladar un registro válido, organizar una cola o preparar un borrador. Define dónde empieza, dónde termina y qué queda para una persona. Un primer flujo acotado permite observar la calidad de la entrada y las excepciones antes de ampliar su responsabilidad.
Para elegir entre candidatos, compara preguntas prácticas: ¿la información necesaria suele estar disponible?, ¿hay una persona responsable?, ¿podemos detectar un resultado incorrecto?, ¿se puede detener el flujo y continuar manualmente? Si varias respuestas son inciertas, resuelve esas dudas como parte del alcance.
Evita convertir “usa IA” en el criterio de aceptación. Una automatización es útil cuando realiza la tarea acordada de manera comprensible y permite manejar sus fallos. El tipo de herramienta se decide a partir de lo que el proceso necesita y de los límites que el negocio acepta.
Un ejemplo: de consulta entrante a borrador revisable
Supongamos que un equipo recibe consultas mediante un formulario de su web. En este escenario ficticio, el objetivo inicial es preparar el trabajo de respuesta. La salida prevista es una solicitud organizada, con responsable y borrador pendiente de aprobación. El envío al interesado queda en manos de una persona.
El flujo comienza comprobando los campos requeridos. Si falta información, la solicitud pasa a una bandeja de revisión. Si está completa, se registra con un identificador y se busca si ya existe una entrada equivalente. La definición de duplicado debe acordarse: no conviene eliminar una consulta solamente porque se parece a otra.
Luego puede usarse una regla para asignar un servicio conocido. Cuando el mensaje necesita interpretación, una herramienta de IA podría sugerir una categoría y resumir lo solicitado. Esa sugerencia debe distinguirse del mensaje original para que quien revisa pueda detectar una interpretación incorrecta.
Por último, el sistema prepara un borrador basado en información aprobada sobre el servicio. La persona responsable verifica destinatario, contexto y contenido antes de enviar. Una duda de alcance, una condición comercial o una solicitud fuera del catálogo permanece como decisión humana. El ejemplo ilustra un diseño posible, no una integración ya construida para un caso del portafolio.
Decide qué puede hacer una regla y qué requiere interpretación
Una regla funciona con condiciones explícitas: existe un campo, coincide un código, falta una aprobación. Es posible explicar por qué tomó una ruta. Documenta esas condiciones y permite que el equipo entienda qué información necesita corregir para continuar.
La IA puede participar cuando hay lenguaje abierto: resumir una descripción o proponer una clasificación. También puede interpretar mal el mensaje o agregar información que nadie proporcionó. Por eso el diseño debe conservar la entrada original y definir qué puede utilizarse sin aprobación y qué requiere revisión.
No necesitas elegir la misma política para todo el flujo. Registrar una solicitud recibida y enviar una respuesta comercial tienen consecuencias distintas. Acordar permisos por acción permite avanzar con una parte útil sin entregar automáticamente decisiones que el equipo todavía necesita controlar.
Coloca la revisión donde cambian las consecuencias
“Una persona revisa” necesita detalles. Define quién recibe la tarea, qué información ve y qué opciones tiene: aprobar, corregir, pedir contexto o descartar con una razón. Incluye qué ocurre si esa persona no está disponible y cómo identifica lo que lleva tiempo pendiente.
Una revisión útil compara el resultado con su origen. En el ejemplo, la persona puede leer el mensaje inicial junto al resumen y al borrador. Si debe reconstruir el contexto en varias herramientas, todavía queda una fricción que conviene reconocer y discutir.
Acordar este punto también ayuda a separar preparación y ejecución. Un borrador generado es un material pendiente; una respuesta enviada es una acción externa. La interfaz y el registro del flujo deben mostrar esa diferencia para que el equipo sepa qué sucedió realmente.
Diseña la excepción antes de ampliar el recorrido
Anota qué pasará si un proveedor no responde, una conexión falla o una solicitud llega dos veces. Define una forma de registrar el incidente y de retomar el trabajo sin repetir acciones ya completadas. Si el flujo se pausa, alguien necesita poder identificar dónde quedó y qué parte requiere intervención.
Acuerda también qué información puede salir de las herramientas del negocio, con qué proveedores y con qué accesos. Usa datos ficticios o preparados para las pruebas. Estas son decisiones de alcance y operación; una conexión técnica por sí sola no acredita que todo uso de información esté autorizado.
La documentación debe permitir continuar manualmente mientras se resuelve un problema. Describe cómo detener el flujo, cómo atender los pendientes y quién revisará la causa. Ese recorrido forma parte de la entrega, junto con la integración principal.
Prueba el recorrido y define qué observar
Antes de activar el flujo con trabajo real, revisa ejemplos preparados: entrada completa, información faltante, duplicado, categoría dudosa, corrección humana y fallo de conexión. Comprueba los estados y las notificaciones, además del resultado final. Ninguna prueba necesita incluir datos de clientes para demostrar la lógica acordada.
Después define qué observarás: solicitudes pendientes, excepciones, correcciones y acciones completadas. Si buscas medir tiempo o calidad, primero establece cómo registrarás la situación inicial y el periodo de revisión. Sin esa referencia no corresponde prometer un porcentaje de ahorro ni atribuir un resultado a la automatización.
En ADN Dev Labs, el servicio de automatización e IA parte del mapa del proceso, sus entradas y sus responsables. Nuestro trabajo en Heztio y Heztio Inn también puede explorarse como software para operaciones con distintos roles; esos casos no se presentan como prueba de esta integración hipotética con IA.
Cuéntanos qué tarea repite tu equipo y dónde suele atascarse. Con ese punto de partida podemos conversar sobre un primer flujo, sus límites y la revisión humana que necesita.