Fala com quem opera antes de desenhar software

Comprar software pelo dashboard bonito é fácil. Mais difícil é perceber porque é que a equipa de vendas ainda aprova descontos num grupo de WhatsApp, apesar de já ter um sistema para gerir clientes. Se desenhares a solução sem perceber essa diferença, podes acabar com mais um ecrã que ninguém consulta e com as mesmas decisões a acontecer fora dele.

A direcção vê objectivos, etapas e resultados esperados. Quem opera vê os pedidos que chegam incompletos, as esperas e as excepções que não cabem no fluxo apresentado numa reunião. Na Seamless Doubt, começamos por ouvir ambos. A descrição da direcção ajuda a perceber o que se pretende; o trabalho de quem executa mostra se essa descrição corresponde à realidade.

• Se não souberes quem decide o próximo passo, vais automatizar o caos.

• Um processo descrito numa reunião ainda é uma hipótese.

• O software só ajuda quando acompanha o trabalho real, incluindo as excepções.

Um dashboard não explica o trabalho

Antes de escolher uma plataforma, percebe porque é que a equipa contorna a que já tem. Num processo de vendas, esse desvio pode ser um grupo de WhatsApp onde se aprovam descontos. A direcção pode ver uma decisão simples. Quem vende pode estar a tentar obter uma resposta rápida, confirmar uma margem ou resolver um caso que o sistema não prevê.

Cada explicação aponta para um problema diferente. Talvez falte uma regra de aprovação. Talvez a informação necessária esteja espalhada por várias ferramentas. Talvez ninguém saiba quem tem autoridade para decidir. Se começares pelo dashboard, arriscas-te a desenhar um espaço bonito para um processo que continua por esclarecer.

O mesmo acontece com os leads recebidos por formulário. Um CRM pode mostrar estados e responsáveis, mas isso não garante que alguém saiba o que fazer quando falta informação ou quando o pedido não encaixa nas categorias previstas. A interface torna o processo visível. Não decide por si qual deve ser o processo.

O que a direcção descreveu e o que vimos no terreno

Num cliente, a direcção descreveu o fluxo de uma forma simples: «o fluxo é X». Quando nos sentámos com quem fazia o trabalho, o percurso era outro: «o fluxo é Y e demora o triplo porque falta a password do portal».

A diferença não estava numa preferência de interface. Havia uma dependência concreta que não aparecia na versão da direcção: sem a password do portal, o operador não conseguia avançar. O trabalho ficava à espera, e o tempo gasto era o triplo do que a descrição inicial fazia prever.

Esse detalhe muda o desenho. Se automatizássemos a sequência apresentada pela direcção, teríamos acelerado apenas os passos que já estavam visíveis. A espera continuaria. E o novo sistema podia tornar ainda menos claro onde o processo tinha parado.

Foi por isso que o percurso observado teve mais peso do que a descrição inicial. A versão da direcção continuou a ser útil para perceber o resultado pretendido. Mas não podia servir, sozinha, de base para construir a solução.

A espera custa mais do que minutos

Uma etapa parada pode atrasar uma resposta, ocupar tempo de quem tem de ir atrás da informação e deixar a responsabilidade pouco clara. Num processo de leads, isso pode significar que o pedido fica sem seguimento enquanto a equipa procura dados, aguarda uma validação ou tenta perceber quem deve assumir o caso.

O efeito não se resolve sempre com uma automatização. Se a password está em falta, automatizar os passos seguintes não a faz aparecer. Se a aprovação depende de uma pessoa que não está identificada, criar um novo estado no CRM não resolve quem tem de decidir. O sistema pode até registar a pendência, mas a operação continuará parada.

É aqui que a conversa com quem executa protege o investimento. Ajuda-te a separar o atraso que uma ferramenta pode reduzir daquele que depende de uma regra, de informação ou de uma responsabilidade ainda por definir. Sem essa distinção, é fácil pagar para digitalizar o bloqueio.

O fluxo real inclui excepções

O percurso habitual não chega para desenhar uma solução que aguente o trabalho diário. Um pedido pode chegar sem um dado necessário, vir duplicado ou exigir uma aprovação que não se aplica à maioria dos casos. São estas situações que levam muitas equipas a recorrer a mensagens e folhas paralelas.

Acompanhar um pedido recente ajuda a perceber o que acontece de facto: onde chega, quem o abre, que informação procura e onde fica à espera. Depois, importa confirmar se esse percurso é frequente ou se foi uma excepção. Um único caso não representa a operação inteira, mas pode revelar uma pergunta que a descrição do processo deixou de fora.

Também convém perceber se a diferença entre pessoas é legítima. Se cada operador encaminha o mesmo tipo de lead de maneira diferente, talvez exista uma regra por acordar. Se há motivos válidos para caminhos diferentes, o processo deve permitir essa distinção. Forçar todos os casos para o mesmo percurso só para simplificar o desenho pode criar mais trabalho fora do sistema.

A tecnologia deve acompanhar a maturidade da operação

Escolhe a ferramenta depois de perceberes o que falha. Se a informação está dispersa, pode ser preciso criar um registo fiável. Se existe um registo, mas ninguém sabe quem age a seguir, é a responsabilidade que precisa de clarificação. Se uma tarefa se repete e as regras já são estáveis, então pode fazer sentido automatizá-la.

Um agente de inteligência artificial não resolve dados incompletos nem critérios que mudam de pessoa para pessoa. Pode acrescentar uma camada de supervisão a uma operação que ainda não consegue manter a informação ou explicar quem toma cada decisão. Nessa fase, a tecnologia acrescenta complexidade sem resolver a causa.

Por vezes, a resposta certa é «isto agora não». Primeiro, a equipa precisa de conseguir usar a ferramenta, guardar a informação e perceber que pedidos avançam. Depois, pode avaliar-se se uma automatização mais autónoma tem lugar. A medida certa depende do que a operação consegue sustentar, não do que fica melhor numa demonstração.

Antes de dar o desenho por fechado, alguém que faça o trabalho deve conseguir tratar um pedido normal sem uma explicação oral a cada passo. Também deve conseguir perceber o que fazer quando o pedido sai do percurso habitual. Se a pessoa tiver de voltar ao WhatsApp para descobrir quem decide, o problema continua por resolver.

Perguntas frequentes

Tenho de falar com toda a equipa antes de desenhar software?

Não necessariamente. Começa com quem recebe e trata os pedidos, e inclui quem decide o encaminhamento ou acompanha os resultados. Se as versões forem diferentes, percebe primeiro onde divergem. Essa diferença pode ser o problema que a solução tem de resolver.

E se a direcção já tiver um processo documentado?

Usa-o como ponto de partida, não como prova de que a operação funciona assim. Acompanha um caso real com quem o tratou e confirma se as etapas, esperas e decisões coincidem com o documento.

Quando devo automatizar o tratamento dos leads?

Quando sabes quem fica responsável, que informação precisa e como são tratados os casos fora do padrão. Se estas regras ainda dependem de quem está de serviço, clarifica-as antes de automatizar.

Conclusão

Antes de pedires uma proposta de software, escolhe um pedido recente e percorre-o com a pessoa que o tratou. Compara esse percurso com a versão da direcção. Regista onde houve espera, que informação faltou e quem teve de decidir o passo seguinte.

Depois, escolhe a causa que queres corrigir e testa a alteração com quem vai trabalhar nela. Se ainda não consegues explicar o que acontece quando falta uma password, uma aprovação ou um dado do formulário, não feches o desenho. Primeiro, percebe o processo. Só depois faz sentido pedir ao software que o acompanhe.