Switching costs: lo que cuesta irse, no lo que cuesta quedarse

Descripción

Un switching cost es la fricción —en dinero, en tiempo, en datos o en hábito— que un usuario enfrenta al dejar tu producto por el de un competidor. Es fácil de confundir con la pregunta anterior, la de la lección 3: un network effect explica por qué un usuario llegó y se quedó porque otros ya estaban ahí; un switching cost explica por qué, aunque un competidor lanzara mañana algo objetivamente un poco mejor, ese mismo usuario no se movería — no porque Mercado sea insustituible, sino porque irse cuesta algo real, y ese costo no lo paga Mercado, lo paga el usuario que decide cambiarse.

Esta lección abre el segundo de los cinco tipos de moat y, con él, la distinción más importante del tema: no todos los switching costs son iguales, y el que se siente más fuerte en el papel —un contrato firmado— es, según el modelo, el más débil de los tres. Vas a entender por qué.

Conexión con el módulo. La lección 3 trabajó sobre la red completa —cómo se atraen los usuarios entre sí—. Esta lección mira al usuario individual, ya adentro, y pregunta algo distinto: si ese usuario, uno solo, decidiera irse hoy, ¿qué le costaría? La lección 5 sigue el mismo patrón de "abrir un tipo a la vez" con dataMoat y scaleEconomies.

Una analogía cotidiana: mudarte de banco con diez domiciliaciones

Cambiar de banco, en el papel, es trivial: llenas un formulario, en un par de días tienes una cuenta nueva. Y sin embargo, casi nadie lo hace, aunque el banco nuevo ofrezca mejores condiciones. La razón no tiene nada que ver con abrir la cuenta nueva — tiene que ver con desenredar tu vida del banco viejo: el pago automático del alquiler, la domiciliación del gimnasio, la suscripción de streaming, el seguro del auto, la nómina que tu empleador deposita ahí desde hace tres años. Cambiarte significa actualizar cada una de esas diez cosas, una por una, y si te olvidas de una sola, el resultado es un pago rechazado, un recargo, un servicio cortado. El banco nuevo no te retiene con nada — te retiene el trabajo de desconectar diez hilos que tú mismo, con el tiempo, fuiste atando al banco viejo.

Ahora compara eso con un banco que te ofrece una tasa mejor a cambio de que firmes un contrato de permanencia de un año, con penalidad si te vas antes. Se siente parecido —en ambos casos "cuesta irse"— pero son dos cosas completamente distintas. Los diez hilos son un costo que tú construiste, sin que nadie te obligara, simplemente usando el servicio con el tiempo — y por eso no desaparecen nunca por sí solos. El contrato es una cerca que el banco construyó y te hizo firmar — y el día que el contrato vence, la cerca desaparece, aunque los diez hilos de tu vida real jamás se hayan tocado. Esa diferencia —hilos que tejiste tú, contra una cerca que te impusieron— es exactamente la que separa los tres niveles de profundidad que el modelo mide.

Ejemplo trabajado: tres profundidades, tres vendedores de Mercado

Reutilizamos moatScore sin cambios y lo corremos sobre tres switching costs reales de Mercado, uno por cada profundidad que el modelo reconoce. sellerAnnualContract es un vendedor que firmó un contrato de exclusividad de doce meses con Mercado, con penalidad si se va antes — profundidad contractual. buyerSavedPreferences es un comprador que tiene métodos de pago guardados, direcciones de envío, una lista de deseos y recomendaciones ya calibradas a su historial — profundidad habit: nada se lo impide, pero rehacer todo eso en otra plataforma da pereza. sellerDashboardWorkflow es un vendedor que corre toda su operación diaria a través del panel de Mercado: sincroniza inventario, procesa pedidos, exporta la contabilidad — profundidad dataAndWorkflow: irse no es "registrarse en otro lado", es re-cablear su negocio entero.

