CRM multi-pipeline para equipos de ventas en empresas medianas

Los equipos de ventas del mercado medio operan en tres o cuatro pipelines a la vez — renovaciones enterprise, jugadas de expansión, prospección de cuentas nuevas y crecimiento regional — pero la mayoría de los CRMs comprimen esa complejidad en una sola lista plana. El resultado es una herramienta que técnicamente contiene los datos pero oscurece la narrativa: qué deals avanzan, qué cuentas se enfrían y dónde se encuentra realmente el trimestre.

Las revisiones de pronóstico se convierten en rituales de planilla. Los managers reconstruyen snapshots de pipeline manualmente porque el sistema no puede ponderar probabilidad por etapa ni por segmento. Los reps alternan entre pestañas y filtros para reconstruir un contexto que debería aparecer automáticamente. El costo se acumula: cuando un deal en riesgo se hace visible, la ventana para recuperarlo ya se cerró.

El brief pedía un CRM que tratara la ejecución multi-pipeline como eje del producto — no un filtro sobre una tabla genérica, sino el principio organizador de cada vista, métrica y flujo.

La fase de descubrimiento se centró en tres grupos de usuarios: account executives gestionando libros multi-segmento, sales managers preparando pronósticos semanales y líderes de operaciones uniendo datos de pipeline desde fuentes desconectadas. Las entrevistas estructuradas revelaron un patrón consistente: el CRM se trataba como una obligación de reporte, no como una herramienta de trabajo.

Los reps mantenían sistemas paralelos de tracking en planillas porque el CRM existente no podía representar etapas específicas por pipeline con ponderaciones de probabilidad distintas. Los managers describían las revisiones de forecast como ejercicios adversariales de reconciliación de datos. Nadie confiaba en los números en pantalla porque reflejaban cumplimiento de carga, no realidad de deals.

Un análisis competitivo de varios CRMs establecidos confirmó la brecha estructural. La mayoría ofrecía vistas de pipeline como filtro sobre una lista unificada de deals, no como capa organizacional discreta. El insight que reenmarcó el proyecto: la identidad de pipeline necesitaba propagarse por cada superficie — pronósticos, feeds de actividad, alertas de riesgo — no quedarse como etiqueta en un registro de deal.

El mercado de CRM se divide en dos niveles que desatienden al mercado medio. Las plataformas enterprise ofrecen configurabilidad profunda pero exigen administradores dedicados e implementaciones de meses. Las herramientas livianas optimizan velocidad y simplicidad pero colapsan cuando un equipo gestiona cuatro pipelines con etapas, ponderaciones y modelos de ownership regional distintos.

Entre estos polos persiste una brecha estructural. Los productos que detectan riesgo en deals lo hacen a través de reportes estáticos generados después del hecho, no mediante vistas integradas al flujo de trabajo diario. Los módulos de forecasting existen como complementos montados sobre bases de contactos — heredan el modelo de datos plano y no pueden ponderar probabilidad a nivel de pipeline sin configuración extensiva.

El posicionamiento de Relio ocupó el espacio entre estos extremos: un workspace de revenue construido con propósito donde la estructura multi-pipeline, el forecasting ponderado y la detección proactiva de riesgos son nativos del producto, no capas añadidas mediante administración. La diferenciación era arquitectónica, no cosmética — debía vivir en el modelo de datos, no en el tema visual.

Tres principios de diseño gobernaron cada decisión posterior:

• La identidad de pipeline es soberana. Cada pantalla hereda el contexto del pipeline activo, y cambiar de pipeline reencuadra el workspace completo en lugar de alternar un dropdown sobre una tabla estática.
• El sistema detecta riesgo antes de que se solicite. Deals que se enfrían, fechas de cierre vencidas y cuentas inactivas aparecen en vistas dedicadas y badges contextuales, no en reportes que requieren generación manual.
• La densidad sirve al operador. Los equipos de ventas escanean datasets extensos bajo presión de tiempo — durante llamadas de forecast, revisiones de pipeline y stand-ups de los lunes. La interfaz adoptó una estética densa y funcional que priorizó tablas escaneables y tarjetas métricas compactas.

Estos principios crearon un contrato de comportamiento consistente: en cualquier vista, el usuario encuentra la misma jerarquía de información — contexto de pipeline arriba, métricas accionables en el medio, registros granulares abajo.

