Lista de avaliação de fornecedores de plataformas de loteria: documento RFP prático
Uma solicitação de proposta (RFP) de plataforma de loteria deve descrever os fluxos de trabalho do operador, integrações, acesso a dados, controles, responsabilidades de entrega e evidências de aceitação. Separe requisitos obrigatórios de lançamento de preferências, pergunte a cada fornecedor como serão entregues e teste os cenários difíceis antes de assumir um compromisso. O resultado […]
Uma solicitação de proposta (RFP) de plataforma de loteria deve descrever os fluxos de trabalho do operador, integrações, acesso a dados, controles, responsabilidades de entrega e evidências de aceitação. Separe requisitos obrigatórios de lançamento de preferências, pergunte a cada fornecedor como serão entregues e teste os cenários difíceis antes de assumir um compromisso. O resultado deve ser um documento versionado de requisitos que siga para o contrato e o plano de implementação.
Esta lista ajuda a equipe de compras a preparar esse documento e comparar respostas. Ela não classifica fornecedores nem presume que determinada plataforma já ofereça as capacidades listadas abaixo. Cada item é um requisito a investigar e verificar.
1. Defina o escopo operacional antes de pedir uma demonstração
Comece pelas decisões já tomadas no projeto, pelas premissas ainda abertas e pelas pessoas autorizadas a resolvê-las. Registre:
- Produtos pretendidos: bilhetes de sorteios externos, sorteios próprios, Keno, jogos personalizados ou a combinação específica necessária.
- Mercados de clientes, marcas, idiomas, moedas, dispositivos e canais de distribuição pretendidos.
- Entidades e partes que devem operar a marca, fornecer a plataforma e cuidar de cada serviço externo.
- Fases de lançamento, volumes estimados de transações, períodos de pico esperados e evidências que sustentam essas estimativas.
- Sistemas ou dados existentes que precisam ser conectados, mantidos ou migrados.
- Restrições e requisitos operacionais fornecidos pelos assessores qualificados do operador e pelas contrapartes pertinentes.
- Premissas orçamentárias, responsáveis pelas decisões e dependências que podem afetar as datas de entrega.
Um insumo não resolvido deve ter um responsável e uma data de decisão. Registrá-lo como premissa é mais útil do que pedir ao fornecedor uma cotação para um escopo aparentemente completo que mudará durante a implementação.
A seleção de uma plataforma não resolve permissões de mercado, licenciamento ou questões tributárias. Peça aos assessores adequados que definam esses requisitos e depois os traduza nos fluxos de trabalho, controles de sistema e evidências que a RFP deve cobrir.
2. Escreva os requisitos como fluxos de trabalho e evidências de aceitação
O nome de um recurso raramente explica o resultado necessário. Por exemplo, “carteira” não diz ao fornecedor como saldos, liquidações, estornos e transações contestadas devem se comportar.
Use uma matriz de requisitos que conecte a jornada às evidências que você aceitará:
| Fluxo de trabalho | Requisito a descrever | Evidências a solicitar |
|---|---|---|
| Cadastro e verificação | Campos obrigatórios, estados de verificação de identidade, tratamento de exceções e visibilidade para o suporte | Uma jornada roteirizada com verificações bem-sucedidas, incompletas e rejeitadas |
| Compra de bilhete ou jogo | Regras do produto, encerramento das vendas, confirmação da compra e tratamento de cancelamentos | Um exemplo rastreável da criação do pedido ao resultado ou à liquidação |
| Carteira e pagamentos | Regras de saldo, depósitos, saques, reembolsos e conciliação | Registros de transações cobrindo um pagamento bem-sucedido, uma tentativa falha e um estorno |
| Sorteios e resultados | Fonte do resultado, mapeamento para o produto, tratamento de correções e regras de pagamento de prêmios | Uma demonstração do resultado à liquidação com referências às fontes e registros |
| Proteção do jogador | Limites e restrições de conta definidos para o modelo operacional | Testes mostrando como as restrições afetam as jornadas pertinentes de compra e pagamento |
| Operações de atendimento ao cliente | Reclamações, intervenções manuais, permissões e escalonamento | Visões por função e trilha de auditoria para um caso difícil de suporte |
| Relatórios e acesso a dados | Campos necessários, identificadores estáveis, formatos de exportação e frequência de acesso | Relatórios e exportações de exemplo que finanças e operações possam conciliar |
Atribua a cada requisito um identificador, prioridade, responsável pela aceitação e dependência. Acrescente uma breve explicação de sua importância. Responsáveis por produto, finanças, segurança, conformidade e atendimento devem conseguir revisar suas seções sem inferir o fluxo pretendido a partir de uma lista de nomes de módulos.
Para requisitos específicos de pagamento, use o guia da arquitetura de pagamentos de loteria junto com esta matriz.
3. Torne comparáveis as respostas dos fornecedores
Peça a todos os fornecedores pré-selecionados que usem as mesmas categorias de resposta. Elas descrevem a rota de entrega proposta, não uma nota de qualidade.
| Resposta | O que deve significar | Esclarecimento necessário |
|---|---|---|
| Disponível na versão indicada | O fornecedor consegue demonstrar o resultado exigido em uma versão identificada do produto | Versão, evidências e eventuais limites operacionais |
| Exige configuração | O resultado depende de ajustes ou trabalho de configuração acordado | Quem configura, esforço, validação e responsabilidade contínua |
| Exige desenvolvimento personalizado | O escopo proposto inclui funcionalidades ainda não entregues | Especificação, base de custo, dependências, critérios de aceitação e responsabilidade por mudanças |
| Dependência de fornecedor externo | Outro fornecedor ou serviço é necessário para atender ao requisito | Parte contratante, limite da integração, responsável pelo suporte e tratamento de falhas |
| Não suportado ou fora do escopo | A proposta não atende ao requisito | Impacto no escopo de lançamento e qualquer alternativa proposta |
Para cada linha, solicite responsável pela entrega, premissa, referência de evidência, tratamento comercial e dependência de prazo. Mantenha visíveis as perguntas sem resposta. Uma declaração de roteiro futuro não deve ser registrada como capacidade entregue.
Quando houver mais de uma parte envolvida, identifique a pessoa ou equipe que coordenará a jornada completa. Caso contrário, uma integração tecnicamente válida ainda pode deixar o operador sem responsável por exceções ou incidentes.
4. Inclua dados, integrações e requisitos de saída desde o início
O acesso a dados é um requisito operacional e também uma preocupação de saída. Especifique os registros necessários, quem pode acessá-los, os identificadores que os conectam e como as exportações serão entregues.
Limites das integrações
Para cada conexão necessária, documente os sistemas dos dois lados, os dados trocados, os tempos dos eventos, a abordagem de autenticação, o versionamento, o monitoramento e a responsabilidade pelo suporte. Descreva o que deve ocorrer após um tempo limite excedido, mensagem atrasada, callback duplicado ou parceiro indisponível.
Peça documentação representativa de interfaces e dados de teste. Um logotipo de integração ou uma demonstração comercial bem-sucedida não estabelece o comportamento do fluxo completo pretendido.
Propriedade, acesso e portabilidade
Solicite um inventário de registros de jogadores, pedidos, transações, resultados, suporte e auditoria. Defina campos necessários para cada função operacional, formatos de exportação, frequência, volume esperado e tratamento de correções. Registre o acesso durante as operações normais, implementação, incidente e encerramento do contrato.
Separe propriedade contratual, acesso prático e responsabilidades de tratamento de dados. Peça às partes responsáveis que avaliem requisitos de retenção, acesso e transferência para suas circunstâncias. O guia de propriedade dos dados de jogadores fornece perguntas adicionais de aquisição.
Exemplo: as compras funcionam, mas o histórico de transações não pode ser exportado
Nesta avaliação hipotética, uma demonstração conclui cadastro, depósito e compra de bilhete. O fornecedor ainda não consegue produzir uma exportação completa de transações com identificadores estáveis que vinculem registros de jogador, pedido, pagamento e liquidação.
Peça ao fornecedor que demonstre a exportação com volumes representativos e explique campos, prazos, limitações e qualquer trabalho adicional. Finanças e operações devem verificar se o resultado atende às necessidades de conciliação e investigação. Se a lacuna persistir, decida se uma alternativa testada pode atender ao requisito ou se a proposta deve permanecer fora da lista restrita.
Trate isso como uma dependência operacional atual, não uma pergunta a adiar até que a migração se torne urgente.
5. Especifique expectativas de segurança, desempenho e serviço
Registre os resultados de segurança e operação necessários ao projeto: permissões administrativas, registro de acesso, monitoramento, backups, recuperação, escalonamento de suporte e gestão de mudanças. Inclua medição de disponibilidade e desempenho, premissas de capacidade, acessibilidade e requisitos de localização.
Pergunte o que será medido, em qual período, por quem e com quais exclusões. Documente objetivos de recuperação e evidências esperadas de um exercício de recuperação. Evite tratar um percentual de disponibilidade ou selo de segurança como substituto para entender o escopo proposto e suas dependências.
O Framework de Cibersegurança do NIST é uma referência primária para estruturar discussões de risco cibernético. Use-o para organizar perguntas e evidências solicitadas; este guia não afirma que um fornecedor tenha sido avaliado segundo ele.
Para dados de cartões de pagamento, os recursos PCI DSS do PCI Security Standards Council descrevem requisitos técnicos e operacionais de segurança. Peça aos especialistas pertinentes de pagamentos e segurança que identifiquem escopo, responsabilidades e evidências de validação aplicáveis à arquitetura proposta. Uma integração externa de pagamentos, sozinha, não responde a essas perguntas.
6. Roteirize a demonstração em torno de exceções
Entregue aos fornecedores os mesmos cenários antes da sessão de avaliação. Inclua uma jornada bem-sucedida e casos que revelem transferências entre sistemas:
- Um caso de verificação que exija informações adicionais e uma resposta clara de suporte.
- Um callback de pagamento que chegue atrasado ou mais de uma vez.
- Uma compra tentada perto do encerramento de vendas configurado.
- Um resultado externo corrigido ou indisponível.
- Uma conta restrita tentando realizar uma transação pertinente.
- Um ajuste manual que exija usuário autorizado e registro rastreável.
- Um relatório ou exportação que finanças precise conciliar com os registros da plataforma.
Registre a versão do produto, premissas, comportamento observado e perguntas não resolvidas. Se um cenário não puder ser demonstrado, acorde as evidências adicionais necessárias em vez de marcá-lo como aceito.
7. Use uma matriz de decisão que mantenha visíveis as lacunas obrigatórias
Defina suas prioridades antes de revisar propostas. Um registro sugerido de decisão é:
| Área de decisão | Registro | Condição para a lista restrita |
|---|---|---|
| Resultados obrigatórios | Identificadores de requisitos e evidências da rota de entrega proposta | Nenhuma lacuna não resolvida sem alternativa viável expressamente aceita |
| Responsabilidade de entrega | Responsabilidades do operador, fornecedor e partes externas | Cada dependência e decisão de aceitação tem um responsável |
| Acesso a dados e controles | Evidências de exportação, permissões, registros e relatórios | O acesso operacional necessário é demonstrável e acordado |
| Exposição comercial | Implantação inicial, cobranças recorrentes, premissas de uso e trabalho opcional | A proposta explica o que o escopo cotado inclui e exclui |
| Implementação e suporte | Marcos, datas de dependências, escalonamento e processo de aceitação | O plano é consistente com o escopo e os requisitos de partes externas |
Pontue as preferências separadamente se a equipe de compras considerar útil. Não deixe uma nota alta em design ou recursos opcionais ocultar um requisito obrigatório ausente. Mantenha a qualidade das evidências e as premissas não resolvidas ao lado de qualquer pontuação.
8. Aprove uma linha de base numerada de requisitos
Após os esclarecimentos, congele uma versão que liste itens obrigatórios, adiados e rejeitados, além das premissas ainda abertas. Use os mesmos identificadores de requisitos na proposta, no escopo contratual acordado, no trabalho de implementação e no registro de aceitação.
Para cada mudança, registre efeitos em custo, prazo, dependências e controles. Defina quem pode aprovar a mudança e quem testará o resultado. Isso impede que um requisito operacional importante desapareça entre uma oficina, uma proposta comercial e a lista de verificação de lançamento da versão.
Antes de enviar a RFP
- Confirme os insumos de produto, mercado, canal e modelo operacional, identificando claramente os itens não resolvidos.
- Atribua identificador, prioridade, requisito de evidência e responsável pela aceitação a cada fluxo.
- Solicite de todos os fornecedores uma resposta comum sobre o status de entrega.
- Inclua exceções de integração, relatórios, acesso a dados, segurança e suporte.
- Peça o escopo comercial completo e as dependências por trás das datas de entrega.
- Forneça cenários roteirizados de demonstração e registre as evidências observadas.
- Resolva as lacunas obrigatórias antes de tratar uma proposta como pronta para seleção.
- Leve a linha de base aprovada à implementação e à lista de entrada em operação.
Baixe a pasta de trabalho de decisões do operador
O WhiteLotto Operator Decision Pack inclui uma lista RFP baseada em evidências, um modelo de TCO de plataforma de 36 meses e uma planilha de contribuição incremental para um operador existente que adiciona loteria. Os dados financeiros começam em branco para que você use seu próprio escopo, condições da proposta e premissas. A pasta de trabalho não contém preços da WhiteLotto nem retornos previstos.
Baixe o WhiteLotto Operator Decision Pack (XLSX)
Use a pasta de trabalho para identificar perguntas para sua conversa de definição do escopo da plataforma. Não inclua registros de jogadores, documentos de identidade ou outros dados sensíveis em uma solicitação de contato.
Use o guia de preços e TCO de software de loteria para esclarecer as definições de tarifas antes de comparar respostas comerciais.
Converse sobre seus requisitos de plataforma com a WhiteLotto
Leve escopo do produto, fluxos necessários, integrações, necessidades de dados e dependências não resolvidas a uma conversa de definição do escopo da plataforma. Pergunte quais itens estão disponíveis no escopo proposto, quais exigem configuração ou outros trabalhos e quais dependem de partes externas.
Entre em contato com a WhiteLotto sobre o escopo da plataforma.
Decisões de licenciamento, jurídicas e tributárias devem ser tratadas pelos assessores qualificados adequados. Uma conversa de definição de escopo da plataforma não estabelece autorização de mercado nem substitui sua assessoria.