Clan · We Are Clan · propuesta · 7 sep 2026
Una métrica que dice si Clan va bien, tres palancas que la explican y ocho números que alguien puede mover esta semana. Nada aparece dos veces: lo que está en un nivel no se repite en otro.
Vocabulario
Todo el documento usa estas tres y ninguna más. Son etapas anidadas: toda compra fue antes una reserva, y toda reserva fue antes un contacto.
| Etapa | Qué hizo la persona | Dónde vive | Hoy |
|---|---|---|---|
| Contacto | Dejó sus datos. No pidió lugar en ninguna edición | MailerLite · form corto de Webflow | ~950 activos · el form sin relevar |
| Reserva | Pidió un lugar en una edición concreta | Airtable Reservas | 447 registros |
| Compra | Reservó y hizo el primer pago | Reservas.Estado = Confirmado | 159 |
Por qué importa decirlo así. La tabla se llama Reservas y tiene 447 registros, de los cuales 280 están caídos: el equipo ya convive con la ambigüedad entre "reservó" y "va a viajar". Nombrarlas distinto no crea el problema, lo hace visible — y obliga a leer siempre el par reservas / compras.
Una consecuencia que hay que tener presente: como las etapas son anidadas, ⑦ contactos sin reserva es un stock que se vacía cuando alguien reserva. No es una población separada: es la parte del embudo que todavía no avanzó.
El árbol
Cada nivel se explica por el de abajo. La North Star se parte en oferta y demanda; la demanda se parte en tres palancas; cada palanca tiene los inputs que un área mueve.
La regla que sostiene la jerarquía: un número vive en un solo nivel. Si el output de P3 es "personas de la base que compraron", sus dos componentes —repitentes y reconvertidos— son inputs y no se repiten arriba. Un número que aparece dos veces no es un árbol, es una lista con dos formatos.
Nivel 0
La métrica es una sola. Se lee en tres ventanas porque cada una responde una pregunta distinta y tiene su propia reunión. El 12 m no se menciona en la semanal: no cambió desde el lunes anterior.
| Ventana | Pregunta | Reunión | Qué se hace |
|---|---|---|---|
| Edición en venta | ¿Esta semana hay que hacer algo? | Semanal · 15 min | Decidir. % del cupo a T−n contra la referencia del destino (anexo C). |
| 12 meses rodantes | ¿El año va bien? ¿Es oferta o demanda? | Mensual · 20 min | Observar. El par de abajo. |
| Edición cerrada | ¿Qué cambia en la próxima de este destino? | Post-mortem · 30 min | Aprender. El árbol completo de esa edición. |
Lectura mensual · 12 meses rodantes
Viajeros = Cupos ofrecidos × Ocupación. Con dos de los tres términos el tercero sale solo, y el delta se parte en cuánto vino de la oferta y cuánto de la demanda. Un repitente cuenta cada vez que viaja.
Contra los 12 meses previos (73 viajeros · 61% · 119 cupos). 0,82 × 0,85 = 0,70: cierra. Mitad oferta, mitad demanda. Mismas 6 ediciones, más chicas (16,3 plazas de media contra 19,8) y peor llenadas. Dueño: Dirección.
El cupo se escribe una vez, al abrir la venta, y no se toca. Si se ajusta a lo vendido, la ocupación converge a 100% y el par pierde la mitad que lo justifica.
Siempre en % relativo y en plazas, con el n.º de ediciones al lado. "−22 plazas, mismas 6 ediciones" dice más que "−30%". Los límites del par, en el anexo B.
Nivel 1
Uno por palanca. Son indicadores de resultado: se leen para saber de dónde vino el movimiento, no para actuar sobre ellos.
¿Entra suficiente gente que no nos conocía?
Ventana: por edición, acumulado a T−n · medible hoy
De los que reservan, ¿cuántos pagan?
Ventana: por edición · 12 m para la lectura mensual · medible hoy
De los que ya nos conocían, ¿cuántos compran?
Ventana: 12 meses rodantes · a medias
La caída más grande del árbol es ②: cierra el 17,4% contra el 30,5% histórico. Con 190 reservas de gente nueva en 12 meses no es ruido de muestra. La demanda entró y el cierre no acompañó: se mira el tiempo de respuesta (⑧) antes que la pauta.
Todos los que quieren reservar llenan el mismo form, hayan viajado o no. Dos formularios obligan a la persona a saber cuál le toca y a Ventas a mantener dos circuitos; el que se equivoca de form desaparece de las dos cuentas.
La separación es derivada, no declarada: no se pregunta "¿ya viajaste con nosotros?" —se completa mal y además ya lo sabemos— sino que se resuelve cruzando el email contra el histórico.
Tipo de reserva = Nuevo · Reconvertido · Repitente
Excluyentes y exhaustivos, y son las tres poblaciones del árbol: nunca estuvo en la base (Entrada) · estaba y nunca viajó (Vuelta, ⑪) · ya viajó (Vuelta, ⑩).
| Corte | Hoy | Qué mide en realidad |
|---|---|---|
| Nuevos | 17,4% 12 m · 30,5% hist. | Cierre real. Es la que se gestiona. |
| Repitentes | 96,8% (30 de 31) | Cómo se carga el CRM, no un cierre: el repitente no pasa por el Tally, aparece cuando ya decidió. |
| Reconvertidos | sin medir | Depende del cruce por email (paso 6). |
La de repitentes se publica igual, marcada como no interpretable. Sirve de test de instrumentación: el día que deje de dar 97% vamos a saber que el circuito empezó a funcionar. Lo que no se usa nunca es la tasa global (35,7%): sube y baja con el mix de repitentes, no con el desempeño.
"Vuelta" es vuelta a la conversación, no necesariamente segunda compra. ③ se descompone en dos poblaciones sin solapamiento: viajó antes (⑩) o reservó y nunca viajó (⑪) — el segundo grupo compra por primera vez, así que la palanca no es recompra: es todo lo que produce la base propia. No se combinan en una tasa única porque pueden moverse en direcciones opuestas; el argumento completo, en el anexo B.
Nivel 2
Cada uno tiene un área que lo mueve y una ventana declarada. Si no está acá, no se acciona semanalmente. Hoy son medibles 5 de las 12 métricas del árbol, y ③ a medias.
| # | Input | De | Cómo se calcula | Ventana | Área | Hoy | Decisión que dispara |
|---|---|---|---|---|---|---|---|
| ④ | Cupos en venta próximas 16 semanas | Oferta | Σ (cupos − confirmados) de ediciones con inicio en ≤ 16 semanas | Horizonte, hacia adelante | Dirección | ninguna cargada | Cero cupos en el horizonte: abrir edición o aceptar el hueco. Es el único número que mira adelante |
| ⑤ | Landing → reserva | P1 | Usuarios con evento lead / usuarios de la landing (sin thank-you) | 8 semanas rodantes | Web | medible | Bajo el piso del destino: es la landing, no la pauta. Revisar CTA y largo del Tally |
| ⑥ | Costo de captación | P1 | Dos cortes del mismo gasto: gasto Meta / reservas de origen pago (valor de corto plazo), y gasto Meta / todos los contactos captados, sumando los que dejaron el mail sin reservar (eficiencia de captación) | 8 semanas rodantes | Pauta | sin acceso a Meta | El corte por reserva sube dos períodos seguidos con ⑤ estable: es la pauta, no la web. Los dos juntos deciden cuánta pauta va a venta directa y cuánta a llenar el pool |
| ⑦ | Contactos sin reserva | P1 | Mails del form corto "avisame de la próxima edición" que todavía no reservaron ninguna edición. Stock, altas del mes y cuántas de esas altas vienen de pauta | Mes (stock acumulado) | Contenido | ~55 en 15 m, destino desconocido | Al abrir una edición se le vende primero a este pool. Si crece y nadie pasa a reserva, el form capta a la gente equivocada. Si el pool no existe en ningún lado, es la fuga #1 |
| ⑧ | Primer mensaje en 24 h | P2 | % de reservas nuevas con Fecha primer contacto ≤ 1 día del envío del form | Semana | Ventas | campo vacío | Bajo 80% en venta activa: sumar manos o automatizar el primer mensaje. Es el dolor #2 y hoy no tiene número |
| ⑨ | Reservas estancadas | P2 | Reservas que llevan más de 14 días sin pasar ni a compra ni a caída. Absoluto y % del pipeline abierto | Semana | Ventas | la antigüedad no se puede calcular hacia atrás | Sube: alguien se está quedando sin capacidad de seguimiento — sumar manos, o cerrar las viejas como caídas y dejar de contarlas como pipeline vivo. Es el único número del árbol que mira la saturación operativa, el dolor #1 declarado |
| ⑩ | Repitentes 12 m | P3 | Personas con viaje previo que confirmaron, en absoluto y como tasa sobre el pool elegible (≥ 1 viaje en los 24 m previos). Nunca % de las plazas | 12 meses rodantes | Ventas | 13 (+7) · 13,8% (−3,8 pts) | Absoluto arriba y tasa abajo: el pool creció y la reactivación no lo siguió — campaña sobre los 81 que no volvieron. Tasa arriba con absoluto plano: el pool se achica, el problema es P1 |
| ⑪ | Reconversión de la base | P3 | Reservas cuyo email ya estaba en la base antes de abrir la venta, sobre la base activa no compradora. Se lee cortada por pool de origen: los que reservaron y nunca viajaron · los contactos del form corto (su activación) | Por edición | Contenido | 5 casos, sin medir | Si la base activa (~950) produce menos del 5% de las reservas de una edición, el email no reconvierte: cambia el contenido o la segmentación, no la pauta |
El límite de ⑨, declarado. Los 447 registros tienen createdTime entre el 7 y el 10 de mayo de 2026 —fue una migración masiva—, así que la antigüedad de una reserva no se puede calcular hacia atrás. ⑨ funciona de ahora en adelante, y bien desde que Fecha de reserva sea obligatoria (paso 2). Mientras la carga al CRM sea manual, además, mide cuándo se cargó, no cuándo reservó: si la carga se atrasa una semana, toda reserva nace con una semana de antigüedad falsa.
El email marketing es el canal que trabaja P3, no una métrica de salud aparte. CTOR y bajas por clic se leen dentro de ⑪, como cuánto responde la base a lo que se le manda. La apertura queda afuera: inflada por Apple Mail, r = −0,26 con el clic.
Ventanas
Una ventana no se elige por prolijidad: se elige por volumen. Con los volúmenes de Clan la diferencia es entre un número y un ruido.
Reservas de gente nueva: 190 en 12 meses = 3,7 por semana. Contactos web en GA4: 149 = 2,9 por semana. En 4 semanas entran ~12 y un movimiento del 30% es una persona. En 8 semanas entran ~23, que ya es un número. Por eso los ratios de Web y Pauta van a 8 semanas rodantes y no a 4, como estaban.
④ no es una ventana, es un horizonte: no agrega el pasado, proyecta. Las 16 semanas salen del período típico de venta de una edición — con 12 ya llegás tarde para abrir algo. Ese número es un supuesto y lo tiene que confirmar Dirección: hoy Fecha de reserva está en 1 de 447 reservas, así que cuánto dura una venta no se puede medir.
Entran ≥ 25 eventos en la ventana, o el número describe a una persona.
La ventana es más larga que lo que tarda la acción en verse.
Si entre dos lecturas se renovó menos de la mitad de la ventana, el número se mira pero no se discute, salvo que cruce un umbral. Por eso el 12 m no se menciona en la semanal.
| Ventana | Qué mide | Métricas |
|---|---|---|
| Semana | Flujo con dueño diario | ⑧ ⑨ · el conteo semanal de ① |
| 8 semanas rodantes | Ratios de volumen bajo | ⑤ ⑥ |
| Por edición | Lo que la edición determina | ① ② ⑪ |
| 12 meses rodantes | Resultado del año | North Star · ③ ⑩ |
| Horizonte 16 semanas | Lo único que mira adelante | ④ |
Retorno de la pauta
La pauta trae dos cosas distintas y hasta ahora el árbol sólo contaba una. Un visitante que deja el mail en el form corto no es tráfico perdido, y una campaña juzgada sólo por costo de captación lo trata como si lo fuera.
Quiere esta edición.
Completó el form extenso de una edición concreta. En Airtable es una Reserva creada. Su destino es ② y se resuelve en semanas.
Denominador del primer corte de ⑥
Es target, pero ni la fecha ni el destino del momento le sirven.
Deja el mail en "avisame de la próxima edición". No se le vende ahora: se guarda, y se le vende primero cuando abre la edición que sí le sirve.
Denominador del segundo corte de ⑥ · se activa vía ⑪
La cuenta que decide el presupuesto
Valor esperado por interesado = tasa de activación × conversión de nuevos × precio de lista
Costo por interesado = gasto Meta / interesados captados en la ventana
La tasa de activación es qué proporción del pool pasa a reserva cuando abre una edición que le sirve: es el corte de ⑪ por pool de origen, así que la métrica ya existe y sólo hay que leerla partida. Si el valor esperado supera al costo, conviene mover presupuesto de venta directa a captación de pool, y al revés. Es la única forma de justificar pauta que no convierte este mes, y hoy Clan no la tiene: la inversión se juzga contra la edición en venta, que es el peor momento para juzgarla.
| Término | Estado | Qué lo destraba |
|---|---|---|
| Gasto e interesados de origen pago | sin acceso a Meta · el form corto no lleva UTM | Acceso de lectura a Meta (paso 5) + parámetros de campaña en el form corto |
| Interesados captados | no se sabe dónde caen los ~55 submits | Relevar el form (paso 4). Y que capture destino o fecha de interés: sin eso no se puede saber cuándo abre "la edición que le sirve", y la tasa de activación no existe |
| Tasa de activación | requiere el cruce por email | Dedup + grupo por edición (paso 6) |
| Precio | se usa precio de lista | Monto pagado está en 5 de 159: el retorno se expresa en plazas y en precio de lista, no en margen |
La tasa de activación tarda un ciclo entero en existir. La estimación histórica de Clan es de 17 puntos de contacto para una compra, y hay un caso documentado de siete meses entre el registro y la reserva. La primera lectura confiable llega con dos o tres ediciones abiertas después de empezar a medir.
Sumar interesados al denominador baja el costo de captación automáticamente, sin que nada haya mejorado. Por eso los dos cortes se leen siempre juntos y nunca se reemplaza uno por el otro.
Para que exista
Con el paso 1 el scorecard existe el lunes que viene.
Qué decisión habilita este documento: aprobar la North Star como par Viajeros × Ocupación, la regla del cupo congelado, los tres niveles con sus 12 métricas y las ventanas de arriba; y asignar quién trae cada número. La rutina de lectura —semanal, mensual y post-mortem— es un documento aparte.
Anexos
Nada de esto hace falta para leer el árbol. Está acá porque alguien va a preguntar.
Cupos totales es un campo que se carga, no una capacidad física: hay una edición registrada con 106,7% de ocupación y Bariloche pasó de 23 a 15 plazas sin que quede asentado si cambió el hotel o cambió cómo se anota. Si el cupo se ajusta a lo vendido, la ocupación converge a 100% y deja de informar.
Seis ediciones por ventana es poco: una edición de 23 cupos mueve el total un 30–45%, y una fecha que cruza el borde de la ventana (31 de agosto contra 7 de septiembre, que es lo que pasó en 2025) cambia el signo del delta sin que pase nada en el negocio. Además el par mira para atrás y promedia destinos: un año con más Río baja la ocupación sin que ninguna edición haya vendido peor. Eso lo cubre el post-mortem por destino.
No es que el repitente convierta mejor: el repitente no pasa por el Tally, aparece en Airtable cuando ya decidió. Ese 97% mide cómo se carga el CRM, no una conversión. La conversión que se gestiona es la de nuevos; el repitente se gestiona por reactivación, no por embudo.
La base tiene dos tipos de persona y la condición de una es la negación de la otra: viajó antes (⑩) o reservó y nunca viajó (⑪). Cero solapamiento, y pueden moverse en direcciones opuestas — buenos hosts y mal email suben ⑩ y bajan ⑪. Una tasa combinada mezclaría un pool que convierte al 14% con otro que hoy da 5 casos en 446: el promedio no describiría a nadie.
Las plazas de repitentes fueron 16 de 51 (31%) contra 19% histórico, y parece un éxito: sube porque cayeron las reservas de gente nueva. Volvieron 13 personas contra 6, pero el pool que podía volver se triplicó (34 → 94) y la tasa cayó de 17,6% a 13,8%. Más gente para retener, retenida peor. El % de plazas queda como nota de composición en el post-mortem.
Hay 5 contactos retenidos en dos años (reservó, no viajó, volvió a reservar): 281 contactos nunca viajaron y sólo 1 tiene dos reservas. O la base no reconvierte, o el que vuelve entra como contacto nuevo por duplicados y Airtable no lo ve. La segunda lectura hay que descartarla primero.
Cambian destino, precio, fecha y tamaño de base al mismo tiempo. Los rangos detectan anomalías que hay que mirar; no afirman causas. Cada edición se compara con la anterior del mismo destino, nunca con el promedio de Clan.
Una fila por edición en venta, todas las columnas normalizadas para que dos ediciones de tamaño distinto se lean igual. Las filas son un ejemplo del formato: Airtable no tiene cargada ninguna edición en venta.
| Edición | T−n | Cupos | Conf. | % cupo | Ref. destino a T−n | Δ | Reservas (sem.) | Sin contactar | Repitentes | Semáforo |
|---|---|---|---|---|---|---|---|---|---|---|
| Tandil sep-26 | −3 | 23 | ? | ?% | Tandil may-26 a T−3: ?% | ? | ? | ? | ? | |
| Río dic-26 | −14 | 23 | ? | ?% | Río oct-25 a T−14: ?% | ? | ? | ? | ? |
Para saber qué % del cupo tenía Río oct-25 a T−14 hace falta la fecha de cada confirmación, y Fecha de reserva está en 1 de 447. Hacia adelante, en orden de calidad: (1) Fecha de reserva obligatoria desde ahora — con una edición cerrada por destino ya hay curva real; (2) mientras tanto, proxy de ritmo lineal: referencia = % del período de venta transcurrido; (3) reconstrucción parcial desde MailerLite y WhatsApp, sólo si Dirección y Datos consideran que vale 2 horas. Propuesta: 2 ahora, 1 desde el paso 2, 3 no.
| Métrica | Dónde se mira | Por qué no está |
|---|---|---|
| Precio neto · descuento efectivo · Clan Coins | Post-mortem, como mix de plazas por tipo de descuento | El precio y los descuentos se definen al lanzar la convocatoria y no se tocan: no hay dinamismo que seguir. Ver abajo. |
| Visita → empieza el form · empieza → completa | Rutina Tally drop-off (ya corre semanal) | Diagnóstico del form, no del negocio. Se mira cuando ⑤ cae. |
| Reservas por canal | Bloque 2 + rol paid media (B-03) | Sin "¿Cómo nos conoció?" cerrado no hay dato. |
| Tiempo a primera respuesta (mediana) | Absorbida por ⑧ | Un semáforo se lee en 2 segundos; una mediana no. Misma fuente. |
| Reservas en Tally vs. reservas en Airtable | Precondición, en el checklist de arranque de la rutina | Es un control de integridad del dato, no una decisión comercial: dispara "cargá lo que falta", no "cambiá algo del negocio". Con la carga manual sigue siendo crítico —una reserva que no se carga no la llama nadie— pero desaparece cuando ande el circuito Tally → Airtable. |
| Motivo de caída de una reserva | Post-mortem, como análisis ocasional | No tiene umbral: no existe "20% de caídas por precio está mal", así que no puede disparar una decisión semanal — y por la regla del propio árbol, sin umbral no es un input. Además la mayoría de las caídas no tienen motivo, tienen silencio: el campo iba a ser mitad "no respondió" y mitad vacío. Sirve para revisar proceso o propuesta cada tanto, no para el lunes. |
| Etapas intermedias entre reserva y compra (seña, pago parcial) | No se puede medir | Reservas.Estado tiene tres valores —Caído 280 · Confirmado 159 · Interesado 8— y ninguna etapa de pago parcial: el pipeline es binario. Partir el tramo requeriría estados nuevos. |
| Días reserva → pago | Post-mortem, cuando exista Fecha de reserva | Sin fecha no hay dato. |
| NPS y satisfacción declarada | Post-mortem, como contexto · rediseño de encuesta (C-02) | Se mueve una vez por edición, no por semana. Y hoy no es medible con validez: 15% de respuesta con autoselección, y con ediciones de 15 a 23 personas el NPS es una resta de porcentajes que dos detractores mueven 15 puntos. ⑩ es el NPS revelado: la recompra observada es la misma pregunta contestada con plata, sobre el 100% de la población. Si hace falta un número declarado que llegue antes que la recompra, la pregunta es "¿volverías?" en el cierre del viaje y en persona — respuesta cerca del 100%, y se valida contra ⑩ un año después. |
| Recompra por destino y host · respuesta del feedback | Post-mortem | Muestra ≤ 15%, sin comparabilidad entre ediciones. |
| % de plazas ocupadas por repitentes | Post-mortem, nota de composición | Sube cuando caen las reservas de gente nueva. |
Sale del seguimiento frecuente porque no es una variable que se opere: se define un early bird y un descuento de repitente al lanzar, y no hay cupones personalizados ni ajustes sobre la marcha. Un número que no cambia entre dos lecturas no dispara ninguna decisión. Queda una línea en el post-mortem —cuántas plazas se vendieron a lista, a early bird y a precio de repitente— que es lo que permite calibrar el early bird de la próxima edición.
Ojo con el arrastre: la carga de montos y descuentos en Airtable se justificaba en parte por esta palanca. Sigue haciendo falta igual, por Fecha de reserva: es lo único que construye la curva de referencia del scorecard (paso 2).