a16z última entrevista: SaaS todavía no ha muerto, la mayor barrera para la implementación de la IA ya no es la inteligencia del modelo

Ante el extremo pánico en el mercado abierto respecto a que “la IA destruye el SaaS”, el socio de a16z Alex Rampell opina que esta preocupación surge de un pensamiento estático desconectado de la realidad, las verdaderas operaciones comerciales centrales que ya incorporan la gestión de situaciones reales no desaparecerán, sino que experimentarán un auge en flujo de caja.

El 6 de marzo, la reconocida firma de inversión a16z y el CEO de Atlassian, Mike, sostuvieron una profunda conversación sobre la narrativa de la “gran catástrofe del SaaS” que domina actualmente el mercado.

Los asistentes consideran que, la actual ola de pánico está algo desconectada de la realidad; la IA no es el fin del SaaS, sino un catalizador para una mayor diferenciación en la industria; la competencia futura en software no solo dependerá de las capacidades del modelo, sino también de las barreras en la lógica de negocio y de la psicología de precios.

Gran polarización en las valoraciones del SaaS: ¿quién llegará a cero y quién experimentará un auge en flujo de caja?

Actualmente, los inversores en el mercado público tienden a agrupar todas las empresas de software, pero en realidad, el impacto de la IA en diferentes categorías de SaaS varía radicalmente. Alex señala que las empresas de SaaS pueden dividirse en aproximadamente tres tipos, y el mercado no distingue sus capacidades.

La primera categoría son empresas extremadamente peligrosas, como Zendesk, que dependen mucho de cuentas y resultados vinculados. Alex dice:

“Zendesk es aquí el ‘paciente número uno’. Si los clientes de Zendesk ahora usan Sierra, Decagon o optan por soluciones internas, la cantidad de cuentas que necesitan puede ser cero.”

Para estas empresas, si no cambian a una estrategia de precios basada en resultados y no transforman radicalmente su modelo actual, “esa fuente de ingresos se reducirá a cero”.

La segunda categoría comprende sistemas de negocio núcleo con barreras muy fuertes, como Workday. Aunque también cobran por cuentas, esto es solo una “estrategia de precios inteligente”, y su verdadera barrera competitiva radica en reglas implícitas de décadas y en “casos límite (Edge cases)”. Alex enfatiza:

“Muchas softwares en realidad son un conjunto de reglas determinísticas aprendidas durante décadas… ¿qué pasa si un empleado en Indiana se va y en ese momento está en licencia de maternidad? A menos que lo hayas vivido, no tienes idea de esas situaciones límite.”

Para estos sistemas profundamente integrados en la estructura empresarial, la IA no solo no los eliminará, sino que les aportará un valor incremental enorme.

“Los sistemas de negocio verdaderamente centrales, con alta retención, en los que la gente confía y que ya incorporan todos los casos límite, tendrán un gran futuro… cuando esto realmente ocurra, el flujo de caja futuro crecerá sustancialmente, y eso me sorprende.”

La tercera categoría son productos en estado intermedio, como Adobe. La era de la IA reducirá la demanda de estos productos, pero no en extremos como Zendesk ni en total como Workday. El impacto será intermedio.

¿Por qué a los clientes no les gusta pagar “por resultados y tokens”?

Con la expansión de la IA, las aplicaciones front-end y las bases de datos back-end se están separando gradualmente, y los modelos de precios de software enfrentan desafíos severos. Aunque hay un fuerte impulso hacia “pago por consumo (Tokens/puntos)” o “pago por resultados”, en la práctica hay muchas resistencias.

Mike señala con precisión la resistencia de los clientes:

“Cuando hablas con ellos, descubres que realmente odian ese método, les molesta mucho que haya cláusulas con asteriscos.”

Explica que, la facturación tradicional en almacenamiento en la nube es controlable, pero en el mundo de los Tokens de IA, para los clientes es una caja negra.

“Los clientes sienten que no entienden qué son esos tokens o fichas que les das… puedo hacer que el consumo de sus límites se multiplique por diez de la noche a la mañana, solo agregando funciones como resúmenes geniales. Y sienten que no les pedí eso.”

Además, pagar por resultados (como reducir costos) en el primer año funciona como argumento de venta, pero en el segundo año, los clientes consideran que la base de comparación ya bajó, y les resulta difícil seguir midiendo el valor incremental que aporta la IA. Por ello, Mike concluye:

“Cuando hablas con los clientes, ellos todavía prefieren pagar por cuenta (seats). Esto puede ser porque ahora entienden mejor ese modelo y han sido perjudicados por muchas tarifas por uso que hacen que la factura se dispare sin control.”

