Aplicações para motoristas em empresas de aluguer: que funcionalidades devem incluir?

Para uma empresa de aluguer, a aplicação de motorista não é um extra logístico acrescentado à frota. É o único registo do que realmente aconteceu à porta do cliente. A que horas chegou a miniescavadora? O painel já estava riscado quando saiu do armazém? O responsável da obra assinou mesmo por quatro vedações ou por dez? Se a resposta a qualquer uma destas perguntas depender da memória de um motorista, de uma guia de remessa em papel esquecida na cabine, ou de uma fotografia perdida no rolo de fotos pessoal de um telemóvel, a empresa fica exposta sempre que um cliente contesta uma fatura ou um encargo por danos.

É por isso que «têm uma aplicação de motorista?» é a pergunta errada quando uma empresa de aluguer compara sistemas, ou decide finalmente abandonar as guias de remessa em papel. Quase todos os fornecedores responderão que sim. A pergunta certa é mais específica, e mais incómoda de fazer numa demonstração comercial: o que é que a aplicação realmente capta, obriga a essa captura em vez de a deixar opcional, e continua a funcionar quando um motorista entra numa cave técnica sem rede?

Este artigo percorre as funcionalidades que respondem a estas perguntas, como uma verdadeira lista de verificação do que procurar numa aplicação de motorista para aluguer, não como um discurso comercial.

Uma aplicação de motorista que existe separada da ferramenta que o escritório usa para planear o dia é apenas meio sistema. O trabalho que um motorista vê no telemóvel deve vir do mesmo quadro de planeamento usado para construir a rota, não de uma lista à parte que alguém retranscreve ou dita ao telefone.

Na Renttix, os trabalhos de entrega e recolha são planeados num quadro de planeamento, agrupados por rota e atribuídos diretamente aos motoristas; os calendários recorrentes geram os trabalhos automaticamente para clientes com visitas repetidas, para que uma visita semanal não dependa de alguém se lembrar de a criar. A cobertura geográfica também conta: cada armazém tem uma área de serviço definida como um polígono num mapa, os endereços de entrega são verificados em relação a essa área, e as encomendas feitas através de uma loja online associada são bloqueadas no pagamento se o endereço estiver fora dessa área. Quando o dia é planeado, qualquer endereço fora da área de serviço é assinalado no quadro de planeamento em vez de ser descoberto por um motorista já a meio de uma rota que nunca deveria ter recebido.

O teste prático para um comprador é simples: um trabalho pode ser criado, atribuído e alterado a partir do mesmo ecrã que o escritório já usa para planear rotas, ou manter a aplicação do motorista sincronizada torna-se um passo manual no dia de alguém?

Assim que um motorista está na estrada, o escritório precisa de saber em que ponto está cada trabalho sem ter de pegar no telefone. Uma aplicação de motorista que valha a pena deve enviar as alterações de estado para o escritório no momento em que acontecem, não no final do turno, quando o motorista volta a ter rede e se lembra de atualizar algo.

Isto importa por razões que vão além da curiosidade. Um cliente que pergunta por uma entrega obtém uma resposta em segundos em vez de uma chamada a um motorista que está agora inacessível porque está a conduzir. Um estado de «em espera» num trabalho, seja por acesso bloqueado, uma peça em falta ou uma dúvida sobre o local, chega ao escritório no momento em que acontece, enquanto ainda há tempo para agir, em vez de ser descoberto quando o motorista regressa ao armazém.

A Renttix Field envia exatamente estas atualizações: as alterações de estado do trabalho, como iniciado, em pausa, em espera, retomado e concluído, são todas visíveis para o escritório em tempo real à medida que o motorista avança no trabalho. Isto é uma afirmação bastante diferente de um mapa em direto que permite a um responsável acompanhar a posição de um motorista ao longo do dia. O valor aqui está no estado do trabalho, ligado aos eventos que realmente importam para o negócio, e não num ponto que se move num ecrã.

Caves, salas técnicas, obras em zonas rurais, os pisos inferiores de um parque de estacionamento, um empreendimento novo que ainda não tem cobertura móvel completa: estes são locais comuns e do dia a dia para uma entrega de aluguer, não casos excecionais. Se uma aplicação de motorista depender de uma ligação ativa para guardar uma assinatura ou uma fotografia, o registo ou não é captado de todo, ou o motorista tem de o refazer mais tarde de memória, altura em que vale muito pouco como prova.

O funcionamento offline por conceção é um padrão bem estabelecido em software de trabalho de campo em geral: o dispositivo trata primeiro o seu próprio armazenamento local como a fonte de verdade, e trata o servidor como algo que tem de recuperar o atraso assim que houver ligação disponível, e não o contrário. Vale a pena verificar se uma aplicação de motorista está realmente construída assim, em vez de simplesmente funcionar a maior parte do tempo quando a rede é boa.

A Renttix Field foi concebida offline-first desde o início. As assinaturas, fotografias, respostas a listas de verificação e mensagens são guardadas no dispositivo no momento em que são captadas e sincronizadas automaticamente assim que a ligação volta. Um motorista que termina um trabalho numa cave técnica não precisa de procurar um parapeito de janela com duas barras de rede para que o registo conte; já está guardado, e chega ao escritório assim que o telemóvel voltar a apanhar rede.

Captar provas e exigir provas são duas coisas diferentes, e é nessa diferença que vivem a maioria dos litígios. Uma aplicação de motorista que permite saltar uma assinatura, ou marcar um trabalho como concluído sem uma fotografia, será contornada precisamente no dia em que isso importava, normalmente o dia em que algo já estava danificado, ou o dia em que saiu a quantidade errada.

