Uma caixa de entrada para todos os canais

Uma mensagem entra às nove e vinte e três. Ao meio-dia ainda não teve resposta — não por má vontade, mas porque três pessoas a viram e cada uma assumiu que outra estava a tratar dela. É este o problema que uma caixa de entrada única resolve, e note-se que não é um problema de canais: é um problema de dono.

Este artigo tem dois vizinhos. Um trata da arquitetura — como se reúnem pedidos de vários canais sem perder a origem de cada um. O outro trata da equipa — quem atende o quê quando tudo passa a chegar à mesma lista. Falta o que está no meio, e é do que se fala aqui: o que é, na prática, uma caixa de entrada única, o que entra nela, o que é melhor que fique fora, e o que acontece a uma conversa do princípio ao fim.

Não é um ecrã que mostra tudo

A imagem que se vende é a de um ecrã onde aparecem, lado a lado, as mensagens de todos os canais. É a parte visível e é a menos importante. Um ecrã que mostra tudo e mais nada é uma pilha de coisas por fazer que ninguém consegue fechar.

O que torna uma caixa de entrada útil são três atributos por conversa, e nenhum deles é o canal:

• Um estado. Por atender, atribuída, à espera do cliente, terminada. Sem estado não há lista, há acumulação.
• Um responsável. Uma pessoa, não uma equipa. «Vendas» não responde a ninguém.
• Um próximo passo com data. Sobretudo nas conversas que ficam à espera de terceiros, que são as que desaparecem sem que ninguém repare.

Se os três existirem, a caixa pode até estar organizada de forma feia e continua a funcionar. Se faltar um, o desenho mais bonito não a salva.

O que entra, e o que é melhor que fique fora

A tentação é meter tudo lá dentro. É um erro, e é o erro que dá razão a quem preferia as caixas separadas. O critério pode ser simples: entra o que é uma conversa com alguém que está à espera de resposta. O resto fica fora.

Isso deixa fora notificações automáticas de outros sistemas, subscrições e boletins, alertas internos e, sobretudo, mensagens de canais onde não é possível saber com quem se está a falar. Este último caso merece atenção: uma mensagem sem identidade nenhuma — sem nome, sem contacto, sem histórico — não pode ser ligada a um cliente e vai sujar a lista até alguém a apagar à mão.

Há ainda uma decisão que costuma ser esquecida: as conversas internas. Falar com um colega sobre um pedido é trabalho útil, mas não é atendimento, e se as duas coisas partilharem a mesma lista os tempos de resposta deixam de querer dizer nada. A nota interna vive dentro da conversa do cliente; não é uma conversa da lista.

O percurso de uma conversa, do princípio ao fim

Vale a pena percorrer isto com um caso concreto na cabeça — um pedido de orçamento que chega de manhã. São seis passos, e todos têm de existir:

• Chega e é identificada. Ou corresponde a um cliente conhecido, ou cria um contacto novo. Se ficar sem identidade, tudo o que vem depois é trabalho perdido.
• Recebe estado e dono, por uma regra escrita e não por quem chegou primeiro ao ecrã.
• Junta-se ao que já existe. Se houver um negócio aberto ou um trabalho em curso com aquele cliente, a conversa passa a fazer parte dele em vez de viver ao lado.
• É trabalhada, e o que se promete fica escrito. Um prazo dito numa mensagem é um compromisso da empresa, não daquela pessoa.
• Fecha com um estado que explica o fim. Resolvida, sem resposta do cliente, encaminhada para outro sítio. «Fechada» sem razão não ensina nada a ninguém.
• Deixa rasto na ficha do cliente. Daqui a oito meses, quem atender o contacto seguinte tem de poder ler isto sem pedir favores a colegas.

Se um destes seis passos depender de alguém se lembrar, é aí que a caixa vai falhar primeiro — e vai falhar numa semana de muito trabalho, que é quando custa mais.

Sem regra de estado, juntar tudo é pior do que ter caixas separadas

Isto é contraintuitivo e é a parte mais importante do artigo. Quando cada canal tem a sua janela, a operação é ineficiente mas tem uma propriedade acidental: cada janela tem um dono implícito. Quem abre o chat do site é quem trata do chat do site. É frágil, não sobrevive a férias, mas funciona.

Ao juntar tudo numa lista sem regra de estado nem de atribuição, essa propriedade desaparece e não é substituída por nada. Passa a haver uma lista que é de todos, e uma lista que é de todos não é de ninguém. O resultado é pior do que o ponto de partida: mais conversas visíveis, menos conversas com dono, e a sensação partilhada de que «está ali, alguém vê».

Por isso a ordem importa. Primeiro a regra de estado e de atribuição, depois a junção dos canais. Quem faz ao contrário tem de recuar, e recuar depois de a equipa ter perdido a confiança na lista é bastante mais caro do que ter esperado duas semanas.

Como montar a primeira versão sem parar a operação

Comece por dois canais e não por seis, e escolha os dois por onde entram os pedidos que custam dinheiro quando ficam sem resposta. Escreva a regra de atribuição numa linha antes de ligar o que for. Defina os estados, que são poucos, e proíba os estados de conveniência do género «em análise», que só servem para tirar a conversa da frente sem a resolver.

Ao fim de duas semanas, olhe para a lista à procura de uma coisa só: conversas sem dono com mais de um dia. Se existirem, a regra não é regra e não vale a pena acrescentar canais. Se não existirem, junte o terceiro.

Se quiser fazer esse desenho com alguém, é por aqui que começa uma sessão de diagnóstico: percorremos os canais por onde os seus clientes falam hoje, decidimos o que entra na fila e com que estados, e só depois se fala de ecrãs. O âmbito está em omnicanal e IA, e a ordem por que trabalhamos em o nosso modelo.