La automatización de ventas en Bitrix24 (Alaio) se compone de escenarios cortos: un disparador en un evento o una etapa, uno o dos robots, un resultado medible. Los grandes «procesos llave en mano» se rompen al primer cambio del embudo; las combinaciones cortas viven durante años. A continuación, ocho escenarios reales a lo largo de las etapas de la negociación: recepción de la solicitud, primer contacto, factura y contrato, pago y ventas repetidas. Cada uno se monta en el diseñador de procesos a partir de las acciones nativas y los robots de Roboteka, sin programar.
¿Cómo automatizar la recepción de la solicitud?
Escenario 1, normalización del teléfono. Disparador: se crea un prospecto desde un formulario web. El robot «Formatear teléfono: prefijo propio» lleva el número a un formato único: elimina espacios, paréntesis y guiones y antepone el prefijo de país que hayas indicado —+34, +1, +44 o el que uses—, sin duplicarlo si el número ya empieza por esos dígitos; además devuelve un indicador de reconocimiento (Y/N). Resultado: la búsqueda de duplicados y la telefonía trabajan con una única forma de escribir el número, y el teléfono no reconocido le llega al gestor como una tarea.
Escenario 2, vinculación con un cliente existente. Disparador: se crea un prospecto o una negociación. El robot «Buscar contacto por teléfono/email» busca un contacto por el número normalizado o el correo y devuelve el ID, el nombre y el indicador «Encontrado» (Y/N). Resultado: si es Y, el registro se vincula a la ficha del cliente; el historial de interacciones no se interrumpe y no se crea un contacto duplicado.
¿Cómo automatizar el primer contacto?
Escenario 3, plazo para la primera llamada sin fines de semana. Disparador: el prospecto se toma en trabajo. Ten presente que los plazos nativos se cuentan en días naturales: «dentro de un día» puede caer perfectamente en sábado. El robot «Fecha más cercana según condición» resuelve el caso con la condición next-weekday: toma la fecha de origen y devuelve el día laborable más próximo —el sábado y el domingo se saltan— en los formatos AAAA-MM-DD y DD.MM.AAAA, más los días que faltan hasta él. Un robot nativo crea una tarea con ese plazo. Resultado: la primera llamada no se programa para un fin de semana, y los plazos de las tareas son cumplibles.
Escenario 4, número para SMS. Disparador: se envía al prospecto la confirmación de la solicitud. El robot «Formatear teléfono: prefijo propio» devuelve la variante «solo dígitos», sin el signo más, paréntesis ni espacios. Resultado: la pasarela de SMS y las integraciones de mensajería reciben el número en la forma que aceptan sin errores.
¿Qué automatizar en la factura y el contrato?
Escenario 5, tipo de cambio en la factura. Disparador: la negociación pasa a la etapa «Factura». Bitrix24 no trae tipos de cambio de fuentes externas, así que se combinan dos robots: «Solicitud HTTP GET/POST» consulta cualquier API pública de divisas y «Extraer valor de JSON por ruta» saca del cuerpo de la respuesta el valor que necesitas indicando su ruta, por ejemplo rates.USD. Resultado: el importe de la negociación en la moneda de la contabilidad se calcula según un tipo tomado de una fuente verificable, y no según una cifra de la cabeza del gestor.
Escenario 6, tipo de cambio en la fecha del contrato. Disparador: en la negociación está rellenada la fecha del contrato. Sirve la misma pareja de robots: casi todas las API de divisas admiten la fecha dentro de la propia dirección de la consulta, así que basta con montar la URL con el valor del campo y volver a extraer el tipo del JSON de la respuesta. Resultado: el tipo de cambio en la fecha de la firma queda fijado en el campo de la negociación; ante una disputa sobre el importe hay una base documental.
¿Cómo controlar el pago y las ventas repetidas?
Escenario 7, plazo de pago. Disparador: etapa «Contrato firmado». Los plazos se cuentan aquí en días naturales, así que la vía sencilla es una regla de automatización con retardo —el retardo se indica en horas o días— o la acción de pausa del proceso de negocio. Si el contrato exige que el control caiga en día laborable, «Fecha más cercana según condición» desplaza la fecha obtenida al siguiente día hábil. La tarea «comprobar el pago» se programa para esa fecha y, si es necesario, el plazo se escribe en el campo de la negociación. Resultado: el control del pago no cae en un fin de semana ni se dispara antes de tiempo.
Escenario 8, interacción repetida. Disparador: una nueva solicitud desde el sitio. El robot «Buscar contacto por teléfono/email» encuentra la ficha del cliente antiguo por el número. Resultado: la negociación se crea sobre el contacto existente; el gestor ve el historial de compras y habla con el cliente como con un conocido, no como con un prospecto nuevo.
¿Cómo montar un escenario en el diseñador?
El orden es siempre el mismo. Abra la configuración de robots del embudo deseado, elija la etapa-disparador y añada un robot de la lista; tras instalar Roboteka, sus robots aparecen junto a los nativos. Los resultados del robot (ID, indicadores Y/N, fechas, valores extraídos de respuestas externas) están disponibles para los siguientes pasos de la plantilla: construya condiciones con ellos y escriba los valores en los campos de la negociación mediante el cambio de documento nativo. Pruebe la combinación en una sola negociación de prueba antes de activarla en producción. El análisis paso a paso de la configuración está en la guía sobre robots de Bitrix24, y la distribución de escenarios por etapas, en el artículo sobre embudos.
Conclusión
Ocho escenarios cubren el recorrido de la negociación desde la solicitud hasta la venta repetida: número limpio a la entrada, vinculación con el cliente existente, plazos que no caen en fin de semana, tipo de cambio tomado de una fuente externa y control del pago. Empiece con los dos escenarios de recepción de la solicitud: dan efecto desde el primer día. El conjunto completo de robots está en el catálogo de robots de CRM. Si falta el robot que necesita, describa la tarea: lo haremos gratis y lo añadiremos a la biblioteca común.