Vibe Coding no puede reemplazar los procesos centrales

En el mundo tecnológico, existe una corriente llamada “teoría de sustitución”, que sostiene que mediante la programación con IA (Vibe Coding), las empresas pueden escribir código para reemplazar todas las herramientas SaaS tradicionales. Pero Mike afirma que esa idea no es realista.

Mike dice que el núcleo de las empresas de conocimiento radica en coordinar miles de procesos con restricciones en entradas (como aprobaciones legales, de atención al cliente) y salidas (como desarrollo, marketing creativo).

“Personalmente, odio el término ‘sistema de negocio central’, porque suena como una base de datos estática… para mí, el negocio es un sistema basado en procesos, no solo un sistema de registros.”

El cambio real que trae la programación con IA no es que las empresas vuelvan a escribir un Workday desde cero, sino que puedan construir aplicaciones altamente personalizadas sobre estos gigantes del sistema base a costos muy bajos. Mike explica:

“Por ejemplo, quiero una app de reserva de salas para el equipo de Miami… antes no podía, pero ahora quizás sí. Esa app usa los datos y reglas de Workday en todo el mundo en su núcleo.”

Esto hace que los gigantes del SaaS en el nivel base sean “más adhesivos y valiosos en el mercado empresarial”.

El último kilómetro de la implementación de IA: no es la inteligencia del modelo, sino el diseño de confianza

Al explorar el espacio de productos futuros, la entrevista revela que antes de que el software con IA genere ingresos reales, debe superar un gran obstáculo en la experiencia del usuario. La capacidad del modelo ya supera con mucho el valor entregado, pero el cuello de botella está en el diseño UI/UX y en la confianza que genera en las personas.

Mike señala que, al introducir agentes (inteligencias) en flujos complejos de aprobación, el mayor reto no es la potencia del hardware, sino cómo eliminar la sensación de caja negra. Si la IA procesa de golpe una docena de correos, la reacción instintiva del usuario será de pánico, no de gratitud.

“Prometer ciegamente ‘puedo hacer cualquier cosa por ti’ solo genera confusión en el usuario.”

El futuro de la interacción en software está en la evolución de “skeuomorphic” hacia los principios fundamentales. Por ejemplo, en el flujo de documentos, la edición tradicional de texto y formato está siendo reemplazada por un modo de colaboración en IA donde “el lado izquierdo es la entidad del documento y el derecho, la ventana de chat”.

Aunque cambiar décadas de hábitos de usuario es un gran reto, esto no solo representa un cambio de paradigma en el diseño de productos, sino también un camino inevitable para que las empresas SaaS conviertan el potencial de la IA en ingresos por suscripción reales. Como dice Mike:

“La realidad es que no todas las empresas SaaS prosperarán en los próximos diez años… pero para nosotros, esto es lo mejor que nos ha pasado en el negocio.”

El texto completo de la entrevista está a continuación:

Alex: Desde 1960 hasta 2022, toda la historia del software es convertir archivos en bases de datos. El primer ejemplo fue en 1960, cuando IBM y American Airlines desarrollaron el sistema SABRE. Reemplazó los sistemas de reservas en papel gestionados por secretarias, almacenando esos datos en las primeras bases de datos. En esa época, un disco duro de 10MB podía costar millones de dólares. Lo mismo ocurrió con los registros electrónicos de salud, como el sistema MUMPS desarrollado por Mass General. Igualmente, Salesforce y la primera CRM en 1987 son esencialmente archivos convertidos en bases de datos.

Esto tiene ventajas, pero no hizo el mundo mucho más eficiente. Antes, para encontrar información de Eric, alguien tenía que ir a la oficina de recursos humanos y buscar en los archivos físicos. Ahora, aunque los datos están en Workday, hay que tener un CISO para proteger el sistema, y configurar cuentas en un sistema de inicio de sesión único (seats). La eficiencia solo se nota en colaboración entre regiones, donde la gente puede trabajar en conjunto y realizar consultas complejas en bases de datos, algo muy difícil en la era de los documentos en papel. Pero en esencia, desde 1960 hasta 2022, el software sigue siendo estático, porque los archivos no piensan.

Lo más genial en IA ahora es que los archivos pueden hacer trabajo por sí mismos. Por ejemplo, QuickBooks ahora puede completar tareas de forma independiente, sin depender solo de que humanos busquen archivos en el sistema, como si se dijera adiós a la era del archivo físico del siglo XVI, muy interesante.

Erik: Es un excelente punto de partida. Todos hablan ahora de “el fin del SaaS” o “la gran catástrofe del SaaS”, claramente refiriéndose a lo que pasa en el mercado abierto. Muchos tienen diferentes opiniones sobre su significado. Quiero escuchar cómo interpretan ustedes qué está ocurriendo y por qué todos están tan asustados.

