Bewertungscheckliste für Lotterieplattform-Anbieter: ein praktisches RFP-Briefing
Eine Angebotsanfrage (RFP) für eine Lotterieplattform sollte die Arbeitsabläufe des Betreibers, Integrationen, Datenzugriff, Kontrollen, Lieferzuständigkeiten und Abnahmenachweise beschreiben. Trennen Sie verpflichtende Startanforderungen von Präferenzen, fragen Sie jeden Anbieter nach der Umsetzung und testen Sie schwierige Szenarien vor einer verbindlichen Entscheidung. Das Ergebnis sollte ein versioniertes Anforderungsdokument sein, das in Vertrag und Implementierungsplan übernommen wird. Diese […]
Eine Angebotsanfrage (RFP) für eine Lotterieplattform sollte die Arbeitsabläufe des Betreibers, Integrationen, Datenzugriff, Kontrollen, Lieferzuständigkeiten und Abnahmenachweise beschreiben. Trennen Sie verpflichtende Startanforderungen von Präferenzen, fragen Sie jeden Anbieter nach der Umsetzung und testen Sie schwierige Szenarien vor einer verbindlichen Entscheidung. Das Ergebnis sollte ein versioniertes Anforderungsdokument sein, das in Vertrag und Implementierungsplan übernommen wird.
Diese Checkliste hilft einem Einkaufsteam, das Dokument vorzubereiten und Antworten zu vergleichen. Sie ordnet Anbieter nicht in eine Rangfolge ein und setzt nicht voraus, dass eine bestimmte Plattform die aufgeführten Fähigkeiten bereits unterstützt. Jeder Punkt ist eine zu untersuchende und zu überprüfende Anforderung.
1. Definieren Sie den Betriebsumfang vor einer Demoanfrage
Beginnen Sie mit bereits getroffenen Projektentscheidungen, noch offenen Annahmen und den Personen, die zu deren Klärung befugt sind. Halten Sie fest:
- Vorgesehene Produkte: Lose für externe Ziehungen, eigene Ziehungen, Keno, individuelle Spiele oder die konkret benötigte Kombination.
- Vorgesehene Kundenmärkte, Marken, Sprachen, Währungen, Geräte und Vertriebskanäle.
- Die Gesellschaften und Parteien, die die Marke betreiben, die Plattform bereitstellen und die einzelnen externen Dienste übernehmen sollen.
- Startphasen, geschätzte Transaktionsvolumen, erwartete Spitzenzeiten und Nachweise für diese Schätzungen.
- Bestehende Systeme oder Daten, die verbunden, erhalten oder migriert werden müssen.
- Betriebsbeschränkungen und Anforderungen der qualifizierten Berater des Betreibers und einschlägiger Gegenparteien.
- Budgetannahmen, Entscheidungsverantwortliche und Abhängigkeiten mit möglichem Einfluss auf Liefertermine.
Eine ungeklärte Eingabe sollte einen Verantwortlichen und einen Entscheidungstermin haben. Sie als Annahme zu dokumentieren ist hilfreicher, als einen Anbieter um ein Angebot für einen scheinbar vollständigen Umfang zu bitten, der sich während der Implementierung ändern wird.
Die Plattformwahl klärt keine Marktberechtigungen, Lizenzierung oder Steuerfragen. Lassen Sie diese Anforderungen von den passenden Beratern definieren und übersetzen Sie sie anschließend in Arbeitsabläufe, Systemkontrollen und Nachweise, die das RFP abdecken muss.
2. Formulieren Sie Anforderungen als Arbeitsabläufe und Abnahmenachweise
Ein Funktionsname erklärt selten das benötigte Ergebnis. „Wallet“ sagt einem Anbieter beispielsweise nicht, wie sich Salden, Abrechnungen, Rückbuchungen und strittige Transaktionen verhalten müssen.
Nutzen Sie eine Anforderungsmatrix, die den Ablauf mit den akzeptierten Nachweisen verbindet:
| Arbeitsablauf | Zu beschreibende Anforderung | Anzufordernde Nachweise |
|---|---|---|
| Registrierung und Verifizierung | Pflichtfelder, Identitätsprüfungszustände, Ausnahmebehandlung und Sichtbarkeit für den Support | Ein vorgegebener Ablauf mit erfolgreichen, unvollständigen und abgelehnten Prüfungen |
| Los- oder Spielkauf | Produktregeln, Verkaufsschluss, Kaufbestätigung und Stornierungsbearbeitung | Ein nachvollziehbares Beispiel von der Bestellanlage bis zum Ergebnis oder zur Abrechnung |
| Wallet und Zahlungen | Saldoregeln, Einzahlungen, Auszahlungen, Erstattungen und Abstimmung | Transaktionsdatensätze für eine erfolgreiche Zahlung, einen fehlgeschlagenen Versuch und eine Rückbuchung |
| Ziehungen und Ergebnisse | Ergebnisquelle, Produktzuordnung, Korrekturbearbeitung und Gewinnauszahlungsregeln | Ein Ablauf vom Ergebnis bis zur Abrechnung mit Quellenreferenzen und Protokollen |
| Spielerschutz | Die für das Betriebsmodell festgelegten Limits und Kontobeschränkungen | Tests zur Auswirkung von Beschränkungen auf einschlägige Kauf- und Zahlungsabläufe |
| Kundenbetrieb | Beschwerden, manuelle Eingriffe, Berechtigungen und Eskalation | Rollenbasierte Ansichten und ein Prüfpfad für einen schwierigen Supportfall |
| Berichte und Datenzugriff | Erforderliche Felder, stabile Kennungen, Exportformate und Zugriffshäufigkeit | Beispielberichte und Exporte, die Finanz- und Betriebsteams abstimmen können |
Geben Sie jeder Anforderung eine Kennung, Priorität, einen Abnahmeverantwortlichen und eine Abhängigkeit. Ergänzen Sie kurz, warum sie wichtig ist. Produkt-, Finanz-, Sicherheits-, Compliance- und Kundenbetriebsverantwortliche sollten ihre Abschnitte prüfen können, ohne den vorgesehenen Ablauf aus einer Liste von Modulnamen ableiten zu müssen.
Nutzen Sie für zahlungsspezifische Anforderungen neben dieser Matrix den Leitfaden zur Lotterie-Zahlungsarchitektur.
3. Machen Sie Anbieterantworten vergleichbar
Bitten Sie jeden vorausgewählten Anbieter, dieselben Antwortkategorien zu verwenden. Sie beschreiben den vorgeschlagenen Lieferweg, keine Qualitätsbewertung.
| Antwort | Erwartete Bedeutung | Erforderliche Klärung |
|---|---|---|
| In der genannten Version verfügbar | Der Anbieter kann das geforderte Ergebnis in einer identifizierten Produktversion zeigen | Version, Nachweise und mögliche Betriebsgrenzen |
| Konfiguration erforderlich | Das Ergebnis hängt von Einstellungen oder vereinbarten Konfigurationsarbeiten ab | Wer konfiguriert, Aufwand, Validierung und laufende Zuständigkeit |
| Individuelle Entwicklung erforderlich | Der vorgeschlagene Umfang enthält noch nicht gelieferte Funktionen | Spezifikation, Kostengrundlage, Abhängigkeiten, Abnahmekriterien und Änderungszuständigkeit |
| Abhängigkeit von externem Anbieter | Ein anderer Anbieter oder Dienst ist zur Erfüllung der Anforderung nötig | Vertragspartei, Integrationsgrenze, Supportverantwortlicher und Fehlerbehandlung |
| Nicht unterstützt oder außerhalb des Umfangs | Das Angebot erfüllt die Anforderung nicht | Auswirkung auf den Startumfang und jede vorgeschlagene Alternative |
Fordern Sie für jede Zeile Lieferverantwortlichen, Annahme, Nachweisreferenz, kommerzielle Behandlung und zeitliche Abhängigkeit an. Halten Sie unbeantwortete Fragen sichtbar. Eine Roadmap-Aussage sollte nicht als gelieferte Fähigkeit dokumentiert werden.
Sind mehrere Parteien beteiligt, benennen Sie die Person oder das Team, die den vollständigen Ablauf koordinieren. Andernfalls kann selbst eine technisch gültige Integration den Betreiber ohne Verantwortlichen für Ausnahmen oder Vorfälle lassen.
4. Berücksichtigen Sie Daten, Integrationen und Ausstiegsanforderungen von Anfang an
Datenzugriff ist eine Betriebsanforderung und zugleich ein Ausstiegsthema. Legen Sie fest, welche Datensätze benötigt werden, wer darauf zugreifen darf, welche Kennungen sie verbinden und wie Exporte geliefert werden.
Integrationsgrenzen
Dokumentieren Sie für jede erforderliche Verbindung die Systeme auf beiden Seiten, ausgetauschte Daten, Ereigniszeitpunkte, Authentifizierungsansatz, Versionierung, Überwachung und Supportzuständigkeit. Beschreiben Sie das Verhalten nach einer Zeitüberschreitung, einer verspäteten Nachricht, einem doppelten Callback oder einem nicht verfügbaren Partner.
Fordern Sie repräsentative Schnittstellendokumentation und Testdaten an. Ein Integrationslogo oder eine erfolgreiche Verkaufsdemo belegt nicht das Verhalten des vorgesehenen durchgängigen Ablaufs.
Eigentum, Zugriff und Portabilität
Fordern Sie ein Inventar von Spieler-, Bestell-, Transaktions-, Ergebnis-, Support- und Prüfdatensätzen an. Definieren Sie benötigte Felder je Betriebsrolle, Exportformate, Häufigkeit, erwartetes Volumen und Korrekturbehandlung. Erfassen Sie Zugriff im Normalbetrieb, während der Implementierung, bei einem Vorfall und bei Vertragsende.
Trennen Sie vertragliches Eigentum, praktischen Zugriff und Datenverarbeitungszuständigkeiten. Lassen Sie die verantwortlichen Parteien Aufbewahrungs-, Zugriffs- und Übertragungsanforderungen für Ihre Situation bewerten. Der Leitfaden zum Eigentum an Spielerdaten bietet weitere Beschaffungsfragen.
Beispiel: Käufe funktionieren, aber die Transaktionshistorie lässt sich nicht exportieren
In dieser hypothetischen Bewertung führt eine Demo Registrierung, Einzahlung und Loskauf aus. Der Anbieter kann noch keinen vollständigen Transaktionsexport mit stabilen Kennungen liefern, die Spieler-, Bestell-, Zahlungs- und Abrechnungsdatensätze verbinden.
Bitten Sie den Anbieter, den Export mit repräsentativen Volumen zu zeigen und Felder, Zeitabläufe, Einschränkungen und zusätzliche Arbeiten zu erläutern. Finanz- und Betriebsteams sollten prüfen, ob das Ergebnis ihren Abstimmungs- und Untersuchungsbedarf erfüllt. Bleibt die Lücke, entscheiden Sie, ob eine getestete Alternative die Anforderung erfüllen kann oder das Angebot außerhalb der Shortlist bleiben sollte.
Behandeln Sie dies als aktuelle Betriebsabhängigkeit, nicht als Frage, die bis zur dringenden Migration aufgeschoben wird.
5. Legen Sie Erwartungen an Sicherheit, Leistung und Service fest
Dokumentieren Sie die benötigten Sicherheits- und Betriebsergebnisse: Verwaltungsberechtigungen, Zugriffsprotokollierung, Überwachung, Sicherungen, Wiederherstellung, Supporteskalation und Änderungsmanagement. Berücksichtigen Sie Verfügbarkeits- und Leistungsmessung, Kapazitätsannahmen, Barrierefreiheit und Lokalisierungsanforderungen.
Fragen Sie, was über welchen Zeitraum von wem und mit welchen Ausschlüssen gemessen wird. Dokumentieren Sie Wiederherstellungsziele und erwartete Nachweise einer Wiederherstellungsübung. Behandeln Sie einen Verfügbarkeitsprozentsatz oder ein Sicherheitssiegel nicht als Ersatz für das Verständnis des vorgeschlagenen Umfangs und seiner Abhängigkeiten.
Das NIST Cybersecurity Framework ist eine Primärreferenz zur Strukturierung von Gesprächen über Cybersicherheitsrisiken. Nutzen Sie es zur Ordnung von Fragen und angeforderten Nachweisen; dieser Leitfaden behauptet nicht, dass ein Anbieter danach geprüft wurde.
Für Zahlungskartendaten beschreiben die PCI-DSS-Ressourcen des PCI Security Standards Council technische und betriebliche Sicherheitsanforderungen. Bitten Sie die einschlägigen Zahlungs- und Sicherheitsspezialisten, den geltenden Umfang, Zuständigkeiten und Validierungsnachweise für die vorgeschlagene Architektur festzustellen. Eine externe Zahlungsintegration allein beantwortet diese Fragen nicht.
6. Richten Sie das Demoskript auf Ausnahmefälle aus
Geben Sie Anbietern vor dem Bewertungstermin dieselben Szenarien. Nehmen Sie einen erfolgreichen Ablauf und Fälle auf, die Übergaben zwischen Systemen sichtbar machen:
- Ein Verifizierungsfall mit zusätzlichem Informationsbedarf und einer klaren Supportantwort.
- Ein verspäteter oder mehrfach eintreffender Zahlungs-Callback.
- Ein Kaufversuch nahe am konfigurierten Verkaufsschluss.
- Ein korrigiertes oder nicht verfügbares externes Ergebnis.
- Ein eingeschränktes Konto, das eine einschlägige Transaktion versucht.
- Eine manuelle Korrektur, die einen befugten Benutzer und einen nachvollziehbaren Datensatz erfordert.
- Ein Bericht oder Export, den das Finanzteam mit Plattformdatensätzen abstimmen muss.
Dokumentieren Sie Produktversion, Annahmen, beobachtetes Verhalten und offene Fragen. Kann ein Szenario nicht gezeigt werden, vereinbaren Sie nötige weitere Nachweise, statt es als abgenommen zu kennzeichnen.
7. Nutzen Sie eine Entscheidungsmatrix, die Pflichtlücken sichtbar hält
Legen Sie Prioritäten vor der Angebotsprüfung fest. Ein möglicher Entscheidungsdatensatz ist:
| Entscheidungsbereich | Dokumentation | Shortlist-Bedingung |
|---|---|---|
| Verpflichtende Ergebnisse | Anforderungskennungen und Nachweise des vorgeschlagenen Lieferwegs | Keine ungelöste Lücke ohne ausdrücklich akzeptierte, praktikable Alternative |
| Lieferzuständigkeit | Verantwortung von Betreiber, Anbieter und externen Parteien | Jede Abhängigkeit und Abnahmeentscheidung hat einen Verantwortlichen |
| Daten- und Kontrollzugriff | Nachweise zu Exporten, Berechtigungen, Protokollen und Berichten | Der erforderliche Betriebszugriff ist nachweisbar und vereinbart |
| Kommerzielles Risiko | Einrichtung, laufende Gebühren, Nutzungsannahmen und optionale Arbeiten | Das Angebot erklärt Ein- und Ausschlüsse des angebotenen Umfangs |
| Implementierung und Support | Meilensteine, Abhängigkeitstermine, Eskalation und Abnahmeprozess | Der Plan passt zu Umfang und Anforderungen externer Parteien |
Bewerten Sie Präferenzen separat, wenn das Einkaufsteam dies hilfreich findet. Eine hohe Bewertung für Design oder optionale Funktionen darf eine fehlende Pflichtanforderung nicht verdecken. Halten Sie Nachweisqualität und ungeklärte Annahmen neben jeder Bewertung fest.
8. Genehmigen Sie eine nummerierte Anforderungsbasis
Fixieren Sie nach der Klärung eine Version mit verpflichtenden, verschobenen und abgelehnten Punkten sowie noch offenen Annahmen. Nutzen Sie dieselben Anforderungskennungen im Angebot, vereinbarten Vertragsumfang, in der Implementierungsarbeit und im Abnahmedatensatz.
Dokumentieren Sie für jede Änderung Auswirkungen auf Kosten, Zeit, Abhängigkeiten und Kontrollen. Definieren Sie, wer die Änderung genehmigen darf und wer das Ergebnis testet. So geht eine wichtige Betriebsanforderung nicht zwischen Workshop, Verkaufsangebot und Versionscheckliste verloren.
Bevor Sie das RFP senden
- Bestätigen Sie Produkt-, Markt-, Kanal- und Betriebsmodelleingaben mit klar gekennzeichneten offenen Punkten.
- Ordnen Sie jedem Ablauf Kennung, Priorität, Nachweisanforderung und Abnahmeverantwortlichen zu.
- Fordern Sie von jedem Anbieter eine einheitliche Lieferstatusantwort an.
- Berücksichtigen Sie Integrationsausnahmen, Berichte, Datenzugriff, Sicherheit und Support.
- Fragen Sie nach dem vollständigen kommerziellen Umfang und den Abhängigkeiten hinter Lieferterminen.
- Geben Sie Demoszenarien vor und dokumentieren Sie beobachtete Nachweise.
- Schließen Sie Pflichtlücken, bevor ein Angebot als auswahlbereit gilt.
- Übernehmen Sie die genehmigte Basis in die Implementierung und die Go-live-Checkliste.
Laden Sie die Betreiber-Entscheidungsarbeitsmappe herunter
Das WhiteLotto Operator Decision Pack enthält eine nachweisgestützte RFP-Checkliste, ein Plattform-TCO-Modell für 36 Monate und ein Arbeitsblatt zum zusätzlichen Ergebnisbeitrag eines bestehenden Betreibers, der Lotterie ergänzt. Finanzielle Eingaben sind zunächst leer, damit Sie Ihren eigenen Umfang, Angebotsbedingungen und Annahmen verwenden können. Die Arbeitsmappe enthält keine WhiteLotto-Preise oder prognostizierten Renditen.
Laden Sie das WhiteLotto Operator Decision Pack (XLSX) herunter
Nutzen Sie die Arbeitsmappe, um Fragen für Ihr Plattformumfangsgespräch zu ermitteln. Fügen Sie einer Kontaktanfrage keine Spielerdatensätze, Identitätsdokumente oder anderen sensiblen Daten bei.
Nutzen Sie den Preis- und TCO-Leitfaden für Lotteriesoftware, um Gebührendefinitionen vor dem Vergleich kommerzieller Antworten zu klären.
Besprechen Sie Ihre Plattformanforderungen mit WhiteLotto
Bringen Sie Produktumfang, erforderliche Abläufe, Integrationen, Datenbedarf und offene Abhängigkeiten zu einem Gespräch über den Plattformumfang mit. Fragen Sie, welche Punkte im vorgeschlagenen Umfang verfügbar sind, welche Konfiguration oder andere Arbeiten benötigen und welche von externen Parteien abhängen.
Kontaktieren Sie WhiteLotto zum Plattformumfang.
Lizenzierungs-, Rechts- und Steuerentscheidungen sollten die passenden qualifizierten Berater bearbeiten. Ein Gespräch über den Plattformumfang begründet keine Marktberechtigung und ersetzt ihre Beratung nicht.