El modelo de navegación organiza el producto en dos ejes: tipo de objeto y contexto organizacional. La barra lateral agrupa siete destinos — Companies, Deals, Forecast, Activities, Contacts, Email sequences y Slipping deals — que corresponden a los objetos centrales de un equipo de ventas. Debajo, accesos directos para equipos, reportes y pipelines nombrados permiten saltar a un contexto filtrado sin aplicar filtros manualmente.

Esta estructura de doble eje significa que un sales manager revisando el pipeline EMEA Enterprise ve companies, deals y forecasts prefiltrados a ese contexto, mientras un SDR trabajando la lista de contactos opera dentro del mismo shell pero con alcance de su equipo. La arquitectura premia la memoria muscular — las ubicaciones son estables y el costo cognitivo de cambiar de contexto permanece bajo sin importar el rol.

En móvil, la arquitectura se comprime con elegancia. Una barra inferior expone las cinco vistas más usadas mientras los destinos secundarios permanecen accesibles desde la barra lateral colapsada. La grilla de métricas se adapta de cuatro columnas a un layout de dos por dos, preservando las relaciones comparativas entre cifras sin forzar scroll horizontal.

El tablero de deals es el centro gravitacional del producto. Un layout Kanban con cinco etapas — Prospecting, Qualified, Proposal, Negotiation y Closed won — muestra tarjetas anotadas con fecha de cierre, monto, owner y tags de segmento. Cada encabezado de columna muestra el total de la etapa, dando a los managers una lectura instantánea de la distribución de pipeline. Un badge contextual marca deals que se acercan a su fecha de cierre, inyectando urgencia en una vista diseñada para el escaneo diario.

El forecasting opera como complemento del tablero, no como un módulo separado. Una franja de métricas muestra cuatro cifras — pipeline total, pipeline ponderado, closed-won del año y tamaño promedio de deal — cada una con un indicador de tendencia trimestral. Debajo, una tabla ordenable vincula cada deal abierto con su revenue ponderado por probabilidad, convirtiendo las revisiones de forecast en una lectura de pantalla en lugar de una reconstrucción de planilla.

La vista de slipping deals completa la tríada operacional. Aísla oportunidades en riesgo usando umbrales de inactividad y fechas de cierre vencidas, graduando severidad con badges que escalan de neutro a crítico a medida que la inactividad crece.

El brief original describía un CRM capaz de manejar múltiples pipelines con mejor visibilidad que una planilla. El producto entregado superó ese alcance en tres dimensiones concretas:

• Revenue ponderado por probabilidad como columna nativa. La vista de forecast introdujo esta capacidad — mencionada en el brief como consideración futura, no como requisito de lanzamiento. Incluirla desde el día uno transformó el forecast de un volcado de datos en una superficie de decisión.
• Vista dedicada de slipping deals. Durante el descubrimiento, el patrón de deals que se enfrían sin intervención oportuna apareció repetidamente. En lugar de tratarlo como un feature de reportes, el equipo de diseño lo elevó a destino propio en la barra lateral — visible en cada sesión, no enterrado detrás de un filtro guardado.
• Email sequences como complemento del pipeline. El brief se enfocaba en deal tracking; el diseño entregado incluyó métricas de rendimiento — tasas de apertura, tasas de respuesta, conteos de enrollment — que conectan la actividad de outreach con el pipeline que alimenta.

El producto consolidó gestión de pipeline, forecasting, tracking de actividades y ejecución de outbound en un solo workspace — eliminando la capa de planillas que se interponía entre el CRM y el flujo de trabajo del equipo de ventas. La preparación de pronósticos pasó de un ritual de horas exportando y reconciliando datos a una lectura directa de la vista de pipeline ponderado.

El riesgo en deals se hizo visible más temprano en el ciclo. La vista de slipping deals detectó inactividad y fechas vencidas en tiempo real en lugar de reportes semanales, dando a los managers una ventana más estrecha pero más accionable para intervenir. Los equipos reportaron que las revisiones de pipeline pasaron de interrogatorio a conversación — los datos en pantalla eran confiables porque reflejaban realidad de deals, no cumplimiento de carga.

La arquitectura centrada en el pipeline abrió un camino claro para la expansión. El modelo soporta regiones y segmentos adicionales sin cambios estructurales. El forecasting puede extenderse a análisis de tendencias multi-trimestrales, y el feed de actividades provee la base para scoring de engagement — features que derivan de las decisiones tomadas en este proyecto.