Pipeline y relaciones
La etapa del negocio como eje principal, el registro de auditoría como sistema de constancia, y la línea de tiempo del contacto agregada sola a partir de cada interacción que el comprador haya tenido con esa persona. Por qué la pregunta de la fuente de la verdad le da forma a todo, por qué rechacé el estado del contacto como eje, y qué le permite hacer a un equipo esta forma de los datos que un CRM típico no.

La pregunta que gobierna el modelo de datos: qué significa realmente decir que un CRM es 'la fuente de la verdad'. Para la mayoría de los CRM de negocios pequeños, la respuesta es 'lo que haya tecleado la última persona que tocó el registro'. Eso no es la verdad; es la creencia más reciente de quien resultó ser el último en editar. Dos días después, cuando el equipo trata de recordar si el negocio pasó a propuesta porque el director financiero del prospecto lo aprobó o porque nadie actualizó el registro tras una llamada que se estancó, el modelo de la última creencia da la respuesta equivocada a la única pregunta que importa: qué pasó de verdad. Un CRM que no le puede decir qué pasó, solo qué se tecleó al final, es un espejo peor que inútil del olvido del propio equipo. Canopy trata la verdad como el registro de auditoría. Cada cambio significativo en un registro guarda una foto del antes y el después, atribuida al operador que lo hizo, con su marca de tiempo y la acción o regla que lo produjo. El estado actual de cualquier registro es la proyección de esos eventos, igual que se calcula el saldo actual de una cuenta a partir de la secuencia de movimientos bancarios. La implicación es que la base de datos puede responder preguntas que el equipo no sabía que iba a hacer cuando escribió el registro, porque los eventos siguen ahí para volver a reproducirlos. 'Cuándo entró este negocio a la etapa de propuesta' es una consulta contra el registro de auditoría, no una conjetura basada en el valor actual del campo. 'Quién fue el operador en los últimos tres cambios de estado de este contacto' también es una consulta. Las respuestas son consultables, atribuibles y exportables, y son las mismas dos semanas después que hoy. Consideré hacer del estado del contacto el eje principal del modelo de datos, con los negocios como campos derivados del contacto. Esa es la forma que usan casi todos los CRM para negocios pequeños, porque es el diseño relacional más simple: cada contacto tiene un campo de estado, el estado cambia con el tiempo y la vista del equipo tiene forma de contacto. Lo rechacé por una razón que cualquier negocio con clientes recurrentes va a reconocer. Un contacto cuyo primer negocio se cerró hace seis meses y cuyo segundo negocio está hoy en propuesta no se puede expresar con un solo campo de estado. El modelo con forma de contacto colapsa hacia el negocio más reciente y descarta en silencio la historia anterior. En un negocio de relaciones recurrentes, esa historia anterior es exactamente donde vive la siguiente venta, así que el modelo tiene que mantenerla visible en lugar de doblarla. Por eso los negocios son primarios, y el estado del contacto es un espejo desnormalizado de la etapa de su negocio principal actual, conservado por compatibilidad con la forma antigua, pero no la fuente de la verdad. El mecanismo del modelo con negocios primarios es simple en su forma: los negocios son entidades de primera clase con sus propias transiciones de etapa, sus propios porcentajes de probabilidad, sus propios valores y sus propios tiempos. Un contacto tiene muchos negocios a lo largo del tiempo. El tablero kanban del pipeline lee negocios, no contactos; las columnas son etapas de negocio, las tarjetas son negocios individuales, y un contacto con tres negocios abiertos aparece como tres tarjetas en tres columnas. El acumulado de probabilidad es por etapa y con peso por negocio, que es la unidad correcta para pronosticar, porque dos negocios de veinticinco mil dólares cada uno en propuesta al setenta y cinco por ciento de probabilidad le dicen al comprador algo que el modelo con estado de contacto no puede decirle. La vista de detalle del contacto se arma sola. Todo lo que el equipo del comprador haya hecho alguna vez con una persona llega a una sola línea de tiempo sin que nadie tenga que copiarlo ahí. Los envíos de formulario llegan como registros; las respuestas de correo se traen de la cuenta del comprador por una integración autenticada; los reportes de escaneo se adjuntan cuando se escanea el dominio del contacto; las llamadas registradas desde el modal de llamadas llegan como eventos; las notas agregadas desde la interfaz escriben en la misma línea de tiempo; las transiciones de etapa de cualquier negocio de ese contacto también aparecen ahí. Nada tiene que copiarse a mano entre sistemas porque no hay otros sistemas. La línea de tiempo tiene forma de eventos, ordenada por tiempo, y cada evento conserva su procedencia, así que el comprador puede preguntar 'cómo me llegó este correo' y recibir una respuesta real en lugar de 'lo sincronizamos de algún lado'. Las acciones en lote cubren los casos donde editar registro por registro no corresponde a la intención del operador. Mover diez negocios de contactado a calificado de una vez. Etiquetar cincuenta contactos como una cohorte de prospección del tercer trimestre. Reasignar una lista de contactos a otro operador. Cada acción en lote escribe una sola entrada en el registro de auditoría con los identificadores afectados y el cambio aplicado, así que una pregunta como 'quién etiquetó a estos cincuenta contactos y cuándo' tiene una respuesta definitiva. Las acciones en lote son deliberadas, rastreables y reversibles por diseño. La navegación por teclado funciona como espera quien vive en la herramienta todos los días. El kanban tiene atajos para mover negocios entre etapas, moverse entre tarjetas, abrir el detalle de un negocio y aplicar selecciones en lote. La lista de contactos tiene una paleta de comandos con búsqueda difusa sobre cada contacto y cada negocio de la base de datos. La expectativa es que un operador pueda vivir dentro de Canopy sin tocar el ratón durante una hora seguida, igual que vive dentro de su cliente de correo y de su editor de texto. La mayoría de los CRM no paga esta disciplina porque su mercado principal son directivos revisando tableros, no operadores ejecutando el trabajo del día. El mercado principal de Canopy es el operador. El pronóstico del pipeline se acumula en varios niveles. Pronóstico ponderado por etapa sobre todo el pipeline; pronóstico por operador para un equipo de ventas; pronóstico por ventana de tiempo para análisis de cohortes. Los pesos se configuran por instalación, porque las probabilidades por etapa son distintas en cada negocio. Un servicio productizado con un ciclo de descubrimiento largo tendrá probabilidades de propuesta que no se parecen en nada a las de un producto de comercio electrónico que se mueve rápido, y los pesos deben reflejar las tasas de cierre reales del comprador y no los valores por defecto de un proveedor. El registro de auditoría es además donde vive la protección contra el arrepentimiento. Si un operador marca un negocio como cerrado perdido y una semana después se da cuenta de que el prospecto volvió y firmó, el registro guarda el estado anterior y el negocio se puede restaurar a su posición previa, con la entrada de auditoría dejando constancia de la restauración. La restauración es en sí misma un evento del registro, así que la pregunta 'qué pasó realmente con este negocio' produce una historia completa en lugar de un estado actual que se puede fingir limpio. Ese es el valor práctico del abastecimiento por eventos: no solo la atribución de los cambios, también su reversibilidad y una crónica completa que el comprador puede auditar. El encuadre honesto sobre lo que esto no es: la superficie de pipeline de Canopy está hecha para negocios pequeños con menos de quinientos negocios activos a la vez, donde los operadores tienen el tiempo y la disciplina de actualizar registros. No es una plataforma de interacción comercial con marcador automático y sugerencias de seguimiento generadas por modelos; eso es otro producto para otra escala. El comprador que necesita esa escala ya pasó del tamaño donde Canopy es la opción correcta, y está bien; las exclusiones honestas de la arquitectura son parte del diseño, no una disculpa. La consecuencia operativa que el comprador siente es la portabilidad. Se va un miembro del equipo, la base de datos se queda. Entra un operador nuevo, y el registro de auditoría ya explica qué hizo el equipo anterior y por qué. Las preguntas son consultables y las respuestas verificables. La exportación, si algún día ocurre, es la base de datos del comprador tal cual, en su forma nativa, sobre infraestructura que el comprador paga directamente. El equipo se puede ir cuando quiera y llevarse el pipeline completo, porque el pipeline siempre fue suyo.