Software de dispatch para aluguer: como planear entregas, motoristas e equipamentos

Levar um único equipamento de um depósito a um cliente é um problema resolvido: escolhe-se um motorista, dá-se-lhe uma morada, e ele parte. Levar doze ou vinte equipamentos a doze ou vinte clientes diferentes no mesmo dia, alguns a serem entregues, outros recolhidos, alguns já comprometidos com uma janela fixa da manhã, outros flexíveis, é um problema completamente diferente. É tanto um exercício de sequenciação como de horários: que paragens estão perto umas das outras, que motorista já vai naquela direção, e que moradas são realmente acessíveis, apurado antes de uma rota ser acordada, em vez de descoberto depois de uma carrinha estar carregada e a caminho.

É precisamente essa a parte do dispatch de aluguer à qual se dá menos atenção. Há muito a dizer sobre o que acontece depois de um motorista partir, desde a aplicação do motorista que utiliza na estrada até à experiência de entrega que o cliente vê enquanto espera, e ainda mais sobre a captura de provas sólidas no momento da entrega. Este artigo trata do passo anterior a tudo isso: o ecrã de planeamento no escritório, onde a rota do dia é efetivamente construída, antes de qualquer motorista sair do depósito. Se a rota for mal construída, nenhuma aplicação polida nem prova de entrega corrige o que se segue: um motorista que atravessa o mesmo código postal três vezes num dia, uma paragem que ninguém percebeu estar fora da área de serviço até estar estacionado à sua frente, ou a visita semanal de um cliente habitual esquecida porque ninguém reconstruiu a rota a partir da lista da semana anterior.

O ponto de partida para a rota do dia deve ser as reservas já existentes, não uma lista nova escrita por quem estiver a planear rotas nessa manhã. Um pedido de aluguer já contém a morada de entrega, os artigos que saem ou regressam, o contacto no local e as datas envolvidas, porque essa informação foi recolhida quando o pedido foi feito, não inventada no momento do dispatch. Voltar a introduzir qualquer um desses dados numa ferramenta de planeamento separada é exatamente onde se introduzem erros: um dígito trocado num código postal, um número de contacto copiado da linha errada, uma quantidade de artigos que se afasta discretamente do que foi efetivamente orçamentado.

Na Renttix, as tarefas de entrega e recolha são planeadas diretamente num quadro de dispatch, a partir do próprio pedido em vez de uma folha de cálculo paralela. Isto importa mais do que parece: a pessoa que planeia a rota do dia trabalha a partir do mesmo registo onde está o pedido do cliente, pelo que uma alteração feita a um pedido, uma quantidade corrigida, um contacto de local diferente, uma data reagendada, é exatamente a alteração que aparece no quadro, em vez de algo que tenha de ser transmitido separadamente a quem gere o plano de rotas.

Assim que as tarefas do dia existem, o passo seguinte é organizá-las de forma a que um motorista as consiga percorrer numa ordem sensata. Isto não tem nada de extraordinário: agrupar entregas e recolhas próximas entre si na mesma rota, em vez de enviar um motorista a ziguezaguear pela cidade enquanto outro cobre três ruas mais além, é um princípio básico e bem conhecido do planeamento de rotas. A vantagem é simples: menos quilómetros, menos minutos desperdiçados entre paragens, e uma rota que um motorista consegue guardar de cabeça em vez de a seguir paragem a paragem ditada por um GPS sem noção do que vem a seguir.

No quadro de dispatch, as tarefas são agrupadas por rota e atribuídas diretamente a motoristas, para que quem planeia o dia consiga ver toda a forma de uma rota à medida que é construída: que paragens ficam bem juntas, que motorista já tem um dia mais leve e pode assumir mais uma, e que tarefas ainda não foram atribuídas a ninguém. Construir essa visão no quadro de dispatch, em vez de fazer malabarismos entre uma lista impressa e um mapa separado, faz da rota um único plano, não vários documentos que têm todos de coincidir até os motoristas partirem.

Um dos problemas mais evitáveis no planeamento de dispatch é uma morada que nunca deveria ter sido aceite à partida. Uma reserva feita por telefone, ou uma morada de cliente antiga reutilizada para um pedido novo, pode ficar fora da área que um depósito consegue realmente servir, e a primeira vez que alguém o descobre é quando um motorista está estacionado junto a um portão, quarenta minutos depois da janela prevista, ao telefone com o escritório a perguntar o que deve fazer.

A Renttix trata isto na fase de planeamento, não na estrada. Cada depósito tem uma área de serviço definida como um polígono desenhado num mapa, e as moradas de entrega são verificadas em relação a ela. Um pedido feito através de uma loja online associada é bloqueado antes do checkout se a morada estiver fora da cobertura do depósito relevante, pelo que a reserva nunca chega a ser aceite. Para pedidos que chegam ao quadro por outra via, aplica-se a mesma verificação quando o dia é planeado: uma paragem fora da área de serviço de um depósito é assinalada como fora de área no quadro de dispatch enquanto a rota ainda está a ser construída, não depois de uma carrinha ter saído do depósito. Essa é a diferença que importa: a conversa sobre se uma tarefa é realista acontece no ecrã de planeamento, com tempo para a reatribuir ao depósito certo ou confirmar com o cliente, em vez de no telemóvel de alguém parado na berma.

