Ninguém nunca ia aprender o nosso software.

Software de contact center. Ferramentas de campanha. Uma plataforma de chat. Clientes reais, volume real, um trabalho do qual nos orgulhávamos e ainda nos orgulhamos.

E, toda vez que um desses clientes queria alguma coisa, o pedido vinha para nós.

Não para uma página de configurações. Para nós — uma pessoa do nosso lado, lendo um e-mail, abrindo a conta, fazendo o que precisava ser feito e respondendo. Isso não era uma falha. Era o produto funcionando exatamente como projetado, e é assim que quase todo software corporativo funciona. Durante a maior parte do tempo em que o construíamos, não havia alternativa.

Agora há. Então, antes de contarmos o que o Omni Octo faz, aqui está o que achamos que estava errado com o que fazíamos antes — escrito pelas pessoas que o fizeram.

Um

O sistema já fazia. Eles só não conseguiam acessar.

O que um cliente pede quase nunca é um recurso que não existe.

Geralmente é algo que o software já consegue fazer, escondido atrás de um menu que eles não acharam, de um relatório que não sabem montar, ou de uma configuração cujo nome você já precisaria saber para conseguir buscar. A capacidade está lá. Foi lançada há meses. Nós até anunciamos.

Então eles fazem a única coisa que lhes resta. Eles nos perguntam.

E esse pedido — que não exige engenharia, nem lançamento, nem deploy, e ninguém para escrever uma única linha de código — ainda assim vira um e-mail, vai para uma pessoa, entra numa fila e recebe uma resposta na quinta-feira.

Se fossem pedidos reais de novas funcionalidades, a espera seria justa. Construir algo novo leva tempo, leva tempo para nós, e levaria para qualquer um. Não temos problema nenhum com essa espera, e nossos clientes também não.

O caso interessante são os outros noventa por cento: quando o software já conseguia fazer, e a única coisa que faltava era saber como.

Ninguém nessa cadeia era lento de propósito. As pessoas que respondiam àqueles e-mails eram boas no que faziam e se importavam com o resultado. A fila não era uma falha da equipe — era a única rota que tínhamos construído entre a dúvida de um cliente e uma resposta que já existia dentro do nosso próprio sistema.

E o custo que ninguém contabiliza são as perguntas que nunca chegam a ser feitas.

Quando perguntar custa caro, as pessoas param de perguntar sobre coisas pequenas. Elas mantêm um agent um pouco desajustado por meses, porque deixá-lo um pouco menos desajustado não vale dois dias de espera e uma thread de e-mails. Nós víamos todos os chamados abertos. Nunca vimos as melhorias que nossos clientes decidiram que não valiam o esforço de pedir — e esse grupo era muito maior.

Dois

Os dados deles. O nosso prédio.

Um cliente rodou uma campanha com centenas de ligações. Depois, vieram nos dizer que o resultado tinha sido ruim.

Perguntamos como eles sabiam. Nos enviaram quinze gravações.

Quinze, de várias centenas — não porque estavam escolhendo a dedo, mas porque quinze é o máximo que uma pessoa consegue ouvir manualmente em uma tarde. O resto existia. Gravado, transcrito, armazenado, completo.

Todas as respostas que eles queriam estavam lá. Quantas pessoas atenderam. Quantas chegaram até o final. Em que ponto da conversa as pessoas pararam de falar. Qual pergunta confundiu todo mundo. Se aquele problema que os deixou irritados tinha acontecido seis vezes ou quatrocentas.

Nada disso exigia que construíssemos algo novo. Exigia alguém que soubesse como fazer uma pergunta aos dados. E essa pessoa trabalhava aqui, não lá.

Então, a conversa que tivemos com eles não foi uma análise. Foram duas partes discutindo com base em evidências anedóticas — as deles, quinze, escolhidas por serem ruins.

Tínhamos construído um sistema que acumulava exatamente as evidências necessárias para melhorá-lo, e depois trancávamos essas evidências em um lugar onde os próprios donos não podiam questioná-las.

Essa não é uma decisão de armazenamento. É o que decide se um cliente consegue responder à própria pergunta numa tarde de terça-feira, ou se precisa descrevê-la para outra pessoa primeiro e esperar.

Três

A configuração vira um gabarito.

Um cliente chega com uma planilha. Três níveis de urgência. Quarenta a cinquenta situações em cada nível. Cada linha tem uma resposta prescrita.

É algo totalmente razoável de se trazer para nós. É a expertise deles, documentada — eles entendem do setor deles muito melhor do que nós jamais entenderemos, e a planilha são eles fazendo a parte difícil do trabalho.

Então nós a codificamos. Situação, resposta, situação, resposta. E no momento em que fizemos isso, aconteceram duas coisas em que não tínhamos pensado.

Primeiro, a planilha virou um gabarito. Agora era um registro escrito do que o sistema deveria dizer, o que significava que qualquer conversa que fugisse daquilo era, por definição, um defeito. Eu escrevi que deveria dizer isso. Por que disse aquilo? É uma pergunta justa de se fazer contra um documento com o qual havíamos concordado. E isso significava que o sistema não podia mais ser melhorado sem renegociar o documento — o que, na prática, significava que ele não podia ser melhorado, porque ninguém renegocia cento e cinquenta linhas.

Segundo, ela só crescia. Cada caso isolado, cada situação nova, cada dá pra lidar com isso também virava mais uma linha. Cada linha era mais uma coisa que mantínhamos, indefinidamente, para um único cliente. A configuração era um contrato sem data de término e com viagem só de ida.