Mike: Creo que todo el mundo está tratando de entender cómo valorar o calificar los negocios de software en esta fase de disrupción extrema. Cada uno tiene su visión aguda del futuro. Hay dos extremos: para toda la industria del software, o ciertos tipos de empresas o categorías, el futuro será muy bueno o muy malo. Sin duda, el nivel de riesgo ya ha subido.

Desde la perspectiva de inversión, el SaaS solía ser muy estable, pero ahora, con mayor riesgo, la gente prefiere esperar y observar. Como suelo decir, los inversores no solo descuentan los beneficios históricos con modelos de flujo de caja, sino que también especulan sobre lo que otros harán, o apuestan a cómo será el futuro visto por otros.

La actual ola de pánico está algo desconectada de la realidad. La gente piensa: “¿Qué pasa si en dos o tres años la IA logra tal cosa?” Creo que esa preocupación surge de un pensamiento muy estático, como si nada cambiara, como si solo la IA evoluciona y todo lo demás permaneciera igual. La situación es interesante: empresas como la nuestra siguen rindiendo bien, con tres trimestres consecutivos de excelentes resultados. Aunque no estamos defendiendo a toda la industria del software, en nuestro negocio estamos muy optimistas, y los datos y resultados lo demuestran.

Por supuesto, esto no significa que no debamos adaptarnos. Estamos cambiando nuestra forma de trabajar, rápida y radicalmente, como en los últimos años. Muchos piensan que no podemos cambiar, pero eso no es cierto, aunque hay muchas variables estratégicas en el camino. La realidad es que no todas las empresas SaaS prosperarán en los próximos diez años. Como en la transición de Windows a internet, muchas no lograron la transformación en la nube. No todos podrán seguir creciendo. Algunos creen que el software en cierto modo desaparecerá o solo será una fuente de ingresos en efectivo. Pero puedo decir que eso sería lo mejor que nos ha pasado. Estamos en un mundo de conocimiento, con herramientas para explorar y actuar con conocimiento, para cumplir tareas que los clientes nos contratan para resolver. Es una lógica perfecta, pero hay que demostrarlo en la práctica, y que el mercado tenga paciencia no es fácil.

Erik: Alex, ¿qué opinas? ¿Cómo interpretas lo que está ocurriendo?

Alex: Espero que mi juicio a largo plazo sea correcto, porque lo que pasa ahora es muy loco. Hace unas semanas publiqué un tuit sobre esto, y observé que en el mercado hay aproximadamente tres tipos diferentes de SaaS, pero el mercado no los distingue. Uno de ellos tiene cuentas vinculadas a resultados, donde las cuentas (seats) corresponden a quienes usan realmente el sistema, como en el ejemplo del archivo.

Antes de profundizar, quiero responderte con una anécdota. Dan Ariely escribió un libro genial, “Las trampas del deseo”, que solía compartir con los gerentes de producto para entender cómo cobrar a los usuarios. Un ejemplo clásico: a medianoche, te quedas fuera de tu apartamento y llamas a un cerrajero. Llega en un minuto, en 30 segundos abre la puerta y te cobra 500 dólares. Tú piensas: “¿Solo 90 segundos y me cobra eso?” y de inmediato dejas una reseña de una estrella, sin propina, y quizás intentas revertir el cargo con la tarjeta.

Ahora imagina otro escenario paralelo: el cerrajero tarda 9 horas en abrirte, vuelve a la oficina por más herramientas, trabaja hasta las 9:30 de la mañana y finalmente te deja entrar. Entonces, te sentirás agradecido, le das una propina de 200 dólares y le dejas una reseña de cinco estrellas.

Este ejemplo muestra que, en cierto modo, las personas están dispuestas a pagar por la incompetencia. Muchas estrategias de precios dependen de la percepción de justicia. Creemos que pagar más a quien trabaja toda la noche es justo, aunque no sea competente; y en cambio, nos enojamos con quienes cobran mucho, aunque sean muy capaces. Es ilógico, pero emocionalmente parece justo.

Si recordamos cómo evolucionamos hacia el modelo SaaS, con pagos mensuales por cuenta, cuando el costo de digitalizar era casi cero, la gente pensaba que eso era justo. Por ejemplo, si tienes 500 cuentas, pagarás más que con una sola, aunque el mecanismo subyacente sea similar.