Grande parte do negócio de aluguer é negócio repetido: o mesmo cliente a levar os mesmos artigos no mesmo dia todas as semanas, ou um contrato que se estende durante meses com entregas e recolhas em intervalos fixos. Planear uma rota a partir de uma folha em branco todos os dias, mesmo para clientes cujo padrão nunca muda, é esforço desperdiçado, e é também um risco de fiabilidade. Se construir a rota de amanhã depender de alguém se lembrar de que um determinado cliente tem uma visita semanal pendente, mais cedo ou mais tarde alguém vai esquecer-se.

Os horários recorrentes resolvem isto gerando eles próprios as tarefas de dispatch. O padrão é definido uma única vez, e a partir daí, as entregas e recolhas correspondentes aparecem automaticamente no quadro nos dias certos, já atribuídas à sua rota habitual. Um depósito que planeia a semana seguinte não começa do zero; as visitas recorrentes já estão posicionadas nos dias correspondentes, e o verdadeiro trabalho de planeamento consiste em encaixar as tarefas novas ou pontuais em torno do horário que já existe.

Um caso relacionado, mas distinto, é o de um aluguer que inclui a sua própria componente de assistência contínua, em vez de uma entrega pontual seguida de uma eventual recolha. Uma casa de banho portátil num aluguer longo que precisa de manutenção todas as semanas é o exemplo mais claro: a unidade sai apenas uma vez, mas um motorista tem de voltar ao local num ciclo fixo durante toda a duração do aluguer, e cada uma dessas visitas é uma tarefa própria, com o seu próprio registo de ter acontecido.

Adicionar uma linha de serviço a um pedido trata isto diretamente: a Renttix gera então o calendário de visitas para toda a duração do aluguer, e cada visita é acompanhada ao longo do seu próprio ciclo de vida, desde agendada, passando por concluída, até pronta a faturar. Este último passo importa tanto para o planeamento como para a faturação: uma visita concluída que está em pronta a faturar é um sinal visível de que a tarefa aconteceu e foi encerrada corretamente, em vez de algo que tenha de ser reclamado separadamente no final do mês.

Planear bem a rota é metade do trabalho; saber como está realmente a correr depois de os motoristas saírem é a outra metade. Assim que uma tarefa é atribuída e um motorista a está a realizar, o seu estado é visível para o escritório em tempo real. Uma tarefa em curso, em espera ou concluída aparece no mesmo quadro em que foi planeada, em vez de só se tornar conhecida quando o motorista regressa ao depósito no final do dia.

Para quem faz o dispatch, essa é a diferença entre reagir a um problema enquanto ainda há tempo para fazer algo a esse respeito, e descobri-lo depois do facto. Se uma tarefa mais à frente numa rota vai atrasar-se porque uma paragem anterior demorou mais do que o previsto, isso é visível enquanto o resto do dia ainda pode ser ajustado. A própria experiência do motorista com a tarefa, a captura de assinaturas, fotografias e o resto, é um tema que merece o seu próprio artigo; do lado do planeamento, o que importa é que o quadro de dispatch e a aplicação do motorista leem a mesma tarefa subjacente, não dois sistemas separados que têm de ser reconciliados à mão.

Tomemos, a título de exemplo, um depósito que planeia as entregas e recolhas do dia seguinte numa rota mista: um punhado de novos pedidos pontuais recebidos nessa semana, vários alugueres de longa duração com a visita de assistência semanal pendente, e duas recolhas de alugueres que estão a terminar. Nada disso precisa de ser montado a partir de listas separadas. Os pedidos pontuais estão no quadro porque foram reservados como pedidos desde o início; as visitas de assistência semanais já lá estão porque foram geradas pelas suas linhas de serviço; e as recolhas estão no quadro porque a data de fim do seu aluguer as despoletou. O verdadeiro trabalho de quem planeia nessa manhã é verificar qualquer morada assinalada como fora de área, agrupar as paragens restantes em rotas sensatas por zona, e atribuí-las aos motoristas de serviço, não reinventar uma rota que, na sua maioria, já lá estava, à espera de ser organizada.

É precisamente por isto que vale a pena tratar o planeamento de dispatch como uma disciplina própria, distinta tanto da aplicação do motorista como do registo de entrega: é a fase em que um dia se transforma num plano realista e bem sequenciado, ou numa lista de boas intenções que se desmorona a meio da manhã. Se quiser ver como seria uma rota mista como esta no seu próprio quadro de dispatch, com os seus próprios depósitos, áreas de serviço e clientes habituais, marque uma demonstração e mostramos-lhe passo a passo.