Un platform lead de VC preguntó recientemente: «Tengo once portfolio companies en HubSpot, seis están desordenadas, ¿por dónde empiezo?» El instinto es triagiar por empresa, elija la más desordenada, embeba un trimestre, siga adelante. Ese modelo no se compone. Cuando termina la empresa tres, la cuatro y la cinco han derivado más. El soporte de RevOps para portfolio solo escala cuando la unidad de trabajo es la auditoría, no la empresa. Ejecute la misma pasada de 90 minutos sobre las once, ordénelas en cuatro buckets, e intervenga sobre el bucket, no sobre el logo.
Por qué importa ahora
La infrainversión del founder en RevOps es estructural. Poyar ha argumentado extensamente que combinar motion product-led con ventas tradicionales: la forma estándar de una portco B2B SaaS de early-stage: crea complejidad operativa alrededor de estructura organizativa, hiring, comp y account assignment que los founders sistemáticamente subestiman hasta que los forecasts empiezan a fallar. En ese punto se le pide al platform team intervenir aguas abajo de un año de deuda acumulada. Multiplique eso por once empresas y el platform team está mirando once limpiezas simultáneas, todas urgentes, ninguna construyendo sobre la otra. El modelo de soporte tiene que invertirse, defina la auditoría aguas arriba, ejecútela sobre cada portfolio company al ingreso, y acepte que el 60% del valor del platform RevOps es el diagnóstico, no la implementación.
La trampa del platform team
La mayoría de los platform teams de VC están dotados de uno o dos generalistas senior que han ejecutado RevOps dentro de una portfolio company antes. El instinto es ayudar de la forma en que solían ayudar, embedded, hands-on, con las mangas remangadas dentro de una empresa a la vez. Ese modelo funcionaba cuando eran el operador. No funciona cuando son el fondo.
El problema es que la ayuda a medida sobre un portfolio es ilimitada en tiempo y no repetible en output. Cada compromiso empieza desde cero. Cada recomendación es one-off. El platform team se vuelve una consultoría interna lenta, y las portcos que realmente reciben ayuda son las más ruidosas en la reunión LP, rara vez el mismo conjunto que las que tienen el mayor apalancamiento por intervención.
La auditoría de portfolio de 90 minutos
Lo que escala es lo inverso, defina una sola plantilla de auditoría, scope fijo, tiempo fijo, output fijo. Ejecútela sobre cada portfolio company a la misma profundidad. Use la auditoría, no la empresa, como unidad de trabajo.
La versión que ejecutamos en Checkpoint cubre cuatro áreas en 90 minutos:
- Definiciones de pipeline. ¿Cuáles son las deal stages? ¿Cada una tiene una definición de una frase, un criterio de entrada y un criterio de salida? ¿Pueden dos reps describir «qualified» de la misma manera? La mayoría de las portfolio companies fallan esto en los primeros 15 minutos.
- Atribución de lead source. ¿De dónde vienen los contactos, y la fuente está realmente poblada en la creación? ¿Hay un único campo source-of-truth, o tres compitiendo? ¿Puede el platform team reconciliar un número de campaign spend contra un número de pipeline sourced sin un export manual?
- Contabilidad de marketing-contact. ¿Cómo se está gestionando el tier de contacto de HubSpot? ¿Hay un workflow que auto-marca marketing contacts en cambio de lifecycle, y coincide con el tier pagado real? Aquí es donde se filtran los costes de seats.
- Higiene de renovación y post-sale. ¿Hay un renewal pipeline distinto del new business? ¿Se usan objetos de subscription, o la renovación se trackea en una propiedad custom que nadie actualiza? ¿Customer success opera contra un sistema, o contra una hoja de cálculo?
Noventa minutos no es un deep dive. Produce un diagnóstico de una página y una decisión de triage.
Las cuatro categorías de problema
Cada auditoría de portfolio company aterriza en uno de cuatro buckets. La intervención se empareja al bucket, no se diseña desde cero.
Categoría 1, Greenfield install
Seed o pre-Series A, GTM founder-led, HubSpot fue configurado por un AE fundador en un fin de semana. No hay deuda porque no hay sistema. La intervención es un install templatizado, pipeline estándar, lifecycle stages estándar, schema de lead-source estándar, renewal pipeline estándar. Tenemos una plantilla portátil de HubSpot que el platform team despliega en un sandbox, valida contra los datos reales de deal de la empresa, y entrega en dos semanas. Sin trabajo de diseño a medida.
Categoría 2, Brownfield triage
Series A o B, HubSpot ha estado en vivo durante más de dos años, el recuento de propiedades custom está en los cientos, y tres ex-RevOps hires dejaron sus huellas. La intervención es una pasada keep / edit / delete, cubierta en un post separado, y el output es un schema limpio contra el que el siguiente hire puede operar. Esto es la mayor parte de lo que los platform teams heredan.
Categoría 3, Candidato a replatform
Sentado sobre Pipedrive, Attio, o una instancia de Salesforce que el equipo ha superado pero no puede permitirse migrar solo. La intervención es un doc de scoping de migración y una decisión de vendor, no una implementación. El valor del platform team es la conversación de selección de plataforma desinteresada, la han hecho cinco veces a través del portfolio, y el founder lo está haciendo una.
Categoría 4, Hueco de operating model
El CRM está bien. El problema es aguas arriba, no hay ICP definido, la buying persona es difusa, el territorio está indefinido, el comp plan castiga el comportamiento equivocado. Ninguna intervención de HubSpot arreglará esto. El trabajo del platform team es marcárselo al board y conectar al founder con un GTM lead fraccional, no gastar tres meses ajustando workflows que se reescribirán en seis.
Compartiendo patrones a través de portcos sin filtrar datos
El compounding solo funciona si el platform team puede mover aprendizajes entre portfolio companies. El camino más rápido es una librería de patrones privada y anonimizada: de las once empresas auditadas, ocho tenían el mismo hueco de atribución de lead-source, aquí está el workflow entregado para arreglarlo. La librería es el activo; las portcos son consumidoras, no contribuidoras-por-nombre. Ningún dato de portco se mueve entre portcos. Lo que se mueve es la receta: un export de workflow templatizado, un schema de propiedad, una definición de pipeline, reconstruido en forma limpia, libre de cualquier identificador de la empresa fuente.
Patrón de campo
El platform lead de un fondo early-stage basado en DACH vino con once portfolio companies en HubSpot y un trimestre para mostrar a los LPs progreso medible. El instinto era embeberse en las dos más desordenadas. El proyecto real fue distinto. Ejecutamos la auditoría de 90 minutos sobre las once en tres semanas. El triage salió, cuatro greenfield installs, cinco brownfield triage, un candidato a replatform, un hueco de operating-model que necesitaba una contratación GTM fraccional en lugar de un proyecto de CRM. Los cuatro greenfield se entregaron en ocho semanas contra una sola plantilla. Las cinco brownfield cada una recibió un proyecto scoped de keep / edit / delete con una reducción del 30 al 50% de propiedades custom. Para el mes cuatro, el platform team tenía mejoras medibles en nueve de las once portcos, sobre aproximadamente la headcount que antes recibía trabajo a medida en una y media.
Resolución, un playbook de RevOps de portfolio
Para un platform team configurando soporte de RevOps de portfolio desde cero:
- Defina la auditoría antes de ofrecer ayuda. Escriba un guion de auditoría de 90 minutos con cuatro a seis preguntas por área y una plantilla de output de una página. La auditoría es el producto.
- Ejecute la auditoría sobre cada portfolio company al ingreso. Hágalo parte del plan post-inversión a 30 días, no una call reactiva cuando algo está en llamas. La cadencia crea el dataset.
- Triagie en las cuatro categorías. Greenfield install, brownfield triage, candidato a replatform, hueco de operating model. Fuerce la elección; no invente un quinto bucket por empresa.
- Construya intervenciones templatizadas para las categorías uno y dos. Una plantilla portátil de install de HubSpot, una hoja de cálculo keep / edit / delete, un schema de renewal-pipeline. Estos son activos reutilizables, no entregables a medida.
- Ejecute «office hours» para todo lo demás. Una franja semanal abierta de dos horas que el platform team mantiene para cualquier pregunta de RevOps de portco. La mayoría de los issues no necesitan un compromiso embedded; necesitan 20 minutos de juicio senior.
- Mantenga una librería de patrones privada y anonimizada. Workflows, schemas y documentos de proceso despojados de identificadores de empresa fuente, indexados por categoría de problema. La librería compone el dataset de auditoría.
- Externalice el trabajo embedded. Las categorías tres y cuatro, y los proyectos brownfield profundos en categoría dos, son compromisos externos. El platform team se mantiene escaso y senior; la profundidad de implementación viene de un partner verificado.
El paso siete es donde la mayoría de los platform teams se resiste. Es también donde el modelo se vuelve duradero. Un platform lead haciendo implementación dentro de una portco no puede ejecutar la auditoría sobre las siguientes ocho.
Dónde entra Checkpoint
Ejecutamos auditorías de portfolio y las intervenciones templatizadas que salen de ellas como un servicio en pie para fondos de venture y family offices en DACH y EMEA. La economía funciona porque la auditoría es fija, las cuatro intervenciones están templatizadas, y el platform team mantiene el juicio senior in-house mientras nosotros llevamos profundidad de implementación a través de múltiples portcos. Si es un platform lead intentando escalar el soporte de RevOps a través de más de cinco portfolio companies, hable con nosotros sobre cómo el soporte de VC portfolio puede componerse en lugar de quemar a su equipo una empresa a la vez.
Fuentes
- Poyar, Kyle. «PLG and Sales in 2023: How to Combine Them for Efficient Revenue Growth.» OpenView, 13 de junio de 2023. openviewpartners.com
- Lemkin, Jason. The RevOps playbook: how Owner.com’s CRO scaled from 0 to $1B ARR. SaaStr. saastr.com