Dos personas abren el mismo contacto en el mismo CRM. Una ve la fecha de la última llamada, el owner del deal y el flag de renovación. La otra no ve ninguno, porque las columnas nunca se agregaron al layout que está mirando. No están discutiendo de estrategia. Están discutiendo qué dice el registro, y las dos tienen razón, porque leen dos superficies de visualización distintas sobre un mismo conjunto de datos.
Este es el modo de falla silencioso detrás de la mayoría de las conversaciones de «nuestros números no cuadran». Rara vez es un problema de reporting. Casi siempre es una cuestión de quién configuró qué layout, y de cuántos de esos layouts existen ahora.
Antes este desacuerdo costaba unos minutos de confusión en una call. Ahora se acumula. En cuanto los equipos de GTM apuntan agentes de IA al CRM para redactar follow-ups, calificar cuentas y actualizar registros, el sistema de registro se vuelve el sustrato del que todo lee. El argumento de Jason Lemkin en su artículo de 2026 sobre el CRM agéntico es que el CRM se está convirtiendo en el hub central desde el que varios agentes extraen el historial y devuelven señales. Si sus propios comerciales no se ponen de acuerdo en qué muestra un registro, los agentes que leen ese mismo registro heredan la confusión a velocidad de máquina.
Así que la disciplina que antes era un lujo ahora es portante. Una capa de visualización desordenada era llevadera mientras solo la leían personas. Deja de serlo cuando la lee software.
La señal es simple. Pídale a dos personas del mismo equipo que abran la misma cuenta y describan lo que ven. Si la respuesta es «bueno, en mi vista», ya lo encontró. Los datos de abajo son idénticos. Los layouts de arriba no.
Todo CRM moderno con vistas guardadas, sea HubSpot, Salesforce o Pipedrive, trata una vista como una configuración guardada de filtros, columnas ordenadas y propiedades visibles. Es una comodidad. El problema empieza cuando la comodidad se vuelve propiedad privada: cada comercial, cada manager y cada equipo crea sus propias vistas guardadas, y nadie elimina las viejas.
No es negligencia. Es el comportamiento por defecto de una herramienta flexible. Alguien necesita una columna para una campaña en marzo y la agrega a una vista personal. Un manager quiere los deals ordenados por fecha de cierre para una call de forecast y la guarda. Una persona nueva copia una vista existente y la ajusta. Ninguna de estas acciones está mal por sí sola. Seis meses después hay veinte vistas guardadas, la mitad propiedad de gente que cambió de equipo, y no hay dos que muestren los mismos campos.
El resultado es una capa de visualización que se aleja de cualquier definición compartida del registro. Cuando alguien comparte información con un colega, el colega no la encuentra, porque se agregó a una vista y no a la otra. Los datos estuvieron ahí todo el tiempo. Simplemente no eran visibles desde donde esa persona estaba parada.
Aquí está el reencuadre que corrige el razonamiento. Una vista guardada es una elección de visualización. No son los datos, y no son la verdad. Tratar los layouts como si cargaran significado es la forma en que los equipos terminan reconciliando dashboards en lugar de arreglar lo que está debajo.
Es la misma lección que Thomas Redman lleva años defendiendo sobre la calidad de los datos: en su trabajo para Harvard Business Review, el argumento es que la calidad se controla en el punto en que se crean los datos, y que limpiarlos aguas abajo es caro y no escala. La proliferación de vistas es un síntoma aguas abajo. Cada layout adicional es un lugar más donde la imagen puede diverger de la de todos los demás. Eso no se arregla construyendo un mejor dashboard encima. Se arregla reduciendo primero el número de superficies.
El instinto, cuando los números no cuadran, es construir un nuevo dashboard de «fuente única de verdad» en el que todos deberían confiar. Eso agrega una superficie. No elimina las que están en conflicto, así que ahora tiene una cosa más que mantener sincronizada.
Juegue la jugada opuesta. Aplique a sus vistas guardadas un repaso de conservar, ajustar, eliminar, igual que lo haría con un pipeline inflado o una lista de propiedades crecida de más. Conserve las pocas vistas compartidas que lee todo el equipo. Ajuste el layout por defecto del registro para que lleve los campos que la gente realmente necesita, de modo que nadie tenga que construir una vista privada para verlos. Elimine el resto. La meta no es la vista más potente. Son las vistas compartidas menos numerosas que aún hacen el trabajo, propiedad del equipo y no de los individuos.
No lo complique de más. La mayoría de los equipos de unos cientos de seats necesitan un puñado de vistas compartidas, no veinte vistas privadas.
Hace poco trabajamos con un equipo B2B SaaS de serie B en la región DACH que estaba consolidando en un único CRM. A mitad de camino, dos personas en una sesión de trabajo abrieron lo que cada una llamaba «la vista de contactos» y hablaron en paralelo, porque los campos no coincidían. Contamos las vistas guardadas en los objetos principales. Solo en contactos había más de una docena, varias propiedad de personas que habían cambiado de rol, y cada una mostraba una porción ligeramente distinta.
La solución no fue un proyecto de migración en sí. Hicimos que el layout de contacto por defecto llevara todo lo que tenía la vista personalizada del equipo de servicio, conseguimos el acuerdo para eliminar las redundantes, y fijamos la expectativa de que el equipo trabaje desde vistas compartidas en lugar de personales. El problema de reconciliación desapareció, porque ya no quedaba nada que reconciliar. Por fin todos miraban el mismo registro de la misma manera.
- Inventaríe cada vista guardada en sus objetos principales. Liste cada una con su owner y la última vez que se usó de verdad. No puede decidir qué recortar hasta que vea toda la proliferación en un solo lugar.
- Dé de baja las vistas huérfanas. Todo lo que sea propiedad de alguien que cambió de equipo o se fue es candidato a eliminación. Nadie las defiende, y son las victorias más fáciles.
- Defina las vistas compartidas que lee todo el equipo. Un conjunto pequeño, por objeto y por rol, no por individuo. La unidad de propiedad es el equipo, de modo que una persona nueva hereda desde el primer día la misma vista que todos los demás.
- Mueva los campos necesarios al layout por defecto del registro. La mayoría de las vistas privadas existen porque al layout por defecto le faltaba una columna. Ponga esas columnas en el layout por defecto y la razón para crear una vista personal desaparece.
- Elimine las redundantes, y controle las nuevas. Fije la norma de que las nuevas vistas compartidas pasen por la persona que gobierna el CRM, para no volver a proliferar de inmediato hasta el punto de partida.
- Apunte sus automatizaciones y agentes a las mismas vistas compartidas. Lo que lean sus workflows y sus agentes de IA debe ser la misma imagen que leen las personas, para que software y personas trabajen desde un solo registro, no desde dos.
No puede confiar en un forecast, una automatización o un agente que corre sobre datos que su propio equipo no puede ver de forma consistente. Estandarizar en vistas compartidas es poco vistoso, pero es la ganancia de confiabilidad más barata del CRM, y mover a un equipo a vistas compartidas suele ser medio día de trabajo, no un proyecto. Si quiere un segundo par de manos para la limpieza, eso es exactamente la clase de cosa para la que está pensado nuestro trabajo en Revenue Operations e implementación de HubSpot. Para el problema vecino de estandarizar esto antes de un go-live, lea el artículo complementario sobre el ensayo previo al go-live del CRM.
- Thomas Redman. «To Improve Data Quality, Start at the Source.» Harvard Business Review, febrero de 2020. hbr.org
- Jason Lemkin. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, 2026. saastr.com