Gerenciamento de frotas de e-scooters. Escalando sem interromper as operações

Um operador de mobilidade compartilhada começou a enfrentar problemas de escalonamento à medida que sua frota de e-scooters se expandia por várias cidades. Fluxos de pagamento, monitoramento de conformidade, alertas de segurança e automações de manutenção gradualmente se tornaram mais difíceis de gerenciar dentro de um único fluxo operacional. Cada nova automação resolvia um problema, mas tornava o sistema geral mais difícil de manter, solucionar e escalar.

Este estudo de caso explora como o operador reorganizou suas automações, separou domínios operacionais e mudou sua abordagem de gerenciamento de frotas de e-scooters à medida que o negócio continuava crescendo.

Por que escalar o gerenciamento de frotas de e-scooters se torna operacionalmente difícil

Para frotas de e-scooters compartilhadas, até pequenos atrasos operacionais se tornam imediatamente visíveis. Os usuários esperam que as scooters sejam desbloqueadas quase instantaneamente após a confirmação de pagamento. Quando isso não acontece, as viagens são abandonadas, os tickets de suporte se acumulam e os operadores começam a perder receita antes mesmo da viagem iniciar.

Mas os problemas de pagamento para iniciar o uso são apenas uma parte da pressão que os operadores de mobilidade compartilhada enfrentam diariamente. Roubo, adulteração, movimentação não autorizada, conformidade de limite de velocidade, gerenciamento de bateria e regulamentações específicas de cada cidade adicionam suas próprias camadas de caos operacional. Cada cidade nova traz requisitos de relatório diferentes. Cada novo fluxo de trabalho introduz mais alertas, mais dependências e mais maneiras de sistemas não relacionados interferirem repentinamente uns com os outros.

Gerenciar uma frota de 200 e-scooters, embora não seja uma tarefa operacional simples, ainda parece relativamente gerenciável.

Escalar para 2.000 scooters distribuídas por várias cidades, equipes e regras operacionais começa a parecer como tentar coordenar vários sistemas sobrepostos enquanto incidentes, alertas e atualizações de fluxo de trabalho surgem por todos os lados.

“Isto está bem” © KC Green

Essa foi exatamente a situação que um operador de mobilidade compartilhada enfrentou ao expandir sua frota. Fluxos de pagamento, monitoramento de conformidade, alertas de segurança e automações de manutenção gradualmente se tornaram difíceis de gerenciar dentro de um único fluxo operacional.

Mas vamos detalhar.

Estudo de caso: automatizando operações de e-scooters compartilhadas

Um operador europeu de mobilidade compartilhada abordou inicialmente o problema a partir da perspectiva da experiência do usuário.

A empresa enfrentava uma frustração crescente em relação a atrasos na ativação da corrida. Os usuários concluíam o pagamento no aplicativo, ficavam ao lado da scooter esperando pelo desbloqueio e, às vezes, desistiam da viagem completamente se o processo demorasse muito.

Em frotas menores, esses incidentes eram gerenciáveis manualmente. Mas, à medida que a frota se expandia por várias cidades, os tickets de suporte relacionados ao desbloqueio atrasado começaram a aumentar, juntamente com reclamações dos usuários e sobrecarga operacional.

O operador decidiu automatizar o processo de pagamento para início de uso utilizando IoT Logic.

Observação: IoT Logic é um ambiente de baixo código para telemática e automação IoT. Fluxos de trabalho que antes exigiam desenvolvimento de backend e integrações personalizadas podem ser configurados visualmente em menos de uma hora, dependendo da complexidade.

O fluxo inicial aguardava uma sinalização de confirmação de pagamento no fluxo de telemetria de entrada. Assim que a plataforma detectava que o atributo personalizado de pagamento havia mudado para um estado confirmado, o fluxo acionava um M2M GPRS command automatizado para liberar remotamente a trava da scooter. Ao mesmo tempo, a telemetria continuava sendo encaminhada para a Navixy para fins de monitoramento e rastreamento.

A automação em si era relativamente simples. Confirmação de pagamento como entrada, comando de desbloqueio como saída.

A latência para iniciar a corrida diminuiu. A confiabilidade do desbloqueio melhorou. As reclamações dos usuários diminuíram.