Por eso, creo que las empresas SaaS se pueden dividir en tres categorías. La primera son las que ya no necesitan cuentas (seats) para producir ciertos resultados. Zendesk es aquí el “paciente número uno”. Si sus clientes usan Sierra, Decagon o soluciones internas, la cantidad de cuentas puede ser cero. Para Zendesk, esto significa el valor presente del flujo de caja futuro. Están en peligro, porque si solo cobran por producto actual, sin cambiar precios ni código, esa fuente se reducirá a cero. Pero si cambian a precios basados en resultados y dejan el modelo actual, sus ingresos podrían triplicarse o cuadruplicarse. Todo depende de la justicia y la percepción de lo justo, que puede ser irracional. La trayectoria por defecto de Zendesk es hacia cero, a menos que cambien.

La segunda categoría son empresas que cobran por cuenta (seats), lo cual parece justo, pero esas cuentas no están vinculadas a resultados específicos. Por ejemplo, Workday cobra por empleado, sin saber exactamente qué resultado produce. ¿Por qué? Porque parece justo. Pero en realidad, los empleados de GE no usan Workday para producir resultados. Lo que sí puede hacer AI es llamar a las empresas para verificar antecedentes, por ejemplo, en procesos de reclutamiento, y eso sí está en el núcleo del sistema. Aunque la industria de TI ha bajado un 45%, nadie abandona QuickBooks. Estas dos categorías —pago por cuenta y vinculación a resultados— son estrategias inteligentes de precios.

La tercera categoría son productos en estado intermedio, como Adobe. La cantidad de cuentas (seats) puede variar, pero no en extremos como Zendesk ni en total como Workday.

Además, existe una corriente que cree que con IA se puede programar todo, pero como desarrollador, creo que eso es absurdo. Recordemos la teoría de ventaja comparativa de David Ricardo (1817). Por ejemplo, puedes cultivar o soldar aluminio, pero incluso en estos casos simples, no es correcto. Es como si en un podcast, yo tengo ventaja comparativa en grabar, y aunque sea más productivo que un plomero, debería dedicarme a eso.

Lo más importante son las situaciones límite ocultas. Teóricamente, puedo usar IA para automatizar procesos en Workday, pero si un empleado en Indiana se va y está en licencia de maternidad, ¿cómo lo gestiono si no lo he vivido? Muchas reglas están aprendidas y no son públicas, y no se pueden copiar directamente, solo por experiencia. Si la tarea es simple y sin casos límite, la IA puede hacerlo.

Pero creo que los sistemas de negocio verdaderamente centrales, con alta retención, que la gente confía y que ya incorporan todos los casos límite, tendrán un gran futuro. Podrán agregar funciones que la IA haga automáticamente, como verificar antecedentes o gestionar cobros atrasados. No necesitas contratar personal, solo software. Cuando eso ocurra, el flujo de caja crecerá mucho, y eso me sorprende.

Muchos inversores en mercado público no distinguen estas categorías, están muy entusiasmados con la IA, pero no entienden que para desplegarla en sistemas centrales, hay que tener software que sea núcleo del negocio. Creo que ahora es un momento para volver a los principios básicos del negocio.

Mike: Personalmente, odio el término “sistema de negocio central”, porque suena como una base de datos estática, como un archivo. Esa visión de negocio como un archivo es muy industrial, muy del siglo pasado, y no tiene que ver con la economía del conocimiento. Entiendo el término, pero parece que todavía usamos iconos de disquete, que ya nadie conoce, y eso no tiene sentido. Para mí, el negocio es un sistema basado en procesos, no solo en registros.

Alex: Totalmente de acuerdo. En las empresas hay procesos como verificaciones de antecedentes, y coordinar esos procesos de forma eficiente y económica es la esencia del negocio del conocimiento. En la era del conocimiento, tengo miles de empleados que trabajan con sus cerebros, y cuando se van, se llevan sus conocimientos. No tengo activos físicos, ni fábricas, ni archivos. Todo se trata de coordinar procesos, y eso es lo que la mayoría de las empresas modernas hacen.

¿Qué relación tiene esto con lo que dice Alex? Que es correcto. En nuestro negocio, hay diferentes tipos de procesos, que llamo de entrada limitada y de salida limitada. Por ejemplo, en atención al cliente de Zendesk, la entrada limitada es que los clientes hacen preguntas, y la velocidad de respuesta afecta eficiencia, costo, calidad. Si respondo 10 veces más rápido, no recibiré 10 veces más preguntas, porque el volumen es fijo. La clave es reducir preguntas o responder más rápido. Muchas empresas tienen procesos de entrada limitada.

