Skip to main content

Pulse Check im Intranet: Stimmung messen, ohne Survey-Müdigkeit

Wie ein Pulse-Check-Widget mit fünf Mood-Buttons jährliche Mitarbeiter-Befragungen ersetzt – mit Data Table als Backend, OData-Filter und localStorage-Anti-Double-Vote.

5 Min. Lesezeit
Pulse Check im Intranet: Stimmung messen, ohne Survey-Müdigkeit

Jährliche Mitarbeiter-Befragungen funktionieren nicht. 80 Fragen, 30 Minuten Zeitaufwand, drei Wochen warten auf die Auswertung – und am Ende lesen Mitarbeitende die Ergebnisse, die HR im SharePoint-PDF veröffentlicht hat, ohnehin nicht. Wer einmal im Jahr gefragt wird, fühlt sich nicht gehört. Wer einmal im Jahr antworten muss, antwortet ungenau oder gar nicht.

Das Pulse Check Widget dreht das Verhältnis um: eine Frage pro Woche, fünf Sekunden Aufwand, sofort sichtbares Ergebnis. Kein externes Survey-Tool, keine separate Login-Seite, keine HR-Mail, in der „Bitte nehmt euch 30 Minuten Zeit” steht. Nur ein Widget auf der Intranet-Startseite mit fünf Emoji-Buttons – und einer Data Table als Backend für die Antworten.

Fünf Sekunden, fünf Buttons

Der Mitarbeitende sieht eine Frage – „Wie war deine Woche?” – und fünf Mood-Buttons von 😞 bis 🤩. Ein Klick. Fertig. Das Widget zeigt sofort die aggregierten Antworten der letzten 7 Tage: wie sich das Team fühlt, wo der Durchschnitt liegt, wie viele schon abgestimmt haben.

Für den Einzelnen ist es ein 5-Sekunden-Touchpoint. Für HR und IC ist es eine wöchentliche Stimmungs-Heatmap über alle Standorte und Teams hinweg.

Warum Data Tables statt Settings

Eine wichtige Architektur-Entscheidung vorweg: Widget-Settings sind Editor-Konfiguration, nicht Runtime-User-Daten. Ein Pulse Check, der einfach mit setVariable('has_voted','1') arbeitet, funktioniert nicht – End-User können Widget-Variables nicht persistent ändern, und über mehrere User hinweg gibt es so keine Aggregation.

Der saubere Weg im Widget Builder ist eine Data Table:

  1. Im Widget Builder eine Tabelle pulse_responses mit den Spalten mood (number 1–5) und submitted_at (date) anlegen
  2. Die Tabellen-GUID kopieren
  3. Im Widget-Editor in das Setting „Data-Table-GUID für Pulse-Antworten” einfügen

Das war’s. Jeder Vote landet ab jetzt als Row in der Tabelle, jede Page-Load liest die letzten 7 Tage und baut daraus die Stats.

Die Widget-API: OData mit Handlebars

Das Widget hat eine API-URL, die der Widget Builder beim Render aufruft:

wb://data-table/{{settings.tableGuid}}/rows?$filter=submitted_at ge '{{datetime sub_days=7 to_isodate=true}}'

Zwei wichtige Dinge passieren hier:

  • {{settings.tableGuid}} – die Tabellen-GUID kommt aus dem Editor-Setting. Mehrere Pulses parallel betreiben? Einfach pro Widget eine eigene Tabelle.
  • {{datetime sub_days=7 to_isodate=true}} – der datetime-Helper berechnet das Filter-Datum dynamisch. „Vor 7 Tagen” wird zur Render-Zeit aufgelöst, das Fenster rollt jede Woche automatisch weiter.

Der useProxy: true Flag sorgt dafür, dass der Widget Builder die wb://-URL serverseitig auflöst und die Tabellen-Daten als data.rows ins Template injiziert.

Submit per fetch(), Stats per JavaScript

Beim Klick auf einen Mood-Button macht das Widget einen POST auf den Data-Table-Endpunkt:

 1btn.addEventListener('click', async function(){
 2  var mood = btn.getAttribute('data-mood');
 3  var tableGuid = '{{settings.tableGuid}}';
 4  await fetch('/api/data-table-widget/' + tableGuid + '/rows', {
 5    method: 'POST',
 6    headers: {'Content-Type': 'application/json'},
 7    body: JSON.stringify({
 8      data: { mood: parseInt(mood, 10), submitted_at: new Date().toISOString() }
 9    })
10  });
11  var d = new Date();
12  d.setDate(d.getDate() - ((d.getDay() + 6) % 7));
13  var weekKey = d.getFullYear() + '-' +
14    String(d.getMonth() + 1).padStart(2, '0') + '-' +
15    String(d.getDate()).padStart(2, '0');
16  localStorage.setItem('pulse_voted_' + weekKey, mood);
17  showStats(mood);
18});