// Modelo pedagogico: puntua la DURABILIDAD (0-10) de una ventaja competitiva.
// Reutilizado sin cambios desde la leccion 2 -- esta leccion profundiza en
// los tres niveles de 'depth' del tipo switchingCost.
function moatScore(advantage) {
  const { name, type } = advantage;
  let durability;
  let rationale;

  switch (type) {
    case 'networkEffect': {
      const { sides, localDecay } = advantage;
      durability = sides >= 2 ? 8 : 5;
      if (localDecay) durability -= 3;
      rationale = `network effect ${sides}-sided${localDecay ? ', con decay local' : ', sin decay'}`;
      break;
    }
    case 'switchingCost': {
      const { depth } = advantage;
      const depthScore = { contractual: 3, habit: 5, dataAndWorkflow: 8 };
      durability = depthScore[depth] ?? 3;
      rationale = `switching cost de profundidad '${depth}'`;
      break;
    }
    case 'scaleEconomies': {
      const { fixedCostShare } = advantage;
      durability = Math.round(fixedCostShare * 10);
      rationale = `economias de escala con ${Math.round(fixedCostShare * 100)}% de costo fijo`;
      break;
    }
    case 'dataMoat': {
      const { feedbackLoop, uniqueToUs } = advantage;
      durability = feedbackLoop ? 7 : 2;
      if (feedbackLoop && uniqueToUs) durability += 2;
      rationale = feedbackLoop
        ? `los datos alimentan un loop que mejora el producto${uniqueToUs ? ' y son exclusivos' : ''}`
        : 'los datos se acumulan pero no retroalimentan el producto';
      break;
    }
    case 'brand': {
      const { pricingPower } = advantage;
      durability = pricingPower ? 6 : 2;
      rationale = pricingPower
        ? 'la marca cambia el comportamiento de compra (tolera precio o fricción)'
        : 'la marca es reconocida pero no cambia comportamiento de compra';
      break;
    }
    case 'feature': {
      const { timeToCopyWeekends } = advantage;
      durability = Math.max(0, Math.min(3, timeToCopyWeekends));
      rationale = `feature copiable en ~${timeToCopyWeekends} fin(es) de semana`;
      break;
    }
    default: {
      durability = 0;
      rationale = 'tipo de ventaja desconocido';
    }
  }

  durability = Math.max(0, Math.min(10, durability));
  const verdict = durability >= 7 ? 'moat' : durability >= 4 ? 'weak-moat' : 'not-a-moat';
  return { name, type, durability, verdict, rationale };
}

const candidates = [
  { name: 'sellerAnnualContract', type: 'switchingCost', depth: 'contractual' },
  { name: 'buyerSavedPreferences', type: 'switchingCost', depth: 'habit' },
  { name: 'sellerDashboardWorkflow', type: 'switchingCost', depth: 'dataAndWorkflow' },
];

console.log('=== Tres profundidades de switching cost, misma pregunta: ¿qué tan caro es irse? ===\n');
console.table(candidates.map(moatScore));

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== Tres profundidades de switching cost, misma pregunta: ¿qué tan caro es irse? ===

┌─────────┬───────────────────────────┬─────────────────┬────────────┬──────────────┬───────────────────────────────────────────────────┐
│ (index) │           name            │      type       │ durability │   verdict    │                     rationale                     │
├─────────┼───────────────────────────┼─────────────────┼────────────┼──────────────┼───────────────────────────────────────────────────┤
│    0    │  'sellerAnnualContract'   │ 'switchingCost' │     3      │ 'not-a-moat' │   "switching cost de profundidad 'contractual'"   │
│    1    │  'buyerSavedPreferences'  │ 'switchingCost' │     5      │ 'weak-moat'  │      "switching cost de profundidad 'habit'"      │
│    2    │ 'sellerDashboardWorkflow' │ 'switchingCost' │     8      │    'moat'    │ "switching cost de profundidad 'dataAndWorkflow'" │
└─────────┴───────────────────────────┴─────────────────┴────────────┴──────────────┴───────────────────────────────────────────────────┘

Fíjate en el resultado que más sorprende a quien ve esto por primera vez: sellerAnnualContract —un contrato firmado, con penalidad legal si el vendedor se va antes de tiempo, la clase de cosa que en una reunión sonaría como "los tenemos amarrados"— saca durability: 3 y 'not-a-moat'. Ni siquiera llega al umbral de 'weak-moat' (4). El contrato se siente como el switching cost más fuerte de los tres, porque es explícito, firmado, legal — pero el modelo lo puntúa como el más débil, y la razón está en la analogía: un contrato es una cerca que Mercado construyó, no un hilo que el vendedor tejió usando el producto. El día que el contrato vence, la cerca desaparece completa — y si durante ese año Mercado no le dio al vendedor ninguna razón real para quedarse (el panel operativo de sellerDashboardWorkflow, por ejemplo), lo más probable es que se vaya apenas pueda, con más resentimiento que lealtad por haber estado atado contra su voluntad.

Profundización: earned vs. imposed — el switching cost que se gana, y el que se impone

La distinción central de esta lección no es solo "cuánto duele irse" — es de dónde viene ese dolor. Un switching cost dataAndWorkflow es earned (ganado): existe porque Mercado le dio tanto valor real al vendedor —herramientas que de verdad usa todos los días, en las que invirtió tiempo configurando— que desconectarse cuesta, y ese costo es un subproducto honesto de haber sido útil. Un switching cost contractual es, en cambio, imposed (impuesto): existe porque Mercado escribió una cláusula, no porque el vendedor haya construido nada encima del producto. La diferencia importa por dos razones prácticas, no solo filosóficas.