Pongo el ejemplo de nuestro equipo legal, que no crea trabajo legal, sino que responde y gestiona. ¿Cuántos contratos de alquiler, NDA, contratos normales tenemos? Es un volumen fijo. Para hacer esa tarea, buscamos ser lo más eficientes posible, y eso es entrada limitada con proceso completo. Pero también hay procesos de salida limitada, como creatividad, marketing, desarrollo de software, tecnología. En esas áreas, en teoría, puedo hacer infinitas tareas.

Mi cuello de botella es la creatividad, o cuánto puedo imaginar y entregar valor. Ahí puedo ser más eficiente y producir más. No solo limitando la entrada, sino en esas áreas puedo hacer mucho más.

Mi limitación está en la imaginación y en cuánto puedo entregar a los clientes. Ahí está la verdadera productividad. La forma de mejorar y producir más no es limitar la entrada, sino ampliar la capacidad de salida.

Lo que pasa en Indiana, con procesos que dependen de reglas externas, como leyes y regulaciones, es correcto. En Indiana, tengo que seguir ciertos procedimientos, y esas reglas son la forma en que la empresa debe operar. La empresa es un conjunto de procesos. Desde cierto punto de vista, tenemos sistemas de registros y de ejecución. La forma real de operar de muchas empresas no es así, pero esa es la idea que tenemos.

Alex: Totalmente de acuerdo, es un marco muy bueno. Me gusta cómo Intuit, con TurboTax, hace que las reglas fiscales sean públicas y transparentes, y que puedan ser descargadas y entendidas. Pero en realidad, los casos límite publicados son raros.

Las empresas valen mucho, y muchas son de economía del conocimiento, cuyos activos se llevan en el ascensor cada noche, y tienen un valor central. Por ejemplo, ¿sigue siendo valiosa McKinsey sin empleados? Es una firma basada en conocimiento, no en activos físicos. Pero quizás tengan un manual interno muy secreto, que explique cómo operar, contratar, despedir y entregar resultados. No lo he visto, y por eso no puedo copiarlo, pero probablemente existe desde hace más de cien años.

¿Qué productos tienen las empresas no digitales ni de software? Son conocimientos acumulados durante siglos o décadas. En Japón, hay restaurantes que llevan abiertos desde 1587, y eso es un ejemplo de tradición y cultura acumulada, con recetas y técnicas. Aunque hacer fideos es más simple y con menos casos límite, también hay extremos: ¿qué pasa si se acaba la harina? ¿Cómo sobrevivieron en 1623 durante la hambruna de harina? Seguramente, tomaron medidas, y esas experiencias están en un libro secreto, no en lo público.

Mike: Eso es lo que hace tan fascinante a esto: nos obliga a repensar nuestro negocio. ¿Realmente Intuit te llena los impuestos? ¿O ya tiene un conocimiento tan profundo de la ley fiscal que es como una consultora? Su valor central es ayudarte a gestionar tus datos de vida, entenderte mejor, y hacerte las preguntas correctas. Desde esa perspectiva, ahora parecen más una firma de consultoría como McKinsey. Su habilidad especial es hacerte las preguntas correctas para llenar los formularios, no solo llenarlos.

Ahora, todas las empresas deben reevaluar sus procesos. Quizás tengo 50 procesos que creía únicos y clave, pero en realidad solo 20 lo son. Tengo que pensar cuáles son realmente únicos y cuáles no, porque antes no lo hacía así.

Alex: Es una cuestión de balance. ¿Vale la pena hacerlo todo a mano? Si usas herramientas de terceros, no es una línea roja, sino una variable independiente. ¿Debería usar Claude Code para programar? Si una empresa cobra demasiado por software y eso puede arruinar mi negocio, y puedo hacer el 99% con mi propio código, entonces sí, vale la pena. Pero si ese software cuesta solo un dólar al año, no tiene sentido programar.

Además, no todos los sistemas de registro tienen el mismo valor. Yo veo los sistemas de registro como unidades atómicas del negocio. Por ejemplo, un calendario es un sistema de registro de tiempo, un ERP es un sistema de inventario. Tengo diferentes sistemas de registro. Por ejemplo, en Miami, tengo una oficina que uso poco, con un sistema de reservas similar a Google Calendar. ¿Me interesa cambiar ese sistema? Claro, porque solo voy una vez al año, y no me importa si funciona bien.

En cambio, algunos sistemas afectan directamente mis ingresos, y no son caros. ¿Debería cultivar mi propia comida? Usando la metáfora agrícola, comer en un restaurante es mucho más barato. Si quiero una hamburguesa, no tiene sentido criar una vaca y alimentarla, por economía de escala y ventaja comparativa, es más barato en el restaurante.

