Um gestor de alojamentos com quem falámos tinha acabado de gastar 9.000 euros a construir um sistema automático para enviar mensagens de boas vindas e instruções de check in. Funcionava bem. As mensagens saíam a horas, na língua certa, com os códigos certos. As reservas continuavam a não converter mais rápido e o proprietário continuava a aprovar cada orçamento à mão, às 11 da noite. O verdadeiro constrangimento nunca foi a mensagem de boas vindas. Era o processo de orçamentação, e ninguém lhe tinha tocado.
Isto acontece constantemente. Uma equipa gasta dinheiro e meses a automatizar um passo que já funcionava bem, enquanto o constrangimento real continua a consumir noites e fins de semana.
Porque é que isto continua a acontecer
Projetos de automação costumam começar com a pergunta "o que podemos automatizar" em vez de "o que nos está realmente a travar." São perguntas diferentes com respostas diferentes.
O passo que se automatiza primeiro é normalmente o mais fácil de ver, não o mais caro. Mensagens de boas vindas, pedidos de avaliação, publicações nas redes sociais. Tudo visível, tudo repetitivo, tudo de baixo risco se algo correr mal. Entretanto, aquilo que realmente limita o crescimento é normalmente algo mais lento e mais confuso: orçamentos, aprovações, ou uma decisão que só o proprietário tem confiança para tomar.
Três padrões a verificar antes de construir seja o que for.
Procura onde as coisas esperam, não onde as coisas se repetem. A repetição parece o alvo óbvio porque é irritante. Mas irritante não é o mesmo que caro. Procura o passo onde o trabalho fica numa fila à espera de uma pessoa. Essa fila é normalmente onde a receita é atrasada ou perdida.
Pergunta o que só o proprietário consegue fazer atualmente, e porquê. Se a resposta for "porque só eu sei calcular este preço" ou "porque não confio em mais ninguém para aprovar reembolsos," esse é o teu constrangimento. Raramente é um passo de comunicação. É quase sempre um passo de julgamento que nunca foi transformado num sistema.
Calcula o custo do atraso, não da tarefa. Uma tarefa que demora cinco minutos mas fica três dias em espera antes de alguém a tratar não é um problema de cinco minutos. É um problema de três dias. Automatizar os cinco minutos não resolve nada em relação aos três dias.
Um cenário com números
Imagina um operador turístico com 40 pedidos de orçamento por semana. Valor médio do orçamento, 600 euros. Neste momento, todos os orçamentos precisam da aprovação do proprietário antes de serem enviados, e o proprietário só tem disponibilidade para os rever duas vezes por dia. O atraso médio entre pedido e envio do orçamento é de 14 horas.
A taxa de conversão em orçamentos enviados dentro de uma hora é 38 por cento. A taxa de conversão em orçamentos enviados depois de 14 horas é 21 por cento. Essa diferença, em 40 orçamentos por semana a 600 euros cada, representa cerca de 4.000 euros por semana perdidos. Num ano são mais de 200.000 euros, todos dentro de um atraso que ninguém tinha identificado como o problema.
Agora imagina esse mesmo operador a gastar 9.000 euros a automatizar o design do modelo de orçamento e os emails de seguimento. Resultado bonito. Zero efeito no constrangimento, porque o constrangimento nunca foi o modelo. Era a fila de aprovação.
A solução aqui não é "remover o proprietário." É construir regras de preço claras e limites de aprovação para que 80 por cento dos orçamentos nunca precisem de verificação humana, e os restantes 20 por cento sejam sinalizados para uma decisão rápida em vez de ficarem numa caixa de entrada geral. Isto é trabalho de sistemas, não trabalho de software. O software é só a forma como o sistema corre depois de as regras existirem.
Diagnostica antes de construir
Antes de qualquer projeto começar, mapeamos onde o trabalho fica realmente em fila, quem é o ponto único de aprovação, e quanto custa esse atraso em números reais. Só depois decidimos o que se sistematiza e o que fica manual de propósito.
Esta é a parte que a maioria dos fornecedores de automação salta, porque vender uma ferramenta é mais rápido do que fazer o diagnóstico. É também por isso que tantos destes projetos não produzem nada mensurável seis meses depois.
Se quiseres um segundo olhar sobre onde está o teu constrangimento real, marca uma chamada de 20 minutos. Olhamos para a fila, não para a ferramenta.
Podes também ver como pensamos sobre isto de forma mais ampla na nossa página inicial.
Perguntas frequentes
Como sei se estou a automatizar o processo errado? Verifica se o processo que queres automatizar é um onde o trabalho fica em espera por uma pessoa, ou um que já corre rápido e apenas se repete. Se nada espera, provavelmente não estás a tocar no constrangimento real.
O que deve vir antes de qualquer projeto de automação? Um diagnóstico curto sobre onde os pedidos ficam em fila, quem aprova o quê, e quanto custa esse atraso em receita perdida ou atrasada. Isso vem antes de qualquer decisão sobre ferramentas.
Equipas pequenas conseguem fazer este diagnóstico sozinhas? Sim, com tempo e honestidade sobre onde o proprietário é o bottleneck. A maioria dos proprietários acha mais rápido e mais preciso ter alguém de fora do negócio a mapear isto, já que costumam estar demasiado próximos da fila para a ver com clareza.