Relaciones profesionales y CRM: cuándo no automatizar el seguimiento en Salesforce

Una buena conversación puede terminar sin una venta. El CRM debería permitirlo. En Salesforce, una forma de expresar ese criterio es separar el registro de un contacto de una solicitud de seguimiento comercial. Se puede diseñar una automatización que cree una tarea únicamente cuando exista esa solicitud. Es una propuesta de configuración, no el comportamiento obligatorio de la plataforma.

El punto de partida está en una frase de JuanMa: “A los 25 quería demostrar que sabía. A los 52 prefiero rodearme de gente que sabe más que yo.” Después de más de 30 años trabajando en tecnología, su publicación habla de escuchar sin buscar una oportunidad detrás de cada conversación.

Hay una línea que incomoda cuando uno trabaja diseñando procesos: “pero las relaciones humanas no funcionan como un CRM.” La observación merece algo mejor que una defensa del software. Si cada alta termina en una tarea para vender, esa decisión la tomó alguien. También se puede decidir otra cosa.

Registrar a alguien no obliga a iniciar una venta

Un registro tiene un propósito operativo. Una relación no tiene por qué compartirlo. Guardar datos profesionales puede ayudar a retomar una conversación que la otra persona quiere continuar. Eso no convierte cualquier encuentro en una oportunidad ni justifica cargar información sin una finalidad definida.

Salesforce presenta el Lead como un posible prospecto comercial en su material de Trailhead sobre leads. Esa definición sirve para revisar qué se está registrando y por qué. No establece que toda persona conocida deba ser un Lead. Tampoco significa que un Contact no pueda participar de una conversación comercial.

La distinción entre objetos no resuelve por sí sola el problema. Un equipo puede usar Contact y aun así crear seguimientos que nadie pidió. Lo que hay que discutir es el evento que habilita una acción. Conocer a alguien y recibir un pedido de propuesta son hechos diferentes. Conviene conservar esa diferencia en el proceso.

Mi postura es dejar de usar el alta del contacto como sustituto de una señal de interés. Si la persona pidió que le envíen una propuesta, hay un motivo para avanzar. Si solo hubo una charla, no corresponde inventar ese motivo dentro del sistema.

Un ejemplo hipotético con Salesforce Flow

Este ejemplo es didáctico. No describe una implementación de JuanMa ni un resultado obtenido por EGA Futura. Supone un campo personalizado en Contact llamado Solicita_seguimiento_comercial__c, de tipo checkbox y con valor inicial falso. El nombre expresa un pedido comercial concreto; no una valoración general sobre la relación.

Cuando una persona solicita continuar con una propuesta, quien administra el contacto registra esa solicitud siguiendo el criterio acordado por el equipo. El campo pasa a verdadero. Un Flow disparado por registros, ejecutado después de guardar, puede crear una Task asociada al contacto cuando se cumple esa condición.

La elección de after-save responde a que el ejemplo crea otro registro: una tarea. El material de Salesforce sobre gestión de registros en Flow explica las operaciones con registros. La guía de arquitectura de automatización disparada por registros permite profundizar en las decisiones de entrada y ejecución.

Para la variante que atiende tanto altas como cambios, se configura el disparador sobre creación o actualización de Contact. La condición de entrada exige que el checkbox sea verdadero. En las actualizaciones se elige ejecutar únicamente cuando el registro pasa a cumplir las condiciones. No alcanza con filtrar por verdadero y ejecutar en todas las modificaciones.

Con esa configuración, modificar otro dato de un contacto que ya tenía el checkbox marcado no debería generar otra tarea por este mismo Flow. Hay un límite: desmarcar el campo y marcarlo de nuevo constituye otra transición. Si eso debe o no producir un nuevo seguimiento requiere una decisión adicional, no una suposición.

La tarea necesita una referencia al Contact mediante WhoId. También hay que decidir quién la recibe y qué estado corresponde según la configuración de la organización. Esas decisiones no se pueden copiar a ciegas entre entornos. El ejemplo no envía correos ni inicia una secuencia de marketing.