Por eso, algunos sistemas de registro son más sensibles a los precios, solo porque su costo de almacenamiento o valor en contenido no es tan alto. Carta, por ejemplo, gestiona la estructura accionaria de muchas empresas. ¿Con qué frecuencia revisas esa estructura? Aunque no muy a menudo, es muy importante y no se puede fallar. Por eso, probablemente seguiré usando Carta, porque no cobran mucho y no es un producto de uso diario.

Mike: Me encanta la idea de Vibe Coding. Como alguien del mundo del software, parece que en el futuro se podrá reemplazar toda la programación tradicional solo con “programación por ambiente” (vibe code). Pero si programamos solo con ambiente y eso hace que funcione todo el día, sería muy peligroso. Necesitaríamos ingenieros muy inteligentes para respaldar, y en realidad, aún hay que hacer otras tareas importantes. Por eso, la tendencia de sustitución todavía no es completa.

Es innegable que, usando IA para programar, hemos mejorado mucho la escalabilidad del software. Muchas aplicaciones son altamente configurables y personalizables, y en nuestro caso, incluso escalables. Se puede crear fragmentos de aplicaciones en diferentes áreas, y muchos clientes ya lo hacen, aunque antes necesitaban un gran equipo técnico.

Ahora, con Vibe Code, pueden extender y personalizar aplicaciones para casos específicos. Por ejemplo, quiero una app de reservas para el equipo de Miami, que tenga que consultar Workday y otros sistemas en tiempo real. Antes, no podía, porque el costo era alto, pero ahora quizás sí. La app usa los datos y reglas de Workday globalmente, pero ofrece una interfaz muy personalizada para las necesidades específicas de Miami. Es muy potente, pero no reemplaza completamente a las personas.

En ese sentido, Workday, que a veces es objeto de bromas, en realidad es muy poderoso. Hace que en el mercado empresarial sea más adhesivo y valioso, porque permite construir aplicaciones personalizadas sobre él. Esa es la fuerza de IA, Vibe Coding y la creatividad: hacer que los sistemas base sean más ajustados a necesidades específicas.

Pero hay que tener mucho cuidado en equilibrar estabilidad, reglas y personalización. Por ejemplo, casos como openclaw muestran cómo crear apps muy personalizadas para individuos. La mayoría de quienes construyen esas apps no son desarrolladores, sino usuarios que hacen herramientas en Gmail o similares. Siguen usando Gmail, solo que con apps específicas para sus problemas. Algunos de estos proyectos pueden convertirse en empresas, pero la mayoría solo resuelve necesidades propias, y eso es muy poderoso.

Alex: Por eso me interesa la cuestión de la equidad en precios entre front-end y back-end. Por ejemplo, Salesforce cobra por licencia, y en nuestra empresa, quizás compramos 600 licencias para 600 empleados. Nunca he usado Salesforce, pero seguro la empresa paga por mí. A veces uso sus salidas, porque es nuestro sistema de registros. No quiero abusar, pero en realidad, soy parte de la base de datos, como un ID 422.

Cuando conecto con otra empresa, parece que estamos en otra base de datos, pero en realidad solo pagamos por la base de datos subyacente. En un mundo donde front-end y back-end se separan, esto es así. Creo que Workday tiene una estrategia de precios muy inteligente, que es justa y poderosa. Cuantos más empleados, más pagas. ¿Por qué? Porque la utilidad de GE es mayor que la de una empresa de 10 personas, y debería pagar más. Pero esa cantidad sigue siendo pequeña para ellos. Su precio está en un rango ideal, y nadie lo cuestiona. En el futuro, aumentarán sus ingresos por IA, pero su base de precios sigue siendo justa.

Sin embargo, para productos donde front-end y back-end ya están algo separados, no sé qué modelo de precios sería justo, ni qué pasará en el futuro. Si nadie compra, todos programan por su cuenta, y no hay competencia, los precios se mantendrán. Pero quizás en el futuro, las empresas construirán front-ends personalizados que leen datos directamente de la base, y eso puede presionar los precios.

Para mí, si front-end y back-end dejan de estar estrechamente ligados, serán más vulnerables y sensibles. Por ejemplo, QuickBooks, usado por pequeñas empresas, no tiene concepto de cuentas (seats), solo el dueño entra y usa. En ese caso, el front-end es casi el back-end. En cambio, en Salesforce, aunque nadie lo abandone, podrían reducir mucho las cuentas, porque el back-end sigue siendo esencial, y la demanda de front-end costoso disminuirá. No eliminarán el back-end, solo optimizarán el front-end.

Mike: La equidad en precios y la percepción del cliente son clave. La gente necesita entender por qué paga, y sentir que lo que paga tiene relación con su uso real. Una empresa con 10,000 empleados probablemente pague más que una de 10, y eso parece justo. La lógica es: pago por empleado en mi sistema de RRHH.

