Nadie iba a aprender nuestro software.

Software para contact centers. Herramientas de campañas. Una plataforma de chat. Clientes reales, un volumen real; un trabajo del que estábamos y seguimos estando orgullosos.

Y cada vez que uno de esos clientes quería algo, la petición nos llegaba a nosotros.

No a una página de configuración. A nosotros: a una persona de nuestro lado que leía un correo, abría la cuenta, hacía el trabajo y respondía. No era un fallo. Era el producto funcionando exactamente como lo diseñamos, y así es como funciona casi todo el software empresarial. Durante la mayor parte del tiempo que lo estuvimos construyendo, no había alternativa.

Ahora la hay. Así que antes de contarte lo que hace Omni Octo, esto es lo que creemos que estaba mal en lo que hacíamos antes, escrito por quienes lo hicieron.

Uno

Ya podía hacerlo. Solo que no sabían cómo llegar ahí.

Lo que pide un cliente casi nunca es una función que no existe.

Por lo general, es algo que el software ya puede hacer, pero está escondido detrás de un menú que no han encontrado, o es un informe que no saben cómo generar, o una configuración cuyo nombre tendrías que saber de antemano para poder buscarla. La capacidad está ahí. Se lanzó hace meses. Lo anunciamos.

Así que hacen lo único que pueden hacer. Nos preguntan a nosotros.

Y esa petición —que no requiere ingeniería, ni lanzamientos, ni despliegues, ni que nadie escriba una sola línea de código— acaba siendo un correo, una persona, un puesto en una cola de espera y una respuesta que llega el jueves.

Si de verdad fueran peticiones de funciones nuevas, la espera sería honesta. Construir algo nuevo lleva tiempo; nos lleva tiempo a nosotros y le llevaría tiempo a cualquiera. No tenemos ningún problema con esa espera, y nuestros clientes tampoco.

El caso interesante es el otro noventa por ciento: cuando el software ya podía hacerlo, y lo único que faltaba era saber cómo.

Nadie en esa cadena era lento a propósito. Las personas que respondían esos correos eran buenas en su trabajo y les importaba el resultado. La cola de espera no era un fracaso del equipo: era la única ruta que habíamos construido entre la pregunta de un cliente y una respuesta que ya existía dentro de nuestro propio sistema.

Y el coste que nadie calcula son las preguntas que nunca llegan a hacerse.

Cuando preguntar sale caro, la gente deja de preguntar por cosas pequeñas. Mantienen un agent que se equivoca ligeramente durante meses, porque hacer que se equivoque un poco menos no justifica perder dos días en un hilo de correos. Veíamos cada ticket que se abría. Nunca vimos las mejoras que nuestros clientes decidieron que no valían la pena pedir. Y ese grupo era mucho más grande.

Dos

Sus datos. Nuestro edificio.

Un cliente ejecutó una campaña de varios cientos de llamadas. Al terminar, nos dijeron que había ido mal.

Les preguntamos cómo lo sabían. Nos enviaron quince grabaciones.

Quince, de entre varios cientos. No porque estuvieran eligiendo solo las peores, sino porque quince es lo que una sola persona puede escuchar a mano en una tarde. El resto existía. Grabadas, transcritas, almacenadas, completas.

Todas las respuestas que querían estaban ahí. Cuánta gente descolgó. Cuántos llegaron hasta el final. En qué momento de la conversación la gente dejaba de hablar. Qué pregunta confundía a todo el mundo. Si aquello por lo que estaban molestos había ocurrido seis veces o cuatrocientas.

Nada de eso requería que nosotros construyéramos algo nuevo. Requería a alguien que supiera cómo hacerle una pregunta a los datos. Esa persona trabajaba aquí, no allí.

Así que la conversación que tuvimos con ellos no fue un análisis. Fueron dos partes discutiendo a partir de anécdotas: las suyas, quince de ellas, elegidas precisamente por ser malas.

Habíamos construido un sistema que acumulaba exactamente la evidencia necesaria para mejorarlo, y luego encerraba esa evidencia donde sus dueños no podían interrogarla.

No es una decisión de almacenamiento. Es lo que decide si un cliente puede responder a su propia pregunta un martes por la tarde, o si primero tiene que explicársela a otra persona y sentarse a esperar.

Tres

La configuración se convierte en una hoja de respuestas.

Llega un cliente con una hoja de cálculo. Tres niveles de urgencia. Entre cuarenta y cincuenta situaciones por nivel. Cada fila tiene una respuesta prescrita.

Es algo totalmente razonable de plantear. Es su experiencia, puesta por escrito; entienden su sector mucho mejor de lo que nosotros lo haremos jamás, y esa hoja de cálculo es su forma de hacer la parte difícil del trabajo.

Así que la codificamos. Situación, respuesta, situación, respuesta. Y en el momento en que lo hicimos, pasaron dos cosas en las que no habíamos pensado.

Primero, la hoja de cálculo se convirtió en una hoja de respuestas. Ahora era un registro escrito de lo que se suponía que el sistema debía decir, lo que significaba que cada conversación que se desviara de ella era, por definición, un defecto. Yo escribí que debía decir esto. ¿Por qué dijo aquello? Es una queja justa cuando se compara con un documento que habíamos acordado. Y significaba que el sistema ya no podía mejorarse sin renegociar el documento, lo que en la práctica significaba que no se podía mejorar, porque nadie renegocia ciento cincuenta filas.

Segundo, no dejaba de crecer. Cada caso límite, cada situación nueva, cada ¿también puedes encargarte de esto? se convertía en una fila más. Cada fila era otra cosa que manteníamos, indefinidamente, para un solo cliente. La configuración era un contrato sin fecha de finalización y sin marcha atrás.