La primera: los switching costs impuestos tienen fecha de caducidad y, casi siempre, mala fama — algunas jurisdicciones limitan por ley cuánto puede durar una cláusula de exclusividad, y un vendedor que se siente "atrapado" por contrato, no por valor, es un vendedor que habla mal de la plataforma mientras espera que el contrato termine. La segunda, más incómoda para cualquier equipo que confía demasiado en este tipo: un switching cost fuerte —sobre todo el impuesto— puede convertirse en un riesgo moral. Si el equipo sabe que el vendedor no se puede ir este año, la tentación de dejar de invertir en mejorar su experiencia —"total, no se puede ir"— es real, y esa complacencia es exactamente lo que un vendedor atrapado por contrato, no por valor, va a recordar el día que el contrato expire. Un moat ganado, dataAndWorkflow, no tiene ese riesgo: si Mercado deja de invertir en el panel del vendedor, el switching cost se erosiona solo, con el tiempo, porque deja de dar el valor que lo sostenía — el incentivo de seguir invirtiendo está incorporado en la mecánica misma del moat, no hace falta un contrato para forzarlo.

Errores comunes

Confiar en el contrato como si fuera la ventaja más fuerte. Qué pasa: el equipo de ventas negocia contratos de exclusividad de doce meses con los vendedores más grandes y lo reporta como "nuestro moat con las cuentas clave", sin construir nada adicional que haga que esos vendedores quieran quedarse cuando el contrato termine. Por qué pasa: un contrato firmado se siente concreto y medible —hay una fecha, una cláusula, una firma—, mientras que un switching cost dataAndWorkflow se construye poco a poco y es menos fácil de señalar en una diapositiva. Cómo detectarlo: pregunta "¿qué le queda a este vendedor el día después de que el contrato expire, además del recuerdo de haber estado atado?" — si la respuesta es "nada", el durability real es 3, no lo que dice el contrato. Cómo corregirlo: usa el contrato, si acaso, como un puente temporal mientras se construye el switching cost real —integración profunda, herramientas indispensables—, nunca como el moat en sí mismo.

Confundir hábito con lock-in permanente. Qué pasa: el equipo observa que los compradores "siempre han usado Mercado" y concluye que ese hábito es un moat sólido, sin poner a prueba qué tan fácil sería que un competidor con un incentivo real —un descuento agresivo, una campaña bien dirigida— rompiera ese hábito. Por qué pasa: el hábito se siente estable porque no requiere ningún esfuerzo activo de Mercado para sostenerse día a día, y esa estabilidad aparente se confunde con durabilidad real. Cómo detectarlo: habit puntúa 5, apenas por encima del umbral de 'weak-moat' — si el equipo lo está tratando como un 'moat' completo (≥7) en sus decisiones, hay una sobreestimación activa. Cómo corregirlo: trata cualquier switching cost de tipo habit como una ventaja real pero frágil frente a un incentivo suficientemente grande — y busca profundizarlo hacia dataAndWorkflow (el tema exacto de la lección 7) en vez de conformarte con la inercia.

No invertir en profundizar la integración que ya existe. Qué pasa: Mercado ya tiene vendedores usando el panel operativo a diario —la base de un switching cost dataAndWorkflow—, pero el equipo de producto no prioriza las features que profundizarían esa integración —exportación de contabilidad, sincronización automática de inventario con el punto de venta físico del vendedor—, dejando el moat a medio construir en el nivel habit. Por qué pasa: profundizar una integración existente no se siente tan urgente como lanzar una feature nueva y visible, aunque el impacto en durabilidad sea mucho mayor. Cómo detectarlo: si el roadmap prioriza constantemente features nuevas frente a profundizar las herramientas que los vendedores más grandes ya usan todos los días, la oportunidad de subir de habit a dataAndWorkflow se está dejando pasar. Cómo corregirlo: la lección 7 formaliza esto — la profundidad de una integración es, literalmente, una decisión de arquitectura que el equipo de ingeniería controla, y moverla de habit a dataAndWorkflow cambia el durability de 5 a 8.

Ejercicios

Ejercicio 1 — Clasifica la profundidad. Para cada situación, decide si el switching cost es contractual, habit o dataAndWorkflow, y justifica en una frase: (a) un comprador tiene guardada su talla de ropa y sus marcas favoritas, calibradas con meses de compras; (b) un vendedor exporta cada semana un reporte de ventas de Mercado directo a su sistema de contabilidad, de forma automática; (c) un vendedor firmó que no venderá en ninguna otra plataforma durante seis meses, a cambio de una comisión más baja.

