SkyPark do zero ao topo: como arrancámos um parque sem reservas, sem reviews e sem nome
Há uma coisa que ninguém te diz quando abres um parque de aeroporto: no primeiro dia, ninguém sabe que existes.
O Google não te ranqueia. O Booking não te lista. O cliente que procura "parking aeroporto Lisboa barato" vai para os três suspeitos do costume — os que têm 2.000 reviews acumuladas em sete anos. E tu? Tens um portão, asfalto fresco e silêncio.
Foi assim que o SkyPark arrancou. Sem brand, sem ranking, sem histórico — mas com uma vantagem que demorámos a perceber que era uma vantagem: arrancámos com a stack toda já montada.
Este post é sobre como a Multipark App transformou um parque novo num parque que parece operar há cinco anos. Não é storytelling de pitch deck. São as funcionalidades reais, os problemas reais, e o que mudou na operação diária.
Contexto: porque é que arrancar do zero em parking de aeroporto é mais difícil do que parece
O mercado português de parking de aeroporto é maduro. Lisboa tem dezenas de operadores. Porto e Faro um pouco menos saturados, mas igualmente competitivos no orgânico. O cliente decide em três fatores, por esta ordem:
- Preço (o filtro inicial)
- Reviews (o filtro de confiança)
- Tempo até ao terminal (o filtro de conveniência)
Um parque novo perde no fator 2 quase por definição. Não tem reviews. Mesmo que tenha boas instalações, está num purgatório de seis a doze meses até ganhar tração orgânica.
A nossa hipótese para o SkyPark foi simples: se compensarmos a falta de reviews com previsibilidade operacional radical, ganhamos confiança suficiente para os primeiros 1.000 clientes — e a partir daí, o motor arranca sozinho.
Previsibilidade operacional radical. O que é que isto quer dizer na prática?
- O shuttle chega quando dizemos que chega.
- O cliente sabe onde está o shuttle no telemóvel.
- O agente da recepção tem o nome do cliente, a matrícula, o terminal, o voo, o ETA, tudo num ecrã.
- Quando algo corre mal, o supervisor sabe antes do cliente reclamar.
Tudo isto vive na Multipark App. Vou-te dizer exatamente como.
O que é a Multipark App, sem marketing
Para evitar confusões: a Multipark App não é uma app de telemóvel para o cliente final. É a plataforma operacional interna que corre todas as marcas do grupo (AirPark premium, SkyPark low-cost, RedPark) em Lisboa, Porto e Faro — e em breve Madrid.
Stack, para quem gosta de cheirar o motor:
- Frontend operacional (Barnie): React 19 + TypeScript, Tailwind, shadcn/ui, wouter para routing
- Backend: NestJS + tRPC
- Base de dados: PostgreSQL (Supabase) para queries analíticas, Firebase Realtime Database para escrita rápida no booking flow
- Pagamentos: Stripe (one-time, subscriptions e marketplace splits para a vertical de transfers)
- Integrações externas: Flightradar24 (ETAs de voo), Odoo (ERP financeiro), Google Ads e Windsor.ai (atribuição)
A app divide-se em vários módulos. Vou cobrir os seis que tiveram impacto direto no arranque do SkyPark.
1. Motor de reservas multi-brand desde o dia 1
A primeira tentação quando lanças uma marca nova é dizer "vou montar o site, ligar ao stripe, e depois a operação que se entenda". Já vi isso correr mal demasiadas vezes.
No SkyPark, fizemos o oposto: a reserva entra na pipeline única da Multipark, com brand="skypark" como uma flag. Mesma estrutura de dados, mesmas validações, mesmo sync. Muda o branding, muda o pricing, muda o tone of voice — mas a infraestrutura é a mesma.
2. Barnie — o backoffice onde a operação realmente acontece
O Barnie é o ERP/backoffice interno. O nome é interno, mas a função é universal: é onde os agentes (recepção, condutores, supervisores) vivem oito horas por dia.
Funcionalidades que entraram em jogo no arranque do SkyPark:
- Dashboard com KPI cards customizáveis por role. O agente da recepção vê reservas do dia, no-shows, late arrivals. O supervisor vê ocupação, revenue per slot, pickup time médio. O CEO vê P&L por brand.
- Atribuição de slots e matrículas. Quando o cliente entrega o carro, o agente atribui o slot, a matrícula, tira foto, e a reserva passa a
parked. Tudo num formulário só, com validação contra o estado do parque. - Gestão de transfers. Cada shuttle tem um driver, uma rota, uma capacidade. O Barnie atribui clientes a shuttles em função do voo e do terminal — não por ordem de chegada, que é a forma estúpida que ainda vês por aí.
A peça que mais nos ajudou no SkyPark foi a separação clara entre operação e financeiro. O agente vê o que precisa para operar. O financeiro corre noutro plano (módulo Multipark Finance, módulo 5). Isto evita o erro clássico de parques pequenos: o mesmo agente a tratar de logística e a tentar reconciliar pagamentos com Stripe e Caixa Geral. Não escala e gera erros.
O dark mode "Dark Precision" — sim, foi um capricho estético, mas há um motivo prático: os agentes operam frequentemente com luz fraca (madrugadas, recepções com painéis de vidro contra o sol) e o contraste alto reduz fadiga visual em turnos longos.
3. Página operacional com GPS em tempo real
Esta é a feature de que mais me orgulho, e a que mudou mais a operação do SkyPark.
A página /operational mostra um mapa em tempo real com:
- Localização GPS de todos os shuttles ativos (refresh a cada 5 segundos)
- Velocidade instantânea de cada shuttle (lista lateral ordenada)
- Estado do telemóvel do driver — online / offline / GPS desligado / bateria abaixo de 20%
- ETA dinâmico para o terminal com base em tráfego (Google Maps API por baixo)
Porque é que isto é crítico no SkyPark? Porque o SkyPark é low-cost, o que significa que opera com menos shuttles do que o AirPark e estes têm de rodar mais vezes. Sem visibilidade em tempo real, perdes 10-15 minutos por rotação só em comunicações por WhatsApp ("onde estás?", "estou a chegar"). Com 30+ rotações por dia, são horas perdidas.
Os alertas que correm em background:
- GPS off há mais de 60 segundos → notificação ao supervisor
- Telefone do driver offline → notificação ao supervisor + tentativa de contacto automática
- Bateria do telefone abaixo de 15% → alerta amarelo (importante porque um driver com bateria a zero é um driver sem ETAs)
- Velocidade acima do limite urbano em zona aeroportuária → registo (não punitivo, observabilidade)
Construir isto custou tempo. Operar sem isto custaria muito mais.
4. Flight ETA com Flightradar24 — a peça que ninguém vê mas que faz tudo funcionar
O cliente reserva, viaja, aterra, e quer um shuttle no terminal. A pergunta operacional é: quando exatamente é que ele vai estar à espera no ponto de pickup?
Resposta naïve: hora de chegada do voo + 30 minutos.
Resposta real: depende de mil coisas — atraso do voo, controlo de fronteira, recolha de bagagem, distância do terminal ao pickup, hábitos do cliente. Os 30 minutos default são uma fonte enorme de ineficiência.
Construímos um sistema de resolução de ETA com seis prioridades, em cascata:
- Realtime do Flightradar24 — posição do avião + previsão de touchdown
- Estimated time publicado pela companhia (vs. scheduled)
- Histórico do voo — média dos últimos 30 dias para a mesma rota e companhia
- Padrão de rota / companhia — alguns operadores são consistentemente atrasados em determinadas rotas
- Manual override do agente — quando o cliente liga a dizer "estou na alfândega"
- Default scheduled — fallback final
Estas chamadas correm em paralelo (não em série) e a resposta volta em sub-segundo. O resultado é uma janela de pickup precisa que é injetada na atribuição de shuttles do módulo de transfers.
Resultado mensurável no SkyPark: redução do tempo médio de espera do cliente comparando os primeiros três meses (sem este sistema, ETA = scheduled + 30min) com os meses seguintes (com cascata completa).
E há um efeito secundário que não estávamos à espera: as reviews dos primeiros clientes mencionavam frequentemente a pontualidade do shuttle. Para um parque novo a tentar acumular reviews, isto é ouro.
5. Multipark Finance — visibilidade financeira em tempo (quase) real
O quinto módulo é financeiro. Single-file HTML, internamente, mas com integração com Excel mensal de reservas + ficheiros de Google Ads spend.
O que faz:
- Importação automática de Excel mensal de reservas com parsing robusto (separadores decimais portugueses vs. ingleses — sim, isto partia o ficheiro antes)
- Detecção automática da cidade a partir do parque (tinha um bug de matching que custou dois dias a apanhar)
- P&L por brand, por cidade, por mês
- Custo de aquisição (CAC) por canal cruzando Google Ads spend com reservas atribuíveis
- LTV estimado por brand com base em frequência de retorno
Para o SkyPark, no arranque, isto serviu para uma coisa específica: decidir pricing em ciclos de uma semana, não de um mês. Quando vês que o CAC está a subir num canal, ajustas o pricing ou cortas o canal antes de queimares orçamento de marketing. Para um parque novo a otimizar a curva de aquisição, esta velocidade decide se sobrevives ou não nos primeiros seis meses.
6. Alertas e observabilidade — o sistema imunitário
O último componente é o menos visível e o mais importante. A Multipark App tem alertas em vários níveis:
- Operacionais: GPS off, driver offline, transfer atrasado, slot duplo atribuído
- Financeiros: reserva sem pagamento confirmado há mais de X minutos, refund pendente, Stripe webhook falhado
- Sincronização: lag entre Firebase e Supabase acima de Y segundos, falha no sync de algum campo
A regra de ouro: se algo correu mal, queremos saber antes do cliente. Um cliente que liga a reclamar de um pagamento não processado é um cliente que já está irritado. Um cliente a quem ligamos a dizer "vimos que houve um problema com o pagamento, já está resolvido" é um cliente impressionado.
No SkyPark, com volume baixo no início, os alertas eram quase mais úteis do que num parque maduro — porque cada interação contava em dobro para a perceção de qualidade.
O que mudou, em concreto, com tudo isto
Não vou fingir que tenho métricas precisas para partilhar publicamente. O que posso dizer com confiança:
- O SkyPark conseguiu operar com um rácio supervisor:driver mais magro do que parques comparáveis no mercado porque a visibilidade no dashboard substitui parte do trabalho de coordenação manual.
- A taxa de "pickup atrasado" (cliente espera mais de 10 minutos no ponto de pickup) ficou consistentemente abaixo da média do setor desde o terceiro mês.
- A taxa de erro em atribuição de slots (cliente a chegar e não haver slot livre quando devia haver) ficou em níveis residuais — o Barnie bloqueia overbooking automaticamente.
- O custo marginal de adicionar um novo parque é uma fração do custo de adicionar o primeiro. A próxima cidade (Madrid) herda 90% da infraestrutura.
Lições para quem está a arrancar uma operação física com componente digital
Se estás a montar um parque, um car wash, um hotel, um pet hotel, um whatever — algumas coisas que aprendi a martelar para dentro:
1. Não comeces com Excel "só para já". O "só para já" dura três anos e depois custa-te um refactor que mata a operação durante meses.
2. Backoffice antes do site público. O cliente final vê o site bonito, mas o que o faz voltar é o agente eficiente do outro lado. Investe primeiro em quem opera, depois em quem vende.
3. Multi-brand desde o dia 1, mesmo que só tenhas um brand. A flag brand numa tabela custa zero. O refactor para suportar multi-brand depois custa carradas.
4. Alertas > dashboards. Dashboards bonitos são vaidade. Um alerta a chegar ao Slack quando algo está mal é o que te poupa um cliente.
5. Visibilidade em tempo real paga-se sozinha. A primeira vez que vês o supervisor a coordenar 4 shuttles no telemóvel a partir do mapa, em vez de andar a ligar para drivers, percebes porquê.
6. ETA decente vale mais do que parking decente. O cliente perdoa um parque feio. Não perdoa esperar 25 minutos por um shuttle que disseram que vinha em 5.
Conclusão
O SkyPark não cresceu por causa do site. Não cresceu por causa de campanhas geniais de Google Ads. Cresceu porque, quando o primeiro cliente chegou, a operação atrás dele já tinha cinco anos de bagagem técnica disfarçada num parque novo.
A Multipark App não é mágica. É infraestrutura paciente — código que ninguém vê e que faz com que o cliente não tenha de pensar. E em parking de aeroporto, "não ter de pensar" é exatamente o produto que estamos a vender.
Se estás a arrancar algo parecido e queres trocar dois dedos de conversa sobre stack ou operação, manda mensagem. Tenho cicatrizes para partilhar.
