La automatización que el equipo adoptó porque les quitó trabajo, no porque se los pedí
Los proyectos de automatización que más resistencia generan en los equipos son los que se presentan como mejoras de eficiencia para la organización sin hacer explícito cuál es el beneficio concreto para la persona que tiene que cambiar su forma de trabajar. La resistencia no es irracional. Es la respuesta lógica de alguien a quien se le pide que cambie sus hábitos de trabajo para beneficiar a un sistema o a un manager que revisará reportes más precisos, sin que nadie le explique qué va a ser mejor en su trabajo diario como resultado del cambio.
La automatización que el equipo adoptó sin que nadie se lo pidiera fue la del proceso de actualización de estados de oportunidades en el CRM después de las reuniones. Antes de la automatización, después de cada reunión con un prospecto, el representante de ventas tenía que abrir el CRM, navegar hasta el registro de la oportunidad, actualizar el estado, escribir las notas de la reunión, definir el próximo paso y registrar la fecha. Era un proceso de 8 a 12 minutos por reunión que nadie cuestionaba porque era "parte del trabajo" pero que en un día con 4 reuniones consumía casi una hora de actividad administrativa.
La automatización conectaba el calendario del representante con el CRM. Cuando una reunión marcada como "reunión de ventas" en el calendario terminaba según el horario registrado, el sistema generaba automáticamente una tarea en el CRM con el nombre del prospecto, la fecha de la reunión y un formulario de 4 campos de actualización rápida: estado de la oportunidad después de la reunión, próximo paso acordado, fecha del próximo contacto y notas breves de la reunión. El representante recibía esa tarea como notificación en el móvil, podía completarla en 3 minutos desde el teléfono mientras seguía en el lugar de la reunión o en el transporte de regreso, y los datos llegaban al CRM sin que tuviera que abrir el sistema en el computador.
La tasa de actualización de oportunidades después de reuniones subió del 61% al 94% en las 4 semanas siguientes al lanzamiento de la automatización. Ningún manager lo había pedido. Ningún protocolo lo había impuesto. El equipo adoptó el nuevo proceso porque había reducido el tiempo de actualización de 10 minutos a 3 y había eliminado la fricción de tener que abrir el computador específicamente para hacer una tarea administrativa. El beneficio era para ellos primero. El beneficio para el sistema y para los reportes era consecuencia, no causa.
La lección que esa experiencia consolidó en mi filosofía de implementación de automatizaciones es simple y difícil de aplicar consistentemente: la automatización que busca adopción debe empezar por identificar qué trabajo del usuario es más tedioso, más repetitivo y menos conectado con lo que a esa persona le importa de su trabajo. Automatizar ese trabajo no requiere persuasión. Requiere que la solución funcione bien. La adopción sigue de forma natural cuando el beneficio es para el usuario primero.