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.
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:
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.
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.
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.
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.
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.