O fornecedor falhou. E agora?
O credenciamento travou, o app não funcionou, o site caiu no pico. Antes de trocar por impulso, entenda o que falhou e o que perguntar ao próximo.
por nox. · 8 min de leitura · atualizado em março 2025
Quando a tecnologia falha no dia do evento, trocar o fornecedor é a reação natural. Mas trocar sem entender o que falhou cria o risco de repetir o problema. A decisão entre corrigir, trocar, ou repensar a arquitetura depende do tipo de falha.
Resumo rápido. Antes de trocar de fornecedor por impulso depois de uma falha no evento, separe o tipo: falha de escala (não dimensionou pra carga real), falha de integração (sistemas não conversam), falha de processo (treinamento ou entrega tardia) ou falha estrutural (o produto não foi feito pra esse tipo de evento). Cada uma sugere uma ação diferente. Trocar resolve falha estrutural. Falha de processo costuma ser corrigível com o fornecedor atual. O importante é não repetir o mesmo erro com o próximo.
Quais tipos de falha existem e o que cada uma significa?
| Tipo de falha | Exemplo | O que indica | Ação provável |
|---|---|---|---|
| Falha de escala | Site caiu com 50 mil acessos, app travou no pico de check-in | O fornecedor não dimensionou pra carga real | Perguntar se testaram carga. Se não, é negligência técnica. |
| Falha de integração | Dados de credenciamento não chegaram no CRM, pixel não trackeou conversão | Sistemas não foram conectados corretamente (ou não podem ser) | Avaliar se a integração era escopo do fornecedor ou gap entre fornecedores |
| Falha de processo | Equipe no portão não sabia usar o sistema, app tinha informação desatualizada | Treinamento insuficiente ou entrega tardia | Pode ser resolvível com o mesmo fornecedor se o produto é bom |
| Falha de produto | Sistema de credenciamento não suporta +1 nomeado, app não funciona offline | O produto não atende o caso de uso do evento | Trocar. O produto não vai mudar entre uma edição e outra. |
| Falha de suporte | Fornecedor inacessível no dia do evento, tempo de resposta >2h durante crise | O fornecedor não opera eventos, só entrega software | Trocar. Modelo de negócio incompatível com evento ao vivo. |
Quer ajuda pra diagnosticar o que falhou e o que perguntar ao próximo fornecedor? Manda um alô com o contexto.
Antes de trocar: o diagnóstico que a maioria pula.
A falha visível (site caiu, app travou) raramente é a causa raiz. Antes de procurar outro fornecedor, responda:
- O escopo estava claro? Se o contrato dizia "credenciamento digital" sem especificar volume, +1 nomeado ou offline, a falha pode ser de briefing.
- O fornecedor teve tempo? Se contratado 3 semanas antes, não houve tempo pra teste de carga, treinamento ou integração. Prazo curto = setup precário.
- Falha foi do fornecedor ou do ecossistema? App funcionava mas internet não. Credenciamento pronto mas equipe não foi treinada. Identifique onde na cadeia o problema aconteceu.
- O fornecedor respondeu? Diferença entre "falhou mas resolveu" vs "falhou e sumiu" decide troca. Resposta rápida pode valer manter.
Quando trocar é a decisão certa.
A troca é inevitável quando:
- O produto não atende o caso de uso. Quando o sistema de credenciamento não suporta as regras do evento, o problema é limitação de produto e nenhum patch resolve.
- O fornecedor não entende operação de evento. Agências e software houses que "também fazem eventos" frequentemente entregam UIs bonitas que não sobrevivem à pressão do dia. A realidade é que muitos eventos improvisa com planilhas e processos manuais durante crises porque o sistema "oficial" falhou.
- Padrão de falha repetido. Se o mesmo tipo de problema aconteceu na última edição e não foi corrigido, o fornecedor demonstrou que não trata eventos ao vivo como prioridade.
- Dados ficaram com o fornecedor. Se o fornecedor saiu e levou os dados da audiência, o evento perdeu um ativo. O próximo contrato precisa prever exportação e propriedade de dados.
Como eventos grandes lidam com evolução de fornecedor.
Trocar de fornecedor não precisa ser traumático quando é planejado:
- Lollapalooza Brasil: A evolução de formatos de ingresso ao longo das edições mostra a importância de manter dados ao migrar de fornecedor. Cada mudança de plataforma deve incluir plano de migração de dados históricos antes de fazer a troca.
- Rock in Rio (2024): Eventos de grande porte mantêm histórico de audiência quando trocam de fornecedor. A troca de parceiro não significa perder anos de dados. Isso é cláusula de contrato essencial.
- MotoGP Brasil (2026): Primeira edição em novo venue com 148.384 pessoas. Novo fornecedor, novo espaço: a decisão de padronizar a coleta de dados desde o dia 1 criou a base para comparação nas próximas edições. A lição é planejar coleta de dados estruturada, não improvisar depois.
O que perguntar ao próximo fornecedor antes de assinar.
"Mostra isso funcionando num evento real, não numa demo"
Demo funciona sempre. Evento ao vivo, com 10 mil pessoas, internet instável, e equipe aprendendo no dia é outra coisa. Peça referências de eventos comparáveis ao seu.
"Quem é responsável quando dá problema no dia do evento?"
Se a resposta é "abre um ticket de suporte", o fornecedor não opera eventos. Pra evento ao vivo, precisa de alguém acessível por telefone ou presencial no dia.
"O que acontece com meus dados se eu trocar de fornecedor?"
Se a resposta não inclui "exportação completa em formato aberto", os dados são do fornecedor, não do evento. Negocie isso antes de assinar, não depois de romper.
"Vocês fizeram teste de carga pro volume do meu evento?"
Se o evento espera 30 mil acessos simultâneos e o fornecedor nunca testou nesse volume, você é o teste de carga. No dia do evento.
"O que persiste entre edições?"
A base de audiência, o histórico de credenciamento, a configuração do app: o que sobrevive pra próxima edição e o que precisa ser refeito? Se tudo recomeça, o investimento não acumula.
"Qual é a contingência se o sistema cair no dia?"
Modo offline pra credenciamento, fallback pra check-in manual, cache local no app. Quem não tem plano B pro dia do evento nunca operou sob pressão real.
"Quantos eventos parecidos com o meu vocês operaram no último ano?"
"Parecidos" = mesmo porte, mesmo tipo, mesmo nível de complexidade. Um fornecedor que operou 50 eventos corporativos de 200 pessoas não tem experiência relevante pra um festival de 15 mil.
A nox. é parceira de tecnologia de eventos recorrentes como SPFW e SP Open: constrói o site, o app e a integração de dados, e fica presente no dia do evento com contingência e operação conjunta em vez de entrega e sumiço. Os critérios abaixo vêm dessa relação.
Na prática.
Cenário 1: falha de escala, fornecedor reconheceu. O site do evento caiu no lançamento de ingressos. O fornecedor identificou o problema (sem CDN configurada), corrigiu em 2h, e implementou auto-scaling pra próxima vez. Nesse caso, manter o fornecedor pode ser melhor do que trocar. Ele agora conhece o padrão de tráfego do seu evento.
Cenário 2: falha de produto, sem solução. O sistema de credenciamento não suporta convite com +1 nomeado. O fornecedor diz que "não está no roadmap." Se essa regra é essencial pro evento, a troca é inevitável, porque limitação de produto não se corrige entre uma edição e outra.
Cenário 3: fornecedor sumiu pós-evento. O app funcionou razoavelmente, mas o fornecedor não responde pra entregar o relatório de analytics e exportar os dados. Clássico perfil "entrega e desaparece." A troca é necessária, e o próximo contrato precisa prever entregáveis pós-evento e timeline de dados.
leia também: Como escolher um parceiro de tecnologia · Por que seu evento começa do zero a cada edição · Maturidade digital para eventos
Perguntas frequentes.
O fornecedor falhou mas é o mais barato do mercado. Devo manter?
Depende do custo real da falha. Se o credenciamento caiu e 5 mil pessoas ficaram na fila, o dano de reputação e a insatisfação do sponsor custam mais do que a diferença de preço. Compare custo total (contrato + risco de falha), não só o valor do contrato.
Posso processar o fornecedor pela falha?
Depende do contrato. Se não havia SLA definido (tempo de resposta, disponibilidade, penalidades), é difícil responsabilizar formalmente. Pro próximo contrato, inclua SLAs específicos pra evento-dia: tempo de resposta <15min, disponibilidade 99,9% durante o evento, penalidade por indisponibilidade.
Quanto tempo antes do evento devo contratar o novo fornecedor?
Mínimo 3 meses pra integração sob medida, 4-6 semanas pra plataforma genérica. Inclua tempo pra teste de carga e treinamento da equipe de campo. Se faltam menos de 3 semanas, o risco de setup precário é alto.
Como garantir que os dados da edição anterior migrem pro novo fornecedor?
Exija exportação completa (CSV ou API) do fornecedor atual como parte do encerramento do contrato. Se não está no contrato, negocie. É mais barato que recriar a base. Use email como chave primária pra conectar os dados entre sistemas.
O fornecedor diz que a falha foi culpa da internet do venue. Como sei se é verdade?
Pergunte: o sistema funciona offline? Se não, o fornecedor sabia que dependia da internet do venue e deveria ter testado antes. Sistema de credenciamento que depende de internet estável em venue de grande porte sem modo offline é decisão de arquitetura do fornecedor, não culpa do venue.
Vale a pena ter dois fornecedores diferentes pra reduzir risco?
Em operações de grande porte, pode fazer sentido ter redundância em pontos críticos (ex: credenciamento com backup manual). Dois fornecedores diferentes gerando dados desconectados é pior do que um fornecedor integrado. A redundância deve ser de contingência, não de operação paralela.
Como avaliar se o fornecedor opera eventos ou só vende software?
Três perguntas: (1) Quem fica de plantão no dia do evento? (2) O que aconteceu na última vez que algo deu errado num evento? (3) Posso falar com o produtor do último evento que vocês operaram? Se as respostas são vagas, é software house, não parceiro de evento.
tomou um perrengue com fornecedor de tecnologia na última edição?
conta o que aconteceu e a gente mostra como a gente opera, e o que muda. sem compromisso.