Guia de Avaliação de Fornecedores para Concursos de Análise de Receitas de Lojistas

Três propostas em cima da mesa. As três prometem 99% de precisão de contagem, as três afirmam integrar-se com qualquer POS, e as três apresentam dashboards praticamente idênticos nas capturas de ecrã. Se está a avaliar um concurso de análise de receitas de lojistas para um centro comercial, um aeroporto ou um portefólio de retalho público, este é o momento em que a maioria dos processos de procurement falha: os critérios do caderno de encargos foram escritos de forma tão genérica que qualquer fornecedor consegue responder "sim" a tudo. A diferença entre um contrato que funciona durante oito anos e um que gera litígios sobre renda variável no segundo ano decide-se antes da adjudicação — nas cláusulas, não na demonstração.

Porque é que a renda variável muda tudo

Um sistema de análise de receitas de lojistas não é um projeto de business intelligence comum. Quando a renda de um lojista depende do volume de negócios declarado, os dados do sistema tornam-se prova contratual. Isto tem três consequências práticas para quem redige o concurso:

• A precisão tem de ser contratual, não comercial. Uma afirmação de "até 99%" numa brochura não tem valor jurídico. Exija um mínimo garantido no contrato, com metodologia de auditoria definida. Um fornecedor sério aceita, por exemplo, um mínimo contratual de 96%, com desempenho típico de 98–99% quando as condições de iluminação, layout e comportamento dos visitantes o permitem. Desconfie de quem garante 99% sem qualificações: ou não mede em condições reais, ou não pretende cumprir.
• A metodologia de validação deve estar no caderno de encargos. Defina como se audita: contagens manuais em vídeo, amostras por hora de ponta e hora morta, entradas problemáticas (portas duplas, carrinhos de bebé, grupos). Sem metodologia acordada, a garantia de precisão é inexequível.
• A propriedade dos dados tem de ser inequívoca. Os dados de tráfego e de receitas dos lojistas pertencem ao proprietário do ativo, não ao fornecedor. Inclua cláusula de exportação completa em formato aberto no fim do contrato, sem custos adicionais.

O erro mais caro: comprar hardware e software juntos

Muitos concursos exigem, implícita ou explicitamente, que o fornecedor de software seja também o fabricante dos sensores. Parece prudente — um único responsável — mas cria dependência dupla. Se o sensor for descontinuado ou o preço subir na renovação, o comprador fica preso porque substituir o hardware implica substituir a plataforma inteira, com nova migração de histórico e nova formação dos gestores de centro.

A alternativa é exigir independência de dispositivos como critério eliminatório: a plataforma deve funcionar com sensores de múltiplos fabricantes e permitir substituir hardware em fases sem perder continuidade de dados. Isto é particularmente relevante em portefólios mistos, onde diferentes centros já têm sensores instalados de gerações e marcas diferentes. Uma plataforma agnóstica de sensores permite aproveitar o investimento existente onde a qualidade o justifica e substituir apenas onde a precisão está abaixo do mínimo contratual — em vez de um "rip and replace" total que triplica o CAPEX do projeto.

Integração: a pergunta certa não é "integra?", é "com que esforço?"

Num centro comercial médio há dezenas de sistemas POS diferentes entre os lojistas, além do ERP do proprietário, ferramentas de BI e, cada vez mais, CRM de marketing do centro. Todos os fornecedores dizem que "têm API". A questão de avaliação correta é outra: quantas integrações POS estão em produção hoje, e quem paga o desenvolvimento de conectores novos durante a vigência do contrato? Plataformas com uma camada de integração dedicada — a Vemco, por exemplo, faz isto através do VemFusion para POS, BI, ERP e CRM — reduzem o risco de cada novo lojista se transformar num mini-projeto de desenvolvimento pago à hora.

Inclua no caderno de encargos um cenário de teste concreto: "novo lojista com POS X abre em março; descreva o processo, o prazo e o custo para que as suas vendas apareçam no relatório de renda variável de abril." As respostas a esta pergunta separam fornecedores maduros de fornecedores que aprenderam à custa dos clientes anteriores.

Hosting e requisitos do setor público

Para compradores públicos e para proprietários com políticas de dados rigorosas, a opção entre cloud alojada pelo fornecedor e cloud privada não pode ser um "a definir na implementação". Deve ser um requisito com resposta binária no concurso, com o modelo de responsabilidades (patching, backups, disponibilidade) descrito para cada opção. Exija também clareza sobre onde os dados residem fisicamente e sobre conformidade com o RGPD — dados de contagem de pessoas são, em regra, anónimos, mas a integração com vendas por lojista cria informação comercialmente sensível que os contratos de arrendamento frequentemente obrigam a proteger.

Uma observação de quem já implementou isto

Um detalhe que raramente aparece nos cadernos de encargos e que decide o sucesso do projeto: a fase mais difícil não é técnica, é a recolha das declarações de vendas dos lojistas. Nos primeiros seis meses, é normal que 20 a 30% dos lojistas entreguem dados atrasados, em formatos errados ou com valores que não batem certo com o tráfego registado. O fornecedor certo tem um processo operacional para isto — lembretes automáticos, portais de submissão para lojistas sem integração POS, alertas de plausibilidade que cruzam vendas declaradas com tráfego contado. Pergunte especificamente como o fornecedor gere lojistas não cooperantes; quem nunca o fez em produção responde com generalidades sobre APIs.

Matriz de avaliação sugerida

• Garantia contratual de precisão com metodologia de auditoria (eliminatório): mínimo de 96% escrito no contrato, com processo de verificação acordado.
• Independência de hardware (eliminatório): suporte comprovado a sensores de múltiplos fabricantes e migração faseada.
• Integrações em produção (25% da pontuação): lista verificável de conectores POS/ERP/BI ativos, com referências contactáveis.
• Processo de gestão de lojistas (20%): portais de submissão, validação de plausibilidade, escalonamento de incumprimentos.
• Escalabilidade e longevidade (15%): capacidade demonstrada desde um ativo único até portefólios enterprise, e histórico do fornecedor no mercado — plataformas com quase duas décadas de operação e milhares de clientes dão outra confiança num contrato de 8 anos do que uma startup de série A.
• Modelo de hosting e conformidade (15%): opções claras, responsabilidades definidas, residência de dados documentada.
• Condições de saída (10%): exportação de dados históricos, período de transição, ausência de custos de reversibilidade.

Note o que não está na matriz com peso relevante: o aspeto dos dashboards. É o critério em que os avaliadores gastam mais tempo nas demonstrações e o que menos prediz o sucesso do contrato. Interfaces mudam; garantias contratuais, arquitetura de integração e processos operacionais são o que ainda estará a funcionar — ou a falhar — no quinto ano.

Está a preparar um concurso de análise de receitas de lojistas e quer validar requisitos técnicos, cláusulas de precisão ou o modelo de integração antes de publicar o caderno de encargos? Fale com a equipa da Vemco Group — respondemos a perguntas de pré-consulta, partilhamos exemplos de requisitos utilizados em concursos reais e explicamos exatamente o que podemos garantir por contrato e em que condições.