Inicio › Blog › Cómo diseñar territorios de ventas sin que las hojas de cálculo se derritan en Q4

Cómo diseñar territorios de ventas sin que las hojas de cálculo se derritan en Q4

El diseño de territorios falla en Q4, no en Q1. El diseño que se lanza en enero se ve bien hasta junio, cuando la primera ola de nuevas contrataciones cambia las matemáticas, y luego se vuelve un desastre en octubre cuando un representante reclama accidentalmente una cuenta que otro ya tenía reservada. La solución casi nunca es rediseñar los territorios. Es arreglar la cadencia operativa alrededor de ellos.

Por qué el dolor de territorios aparece en Q4

Todo modelo de territorios sobrevive su primer trimestre. Los representantes participaron en el diseño. Las cuentas nombradas están frescas. La cobertura de pipeline se ve sana porque nadie ha tenido tiempo de quemarla. A mediados de Q2, dos representantes se fueron y sus cuentas se reasignan a las prisas. A mediados de Q3, marketing generó 400 leads inbound que nadie preasignó, así que los AEs los están reclamando en un canal de Slack llamado #inbound-grab. Para Q4, el liderazgo revisa la cobertura de pipeline y descubre que tres representantes están sobre-cubiertos y cuatro sub-cubiertos, no hay dos reportes que coincidan en quién es dueño de las 50 cuentas principales, y la forecast call se convirtió en una competencia sobre de quién es el pipeline que contribuye a la cuota de quién.

Nada de esto es una falla de diseño. El modelo original de territorios estaba bien en enero. Lo que falló fue la cadencia operativa que debió haber cachado cada desviación antes de que se compusiera.

Empieza desde el ICP, no desde la geografía de los representantes

El error de diseño más grande que veo es empezar desde dónde viven los representantes. Los representantes son móviles. Los ICPs no. Construye los territorios desde el universo de cuentas — las cuentas nombradas que encajan con tu perfil de cliente ideal — y luego asigna representantes a esas cuentas según capacidad y capability. La geografía de dónde viven los representantes en un trimestre dado es una preocupación secundaria, no primaria.

En la práctica esto significa: jala el TAM (Total Addressable Market) de una fuente como ZoomInfo o Crunchbase, filtra a cuentas que coincidan con el ICP (industria, número de empleados, banda de ingresos, tech stack, señal reciente de contratación), clasifícalas por valor potencial, y luego agrúpalas en books balanceados. Después asigna representantes. Esto produce territorios donde cada representante tiene aproximadamente el mismo número de cuentas de tier alto, sin importar dónde estén en el mapa. También hace el diseño defendible — cuando alguien pregunta "¿por qué mi territorio solo tiene seis cuentas Enterprise?", la respuesta es "porque el ICP solo contiene seis cuentas Enterprise en tu segmento, y otros tres representantes tienen el mismo problema."

Tres tiers, no cinco

La mayoría de los modelos de tiering de cuentas que he heredado tienen cinco tiers. Cinco son demasiados. Las matemáticas de cuántas cuentas puede cubrir un representante de forma significativa no producen cinco niveles distintos de atención — producen tres: "hay que tocarla este trimestre," "hay que tocarla este año," y "sabe que existimos."

Tier 1: aproximadamente 15-25 cuentas por representante. Estas reciben outbound personalizado, juntas con sponsor ejecutivo, campañas ABM y multi-threading nombrado. El representante tiene una relación por nombre con al menos tres personas en cada cuenta.

Tier 2: aproximadamente 75-150 cuentas por representante. Estas reciben outreach con cadencia, nurture de marketing y un toque trimestral del AE. El representante puede recitar las top 30 de memoria.

Tier 3: todos los demás. Demand-gen carga el peso. El AE las hereda solo cuando el interés inbound las hace visibles.

Tres tiers son suficiente granularidad para tomar decisiones de asignación. Cinco tiers introducen categorías que en la práctica nadie trata distinto, lo que significa que los dos de abajo colapsan en "ya llegaremos a eso" — que es lo mismo.

Rollups jerárquicos en Salesforce

El liderazgo quiere hacer rollup del desempeño por territorio a nivel segmento, región y org completa. La forma en que la mayoría de las orgs de Salesforce manejan esto es un campo custom en el registro de User o Account que no agrega limpiamente. La forma correcta es usar Salesforce Territory Management (la funcionalidad, no el concepto) — sí, la implementación es molesta, pero la alternativa es código Apex custom que se rompe cada vez que alguien cambia la asignación de un representante.

El modelo: cada territorio tiene un padre. AMER-Enterprise hace rollup a AMER, AMER hace rollup a Global. Los reportes construidos contra la jerarquía de territorios agregan automáticamente por cualquier nivel. Cuando un representante se mueve de AMER-SMB a AMER-Mid-Market, su pipeline se mueve con él, los rollups se actualizan, y el reporteo histórico se mantiene consistente porque Salesforce guarda el snapshot. Esta es toda la razón por la que Salesforce lanzó Territory Management 2.0 — y sigue siendo subutilizado porque el setup inicial es quisquilloso.