El núcleo de estos sistemas no es solo una base de datos, sino también un conjunto de procesos complejos, que en mi época llamábamos lógica de negocio. Esa lógica no es trivial, porque las empresas funcionan como un conjunto de procesos, y los gerentes quieren estandarizar y gestionar esas operaciones. Es para que diferentes equipos trabajen igual, puedan entender y seguir los resultados.

Como si tuviera fábricas de autos, y quisiera seguir el número de autos que entran y salen. La lógica de negocio en esas fábricas es una barrera y valor. En el modo tradicional, esas ventas son muy grandes, y los procesos de ventas son muy valiosos, y se paga por ello. Pero, ¿qué pasa con los equipos de ventas y colaboración? ¿Realmente necesitan esos procesos, o solo algunos?

Supongamos que Salesforce Sales Cloud tiene un servidor MCP, que no accede directamente a la base de datos, sino que gestiona procesos y reglas. La discusión ahora es si algunos vendedores en marketing o éxito del cliente necesitan esas reglas y controles pesados. Por ejemplo, si el sistema dice que en Japón solo se puede ofrecer X o Y, y eso requiere un cuenta (seats). La cuestión de si eso es justo o no, queda en otra discusión.

La dificultad está en cómo fijar precios. Cuando hablamos de precios por consumo o por uso, la fijación basada en resultados puede ser razonable en muchos casos, pero no será la norma en todo el industria SaaS.

La gente odia esas tarifas con cláusulas con asterisco, porque sienten que no reflejan su valor real. Por ejemplo, en Splunk, si duplico los logs, pago más. Es lógico, pero el volumen de logs lo decido yo, y puedo decidir cuánto registro. Puedo decir: “¿Por qué tantos logs? Es muy caro, ¿realmente los usas?” Es controlable, como en almacenamiento en S3. Puedo pagar 1GB o 2GB, y eso es controlable.

Pero muchas tarifas basadas en resultados o consumo son impredecibles para el cliente, y no se pueden intercambiar. Por eso, en el mundo de tokens de IA, los clientes sienten que no entienden qué son esos tokens o fichas. Pueden obtener 1GB de almacenamiento en AWS y desplegar en Azure, y saben cuánto cuesta. Pero cuando tienen tokens de IA, no saben cuánto valen, ni qué consumen exactamente. Los proveedores añaden funciones, y los clientes consumen esas funciones, pero no saben qué usan.

Esto no es que la empresa decida usar esas funciones, sino que los proveedores las añaden para mejorar el software, y eso pasa naturalmente. Puedo hacer que el consumo de tokens se multiplique en una noche solo agregando funciones como resúmenes. Y los clientes sienten que no pidieron eso.

Por eso, al hablar de precios por resultados, los clientes todavía prefieren pagar por cuenta (seats), porque ahora entienden mejor ese modelo y han sido perjudicados por tarifas por uso que hacen que la factura suba mucho y no puedan controlarlo.

Sí, hay que adaptarse. Esto aparecerá en muchas categorías. En Atlassian, tenemos modelos de precios basados en uso, o pago por demanda, y nos enfocamos en que, cuando el volumen se duplica, el valor y el costo también se dupliquen, y eso esté en control del cliente. Otros modelos no.

El precio basado en resultados también es dinámico. Por ejemplo, en atención al cliente, si ahorro costos, y antes gastaba 20, ahora gasto 10. Es un buen argumento en el primer año, pero en el segundo, el cliente dirá: “Solo gasté 10, quiero gastar 5”, y si el proveedor dice: “Si te saco, pagarás 20”, el cliente pensará: “Pero ahora solo gasto 10”. La capacidad de ahorrar cada año con resultados es difícil de medir, aunque elimino tareas tediosas.

Alex: Desde la perspectiva de ventas, también es así. Yo fundé dos empresas de pagos. Admiro mucho a Workday, y hablo mucho con mi equipo de ventas sobre ello, porque saben cuánto puede ganar GE. Dicen: “GE tiene 330,000 empleados, y quizás cobramos 5 dólares por empleado al mes, y así ganamos mucho.”

Si vendes un software así, escalar la fuerza de ventas es más fácil. Sabes que esa empresa pagará 3 millones de dólares. Cuando fundamos la empresa, firmamos con 1,800 empresas, y no sabíamos cuánto íbamos a ganar. Pero lo que realmente hizo que el negocio funcionara fue Casper, la marca de colchones. No podíamos predecirlo. Pensábamos que con clientes como Walmart, íbamos bien, pero fue Casper quien nos hizo crecer mucho.