O que o cliente queria nunca foram as cento e cinquenta linhas. Era o discernimento que as linhas tentavam colocar no papel.

Leve isso a sério. Faça uma pergunta de acompanhamento sensata. Saiba quando é urgente. Essa é a instrução inteira, e cabe em três frases. A planilha existia porque não havia como dizer essas três frases para o software e fazê-lo entender — então o discernimento teve que ser achatado em regras antecipadamente, à mão, e depois congelado ali.

Quatro

Algumas coisas não deveríamos ter construído nunca.

Uma das linhas numa dessas planilhas tratava de uma pessoa que dissera estar se sentindo solitária. A resposta prescrita pedia para ela lembrar quantas vezes tinha se sentido assim recentemente, e quando, e para descrever a sensação.

Leia isso como uma etapa de coleta de dados e faz todo o sentido. Produz um campo estruturado, e o campo pode virar um relatório.

Leia isso como algo que um ser humano ouve, numa ligação, segundos depois de admitir para um estranho que está solitário, e é grotesco. Isso pega o único momento da conversa que era inconfundivelmente humano e o transforma numa gravação de banco de dados.

Nós dissemos não para essa. Diríamos não de novo.

Algumas conversas importam precisamente porque uma pessoa escolheu tê-las. Automatizar isso não dá escala ao cuidado. Remove a parte que estava fazendo o trabalho.

Um agent que cuida dos agendamentos, dos lembretes, dos follow-ups, das anotações e da papelada em torno dessas conversas cria mais espaço para elas, e isso tem um valor imenso. Um agent que conduz as conversas em si é um produto diferente com um propósito pior, e não temos interesse em construí-lo.

Cinco

Eles não aprendem. Eles perguntam.

Esta é a grande lição que seis anos nos ensinaram, e nós a aprendemos devagar e na ordem errada.

Primeiro, descobrimos que os clientes não vão aprender a usar a interface. Nem a nossa, nem a de ninguém.

Pense em como é receber o Salesforce, o HubSpot, ou qualquer produto corporativo da Microsoft, e ouvir que tudo o que você precisa está lá em algum lugar. Essa afirmação é completamente verdadeira e completamente inútil. O software não é difícil. É que existe uma quantidade enorme dele, organizado segundo a lógica das pessoas que o construíram, e aprender essa organização é um projeto por si só. Nossos clientes já tinham o próprio trabalho a fazer.

Então, nós escrevemos documentação. Muita documentação. Uma página de wiki para cada funcionalidade, tutoriais passo a passo, vídeos longos, uma biblioteca inteira, sempre atualizada. Era precisa, bem organizada e nós nos orgulhávamos dela.

Eles não liam.

E a fila de suporte se encheu de perguntas que já estavam respondidas. Não algumas delas — a maioria. Perguntadas e respondidas numa página que nós tínhamos escrito, ou paradas num menu a três cliques de distância. Por muito tempo, lemos isso como um problema de documentação, e nossa resposta foi escrever mais documentação.

Nunca foi um problema de documentação. É o mesmo problema da interface, movido um nível acima. Uma wiki é um índice para o modelo mental de outra pessoa. Lê-la é um projeto menor do que aprender os menus, mas ainda é um projeto, e ainda é um projeto sobre nós em vez de ser sobre o trabalho deles.

Ninguém tem capacidade de aprender o produto de outra empresa, o menu de outra empresa e a wiki de outra empresa. Eles têm o próprio trabalho a fazer.

Então eis o que as pessoas fazem em vez disso, e é a coisa mais antiga que fazemos.

Elas perguntam.

Perguntam o que isso significa. Perguntam por que aquilo aconteceu. Pedem para que algo seja feito.

É assim que cada pessoa lida com cada outra pessoa — um amigo, um filho, um professor, um aluno, um colega, um funcionário, um membro do conselho. Ninguém lê o manual de um colega. Você pergunta a eles, eles respondem e, se algo precisa ser feito, eles fazem. Perguntar não é um atalho de gente que teve preguiça de ler. É a interface que os seres humanos usam uns nos outros desde que existem seres humanos, e é extraordinariamente boa: não precisa de treinamento, funciona no primeiro dia, tolera perguntas vagas e permite que você descreva um problema com as palavras que você realmente tem, e não com as palavras que outra pessoa escolheu.

Cada cliente que abria um chamado respondível pela nossa própria wiki não estava falhando em usar o nosso software direito. Eles estavam usando a interface que eles realmente têm.

Nós é que não estávamos do outro lado dela.

Porque o que eles acionavam era uma pessoa na nossa empresa, e essa pessoa tem uma fila, e um fuso horário, e um fim de semana. Então o pedido entrava, e aí começava a espera — e a espera é o custo inteiro.

Eles queriam aquilo agora. Ou na noite passada. O que receberam foi na próxima quinta-feira.

Eles não querem esperar para que seja feito. Eles não querem aprender para que seja feito. Essas são as duas únicas opções que a última geração podia oferecer, e nossos clientes tinham toda a razão de estarem insatisfeitos com ambas.

Então a régua pela qual nos medimos agora não é mais a que costumávamos usar.

Uma capacidade não está pronta quando funciona. Não está pronta quando ganha uma página de configurações, e certamente não está pronta quando tem uma página na documentação. Ela está pronta quando você consegue descrever o que quer com as suas próprias palavras — as palavras que usaria com um colega, não o nome que por acaso demos à funcionalidade — e o agent entende o que você quer dizer, diz o que está prestes a fazer, e faz.

Qualquer coisa menos que isso ainda é pedir para que alguém aprenda o nosso produto primeiro.