Mais importante, o operador descobriu a rapidez com que as automações operacionais podiam melhorar a capacidade de resposta da frota sem exigir integrações profundamente acopladas ou desenvolvimento de backend adicional.

Expansão para fluxos de trabalho de conformidade e segurança

Depois de automatizar o processo de pagamento para início de uso, o operador começou a analisar outros gargalos operacionais e processos repetitivos que poderiam ser tratados automaticamente à medida que a frota continuava crescendo.

A conformidade de velocidade era determinada por requisitos municipais. Cidades em toda a Europa e nos Estados Unidos adotaram limites de 25 km/h para e-scooters compartilhadas, e muitas exigem que os operadores relatam violações sustentadas. O operador precisava de uma forma de detectar quando um usuário excedia esse limite em mensagens de telemetria consecutivas, filtrando picos de GPS, e criar um registro de incidente com coordenadas, carimbo de data/hora e ID do dispositivo.

Um webhook node poderia enviar esse incidente para o CRM, criando um registro de conformidade sem intervenção manual.

A detecção de movimentação não autorizada abordava outra pressão operacional: scooters em movimento sem sessão ativa de aluguel. Esse padrão frequentemente indicava roubo ou adulteração. O operador queria disparar um alerta para a equipe de operações, anexar coordenadas de GPS e ativar remotamente o alarme onboard da scooter.

A detecção de adulteração ia além. Abertura do compartimento, remoção do rastreador e padrões anormais de vibração indicavam que alguém estava tentando desativar ou roubar a scooter. Esses eventos precisavam ativar imediatamente o alarme, encaminhar os dados de posição para a Navixy e criar um incidente de segurança para a equipe de resposta.

Cada automação resolvia uma dor operacional real. Cada automação foi inicialmente adicionada ao fluxo existente.

Por que a configuração original parou de funcionar

Como costuma acontecer, esse tipo de escalonamento não ocorreu sem complicações.

Dessa vez, a razão foi uma limitação de arquitetura do IoT Logic. Um dispositivo usado como fonte de dados só podia pertencer a um fluxo por vez. Usá-lo em uma nova automação o removia automaticamente do fluxo anterior.

A solução alternativa parecia razoável no início. O operador combinou a lógica de pagamento, conformidade de velocidade, alertas de segurança e detecção de adulteração em um grande fluxo que lidava com tudo ao mesmo tempo.

Tecnicamente, funcionou. No entanto, tornou-se difícil de manter muito rapidamente.

Cada nova automação tornava o fluxo mais frágil. A solução de problemas começou a levar mais tempo porque a lógica de pagamento, conformidade, segurança e manutenção estavam todas interconectadas. Atualizar uma parte do fluxo significava arriscar processos não relacionados em toda a frota.

O sistema que visava simplificar as operações parecia gradualmente se transformar em outro gargalo operacional por si só.

Transição para automações operacionais modulares

O ponto de virada ocorreu quando a plataforma permitiu que o mesmo dispositivo participasse de vários fluxos independentes do IoT Logic simultaneamente. O que antes exigia um fluxo operacional excessivamente grande agora podia ser separado em domínios operacionais específicos sem duplicar fluxos de telemetria ou acoplar automações não relacionadas.

O operador reconstruiu suas automações em quatro fluxos separados:

• Fluxo de pagamento: a confirmação de pagamento aciona o comando de desbloqueio
• Fluxo de conformidade: se houver excesso de velocidade sustentado, gera incidente no CRM
• Fluxo de segurança: movimentação não autorizada aciona alerta e alarme
• Fluxo de adulteração: abertura ou remoção do compartimento aciona alarme e encaminha posição

Cada fluxo recebia a mesma telemetria do dispositivo. Cada fluxo operava de forma independente. Modificar a lógica de conformidade não afetava a lógica de pagamento. Testar o fluxo de segurança não exigia testar o fluxo de adulteração.

Vamos detalhar rapidamente.

Fluxo 1: Desbloqueio da scooter após pagamento

Gatilho: Um evento de confirmação de pagamento aparece no fluxo de telemetria, indicando que o usuário concluiu a transação.