O que é preciso procurar é uma política de entrega que a plataforma aplique e não apenas incentive: um conjunto definido de provas, sejam assinaturas, fotografias ou leituras de contadores, que tem de existir antes de a aplicação permitir que o equipamento mude de mãos. Na Renttix, essa política é configurada uma vez e aplicada no momento da entrega, para que um motorista com pressa no final de uma rota longa não consiga concluir uma entrega ou recolha se faltarem as provas exigidas. Esta é uma garantia bastante diferente de um formulário que tem apenas, algures, um campo de assinatura.

A captura em si tem de cobrir bem o essencial: uma assinatura desenhada no ecrã com o nome de quem assina, fotografias de entrega e recolha, e leituras de contador ou de estado sempre que o equipamento o exija, tudo registado contra o trabalho específico e com a hora marcada pelo dispositivo, e não escrita depois pelo motorista. Tratamos a captura da prova de entrega com mais detalhe noutro artigo, incluindo o que um registo de entrega completo deve conter e os litígios que resolve. Aqui, a questão é mais ampla: a captura de provas é uma entre várias funcionalidades de que uma aplicação de motorista precisa, não tudo o que deve fazer.

Metade do valor de bons dados de campo é interno: faturação, litígios, o momento em que termina o aluguer. A outra metade é o que o cliente vê, e uma aplicação de motorista que só serve o escritório está a deixar escapar uma vantagem evidente.

Na Renttix, no momento em que um motorista parte, o cliente recebe um SMS ou um email, consoante os dados registados, com uma hora de chegada estimada e uma ligação de rastreio segura. A ligação abre uma página de mapa em direto sem necessidade de iniciar sessão nem instalar qualquer aplicação; a estimativa de chegada é recalculada com base no percurso rodoviário sempre que a página é atualizada, para que um cliente que verifique duas vezes veja uma resposta que reflete a posição real do motorista, e não uma estimativa fixa feita nessa manhã. Assim que o trabalho é concluído, a mesma página mostra a prova de entrega, para que o cliente não precise de ligar ao escritório para confirmar o que chegou.

Isto fecha um ciclo que, de outra forma, recai sobre a equipa telefónica: «onde está a minha entrega» é uma das chamadas mais comuns recebidas por um balcão de aluguer, e uma ligação de rastreio responde à pergunta antes mesmo de ela ser feita. O detalhe completo de como a Renttix trata isto está na página de experiência de entrega.

Entrega e recolha são apenas parte do panorama para muitas frotas de aluguer. Plataformas elevatórias, geradores e equipamento semelhante precisam de manutenção, e é comum que o mesmo motorista, ou um técnico que cobre a mesma rota, faça uma entrega de manhã e uma assistência de rotina noutro local da mesma zona à tarde. Se a aplicação que trata das entregas não conseguir também tratar de uma visita de assistência, a empresa acaba por gerir dois sistemas e duas formações distintas.

Uma aplicação de motorista que se estende à gestão de serviço de campo deve trazer listas de verificação geradas automaticamente com base no tipo de tarefa, em vez de um técnico a trabalhar de memória ou a partir de um cartão plastificado na carrinha. As peças consumidas do stock da carrinha devem ser registadas contra o trabalho e faturadas automaticamente, em vez de reconciliadas mais tarde a partir de um talão de combustível e de uma estimativa. Quando falta uma peça na carrinha, o técnico deve poder criar um pedido a partir do local; o trabalho fica em espera e o pedido chega à caixa de entrada de operações de campo do escritório, para que alguém trate de obter a peça em vez de o trabalho ficar silenciosamente parado. Quando é identificado trabalho adicional no local, pode ser emitido um orçamento de imediato, e a folha de trabalho preenchida é assinada no local e transformada de imediato num PDF, em vez de ser reconstruída mais tarde no armazém de memória.

É a mesma aplicação Renttix Field que os motoristas usam para entregas, alargada aos técnicos; o detalhe está na página de gestão de serviço de campo. Para uma empresa de aluguer que está a avaliar uma aplicação de motorista, a pergunta que vale a pena fazer é se ela pode crescer até este ponto sem precisar de um segundo software, mesmo que a assistência ainda não faça parte do trabalho hoje.

Tomemos, a título de exemplo, uma empresa de aluguer cujos motoristas cobrem tanto entregas como manutenção básica na mesma rota: entregando equipamento de acesso de manhã e fazendo verificações de segurança de rotina à tarde em unidades já junto de clientes. Para essa empresa, uma aplicação de motorista ganha o seu lugar ao fazer bem, em simultâneo, várias coisas pouco vistosas: retirar os trabalhos diretamente do plano de dispacho em vez de uma lista à parte, avisar o escritório no momento em que um trabalho fica em espera em vez de no final do dia, guardar uma assinatura e fotografias num parque de estacionamento subterrâneo sem rede, recusar-se a concluir uma entrega sem as provas que a política exige, enviar ao cliente uma hora de chegada por SMS sem que ninguém no escritório pegue no telefone, e tratar de uma lista de verificação de assistência e de um pedido de peças na mesma tarde sem mudar de aplicação.

Nada disto se destaca numa tabela de funcionalidades com marcas de visto. Isso vê-se em menos faturas contestadas, menos chamadas de «onde está a minha entrega», e num escritório capaz de responder a uma pergunta olhando para o trabalho em vez de ligar ao motorista. Este é o verdadeiro teste para uma aplicação de motorista de aluguer: não se a caixa está assinalada, mas se o registo que produz se mantém sólido no dia em que é preciso.

Se quiser ver como isto funciona com a sua própria frota, os seus próprios motoristas e os seus próprios casos particulares, as caves, as recolhas em zonas rurais, os dias em que falta uma peça, marque uma demonstração e mostramos-lhe com os seus próprios exemplos.