Automatizacion y procesos de negocio
La automatizacion en el CRM sirve para que el trabajo repetitivo se ejecute siempre igual y sin control manual: una nueva solicitud recibe responsable de inmediato, al pasar a una etapa se crea la tarea necesaria, el cliente recibe un correo segun una plantilla y, antes de cerrar, se verifican las condiciones obligatorias. Una buena automatizacion acelera el proceso y lo hace predecible; una mala cambia los datos de forma silenciosa hasta que el equipo deja de entender que ha pasado.
La automatizacion se gestiona en la seccion de automatizacion del CRM (/crm/automation). Es trabajo del administrador del proceso, no una accion cotidiana del comercial.
La automatizacion del CRM no se limita a ventas: la canalizacion seleccionada puede atender oportunidades comerciales o solicitudes de servicio. En ejemplos seguros, usa Delivery window — demo para una solicitud de servicio y Rebranding — demo para una oportunidad comercial; no uses registros, identificadores ni importes reales y no modifiques datos.
De que se compone la automatizacion
En el CRM hay varias herramientas, y es importante no confundir su proposito:
- Reglas-robot se activan despues de un evento (se ha creado una oportunidad, ha cambiado la etapa, ha cambiado un campo) y ejecutan acciones.
- Comprobaciones previas se activan antes de una operacion y no permiten completarla mientras no se cumpla una condicion.
- Procesos de negocio describen un escenario de varios pasos con condiciones, esperas y tareas para las personas.
- Plantillas de correo guardan el texto de los mensajes externos que envian los robots y los procesos.
Reglas-robot
Una regla responde a la pregunta «que hace el sistema despues de un evento».
- Evento (disparador): creacion de una oportunidad, entrada en una etapa, cambio de un campo, ejecucion manual y tambien eventos del intercambio de documentos (vease mas abajo).
- Si la lista de disparadores muestra códigos en lugar de nombres legibles, no active la regla a ciegas. Confirme el significado del evento con la persona responsable del proceso y espere una etiqueta clara y localizada.
- Condiciones: con que valores se activa la regla; las condiciones se pueden combinar con «y»/«o».
- Acciones: una cadena de pasos: asignar responsable, pasar a una etapa, cambiar un campo, crear una tarea, enviar una notificacion, enviar un correo al cliente, lanzar un proceso y otras.
- Si una acción usa un importe o una moneda, compruebe por separado la moneda de la oportunidad y el resultado esperado. Antes de activar la regla, asegúrese de que usa los datos monetarios y el formato que espera su equipo.
- Ramificacion: «si — si no» dentro de la regla para distintos casos.
- Programacion del paso: de inmediato, con retardo o a una hora exacta.
- Politica de errores: continuar o detener la cadena cuando un paso falla.
Cada regla tiene un ambito de actuacion (toda la empresa, un pipeline o una etapa) y una prioridad. Cuanto mas amplio es el ambito, con mas atencion hay que revisar la regla antes de activarla. Tener acceso al CRM no garantiza el acceso a la automatización de la pipeline o etapa seleccionada. Si un ámbito delegado deniega el acceso, la página muestra el motivo y no carga la lista de reglas; no es una lista vacía. Revise la pipeline y la etapa elegidas y solicite acceso con ese ámbito al responsable de la política.
El historial de ejecucion muestra lo que la regla realmente hizo: el estado de cada ejecucion, los pasos completados y el resultado de la entrega de notificaciones. Es la herramienta principal de analisis cuando la automatizacion se comporta de forma distinta a lo esperado.
Disparadores del intercambio de documentos
Flujo conceptual; no es una captura de UI ni prueba de datos del portal.
Si en el portal esta conectado el intercambio de documentos, las reglas disponen de los eventos propios de ese flujo:
- Contraparte vinculada (intercambio de documentos): un documento entrante se ha emparejado con un cliente del CRM;
- Archivos del intercambio de documentos importados: los documentos y las copias firmadas se han cargado en el lado del portal;
- Documento finalizado (intercambio de documentos): el intercambio del documento ha llegado a su estado final;
- Error de importacion del intercambio de documentos: la carga no se completo.
Esto permite enlazar el intercambio de documentos con el trabajo de las personas en lugar de vigilarlo a mano: cuando un documento se completa, pase la oportunidad a la siguiente etapa o cree una tarea de ejecucion; y ante un error de importacion, avise de inmediato al responsable. El error de importacion merece especialmente una regla: sin aviso solo se detecta cuando el cliente pregunta por un documento que nunca recibio.
Comprobaciones previas
Una comprobacion previa es una condicion que debe cumplirse antes de una operacion: por ejemplo, que un campo obligatorio este relleno, que una lista de control este completa o que el paso entre etapas sea admisible. Si la condicion no se cumple, la operacion se bloquea y el usuario ve un mensaje y una indicacion de que corregir.
Una comprobacion previa no es burocracia, sino proteccion del resultado: no permite cerrar una oportunidad sin motivo ni pasarla a una etapa sin los datos necesarios.
Que es importante al configurarla:
- El bloqueo muestra todas las causas a la vez. Si una operacion incumple varias comprobaciones, el usuario las vera en una sola lista, cada una en su propia linea. Redacte los mensajes para que se lean bien unos junto a otros: breves, concretos, sin formulas vagas del tipo «no se puede».
- El mensaje debe nombrar la correccion, no la prohibicion: «rellene el motivo de cierre», y no «el paso esta prohibido».
- El formulario se desplaza al campo problematico y lo resalta cuando la comprobacion apunta a un campo concreto. Vincule la comprobacion a un campo siempre que pueda: asi el usuario encuentra de inmediato donde corregir.
- La excepcion conocida es el motivo de cierre: el resaltado no lleva hasta el. Si su comprobacion exige un motivo de cierre, indique en el mensaje donde rellenarlo.
Plantillas de correo
Las plantillas de correo guardan los mensajes externos repetitivos hacia el cliente. Una plantilla activa queda disponible para la accion «Correo al cliente» en las reglas y los procesos. En la plantilla se pueden insertar datos de la oportunidad y del cliente, de modo que un mismo correo sirve para muchas situaciones.
Compruebe la insercion con una solicitud de CRM sintetica seleccionada, no con un registro real: la vista previa necesita el ID de la entidad CRM sintetica seleccionada y su contexto de objeto. Use Delivery window — demo para una solicitud de servicio o Rebranding — demo para una oportunidad comercial; mantenga la comprobacion en modo de solo lectura.
- El boton «Variables» abre el catalogo de inserciones disponibles, agrupado por sentido; la variable elegida se inserta en el texto.
- El boton «Comprobar» aparece cuando el texto contiene variables y muestra el bloque «Vista previa»: en que se convertira el mensaje, junto con los errores y avisos de la insercion.
Use la vista previa antes de activar la regla. Detecta justo aquello que hace que los correos salgan mal: una errata en el nombre de una variable, una insercion que no existe en ese contexto y espacios en blanco donde faltan los datos.
Procesos de negocio
Un proceso de negocio describe un escenario de varios pasos: pasos de accion, condiciones, esperas de un evento, tareas para las personas, bucles y ramas paralelas. Los procesos se construyen en un editor visual, donde los pasos se conectan en un esquema.
Antes de lanzarlo, conviene revisar el proceso y probarlo en modo de prueba para asegurarse de que sigue el camino esperado. Un proceso en ejecucion tiene un estado y un historial de pasos; un proceso bloqueado se puede detener. Las tareas para las personas que genera el proceso se reunen en una lista aparte y se ejecutan manualmente.
Que es importante para el control
- Cada regla, proceso y plantilla debe tener un sentido claro por su nombre y un propietario.
- Antes de activar una regla importante, compruebe el resultado previsto y pruebela con datos seguros.
- La automatizacion no debe cambiar de forma silenciosa al responsable, el plazo o el estado: si una accion puede generar dudas, agregue un registro o una notificacion claros.
- Revise periodicamente las reglas sin uso y las demasiado amplias.
- Analice el historial de ejecucion cuando el resultado difiera de lo esperado.
Como analizar la ejecucion de una regla
Cuando una regla no funciona como esperaba, no la desactive de inmediato: primero lea el historial de ejecuciones. Le muestra que ocurrio exactamente y le ahorra horas de suposiciones.
En el historial, por cada ejecucion se puede ver:
- el estado de la ejecucion: correcta, parcial, con error, omitida o en curso;
- que pasos se ejecutaron y en cual paso se detuvo la cadena;
- el resultado del envio de notificaciones y correos: a quien llego, a quien no y por que;
- el origen: que evento y por que oportunidad lanzo la regla.
Si el historial solo muestra un identificador de servicio sin un nombre legible de la oportunidad ni resultado, no considere verificada la ejecucion. Compruebe el nombre, el estado y el resultado que puedan entender las personas implicadas.
Orden de analisis:
- Localice la ejecucion que busca por la oportunidad y la hora.
- Compruebe si la cadena llego hasta el final o se detuvo en un paso.
- Si un paso tiene error, lea la causa: lo mas habitual son datos que faltan, permisos o un destinatario no disponible.
- Corrija la causa (datos, permisos, plantilla o ambito) y, si hace falta, vuelva a ejecutar la regla manualmente.
- Si la regla se dispara demasiado a menudo o donde no debe, acote la condicion y el ambito en lugar de desactivar toda la automatizacion.
Un resultado parcial no es necesariamente una averia: una parte de las acciones puede haberse omitido de forma consciente por las condiciones. Lo importante es distinguir una omision esperada de un error real, y para ello basta con el historial de ejecuciones.
Estados que se pueden ver
- sin permisos para ver o cambiar la automatizacion;
- regla desactivada;
- el resultado previsto muestra que la ejecucion no es posible;
- la ejecucion manual esta en curso;
- el historial muestra un error o un resultado parcial de la ejecucion;
- la comprobacion previa ha bloqueado la operacion y ha enumerado todas las condiciones incumplidas;
- la vista previa de la plantilla ha mostrado un error o un aviso de insercion;
- el proceso esta detenido o finalizado.
Una parte de las pantallas de automatizacion y procesos de negocio aun no esta localizada para todos los idiomas de la interfaz. Es una limitacion conocida del producto: antes de mostrar un flujo, compruebe que los nombres de las acciones y los mensajes sean claros para su equipo.
Buenas practicas
- De a las reglas y procesos nombres claros y un propietario.
- Compruebe el resultado previsto y pruebe antes de activar.
- No permita que la automatizacion cambie de forma silenciosa al responsable, el plazo o el estado.
- Haga claros los mensajes de las comprobaciones previas: que corregir, y no solo «no se puede», y recuerde que pueden aparecer en una lista junto a otros.
- Compruebe la insercion en la plantilla con la vista previa antes de activar la regla.
- Revise las reglas con regularidad y desactive las que sobran.
Errores frecuentes
Activar una regla con un ambito amplio sin comprobarla. Se activa donde no debe y crea acciones innecesarias.
Cambiar de forma silenciosa al responsable o el plazo con la automatizacion. El equipo pierde la comprension de quien responde de que.
Crear una comprobacion previa con un mensaje poco claro. El usuario ve la prohibicion, pero no sabe que corregir.
Usar una plantilla de correo sin comprobar la insercion. La vista previa del campo de la plantilla muestra el resultado y los errores en segundos; sin ella, el cliente recibe un correo con espacios vacios o con datos ajenos.
Redactar el mensaje de una comprobacion previa como si fuera el unico. El usuario puede ver varios mensajes a la vez; las formulas vagas en una lista compartida no dejan claro que hay que corregir.
Lanzar un proceso sin una ejecucion de prueba. Sigue un camino inesperado, y analizar las consecuencias sale mas caro que comprobarlo de antemano.
Como comprobar el resultado
- la regla tiene claros el nombre, el ambito, la condicion, las acciones y el propietario;
- el historial de ejecucion confirma que la regla hizo lo esperado;
- la comprobacion previa bloquea solo lo que debe y explica como corregir;
- la vista previa de la plantilla muestra el texto final sin errores de insercion ni espacios en blanco;
- el proceso de negocio ha pasado una ejecucion de prueba y sigue el camino esperado.
Escenarios relacionados
Mapa conceptual; no es una captura de UI ni prueba de datos del portal.