Ação: IoT Logic envia um comando remoto de desbloqueio via GPRS. O controle de saída da scooter é ativado, liberando a trava física. A sessão de uso começa.

Propósito: Reduzir a fricção no início da corrida. Os usuários esperam uma resposta imediata após o pagamento. Atrasos geram frustração e abandono.

Fluxo 2: Relato de violação de limite de velocidade

Gatilho: A velocidade ultrapassa 25 km/h em mensagens de telemetria consecutivas. O requisito de mensagens consecutivas filtra picos de GPS e breves acelerações, capturando apenas violações sustentadas.

Ação: Um webhook cria um incidente no CRM com coordenadas, carimbo de data/hora, leitura de velocidade e ID do dispositivo. A equipe de conformidade recebe um registro pronto para relatório municipal.

Propósito: Conformidade municipal e responsabilização do usuário. Muitas cidades exigem que os operadores documentem e tratem violações de velocidade como condição de suas licenças de operação.

Fluxo 3: Detecção de movimentação não autorizada

Gatilho: A scooter relata movimentação sem existir uma sessão de aluguel paga ativa. Esse padrão sugere que a scooter está sendo movimentada sem autorização.

Ação: Um webhook alerta a equipe de operações com as coordenadas de GPS. Ao mesmo tempo, o fluxo envia um comando remoto para ativar o alarme onboard da scooter. A telemetria continua sendo encaminhada para a Navixy para rastreamento.

Propósito: Reduzir o tempo de resposta a roubos e melhorar a recuperação de ativos. O alarme chama atenção. As coordenadas permitem envio de equipe. A telemetria fornece um histórico de localização.

Fluxo 4: Detecção de adulteração

Gatilho: A scooter relata abertura do compartimento, remoção do rastreador ou atividade de vibração anormal. Esses sinais indicam adulteração física.

Ação: O alarme onboard é ativado imediatamente via comando remoto. Os dados de posição são encaminhados para a Navixy. Um evento de incidente de segurança é enviado ao centro de operações de segurança.

Propósito: Reduzir o tempo de inatividade relacionado a adulteração e fortalecer a proteção antifurto. A ativação imediata do alarme desencoraja a adulteração contínua. O encaminhamento de posição permite a recuperação.

Resultados estratégicos para operadores de mobilidade compartilhada

Separar as automações em fluxos independentes deu ao operador muito mais flexibilidade à medida que a frota continuava crescendo. Em vez de recriar constantemente um sistema grande e único, as equipes podiam escalar e adaptar fluxos de trabalho de forma independente.

• Expansão mais rápida em novas cidades
  Os fluxos de conformidade podiam ser ajustados às regulamentações locais sem redesenhar automações de pagamento, segurança ou manutenção.

• Menor risco operacional
  Problemas em um fluxo já não afetavam sistemas não relacionados em toda a frota.

• Responsabilidade mais simples pelos fluxos de trabalho
  As equipes de conformidade, segurança e operações podiam gerenciar e atualizar suas próprias automações de forma independente.

• Experimentação mais segura com novas automações
  Novos fluxos de trabalho podiam ser testados e implantados gradualmente sem tornar todo o sistema mais difícil de manter.

Escalando operações de frota sem escalar o caos operacional

Para operadores de mobilidade compartilhada, escalar uma frota deixa de ser apenas um problema de hardware ou logística e se torna um problema de gerenciamento de fluxos de trabalho. Quanto mais cidades, requisitos de conformidade, automações e equipes operacionais são adicionados a uma frota, mais difícil se torna evitar que sistemas não relacionados interfiram uns com os outros.

Neste caso, separar as automações em fluxos independentes do IoT Logic forneceu ao operador uma forma de continuar escalando sem transformar a própria camada de automação em outro gargalo operacional. E, à medida que as operações de mobilidade compartilhada continuam se tornando mais complexas, esse tipo de flexibilidade passa a ser tão importante quanto a própria frota.

Se você tem limitado suas automações porque os dispositivos só podiam pertencer a um fluxo por vez, talvez seja o momento certo de revisar como seus fluxos de trabalho estão estruturados. Agende uma demonstração para discutir suas automações e explorar como elas poderiam ser tratadas com IoT Logic.