Lo que el cliente quería nunca fueron las ciento cincuenta filas. Era el criterio que esas filas intentaban plasmar por escrito.

Tómate esto en serio. Haz una pregunta lógica para seguir el hilo. Identifica cuándo es urgente. Esa es toda la instrucción, y cabe en tres frases. La hoja de cálculo existía porque no había forma de decirle esas tres frases al software y que las entendiera, así que ese criterio tenía que aplastarse y convertirse en reglas fijas de antemano, a mano, para luego quedar congelado ahí.

Cuatro

Había cosas que no deberíamos haber construido en absoluto.

Una fila en una hoja de cálculo de ese tipo trataba sobre una persona que había dicho sentirse sola. La respuesta prescrita le pedía que recordara cuántas veces se había sentido así recientemente, y cuándo, y que lo describiera.

Léelo como un paso de recolección de datos y tiene todo el sentido del mundo. Produce un campo estructurado, y se puede sacar un informe de ese campo.

Léelo como algo que un ser humano escucha, en una llamada telefónica, segundos después de confesarle a un extraño que se siente solo, y es grotesco. Toma el único momento de la conversación que era inconfundiblemente humano y lo convierte en una escritura en la base de datos.

A aquello dijimos que no. Y volveríamos a decir que no.

Algunas conversaciones importan precisamente porque una persona decidió tenerlas. Automatizarlas no escala la empatía. Elimina la parte que estaba haciendo el trabajo.

Un agent que se encarga de programar, de los recordatorios, de los seguimientos, de las notas y del papeleo en torno a esas conversaciones crea más espacio para ellas, y eso tiene muchísimo valor. Un agent que se encarga de las conversaciones en sí es un producto distinto con un propósito mucho peor, y no nos interesa construirlo.

Cinco

No aprenden. Preguntan.

Esto es lo que nos enseñaron seis años, y lo aprendimos despacio y en el orden equivocado.

Primero descubrimos que los clientes no van a aprender a usar la interfaz. Ni la nuestra, ni la de nadie.

Piensa en lo que se siente cuando te dan Salesforce, o HubSpot, o cualquier producto empresarial de Microsoft, y te dicen que todo lo que necesitas está ahí dentro en alguna parte. Esa afirmación es completamente cierta y completamente inútil. El software no es difícil. Simplemente hay una cantidad enorme de él, organizado según la lógica de quienes lo construyeron, y aprender esa organización es un proyecto en sí mismo. Nuestros clientes ya tenían trabajo que hacer.

Así que escribimos documentación. Muchísima. Una página en la wiki para cada función, guías paso a paso, vídeos largos, la biblioteca entera, siempre actualizada. Era precisa, estaba bien organizada y estábamos orgullosos de ella.

No la leían.

Y la cola de soporte se llenó de preguntas que ya estaban respondidas. No algunas; la mayoría. Preguntadas y respondidas en una página que habíamos escrito, o esperando en un menú a tres clics de distancia. Durante mucho tiempo leímos esto como un problema de documentación, y respondimos escribiendo más documentación.

Nunca fue un problema de documentación. Es el mismo problema que el de la interfaz, pero un nivel más arriba. Una wiki es un índice del modelo mental de otra persona. Leerla es un proyecto más pequeño que aprenderse los menús, pero sigue siendo un proyecto, y sigue siendo un proyecto sobre nosotros en lugar de sobre su propio trabajo.

Nadie tiene la capacidad mental para aprenderse el producto de otra empresa, el menú de otra empresa y la wiki de otra empresa. Tienen su propio trabajo que hacer.

Así que esto es lo que hace la gente en su lugar, y es lo más antiguo que hacemos.

Preguntan.

Preguntan qué significa esto. Preguntan por qué ha hecho aquello. Piden que se haga tal cosa.

Es la forma en que cualquier persona trata con cualquier otra persona: un amigo, un hijo, un profesor, un alumno, un colega, un empleado, un miembro de la junta. Nadie se lee el manual de un compañero de trabajo. Le preguntas, te responde, y si hay que hacer algo, lo hace. Preguntar no es un atajo que toman los que no se molestan en leer. Es la interfaz que los seres humanos han usado entre sí desde que existen los seres humanos, y es extraordinariamente buena: no requiere formación, funciona el primer día, tolera preguntas vagas y te permite describir un problema con las palabras que realmente tienes, en lugar de las palabras que eligió otro.

Cada cliente que abría un ticket que se podía responder con nuestra propia wiki no estaba fracasando al usar nuestro software. Estaba usando la interfaz que realmente tiene.

El problema era que nosotros no estábamos al otro lado.

Porque a quien le preguntaban era a una persona de nuestra empresa, y esa persona tiene una cola de trabajo, y una zona horaria, y un fin de semana. Así que entraba la petición, y empezaba la espera. Y la espera es el coste entero.

Lo querían para ya. O para anoche. Lo que obtuvieron fue para el jueves que viene.

No quieren esperar a que se haga. No quieren aprender para hacerlo ellos mismos. Esas eran las dos únicas opciones que la última generación podía ofrecer, y nuestros clientes tenían toda la razón al estar descontentos con ambas.

Así que el estándar que nos exigimos ahora ya no es el que nos exigíamos antes.

Una capacidad no está terminada cuando funciona. No está terminada cuando tiene una página de configuración, y desde luego no está terminada cuando tiene una página de documentación. Está terminada cuando puedes describir lo que quieres con tus propias palabras —las palabras que usarías con un compañero, no las que nosotros decidimos ponerle a la función— y el agent entiende a qué te refieres, te dice lo que está a punto de hacer, y lo hace.

Cualquier cosa que no llegue a eso, sigue siendo pedirle a alguien que aprenda a usar nuestro producto primero.