Drei Sachen passieren parallel:

  1. POST in die Data Table – die Stimme landet sofort in der Tabelle
  2. localStorage-Eintrag – ein Schlüssel pulse_voted_<yyyy-mm-dd> (Montag der aktuellen Woche) markiert „dieser Browser hat diese Woche schon abgestimmt”
  3. showStats(mood) – das Widget wechselt direkt von der Vote-View zur Stats-View, ohne Page-Reload

Beim nächsten Page-Load prüft das Widget den localStorage-Schlüssel – ist er gesetzt, zeigt das Widget direkt die Stats statt der Buttons.

Stats werden im Browser berechnet

Die Aggregation läuft client-seitig, weil sie dort am einfachsten ist. Das Template embeddet die Rows als JavaScript-Konstante:

 1<script>
 2  var rows = {{{json data.rows}}} || [];
 3  var counts = [0,0,0,0,0];
 4  var sum = 0;
 5  rows.forEach(function(r){
 6    var m = parseInt(r.mood, 10);
 7    if (m >= 1 && m <= 5) { counts[m-1]++; sum += m; }
 8  });
 9  var total = rows.length;
10  var avg = total ? (sum/total).toFixed(1) : '0.0';
11  // …Bars und Avg in der DOM-Stats-View setzen
12</script>

Kein Server-Side-Aggregation-Aufwand, keine zusätzliche API. Das {{{json data.rows}}} ist der Trick: der json-Helper serialisiert die Daten als JSON-Literal direkt in den Script-Tag.

Anti-Double-Vote über localStorage

Mitarbeitende sollen nicht mehrfach pro Woche abstimmen. Das Widget setzt deshalb nach erfolgreichem Vote einen Schlüssel pulse_voted_<yyyy-mm-dd> in den Browser-localStorage – das Datum ist dabei der Montag der aktuellen Woche, so dass der Lock pro ISO-Woche greift. Beim nächsten Render prüft das Widget:

1var d = new Date();
2d.setDate(d.getDate() - ((d.getDay() + 6) % 7));
3var weekKey = 'pulse_voted_' + d.getFullYear() + '-' +
4  String(d.getMonth() + 1).padStart(2, '0') + '-' +
5  String(d.getDate()).padStart(2, '0');
6var storedMood = localStorage.getItem(weekKey);
7if (storedMood) showStats(storedMood);

Browser-lokal heißt: Wer wirklich von einem zweiten Gerät abstimmen will, kann es. Für ehrliche Pulse-Daten ist das in Ordnung – ein Pulse Check ist kein Wahlsystem, sondern ein Stimmungs-Sensor. Wer härter durchsetzen will, kann statt localStorage einen User-spezifischen Filter auf der Tabelle einbauen (Spalte user_email, mit eq-Filter beim Render).

Anonymität als Standard

Die Default-Spalten der Tabelle speichern kein Profilfeld – nur Mood und Zeitstempel. Das ist DSGVO-konform und auch in heiklen Phasen (Reorgs, Layoffs, Konflikt-Situationen) rechtssicher.

Wer mit zugeordneten Antworten arbeiten will – etwa für moderierte Manager-Pulses in kleineren Teams – kann eine Spalte team_id ergänzen und sie im JS aus einem zweiten Widget-Setting mitschicken. Anonymität bleibt aber der Default.

Wann du das Widget einsetzt

  • Wöchentlicher Friday Pulse – „Wie war deine Woche?” jeden Freitag um 14 Uhr
  • Onboarding-Phase – neue Mitarbeitende in den ersten 30 Tagen wöchentlich abfragen
  • Change-Begleitung – während Reorgs, Tool-Migrationen, Office-Wechseln den Puls fühlen
  • Team-Retro-Vorbereitung – ein 5-Sekunden-Pulse vor jeder Retro
  • CEO-Connect-Vorbereitung – die Stimmung vor einer Town Hall messen, um Themen zu priorisieren

Im Galerie-Eintrag testen

Die Live-Demo, alle Settings und die Setup-Schritte für die Data Table siehst du im Pulse Check Galerie-Eintrag .

Verwandte Widgets

#Staffbase #Mitarbeiter-Feedback #Pulse Survey #Engagement #Custom Widgets
← Zurück