El caso sin solicitud tiene igual importancia. Se crea un contacto con el checkbox falso. El Flow no encuentra la condición para crear la tarea. La ausencia de una acción comercial es el resultado previsto, no un fallo que haya que corregir agregando otra automatización.

La parte difícil está antes del campo

Un checkbox puede existir y representar mal lo que ocurrió. Por eso el equipo necesita acordar qué cuenta como solicitud. Pedir una propuesta es un ejemplo claro. La interpretación de una conversación agradable no lo es. Si cada persona marca el campo según su entusiasmo, la automatización solo vuelve más rápida esa interpretación.

También hace falta definir cómo queda documentado el pedido. La información debería ser suficiente para entender qué se solicitó, sin guardar detalles personales ajenos al propósito comercial. El campo propuesto no equivale a consentimiento legal para marketing. Un permiso para continuar una conversación no debe expandirse automáticamente a otros usos.

Antes de activar algo así, conviene revisar las automatizaciones que ya existen. Puede haber otra ruta creando tareas al guardar Contact. Que este Flow esté bien delimitado no impide que otro proceso actúe sobre el mismo registro. El comportamiento final depende del conjunto, no del diagrama que se acaba de editar.

La prueba debe hacerse en sandbox. Primero, un contacto sin solicitud: no aparece una tarea de este flujo. Luego, una transición a verdadero: se crea la tarea esperada. Después, una modificación sin cambiar el checkbox: no se crea una repetición. Cada resultado debe comprobarse, no darse por hecho porque la condición parece correcta.

Queda pendiente el caso de solicitudes repetidas. Para algunos equipos, un nuevo pedido merece una tarea nueva. Otros necesitan evitar cualquier duplicado mientras haya una tarea abierta. Ese requisito puede pedir otro modelo de datos o una comprobación adicional. Un checkbox conserva un estado; no lleva por sí solo el historial de solicitudes.

Esta propuesta tampoco permite afirmar que habrá más ventas o menos trabajo. No hay una medición detrás de ese argumento. Lo que ofrece es una regla explícita para decidir cuándo actuar y una manera de comprobar si el sistema la respeta.

Preguntas frecuentes

Toda persona que conozco debería ser un lead?

No. El propósito del registro y el proceso comercial deben justificar esa clasificación. Una conversación sin intención comercial no obliga a abrir una oportunidad. La definición de Lead ayuda a ordenar el criterio, pero no reemplaza la evaluación del caso ni las obligaciones sobre tratamiento de datos.

Cómo evitar tareas automáticas cuando no hay interés explícito?

Una opción es exigir una solicitud registrada como condición de entrada. En el ejemplo hipotético, el checkbox personalizado en Contact permanece falso hasta que existe ese pedido. También hay que revisar otras automatizaciones para evitar que creen el seguimiento por una vía distinta.

El checkbox viene incluido en Salesforce?

No. Solicita_seguimiento_comercial__c es un campo personalizado propuesto para este ejemplo. Hay que crearlo y definir su uso. Tampoco existe aquí una afirmación de que Salesforce evalúe el sentido de la conversación: una persona registra el pedido y el Flow responde al dato.

Este diseño ya está probado en una organización?

No se presenta como un tutorial ejecutado ni como un caso de cliente. Es un diseño para revisar y probar en sandbox. La asignación de tareas, los permisos y la prevención de duplicados necesitan validación en el entorno donde se quiera usar.

En el texto original, JuanMa escribe: “Simplemente escuchás.” Más adelante agrega: “a veces alcanza con haber pasado un buen rato.” El software no tiene que ponerle una próxima acción a esa frase.

Si estás revisando cómo usar Salesforce en tu organización, conoce EGA Futura y lleva esta decisión a la conversación: qué hecho concreto debe autorizar una tarea comercial. Empieza por revisar la automatización que hoy se ejecuta al crear un contacto.