Cuando una empresa incorpora inteligencia artificial con un partner tecnológico, el costo de aprender a usarla suele quedar dentro del proyecto: retrabajo, cambios de alcance, demoras y decisiones tomadas sobre la marcha. En Shifta asumimos ese costo antes. Cada capacidad nueva se prueba, se mide, se descarta o se refina primero dentro de nuestra propia operación, y recién después puede formar parte de una propuesta. A esa práctica la llamamos Customer Zero.
En concreto: un ciclo de varias etapas internas antes de que el cliente vea algo. Cuatro reglas que definen qué avanza y qué no. Espacios internos como las SHIFTalks y la clínica de tokens, donde se comparten resultados, errores y uso real. Lo medimos con indicadores de capacidad de entrega, no de uso de IA. Lo que llega al cliente no es una demo: son decisiones ya tomadas, herramientas evaluadas, tecnologías descartadas y capacidades que ya funcionaron en condiciones reales.
Aprender antes, para entregar mejor
Customer Zero es nuestra práctica para validar internamente nuevas capacidades, procesos y formas de trabajo antes de convertirlos en una recomendación.
Para un CIO, un CTO o un líder de negocio, el riesgo más caro de incorporar inteligencia artificial es contratar a un partner que todavía está aprendiendo a usarla.
En los últimos años aparecieron cientos de empresas ofreciendo servicios de inteligencia artificial. Al mismo tiempo, la conversación de la industria se organizó alrededor de conceptos como AI readiness o AI first: uno mide qué tan preparada está una organización para adoptar IA; el otro propone ubicarla en el centro de cada decisión. Ambos enfoques pueden ser útiles, pero ninguno responde una pregunta más básica.
¿Quién asume el costo de aprender cómo aplicar esa tecnología en condiciones reales de negocio?
Muchas veces la respuesta termina siendo el cliente. La herramienta se presenta como validada, pero sus limitaciones aparecen durante la implementación. Los supuestos se corrigen con el proyecto en marcha. Las estimaciones cambian. El alcance se redefine. El equipo del partner aprende mientras entrega.
En Shifta tomamos otro camino. Antes de incorporar una nueva capacidad de IA a una propuesta o a un proyecto, la usamos para transformar nuestra propia forma de trabajar: la probamos, la medimos, identificamos sus límites, descartamos lo que no funciona y documentamos lo aprendido. Recién después puede llegar a un cliente. A esa forma de trabajar la llamamos Customer Zero.
Quién paga el aprendizaje
Con cada tecnología nueva se repite el mismo patrón: los partners prometen resultados antes de acumular experiencia real, y por un tiempo alcanza. Pero una demo exitosa no garantiza que una capacidad se sostenga dentro de un proceso completo, se integre con sistemas existentes, cumpla requisitos de seguridad o mantenga su calidad bajo presión de entrega. Cuando el partner todavía no tiene esas respuestas, las primeras implementaciones se convierten en su proceso de aprendizaje.
Ese costo rara vez figura como una línea dentro de la propuesta. Aparece después, en forma de retrabajo, cambios de alcance, demoras, decisiones de arquitectura tomadas sobre la marcha e incertidumbre sobre los resultados. Toda tecnología nueva tiene una curva de aprendizaje; el problema para el cliente es financiarla sin saberlo.
Si una herramienta todavía necesita demostrar cómo funciona en condiciones reales, ese aprendizaje debe ocurrir con nuestro tiempo, nuestros equipos y nuestro presupuesto, no con los del cliente.
Ese fue el disparador de Customer Zero: asumir internamente la curva de aprendizaje y convertirla en un método de trabajo reutilizable.
La industria lo aplica a sus productos; nosotros a nuestra forma de trabajar
El concepto de Customer Zero no nació en Shifta. Microsoft lo popularizó usando a sus propios equipos como primeros clientes de sus tecnologías antes de llevarlas al mercado. Amazon sostiene una idea cercana con su principio de "Day 1": operar siempre como si fuera el primer día, cerca del problema y decidiendo con evidencia en lugar de con inercia. Google y Meta usan sus propias plataformas internas antes de abrirlas, y Atlassian y Salesforce hacen algo parecido con sus productos.
La premisa que comparten es simple: una organización debería experimentar primero las dificultades, los límites y las oportunidades de una tecnología que después recomienda a otros.
Customer Zero suele significar usar internamente el mismo software que después llega al mercado.
Construimos capacidades de delivery, metodologías y formas de trabajar que después aplicamos en proyectos de clientes.
Para Shifta, entonces, Customer Zero valida una manera de entender un problema, hacer un discovery, diseñar una solución, desarrollar software, generar documentación, probar calidad, estimar esfuerzos, automatizar tareas, tomar decisiones con IA y entregar un proyecto en condiciones reales.
Cuando una práctica nueva llega a un cliente, ya la usaron nuestros propios equipos, ya se midió dentro de un proceso real y ya se refinó a partir de esos resultados. No alcanza con que haya funcionado una vez: tiene que demostrar que mejora una capacidad de entrega completa.
El ciclo completo, en seis etapas
Toda capacidad nueva recorre el mismo ciclo antes de formar parte de una propuesta o de un proyecto de cliente. El ciclo existe para incorporar únicamente aquello que ya demostró generar valor.
El ciclo comienza con un problema real: una tarea, una fricción o una decisión que podría resolverse mejor. No partimos de una herramienta disponible para buscar después dónde aplicarla. La pregunta inicial es qué parte de nuestro trabajo necesita mejorar y por qué.
La hipótesis se prueba dentro de Shifta. El primer entorno de experimentación puede ser un proceso de ingeniería, una actividad comercial, una tarea de marketing, una necesidad de people o un análisis de finanzas. Experimentar internamente nos permite equivocarnos sin trasladar ese riesgo al cliente.
Una prueba de concepto puede resultar atractiva y, aun así, no mejorar el proceso. Por eso medimos desde el primer experimento. Según el caso, observamos variables como tiempo recuperado, calidad, consistencia, precisión, adopción, reducción de retrabajo o capacidad para acelerar una decisión.
No toda herramienta ni toda hipótesis merece avanzar. Algunas se descartan porque no generan suficiente valor, otras porque introducen más complejidad de la que resuelven y otras porque todavía no cumplen con los niveles necesarios de seguridad, confiabilidad o calidad. Cada capacidad que descartamos evita que esa experimentación ocurra más adelante dentro del proyecto de un cliente.
Una capacidad deja de ser una prueba cuando forma parte del trabajo cotidiano de otros equipos. En esta etapa comprobamos que no dependa únicamente de la persona que creó el experimento: la adopción real revela dificultades que una demostración aislada no muestra.
Para que eso ocurra, cada experimento deja conocimiento reutilizable: criterios de uso, limitaciones conocidas, prompts, skills, agentes, evaluaciones, templates, métricas, decisiones técnicas y casos en los que la herramienta no debería usarse. Cuando la capacidad demuestra que puede repetirse, ese aprendizaje se convierte en método: guías, componentes, flujos de trabajo y criterios de gobernanza que permiten aplicarla de manera consistente. Ahí una experiencia individual pasa a ser una capacidad organizacional.
Solo después de atravesar las etapas anteriores la capacidad puede considerarse para incorporarse a una propuesta o a un proyecto. El cliente recibe una práctica que ya se usó, se midió, se documentó y se refinó dentro de nuestro propio proceso de entrega, no una promesa basada en una demo.
El ciclo no termina cuando una capacidad llega a un cliente. Cada proyecto aporta nuevas condiciones, restricciones y aprendizajes, y esa experiencia vuelve al sistema para actualizar los playbooks, mejorar los estándares y revisar los supuestos iniciales. Así, cada proyecto futuro comienza desde un punto más avanzado que el anterior.
Cuatro reglas que aplicamos antes de llevar algo a un cliente
Customer Zero es un conjunto de principios que usamos para decidir qué capacidades incorporamos a nuestra forma de entregar proyectos. Esos principios son los que lo vuelven una práctica repetible en lugar de una colección de experimentos aislados.
Toda tecnología nueva necesita una curva de aprendizaje y la asumimos nosotros. Cada capacidad se prueba primero dentro de Shifta, con procesos reales y equipos reales. Ahí aparecen las primeras limitaciones, los errores de implementación, los casos borde y las preguntas que una demo nunca responde. Cuando esa capacidad llega a un cliente, buena parte de ese aprendizaje ya ocurrió.
En inteligencia artificial es fácil confundir una buena demostración con una buena solución. Por eso toda hipótesis se prueba y se mide dentro de un proceso real antes de avanzar, y tiene que responder una pregunta sencilla.
¿Qué mejora concreta genera sobre la forma en que hoy entregamos valor?
Si no podemos responderla con evidencia, seguimos experimentando o la descartamos. Cuántas herramientas decidimos no adoptar es uno de los indicadores más importantes de Customer Zero: decir "todavía no" es tan importante como decir "sí".
Un experimento solo genera ventaja competitiva cuando puede repetirse. Por eso cada iniciativa deja algo más que un resultado: la documentación transforma experiencias individuales en conocimiento organizacional.
El objetivo es mejorar nuestra capacidad de entregar resultados, no incorporar IA en todos los procesos. En algunos casos eso significa automatizar, en otros asistir una decisión y en muchos decidir de forma consciente no usar IA.
Antes de automatizar procesos, capacitamos personas
Si hoy estás evaluando cómo incorporar IA en tu organización, la primera decisión parece ser qué herramienta o licencia comprar. En nuestra experiencia esa es la segunda: la primera es entender qué capacidades necesita desarrollar cada equipo para generar valor con esa tecnología.
Fue uno de los primeros procesos en los que fuimos nuestro propio Customer Zero. Mapeamos las habilidades que necesitaba cada rol, evaluamos el nivel de conocimiento de toda la compañía y validamos con un piloto qué formato generaba adopción real. Solo después construimos un programa de upskilling con DataCamp como plataforma principal, que alcanzó a ingeniería, marketing, people, ventas y finanzas: la IA cambia cómo una organización completa aprende, colabora y decide, no solo cómo se desarrolla software.
Y por los resultados obtenidos, DataCamp documentó la experiencia de Shifta como uno de sus casos de éxito.
Customer story publicado por DataCamp
Caso: cómo un piloto terminó convirtiéndose en parte de nuestro delivery
Uno de los primeros procesos que decidimos revisar fue la definición de requerimientos. Era una etapa que exigía al menos dos perfiles técnicos y siete pasos encadenados:
- Definir las historias de usuario
- Refinarlas con el cliente
- Refinarlas con arquitectura
- Armar pantallas o mockups
- Validar criterios de aceptación
- Generar casos de prueba
- Cargar todo en la herramienta de gestión
Dependía mucho de la experiencia de cada Project Manager y la calidad variaba entre proyectos. La hipótesis parecía sencilla: ¿podía la IA ayudarnos a generar historias de usuario más consistentes sin perder el contexto del negocio?
El primer experimento fue básico. Tomamos reuniones grabadas y probamos distintas herramientas para convertirlas automáticamente en historias de usuario. Los resultados fueron irregulares: algunas historias eran demasiado genéricas, otras omitían restricciones importantes y otras inventaban información.
En lugar de descartar la idea, seguimos iterando. Probamos distintos modelos, ajustamos prompts, incorporamos documentación del proyecto como contexto y definimos criterios mínimos de calidad.
Hoy la etapa está partida en tres.
CARGA EN AZURE DEVOPS
Sobre esa etapa medimos tres cosas: lead time de definición, rework de requerimientos y ambigüedad detectada.
Lo que más valor generó fue lo que quedó después del experimento: una skill disponible para todo el equipo, un agente que divide historias de usuario complejas en otras más simples, templates, criterios de revisión, ejemplos y documentación.
SKILL DE REFINAMIENTO DISPONIBLE PARA EL EQUIPO
Hoy los nuevos proyectos comienzan con ese aprendizaje ya incorporado. Ese es el objetivo de Customer Zero: convertir cada experimento en una capacidad de delivery.
Cómo medimos el Customer Zero internamente
Uno de los riesgos más comunes al incorporar inteligencia artificial es confundir actividad con impacto. Es fácil medir cuántas licencias se compraron, cuántas personas hicieron un curso, cuántos prompts se escribieron e incluso cuántos agentes se desarrollaron. Ninguna de esas métricas responde la pregunta más importante.
¿Nuestra capacidad para entregar proyectos con IA realmente mejoró?
Customer Zero existe para responder esa pregunta con evidencia. Medimos antes de escalar para demostrar que entregamos mejor, no que usamos más IA.
En la práctica seguimos tres familias de indicadores. Velocidad: cuánto tarda una idea en convertirse en prueba de concepto y en backlog inicial. Calidad: retrabajo, consistencia entre equipos y precisión de las estimaciones. Adopción: uso por equipo y reutilización de playbooks y agentes internos.
También medimos el uso de tokens por equipo y por proyecto. Es la forma más directa de ver dónde se está usando la IA de verdad, qué cuesta cada capacidad y si ese consumo se traduce en algo. Cruzado con los tiempos de entrega, muestra la tendencia que nos importa: tareas que antes tomaban semanas hoy toman días, y las que tomaban días se resuelven en horas. Esa reducción, sostenida y medida, es la evidencia de que la capacidad mejoró.
SHIFTalks: el lugar donde compartimos errores y aciertos
En muchas conversaciones sobre inteligencia artificial todavía se habla más de posibilidades que de resultados. Preferimos hacerlo al revés.
En Shifta organizamos periódicamente las SHIFTalks, encuentros donde los propios equipos presentan implementaciones reales, aprendizajes y experimentos que ya están ocurriendo dentro de la compañía. Todas las áreas comparten qué probaron, qué funcionó, qué descartaron y qué aprendieron. Customer Zero se alimenta de los éxitos y también de los errores.
En una SHIFTalk mostramos como desarrollamos, en menos de tres horas, una prueba de concepto para detectar daños vehiculares a partir de fotografías. No era un producto terminado, pero mostró que una hipótesis de negocio puede validarse en horas en lugar de semanas.
Inspector de daños vehiculares (prueba de concepto)
En otra SHIFTalk construimos un mapa que estimaba el potencial comercial de una nueva sucursal combinando información pública sobre tránsito, demografía y competencia. El objetivo era reducir la incertidumbre lo suficiente para tomar una mejor decisión.
Location Intelligence (prueba de concepto)
No todas esas iniciativas llegaran a producción, pero todas dejaron activos reutilizables.
La clínica de tokens: mirar de cerca el uso real
Tambien lanzamos La clínica de tokens. Es el espacio equivalente a la SHIFTalks para el equipo técnico: ahí se comparten experiencias y prácticas de manejo de tokens.
Analizamos temas como por ejemplo: dos personas resuelven la misma tarea con la misma herramienta y una consume varias veces más tokens que la otra, con resultados de calidad parecida.
En la clínica se revisa uso real: qué consume cada flujo, qué contexto se está enviando de más, cuándo conviene un modelo más chico, cuándo un archivo de referencia reemplaza tres reintentos y cuándo la tarea no justificaba usar IA.
Cuatro cosas que estamos resolviendo hoy
Ser Customer Zero significa aprender antes que nuestros clientes, no tener todas las respuestas. Estos son algunos de los desafíos que estamos terminando de resolver.
A medida que más equipos generan iniciativas aparecen soluciones distintas para problemas similares. Nuestro desafío es ordenar ese conocimiento sin frenar la experimentación.
Algunos resultados son fáciles de observar: reducir el tiempo necesario para construir una prueba de concepto es relativamente sencillo. Otros requieren más trabajo. ¿Cómo medimos una mejor decisión, la calidad de una recomendación o el valor de haber descartado una herramienta a tiempo? Seguimos refinando esas respuestas.
Cuando una persona comete un error dentro de un proceso, sabemos cómo investigarlo, corregirlo y aprender de él. Con la IA aparecen preguntas nuevas: ¿quién responde por una mala decisión? ¿Cuánta revisión humana hace falta? ¿Cómo queda registrado quién decidió qué?
La inteligencia artificial cambia demasiado rápido para asumir que una decisión será definitiva. Una herramienta que descartamos hace seis meses puede ser hoy la mejor alternativa. Por eso Customer Zero acumula aprendizaje en lugar de certezas, y ese aprendizaje se revisa de forma permanente. El objetivo es seguir mejorando nuestra capacidad de entrega, no tener razón.
Lo que hacemos no cambió: seguimos siendo un partner estratégico
Seguimos construyendo productos digitales, escalando equipos y ayudando a organizaciones a tomar mejores decisiones tecnológicas. Lo que cambió es la forma en que aprendemos: las herramientas cambian, los modelos evolucionan y los proveedores aparecen y desaparecen, y la ventaja sostenible viene de aprender más rápido que el ritmo al que cambia la tecnología.
Un cliente que trabaja con Shifta no compra solo un equipo ni horas de desarrollo. Compra cientos de decisiones ya tomadas: herramientas evaluadas, tecnologías descartadas, procesos refinados, playbooks escritos, agentes construidos y capacidades de delivery que ya funcionaron en condiciones reales. Ese aprendizaje, difícil de observar desde afuera, es lo que reduce incertidumbre desde el primer día.
Donde más se nota es en las reuniones: antes explicábamos posibilidades, hoy contamos cómo usamos una herramienta, qué problema resolvió y qué limitaciones encontramos. El cliente ya no necesita preguntarse si funciona y puede concentrarse en decidir si genera valor para su organización.
Próximos pasos
Customer Zero sigue evolucionando. Hoy estamos explorando nuevas capacidades para discovery, estimación, arquitectura, desarrollo, testing, documentación, operaciones y gestión del conocimiento. Algunas llegarán a nuestros proyectos y muchas otras no, y eso también es parte del proceso.