Decide qué parte de tu proceso necesita IA.

Usaremos un ejemplo ficticio: una empresa recibe solicitudes de soporte y quiere asignarlas a un equipo. Algunas llegan mediante un formulario con una categoría elegida; otras son mensajes libres. El resultado esperado es una solicitud registrada, con un responsable y sin duplicados.

Dibuja el recorrido actual: recepción, comprobación de campos, clasificación, asignación y confirmación. Anota quién resuelve las excepciones. Si dos personas interpretan de forma distinta el resultado correcto, aclara primero el criterio con ellas.

Para el formulario del ejemplo, define una tabla: categoría «facturación» al equipo administrativo; «incidencia técnica» a soporte; categoría vacía a revisión. Si basta con consultar un campo y aplicar esa tabla, puedes implementar esa parte con reglas explícitas.

Añade también validaciones: campos obligatorios, categorías permitidas y un identificador de solicitud para detectar repeticiones. Estas reglas necesitan mantenimiento cuando cambia el proceso; tenerlas escritas permite comprobar qué versión se aplicó.

Un mensaje como «me habéis cobrado dos veces y no puedo entrar» contiene dos asuntos. Puedes ensayar un clasificador con IA que proponga etiquetas a partir del texto. Dale una lista cerrada de categorías, ejemplos y una salida «requiere revisión».

Comprueba la propuesta antes de asignar el caso: ¿la etiqueta está permitida?, ¿falta información?, ¿hay varios asuntos? La propuesta del modelo y la acción del sistema son pasos distintos. En este piloto, una persona decide los casos ambiguos.

Prepara un conjunto de solicitudes cuyo destino correcto haya decidido el equipo. Incluye casos habituales, mensajes incompletos y solicitudes con varios asuntos. Reserva algunos para la comprobación final y evita usarlos para ajustar las instrucciones.

Compara una versión con reglas y revisión manual con otra que añada clasificación por IA. Registra asignaciones correctas, errores de destino, casos derivados y tiempo total de revisión. Separa los errores que retrasan una respuesta de los que envían información al equipo equivocado.

Ejemplo inventado: si el flujo anterior requiere 80 minutos para un lote y el nuevo consume 35 minutos de operación más 30 de revisión, el ahorro observado es de 15 minutos. Son cifras didácticas, no una previsión de resultados. Anota también herramientas y mantenimiento antes de decidir.

Guarda en un documento el proceso elegido, la tabla de reglas, los ejemplos de prueba, los resultados y la persona responsable. Decide qué resultado justificaría continuar y qué error obligaría a detener el piloto. El umbral debe responder a las consecuencias de tu tarea.

Si la revisión consume todo el tiempo que pretendías ahorrar, reduce el alcance o mejora la información de entrada. Si el piloto funciona, amplía un tipo de solicitud cada vez y conserva una vía manual para recuperar el trabajo.