Ver solución

• (a) habit. Es información útil, acumulada con el tiempo, que le ahorra esfuerzo al comprador — pero no está integrada a ningún sistema externo del comprador, y rehacerla en otra plataforma es tedioso, no estructuralmente costoso.
• (b) dataAndWorkflow. El reporte automático está conectado a un sistema externo real (la contabilidad del vendedor) — desconectarse de Mercado rompe un proceso operativo que el vendedor depende para llevar su negocio, no solo una preferencia guardada.
• (c) contractual. Es una cláusula impuesta con fecha de vencimiento, no un hilo tejido por el uso del producto — el día que el contrato termine, el vendedor puede irse sin ningún costo estructural adicional.

Ejercicio 2 — Predice antes de ejecutar. Sin correr código, con la fórmula de switchingCost de esta lección (depthScore = { contractual: 3, habit: 5, dataAndWorkflow: 8 }), predice la durability y el verdict de esta ventaja: { name: 'unknownIntegration', type: 'switchingCost', depth: 'apiOnly' } — nota que 'apiOnly' no es ninguna de las tres claves del objeto depthScore. Luego verifica corriendo moatScore sobre ese objeto.

Ver solución

depthScore['apiOnly'] no existe en el objeto, así que el operador ?? de la fórmula (depthScore[depth] ?? 3) cae al valor por defecto: durability = 3, el mismo nivel que contractual, con verdict: 'not-a-moat'. Esto no es un accidente del código — es una decisión de diseño del modelo: cualquier profundidad de switching cost que no se pueda clasificar explícitamente en una de las tres categorías reconocidas se trata, por defecto, como la más débil. La lección práctica: si no puedes nombrar con precisión qué tipo de switching cost tienes, probablemente no es más fuerte que un contrato — y moatScore te lo recuerda con la misma cifra.

Ejercicio 3 — El riesgo moral del contrato. Describe, en dos o tres frases, un escenario hipotético donde un equipo de Mercado, confiado en que un vendedor está atado por contrato durante un año, deja de invertir en mejorar su experiencia en el panel de vendedores. Explica, usando el vocabulario de "profundización" de esta lección, qué le pasa al durability real de ese vendedor el día que el contrato termina.

Ver solución

No hay una única respuesta correcta — el ejercicio evalúa el razonamiento. Un ejemplo razonable: el equipo de producto, viendo que sus veinte vendedores más grandes tienen contrato de exclusividad por un año, decide priorizar otras features y posterga durante meses las mejoras al panel operativo que esos mismos vendedores llevaban pidiendo. Durante el año del contrato, durability en el papel sigue siendo 3 (el contrato), pero el vendedor no construyó ningún hilo adicional de tipo habit o dataAndWorkflow con la plataforma — su relación real con Mercado nunca se profundizó. El día que el contrato vence, no hay ninguna capa debajo que lo sostenga: durability cae a lo que siempre fue, cero switching cost real, y el vendedor —que además pasó un año sintiéndose atado, no cortejado— tiene un motivo adicional para irse con el primer competidor que le ofrezca algo mejor.

Resumen y siguiente paso

En esta lección abriste el segundo tipo de moat: el switching cost, la fricción de irse, no la dificultad de llegar. Viste los tres niveles de profundidad que el modelo reconoce —contractual, el más débil porque es impuesto y caduca; habit, moderado porque es real pero se rompe con un incentivo suficiente; dataAndWorkflow, el más fuerte porque el usuario tejió ese hilo él mismo, usando el producto con el tiempo— y por qué esa jerarquía, contraintuitiva a primera vista, tiene una lógica sólida detrás: earned vale más que imposed.

Antes de avanzar deberías poder: clasificar cualquier switching cost nuevo en una de las tres profundidades, explicar por qué un contrato firmado puntúa más bajo que un hábito de uso, y nombrar el riesgo moral de confiar demasiado en un switching cost impuesto.

La lección 5 abre los dos tipos que quedan antes de llegar al control del modelo: los moats de datos —que solo cuentan si retroalimentan el producto— y de escala — donde más grande, de verdad, puede significar más barato.

Recursos

• Hamilton Helmer, 7 Powers: The Foundations of Business Strategy — 7powers.com. "Switching costs" es, textualmente, una de las siete fuentes de poder del libro — la misma distinción entre una ventaja earned y una impuesta que esta lección desarrolló con el ejemplo del contrato. En inglés.
• Investopedia, "Economic Moat" — investopedia.com/terms/e/economicmoat.asp. Los costos de cambio están entre los tipos de moat económico que Morningstar usa para calificar empresas — la misma taxonomía, con otro vocabulario, que el módulo entero está recorriendo tipo por tipo. En inglés.