Terminar las guerras por cuentas

El desacuerdo operativo más caro en un equipo B2B SaaS es dos representantes reclamando la misma cuenta. La respuesta correcta es hacerlo imposible — un solo dueño por cuenta en todo momento, forzado por una regla de validación en Salesforce. Las excepciones (un SDR trabajando un prospecto que técnicamente es de otro AE; un CSM dueño de la renovación pero Ventas dueño del upsell) se documentan en una sola hoja que el deal desk administra. Si un deal cierra en una cuenta donde la propiedad estaba en disputa, el deal desk tiene autoridad para resolverlo antes de que se pague la comisión.

El enfoque del canal de Slack — donde los representantes publican "reclamo esta cuenta" y el primero en publicar gana — no escala más allá de 10 representantes. También crea resentimiento que se compone a lo largo de los trimestres. Invierte en la regla de validación. La implementación son 90 minutos para un admin con habilidades intermedias de Salesforce.

El protocolo de reacomodo de medio año

Incluso con un diseño perfecto, los cambios de medio año son inevitables. Los representantes se van, entran nuevos, los segmentos cambian. El protocolo para manejar reacomodos es más importante que el diseño original.

Tres reglas: (1) las bajas de representantes disparan una redistribución de cuentas dentro de cinco días hábiles, con el manager como dueño de la decisión y ops ejecutando. (2) Los nuevos representantes reciben cuentas de un "talent pool" — cuentas que se retuvieron intencionalmente durante el diseño inicial específicamente para este propósito. Retén cerca del 5-10% del universo de cuentas nombradas para esto. (3) Cualquier solicitud de un representante para intercambiar cuentas requiere justificación por escrito al manager y se revisa trimestralmente, no bajo demanda. La tercera regla es la que evita que las solicitudes de reacomodo se conviertan en una junta permanente en el calendario de cada manager.

La plantilla de scoring de 200 cuentas

Si estás empezando de cero, la plantilla que funciona es una matriz de scoring de 200 cuentas por representante. Columnas: nombre de cuenta, industria, número de empleados, ingresos, flags de tech stack, flags de señal de intent, fecha del último contacto, último engagement de marketing, estatus actual de pipeline, tier (1-3), representante asignado. Actualízala mensualmente. Ordena por tier, luego por score de intent. Esa lista ordenada es el universo de cuentas del representante y la base de cada revisión semanal de pipeline.

Por debajo de 200 cuentas nombradas por representante, el modelo es demasiado delgado para darle suficiente con qué trabajar. Por encima de 400, el representante no puede priorizar de forma significativa y cae de vuelta en "lo que llegó esta semana." Doscientas es el punto dulce para la mayoría de los motores B2B SaaS.

Qué software usar y cuál saltarse

No necesitas un proveedor de software de gestión de territorios para un equipo de 20-50 representantes. Territory management nativo de Salesforce, un campo de ranking de Account y una junta mensual de revisión es suficiente. Por encima de 50 representantes, herramientas como Anaplan, Fullcast o Varicent SPM Cloud se ganan su costo porque las matemáticas de optimización (balancear capacidad, capability y potencial a través de cientos de representantes) se vuelven no triviales. Por debajo de 50 representantes, esas herramientas agregan ceremonia y frenan la iteración.

La única herramienta que sí recomiendo a cualquier tamaño: una fuente de datos de TAM/ICP. ZoomInfo, Crunchbase, Apollo. Sin ella, estás diseñando territorios contra un mercado que existe solo en tu CRM, y tu CRM es una muestra de la historia de una sola empresa — no una muestra del mercado direccionable. La fuente de TAM es la diferencia entre un diseño defensivo y uno ofensivo.

Los primeros 30 días de un engagement de territorios

Si heredas un desastre de territorios y tienes 30 días para arreglarlo:

1. Semana 1: jala el universo de cuentas nombradas de Salesforce. Audita duplicados, conflictos de propiedad, cuentas asignadas a ex-empleados. Limpia.
2. Semana 2: define o refresca el ICP. Jala el TAM de una fuente de datos. Identifica la brecha — cuentas en tu CRM que no encajan con el ICP, y cuentas en el TAM que deberían estar en tu CRM y no están.
3. Semana 3: diseña los nuevos territorios usando el modelo de tres tiers. Mantente dentro de ±15% de balance entre representantes para el conteo de Tier 1.
4. Semana 4: lanza. Comunica el razonamiento. Levanta la cadencia operativa (regla de validación, protocolo trimestral de reacomodo, revisión mensual de tiers).

El siguiente año es ejecución. El diseño es la parte fácil. La cadencia es el trabajo.