State Lottery Modernisation RFP: Technical and Operating Requirements
A state or institutional lottery modernisation programme needs more than a catalogue of software features. Procurement must connect the existing operating estate to a deliverable future service, with continuity, accountability and acceptance evidence. Use this framework to prepare that technical and operating brief. The lottery provider evaluation checklist covers general supplier due diligence; this article […]
A state or institutional lottery modernisation programme needs more than a catalogue of software features. Procurement must connect the existing operating estate to a deliverable future service, with continuity, accountability and acceptance evidence.
Use this framework to prepare that technical and operating brief. The lottery provider evaluation checklist covers general supplier due diligence; this article focuses on institutional delivery boundaries. The authority’s procurement and regulatory advisers should define the applicable formal requirements separately.
Begin with outcomes and the current estate
Write the programme outcomes in terms that can be accepted: replace an unsupported component, connect channels, improve reporting access or introduce a defined product capability. Identify who accepts each outcome and which current services cannot be interrupted.
- Inventory player and retailer systems, terminals, draw operations and reporting tools.
- Identify existing contracts, interfaces, data sources and operational dependencies.
- Record service windows, draw schedules and periods when changes are restricted.
- Distinguish first-release requirements from optional future phases.
Describe the target operating architecture
Separate platform supply, hosting, operator processes and third-party services. Specify where the authority retains approval, configuration or data control, and which tasks a supplier is expected to perform.
Use the platform scope overview as a starting point for a module discussion, not as a substitute for a project-specific capability matrix. Require suppliers to identify what is standard, configured, customised, externally provided or excluded.
| Requirement | Evidence to request |
|---|---|
| Retail and digital channels | A channel map with sales, validation, payout and support ownership. |
| Draw and product operations | Defined result sources, cut-offs, settlement and exception handling. |
| Data and reporting | Field-level exports, access controls, report definitions and delivery timing. |
| Service management | Named escalation, change approvals and handover responsibilities. |
Specify interfaces as deliverables
For each interface, identify producer, consumer, data owner, identifiers, frequency, security boundary and exception process. Include terminal or retailer systems, payments, identity checks, finance, support and result distribution where applicable.
The lottery API integration guide helps structure these questions. Require an agreed test environment and sample data. An interface is not accepted merely because an endpoint exists; it must support the agreed business flow and failure cases.
Define continuity and recovery around lottery operations
State the service measures, exclusions, monitoring responsibility and escalation process that matter to your operation. Specify recovery targets and acceptable data loss for each critical service, with a method of demonstrating recovery.
NIST’s contingency-planning guidance provides a reference for prioritising information-system recovery. It is not a lottery certification or a claim about a supplier. Use the security, uptime and SLA checklist to request project-specific controls and evidence.
- What happens to sales and open tickets during a service interruption?
- Who authorises a pause, restart or change around a scheduled draw?
- How are results, balances and outstanding claims checked after recovery?
- What recovery exercise and operational record form part of acceptance?
Plan transition without treating data as a file copy
Document the data scope, source quality, reconciliation, access permissions and cutover sequence. Include outstanding tickets, balances, retailer records and unresolved cases where relevant. State who signs off the transition and what happens if a checkpoint fails.
The lottery platform migration guide covers the detailed transition workstream. In the institutional RFP, make that workstream a priced and accountable deliverable, including retention or decommissioning decisions owned by the authority.
Use evidence-based acceptance and handover
Request a responsibility schedule covering the authority, supplier and each third party. Price integration, support, change and exit work explicitly. Record dependencies and exclusions so that different bids can be compared on the same scope.
- Give each requirement an identifier, priority, responsible owner and acceptance method.
- Separate mandatory pass/fail gates from scored comparisons and optional enhancements.
- Demonstrate complete operational journeys, including an exception and recovery, with retained evidence.
- Agree issue severity, remedial responsibility and the conditions for accepting unresolved items.
- Require documentation, training, access handover and an agreed service transition before final acceptance.
Ask suppliers for a scoped response
A useful response includes the architecture, requirement-by-requirement matrix, evidence links, delivery plan, dependencies and named delivery roles. Ask which requirements are not supported today and what would be required to deliver them. Keep institutional suitability separate from unverified claims about customers, awards or certifications.
Technical reference
Discuss institutional platform requirements
Share your current estate, channel scope, continuity priorities and procurement stage. WhiteLotto can discuss the relevant platform scope and technical questions for an institutional project.