Los vendedores no actualizan el CRM cuando el formulario del trato pide más de lo que ellos, o tú, van a leer alguna vez. La salida no es otro recordatorio: elige los cinco o seis campos que de verdad miras cuando revisas el embudo (etapa, propietario, valor, fecha de cierre prevista, siguiente actividad).
Después haz obligatorios solo los que importan y solo en la etapa donde importan, deja que el último contacto y el siguiente paso salgan de las actividades en lugar de teclearse, oculta o borra el resto, y revisa el resultado una vez por semana con un solo filtro de lista.
El problema está en el formulario, no en el vendedor
Imagina un formulario de trato con 17 campos. Nadie necesita 17 datos para decidir nada un lunes por la mañana. En la práctica doce de esos campos se copian del trato anterior, se adivinan o se dejan vacíos, y los vacíos después parecen descuido. Entonces llega el mensaje en el grupo: “por favor actualicen el CRM”.
Funciona. Durante una semana. Clint, un proveedor de CRM, lo dice casi con esas palabras en un artículo en portugués de junio de 2026: la insistencia resuelve el problema por una semana. Y propone como tope de seis a ocho campos obligatorios en un embudo para equipos que venden por WhatsApp. Es la opinión de un proveedor, sin datos detrás, pero el punto se sostiene: el recordatorio trata el síntoma. La causa sigue en el formulario.
Rework, en una página en alemán sobre campos obligatorios y campos útiles (sin fecha; una guía práctica de un proveedor, no un estudio), lo resume en una frase: demasiados campos obligatorios producen completitud fingida, no mejores datos. Un trato con los 17 campos llenos no es un trato bien documentado. Es un trato donde alguien tecleó 17 cosas.
Creemos que la secuencia correcta es la inversa a la habitual. Primero decide qué lees. Después decide qué pides. Y solo al final decide qué recuerdas al equipo, que a esas alturas suele ser casi nada.
Una pregunta por campo: ¿qué decisión falla si queda vacío?
La revisión no empieza en Pipedrive, empieza en una hoja. Lista todos los campos del trato, los estándar y los personalizados, y hazle a cada uno la misma pregunta que propone Rework: ¿qué decisión falla si este campo queda vacío?
Si la respuesta es “ninguna”, el campo no alimenta ningún filtro, ningún reporte ni la mirada del lunes. Se va. Si la respuesta es “el pronóstico del mes”, se queda. Si la respuesta es “saber cuándo fue el último contacto”, hay una tercera opción que casi nadie usa: ese dato ya existe en otra parte del CRM.
Tres veredictos, escritos junto a cada campo:
- Conservar: lo lees cada semana o lo usa un reporte que sí abres.
- Derivar: sale de las actividades que el equipo ya registra; el campo manual sobra.
- Quitar u ocultar: nadie lo lee. Si no estás seguro, pregúntale al dueño del reporte donde creías que aparecía.
Antes de borrar un campo personalizado, mira su estadística. Un usuario administrador puede abrir el campo y ver cuándo se creó, cuándo se actualizó por última vez y en qué filtros se usa (Pipedrive, centro de ayuda, campos personalizados, 3 de septiembre de 2026; citamos las etiquetas de la ayuda en inglés, y ahí la opción se llama “View field stats”). Es la forma más rapida de descubrir que el campo “Origen secundario” lo llenaron en marzo y nunca más.
Un ejemplo de campo que sí se llena: el motivo de pérdida. Es una lista corta, se elige con un clic y alguien lo lee (cinco motivos de pérdida que sí sirven en Pipedrive). Un vendedor no se resiste a un campo de cinco opciones. Se resiste a un campo de texto libre que nadie contesta.
Los cinco campos que lees el lunes
Nuestra lista para un equipo pequeño en Pipedrive: etapa, propietario, valor, fecha de cierre prevista y fecha de la siguiente actividad. Con eso respondes lo que una revisión semanal pregunta: dónde está el trato, de quién es, cuánto pesa, cuándo debería cerrarse y si alguien tiene algo agendado para moverlo.
No somos los únicos que llegan a una lista parecida. Wati, un proveedor de CRM sobre WhatsApp, publicó el 26 de agosto de 2026 una guía en portugués que recomienda pocos campos obligatorios y arranca con cinco: etapa, responsable, necesidad, siguiente paso y fecha de retorno. Es la lista de un proveedor, no una norma, y no pide ni valor ni fecha de cierre. Cinco o seis es nuestra recomendación, no un estándar; lo que no sobrevive a la pregunta de la sección anterior es el campo número doce.
Este es el ejemplo completo para el resto del artículo. Es ilustrativo: no es un cliente, no es una medición ni un punto de referencia.
Equipo de 6 vendedores en Pipedrive, 48 tratos abiertos, formulario de trato con 17 campos. Después de la revisión: 5 campos se conservan (etapa, propietario, valor, fecha de cierre prevista, fecha de la siguiente actividad); 3 se derivan (los campos manuales “Último contacto”, “Fecha del siguiente paso” y “Nota de última actualización” se reemplazan por la fecha de la última actividad, la fecha de la siguiente actividad y la hora de actualización que Pipedrive muestra por sí mismo); 9 se quitan u ocultan. 5 + 3 + 9 = 17. Y ojo: esos 17 campos son de nuestro ejemplo, no el formulario predeterminado de Pipedrive.
Lo que Pipedrive hace por ti y lo que no
La parte de “derivar” depende de tres campos que Pipedrive mantiene a partir de las actividades. Según el centro de ayuda (actividades, 23 de septiembre de 2026), la fecha de la siguiente actividad es la de la próxima actividad agendada que todavía no se marcó como hecha; la fecha de la última actividad, la de la última que sí se marcó como hecha; y la hora de actualización es la última modificación del elemento, sea una actividad nueva, un campo editado o un cambio de etapa.
Fíjate en el detalle: “marcada como hecha”. El CRM no adivina las llamadas. Si el vendedor agenda una actividad y la cierra cuando la hace, el último contacto queda registrado sin un campo aparte. El hábito que pides es uno solo y reemplaza tres campos manuales.
Los campos obligatorios, en cambio, son menos de lo que parecen. Se configuran por embudo y por etapa, los administra un usuario con permiso de configuración de cuenta, y cuando alguien mueve un trato a una etapa sin el dato requerido, Pipedrive le pide completarlo. Pero la misma página aclara que la función no detiene el avance del trato si los campos se actualizan por importación, edición masiva, API, automatizaciones o integraciones de terceros, y que solo está disponible en el plan Professional o superiores (campos obligatorios, 3 de septiembre de 2026). Un campo obligatorio es un aviso, no un candado. El control real es la revisión semanal.
Dos avisos más, porque tienen consecuencias:
- Borrar un campo personalizado borra el campo y todos sus datos de la cuenta (campos personalizados). Los campos personalizados específicos por embudo, donde eliges dónde se ve o se oculta un campo, son función del plan Premium.
- La vista de detalle del trato se ordena desde el menú “…” con “Manage sidebar sections”, pero esos ajustes aplican solo a tu usuario y no afectan a los demás (vista de detalle, 3 de septiembre de 2026). Sirve para limpiar tu pantalla; no es una regla de equipo.
Campos obligatorios solo en la etapa que los necesita
El error más común después de de recortar campos es hacer obligatorios los que quedan desde la creación del trato. Rework lo plantea como principio: los campos obligatorios deben depender de la etapa. Estamos de acuerdo, y la razón es simple: no pidas lo que el vendedor todavía no puede saber.
En el primer contacto nadie conoce el valor del trato ni la fecha de cierre. Si los haces obligatorios ahí, obtendrás un número inventado y una fecha a fin de mes, y un valor inventado es peor que un campo vacío, porque entra al pronóstico con la misma cara que uno real. El campo vacío al menos dice la verdad.
En el ejemplo, la configuración final queda así: valor y fecha de cierre prevista obligatorios a partir de la etapa “Propuesta enviada”. Dos campos, en una etapa, y nada obligatorio al crear el trato. Es la versión en Pipedrive de los criterios de salida de etapa, que tratamos aparte en qué debe ser cierto para salir de una etapa del embudo; aquí solo importa que el campo se pida en el momento en que una decisión lo va a usar.
La revisión semanal: diez minutos y dos condiciones
Con menos campos, el chequeo semanal se vuelve corto. Una vista de lista de tratos abiertos con dos condiciones: fecha de cierre prevista ya pasada, y sin siguiente actividad agendada. Los filtros rápidos de Pipedrive viven en la vista de lista de tratos, se arman con “Add condition”, admiten hasta diez condiciones y los operadores cambian según el tipo de campo (filtros rápidos, 3 de septiembre de 2026). La ayuda no lista los operadores para fechas vacías o pasadas: arma las dos condiciones por su significado con el operador que el filtro te ofrezca.
Lo que aparece en esa lista es la conversación de la semana, y cabe dentro de tu revisión semanal del embudo. Lo que no aparece, no se discute.
De vuelta a los 48 tratos. Primera revisión: 11 tienen la fecha de cierre prevista en el pasado; 9 no tienen siguiente actividad; 4 están en las dos listas. Es decir, 7 + 4 + 5 = 16 tratos de los que hablar, y 32 que esta semana no entran en la agenda.
Uno de los 16 lo muestra bien. Adecuación de oficinas, 3 pisos, etapa “Propuesta enviada”, valor US$12,000, fecha de cierre prevista ya vencida, última actividad marcada como hecha hace 23 días, sin siguiente actividad. En el formulario viejo este trato se veía completo: los 17 campos llenos, y en “Último contacto” el vendedor había escrito “ayer” el día de una llamada de hace 23 días. En la vista nueva aparece como hueco, porque ni la fecha de la última actividad ni la siguiente actividad vacía las teclea nadie.
El campo vacío, en esta revisión, es una pregunta al vendedor, no un regaño. “¿Qué pasó con el de las oficinas? ¿Tienes algo agendado?” es una conversación de dos minutos que antes no ocurría porque el formulario decía que todo estaba bien. La versión detallada del filtro para tratos sin siguiente paso está en tratos estancados en Pipedrive: el filtro semanal de diez minutos; aquí la fecha de la siguiente actividad es solo una de las dos condiciones.
Dónde se rompe la regla
Hay cuatro casos en los que recortar sin mirar sale caro.
El primero: un campo que alguien fuera de ventas usa de verdad. Finanzas, onboarding, el área legal. Si el campo alimenta una factura o un contrato, su dueño no eres tú, y la respuesta a “qué decisión falla” hay que pedírsela a esa persona antes de tocar nada.
El segundo: el “último contacto” tecleado a mano a veces es el único registro de llamadas hechas fuera del CRM. Si tu equipo llama desde el celular y no agenda actividades, quitar el campo manual te deja sin dato. En ese caso el orden es otro: primero el hábito de marcar actividades como hechas, despues el recorte.
El tercero: los equipos muy pequeños. Dos vendedores y un fundador que vende pueden sostener un sexto o séptimo campo sin que nadie lo falsee, porque todos lo leen.
El cuarto es el más incómodo: la revisión de campos no arregla un embudo que nadie revisa. Si la vista de las dos condiciones se abre una vez y se olvida, el formulario volverá a crecer. SalesBond hace control de calidad continuo: revisa cada trato de tu CRM contra sus reglas y muestra qué falta. La decisión de qué campos existen y qué se le pregunta a cada vendedor sigue siendo tuya.
Tu primer paso es la hoja con los 17 campos y una pregunta por campo. Si después quieres esa segunda mirada sobre cada trato, empieza con SalesBond.