Workday tiene esa predictibilidad bidireccional, que es predecible para los clientes que invierten, y también para el equipo gestor. Puedes enfocarte en cerrar clientes como GE, en lugar de pequeñas empresas, porque el tamaño importa. Pero en internet, la situación es muy loca: Stripe puede ganar más con una startup de 10 personas que con GE. En ese modelo, la predictibilidad es mayor.

Pero si usas precios basados en resultados o en consumo, aunque el consumo en sí no sea malo, si no sabes cuánto puede ganar una cuenta (seats), será muy difícil ampliar ventas y marketing.

Eric: Como emprendedor, quiero volver a lo que esto significa para ti y cómo ha cambiado tu negocio.

Mike: Creemos que vendemos herramientas para resolver problemas de colaboración humana. En muchas áreas, como servicios, negocios, recursos humanos, finanzas, desarrollo de software, diferentes equipos compran diferentes aplicaciones y combinaciones. En esencia, todo eso implica mucha colaboración en texto. Eso nos favorece. Lo que hacen esas personas es lo importante.

La tecnología suele transformar todo, y eso es el futuro. A largo plazo, suele ser correcto. Pero el reto es que muchos clientes todavía trabajan de forma tradicional, con flujos de trabajo poco inteligentes. Quieren avanzar, pero también tienen muchos usuarios. Cuando construimos funciones de IA, primero entendemos qué es esa tecnología y cómo puede ayudarnos. Luego, qué componentes básicos necesitamos para adaptarnos a cambios rápidos, porque la tecnología avanza muy rápido.

Por eso creamos IA Gateway, mapas de colaboración, funciones de cumplimiento y control empresarial. ¿Dónde colocamos esas funciones? ¿Qué son exactamente? Muchas están en los flujos existentes, para hacer que los clientes hagan su trabajo mejor, más rápido, con mayor calidad y eficiencia. Son funciones simples, como un GIF de 30 segundos en una plataforma, pero para los clientes, son muy emocionantes, porque ya las usan y mejoran su forma de trabajar. En el mundo de IA, eso parece simple, pero puede darles un gran valor.

Siempre digo que no basta con un ejemplo de servicio, hay que aprovechar los procesos existentes, combinarlos con nuevas aplicaciones o flujos. Por ejemplo, en Jira, en nuestro producto de gestión de servicios de RRHH y TI, estamos haciendo resúmenes de tickets. Es algo que podemos hacer mucho mejor que antes.

Cuatro o cinco personas trabajan en un mismo ticket, con muchos archivos y conversaciones. Normalmente, tardan 30 minutos en entender todo y resolver. Resumir no es solo poner todo en un LLM y obtener un resumen. El contexto es muy importante, y el flujo de trabajo no cambia. Es como decirle a Eric: “¿Puedes ayudarme con este ticket?” y él tiene que cargar toda la información. Es un flujo existente, y podemos usar LLM para mejorarlo, y a los clientes les encanta. Pero esas funciones no tienen agentes inteligentes.

Entonces, en ese flujo de servicio, necesitamos agentes en cada paso. La mayoría trabaja en un flujo, y en algún paso fallan mucho y toman mucho tiempo. Podemos hacer ese paso más rápido, y eso requiere que diseñemos agentes específicos.

Tenemos un marco de agentes muy bueno, con mapas y contexto, y es barato. O podemos usar nuestro propio marco. La mayoría de las empresas tendrán entre tres y cinco plataformas de agentes grandes. Pueden decir: “Yo uso Agentforce para esto, o Gemini para aquello”. Traen ese agente, y lo integran en el flujo. Eso debemos poder hacerlo.

Pero seguimos en el mundo de los flujos existentes, solo haciendo tareas más eficientes. Pero, ¿qué pasa si el servicio no existe? Entonces, estamos replanteando toda esa categoría de software y flujo. Tenemos que ayudar a los clientes a cruzar esa brecha, porque no solo tienen un equipo de servicio, sino cientos. Si gestionan cientos de centros de servicio, dirán: “Estos 20 funcionarán de otra forma”, pero deben gestionarlos todos. Por eso, intentamos integrar datos del mapa de colaboración con esa visión, desde la perspectiva del cliente. Esa es una tarea que a menudo se pasa por alto. Nuestro trabajo es guiarlos hacia el futuro a 1, 2 y 5 años, pero también a 1 y 2 años, y a 5 años.

Finalmente, invertimos mucho en diseño. En cualquier conversación, esto se pasa por alto, porque en su funcionamiento hay muchas decisiones de diseño fundamentales. Si miramos la era móvil, las primeras apps solo trasladaron contenido de escritorio o web a móvil, y luego evolucionamos a nuevas formas de interacción y experiencia