Qué es el vendor lock-in

Se denomina vendor lock-in a una serie de restricciones que hacen que a los clientes les suponga un riesgo cambiar de un proveedor a otro.

Como todo se entiende mejor con un ejemplo, cuando un cliente quiere migrar desde MailChimp a Acumbamail, tiene una serie de problemas que pueden ser más o menos difíciles de solventar. Por ejemplo tiene que traspasar su base de datos –sencillo– o por ejemplo tiene que traspasar sus plantillas –mucho más complicado– que no están en un formato abierto si no en uno cerrado. Esto podría considerarse una técnica de Vender Lock-in.

Es una técnica cuya ética es bastante cuestionable, pero desde luego es uno de los moats más relevantes que existen en el software. Hoy vamos a hablar de ello, sobre cómo aumentar la recurrencia en nuestro negocio utilizándolo y sobre cómo protegernos contra él cuando somos clientes.

Tipos de vendor lock-in

• Legales: contratos, penalizaciones, cláusulas de permanencia y demás restricciones legales que penalizan el cambio.
• Técnicos: integraciones o conexiones con APIs que obligan a realizar un esfuerzo técnico para realizar la migración.
• Financieros: contratos con descuentos y condiciones pago difíciles de conseguir para nuevos clientes en otros proveedores.
• De datos: el almacenamiento de datos es uno de los pilares del vendor lock-in. Las migraciones nunca son tan sencillas como pensamos.

Algunos ejemplos de cómo se aplica esta técnica

• Un clásico del vendor lock-in, cada vez menos frecuente en las empresas pequeñas y medianas, son los costes de implementación. Todavía en el segmento enterprise se cobran comisiones de implantación y se añaden penalizaciones de cancelación a los contratos que crean un gran coste inicial, que hace que quien lo paga se lo piense mucho antes de cambiar de proveedor.
• Otra situación muy habitual es la limitación del acceso a los datos. Cuando se cancela una cuenta de un cliente, se eliminan los datos que contiene, con la consiguiente pérdida para el usuario. Generalmente se suele ofrecer la posibilidad de exportar los datos, pero la importación en otra plataforma no suele ser sencilla ni directa. Incluso hay empresas que viven únicamente de estas migraciones de datos.
• Integraciones directas: cualquier cosa que esté directamente integrada con tu producto, es difícil de sustituir. Widgets o APIs son buenos ejemplos. Cuanto más profunda sea la integración, más trabajo llevará sustituirla.
• Los productos all-in-one son muy complicados de sustituir. Si una empresa está ligada a un único proveedor para muchas necesidades. Un ejemplo puede ser cuando un cliente utiliza HubSpot para sus landing pages, CRM, email marketing y gestión de anuncios; su dependencia de HubSpot provocará que tenga muy poca capacidad de negociar precios o de migrar servicios a un proveedor mejor.
• Data gravity. Se llama así a la tendencia que tenemos de utilizar los mismos almacenes de datos para todo, en lugar de tener bases de datos diferentes con propósitos diferentes. Imagina una empresa comienza a utilizar Snowflake como sistema de base de datos para tu analítica. Los desarrolladores descubren que es un buen sistema y poco a poco van aumentando las cosas que almacenan en él. Cuando ya tiene varios departamentos utilizando la base de datos, aunque Snowflake decida multiplicar el precio por dos, va a ser muy difícil –y costoso– tomar la decisión de cambiar a otro proveedor.
• Formatos propietarios: muchos proveedores de SaaS utilizan los formatos propietarios para almacenar los datos. Es mucho más sencillo para el proveedor, ya que no tiene que adaptarse a un estándar, pero es un dolor tremendo a la hora de migrar.

Cómo evitarlo como cliente

Todos somos clientes de muchos SaaS y, aunque nos gustaría aprovecharnos del vendor lock-in como proveedor, no queremos sufrirlo como clientes. Algunas ideas para conseguirlo:

• Intentar no firmar permanencias, setup fees y demás formatos legales que requieran adelantar pasta. Esto hará que tengamos más flexibilidad a la hora de poder enfrentarnos a los cambios.
• Trata de realizar integraciones a través de integradores como Zapier o Integromat. Aunque dependerás de ellos, al menos podrás cambiar el resto de proveedores con facilidad.
• Estrategia de backup de los datos. Hay negocios que mandan los datos a varios proveedores diferentes. Por ejemplo utilizan Amplitude para sus analíticas pero conservan una copia de los datos en una alternativa open source como podría ser Matomo, por si llega el día en el que las condiciones de Amplitude no le seducen.
• Además de los Backups, hay que intentar que los datos sean lo más exportables e importables posible. Intentar utilizar proveedores con formatos abiertos y evitar los formatos propietarios.
• Si queremos renegociar un contrato con proveedor, empezar haciéndolo con suficiente antelación, para tener tiempo para buscar alternativas.

¿Es ético el vendor lock-in?

Habrá ciertas características inherentes a tu producto que harán que migrar sea complicado. Cualquier cambio de proveedor tiene fricción y es normal que esto sea así. Pero forzar con contratos eternos o secuestrar los datos de los usuarios son técnicas evitables y que yo creo que a la larga generan más desencanto que adherencia.

Cuando una empresa nos obliga a firmar un contrato con unas condiciones injustas o secuestra nuestros datos para que sigamos siendo clientes, lo que va a conseguir es que desaparezcamos de ahí en cuanto tengamos la oportunidad. A pesar de que va a facturarnos algo más, el coste va a ser mucho más alto que el beneficio.