Lernprämien enden. Die Verantwortung für Lernende bleibt.

Lernprämien enden. Die Verantwortung für Lernende bleibt.

Ein Lernender schließt einen Kurs ab, erwirbt eine Prämie und stößt beim Einlösen auf einen Fehler. Gleichzeitig plant das Produktteam, den Erwerb weiterer Prämien zu beenden. Das sind zwei getrennte Probleme. Die Prämienansicht zu entfernen, löst keines davon.

Ansprüche enden nicht mit dem Abschalten einer Funktion

Um Lernprämien einzustellen, braucht es mehr als einen Veröffentlichungstermin. Der GOV.UK-Leitfaden zur Einstellung digitaler Dienste (gov.uk) stellt die fortbestehenden Bedürfnisse der Nutzer in den Mittelpunkt. Für eine App, die Lernen mit Prämien verbindet, heißt das: Die Entscheidung, keine neuen Zusagen mehr zu machen, ist von der Aufgabe zu trennen, bestehende Zusagen zu erfüllen.

Für das Growth-Team eines Fintechs ist diese Unterscheidung strategisch wichtig. Lernangebote sollen das Produkt auch dann noch erklären, wenn der Anreiz wegfällt. Bei App-Learning gilt als Gestaltungsprinzip: Der Lernprozess bleibt unabhängig vom Prämiensystem.

Vier Zeitpläne bestimmen den Übergang

Für den Prämienprozess im LMS braucht es vier klar definierte Zeitpläne, jeweils mit einer klaren Zuständigkeit und einer Regel für den Übergang.

• Der Prämienerwerb endet zu einem genau festgelegten Zeitpunkt mit Angabe der Zeitzone. Für bereits laufende Aktivitäten gelten eigene Regeln.
• Bei der Prämienvergabe werden berechtigte Aktivitäten vor dem Stichtag berücksichtigt, auch wenn ihre Prüfung erst später erfolgt. Der Erwerb neuer Prämien wird dadurch nicht wieder freigegeben.
• Gültige, bereits erworbene Prämien können nach den vereinbarten Regeln weiter eingelöst werden – unabhängig davon, wann der Prämienerwerb endet.
• Der Support bleibt für fehlgeschlagene Einlösungen, strittige Ansprüche und ungeklärte Fälle erreichbar.

Der Lernfortschritt folgt einem eigenen Ablauf. Die xAPI-Spezifikation von ADL (github.com) behandelt Aussagen zu Lernaktivitäten als unveränderliche Datensätze mit einem eigenen Mechanismus, um sie für ungültig zu erklären. Die Lehre für die Architektur ist, diese Bereiche zu trennen – nicht, xAPI zwingend einzuführen. Ein Fehler beim Einlösen sollte den Kursabschluss nicht rückgängig machen.

Ein Guthaben braucht eine nachvollziehbare Historie

Bei der Verwaltung von Prämienansprüchen sollten die Status „erworben“, „Prüfung ausstehend“, „verfügbar“, „Einlösung ausstehend“, „eingelöst“ und „strittig“ unterschieden werden. Für einen Verfall oder eine Stornierung müssen der konkrete Grund und die zugrunde liegende Regel festgehalten werden. Ein pauschaler Kontostand von null reicht nicht.

Die OWASP-Empfehlungen zur Protokollierung (cheatsheetseries.owasp.org) sehen vor, für Ereignisse festzuhalten, wann und wo sie stattfanden, wer beteiligt war und was geschah. Ein Prämienjournal sollte die Aktivität, die zur Prämie berechtigt, die Regelversion, die Anspruchs-ID sowie den Einlöseversuch und dessen Ergebnis miteinander verknüpfen. Zur Abstimmung sollten die Einträge mit den Nachweisen über die bereitgestellten Prämien abgeglichen werden. Bei manuellen Korrekturen muss festgehalten werden, wer sie aus welchem Grund vorgenommen hat. Einträge dürfen nicht stillschweigend überschrieben werden.

Mitteilungen müssen zur tatsächlichen Situation der Lernenden passen

Der GOV.UK-Leitfaden zur Einstellung digitaler Dienste (gov.uk) empfiehlt zu erklären, was sich ändert und wie Nutzer ihre Bedürfnisse danach weiterhin erfüllen können. Bei Prämien reicht eine einzige Ankündigung nicht aus. Mitteilungen sollten zwischen Lernenden ohne Guthaben, mit verfügbaren Prämien, mit ausstehender Prämienvergabe und mit offenen Streitfällen unterscheiden.

Vor dem Stichtag sollten die Angaben zu Terminen und Anspruchsvoraussetzungen auf Seiten zur Neukundengewinnung, im Onboarding, in Prämienansichten und in Support-Leitfäden übereinstimmen. Eine Fehlermeldung sollte erklären, ob ein Anspruch noch offen ist, und eine Fallnummer nennen. „Prämien gibt es nicht mehr“ ist keine angemessene Antwort auf einen früher entstandenen, gültigen Anspruch.

Ältere App-Versionen dürfen bei den Tests nicht fehlen

Die Testmatrix sollte alte und neue Clients vor und nach dem Stichtag abdecken – einschließlich offline abgeschlossener Kurse, verzögerter Prämienvergabe, zwischengespeicherter Konfiguration und Zeitüberschreitungen beim Anbieter. Ob ein Anspruch besteht, sollten serverseitige Regeln festlegen. Der Prämienerwerb, die Einlösung und die Sichtbarkeit in der Oberfläche sollten sich getrennt steuern lassen.

Die Hinweise zu Wiederholungsversuchen in RFC 9110 (rfc-editor.org) unterscheiden zwischen Vorgängen, die sich gefahrlos wiederholen lassen, und solchen, für die das nicht gilt. Beim Einlösen braucht es auf Anwendungsebene einen Schutz vor doppelter Verarbeitung und die Möglichkeit, den Status abzufragen. Eine Zeitüberschreitung sollte zunächst einen Abgleich auslösen, bevor erneut versucht wird, die Prämie bereitzustellen – statt Lernende zum wiederholten Tippen aufzufordern.

Der Abschluss setzt geklärte Vorgänge voraus

In der Nachbetreuung gamifizierter Lernangebote sollten offene Ansprüche, die Dauer noch offener Fälle, Fehler bei der Einlösung und Streitfälle erfasst werden – getrennt von Kursabschlüssen und weiterem Lernen. Für den Abschluss braucht es abgeglichene Datensätze, gelöste oder ausdrücklich übergebene Fälle, einen Plan zur Datenaufbewahrung und eine benannte Person, die für Eskalationen verantwortlich ist.

Ein Technologiepartner muss solche Übergänge so umsetzen, dass sie sich im Betrieb handhaben und nachvollziehen lassen. Die Prämie hat vielleicht dazu beigetragen, dass jemand mit dem Lernen begonnen hat. Ihr Wegfall sollte weder den Lernerfolg auslöschen noch erworbene Ansprüche im Unklaren lassen oder den Support dazu zwingen, über den Ablauf zu rätseln.