NexTool Solutions

Eine Zufriedenheitsumfrage, auf die niemand antwortet, führt zu keiner einzigen Entscheidung. Dieser Leitfaden zeigt, wie GLPI die Zufriedenheitsumfrage tatsächlich auslöst, speichert und misst: aus welcher Spalte jede Einstellung stammt, warum sie manchmal schlicht nicht versendet wird und was wir im Betrieb von Kundenumgebungen tun, um die Antwortquote vom Boden zu holen.

Wo die Umfrage konfiguriert wird (und warum pro Einheit)

Anders als viele vermuten, ist die Zufriedenheitsumfrage in GLPI kein globaler Schalter: Sie wird pro Einheit konfiguriert, unter Verwaltung > Einheiten > (Einheit auswählen) > Reiter Unterstützung. Jedes Feld der Seite wird in einer Spalte der Tabelle glpi_entities gespeichert, und der Wert kann von der übergeordneten Einheit geerbt werden. Wer die Spalte hinter jedem Feld kennt, kann per SQL diagnostizieren, wenn die Oberfläche „behauptet“, alles sei in Ordnung.

Feld Konfiguration mit Wert -2 (erben) ist die stille Falle: Eine untergeordnete Einheit kann aktiv aussehen und in Wirklichkeit „keine Umfrage“ von der Stammeinheit erben. Neuere Versionen haben dieselbe Mechanik für Änderungen eingeführt, in entsprechenden Spalten mit dem Suffix _change.

Der tatsächliche Auslöser: Schließen + Cron, nicht die Lösung

Hier liegt Ursache Nummer 1 für „die Umfrage geht nicht raus“. Eine Umfrage entsteht nicht, wenn ein Ticket gelöst wird (Status 5, Gelöst); sie entsteht, wenn es geschlossen wird (Status 6, Geschlossen), und selbst dann nur, wenn die Cron-Aufgabe createinquest läuft und jenes Ticket im Rahmen von inquest_rate auslost. Es gibt zwei voneinander unabhängige Voraussetzungen:

1. Ein Ticket muss geschlossen werden. Wenn automatisches Schließen deaktiviert ist und die Techniker nur „lösen“, bleiben Tickets für immer auf Gelöst, und keine Umfrage wird erzeugt. Automatisches Schließen ist Feld autoclose_delay der Einheit selbst.
2. Der Cron muss im externen Modus laufen. Aufgabe createinquest erzeugt die Umfragen für geschlossene Tickets. Im internen Modus läuft sie nur, wenn jemand eine Seite lädt; in Einheiten mit wenig Verkehr kann sie tagelang nicht laufen.

Genau so war es in einer Umgebung, die wir übernommen haben: Die Umfrage war seit Monaten „aktiviert“, und in der Datenbank gab es keine einzige Antwort. Es lag weder an der Vorlage noch an der Rate. createinquest lief im internen Modus (mode = 1) auf einem GLPI mit wenig Verkehr, sodass der Cron praktisch nie auslöste; und zu allem Überfluss war automatisches Schließen deaktiviert, sodass kaum etwas den Status Geschlossen erreichte. Wir haben den externen Cron des Betriebssystems eingeschaltet und autoclose_delay angepasst: Noch am selben Tag begannen die Umfragen zu entstehen. Seitdem gehört die Prüfung dieser zwei Punkte bei jeder Übernahme eines GLPI fest zu unserem Runbook.

Ein externer Cron ist eine Zeile in der Crontab des Systems, ausgeführt mit dem PHP-Benutzer:

# /etc/cron.d/glpi - GLPI external cron (PHP-FPM user)
# 1 run per minute; processes ALL tasks in external mode,
# including "createinquest" (satisfaction survey generation).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Und die Diagnose direkt in der Datenbank bestätigt, ob die Aufgabe läuft und wann sie zuletzt ausgeführt wurde:

-- State of the task that generates surveys (use a read-only user)
-- state: 0=disabled 1=waiting 2=running
-- mode:  1=internal (runs on page load)  2=external (runs on the OS cron)
-- frequency: interval in seconds (default 86400 = 1 day)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS next_expected
FROM glpi_crontasks
WHERE name = 'createinquest';

Die Vorlage der Benachrichtigung

Ist die Umfrage erzeugt, lädt die Benachrichtigung den Benutzer ein. Passen Sie sie unter Einstellungen > Benachrichtigungen > Benachrichtigungsvorlagen an, in der Vorlage, die mit dem Zufriedenheitsereignis des Tickets verknüpft ist. Nützliche Tags:

• ##ticket.urlsatisfaction## - direkter, authentifizierter Link zur Umfrage (der wichtigste).
• ##ticket.id## und ##ticket.title## - Bezug, damit sich der Benutzer an die Bearbeitung erinnert.
• ##satisfaction.text## / ##satisfaction.type## - Text und Typ der Umfrage.

Der häufige Fehler hier ist eine aufwendige, lange E-Mail: Je mehr Text vor dem Link steht, desto geringer die Konversion. Eine Zeile Kontext, der Link, fertig.

Die Antwortquote richtig messen

Eine ehrliche durchschnittliche Antwortquote bei Umfragen per E-Mail liegt im Bereich von 10 % bis 20 %; 30 % als „schlecht“ zu bewerten, ist unrealistisch. Alle Antworten liegen in glpi_ticketsatisfactions, eine Zeile pro erzeugter Umfrage. Wurde sie nicht beantwortet, bleibt date_answered leer; so trennen Sie „versendet“ von „beantwortet“:

-- Response rate and average (last 90 days), read-only user
-- type: 1=internal (stars)  2=external (URL)
-- satisfaction: 0 to 5; date_answered null = not answered yet
SELECT
    COUNT(*)                                                   AS generated,
    SUM(date_answered IS NOT NULL)                            AS answered,
    ROUND(100 * SUM(date_answered IS NOT NULL) / COUNT(*), 1) AS response_rate_pct,
    ROUND(AVG(CASE WHEN date_answered IS NOT NULL
                   THEN satisfaction END), 2)                 AS avg_0to5
FROM glpi_ticketsatisfactions
WHERE date_begin >= DATE_SUB(CURDATE(), INTERVAL 90 DAY);

Beachten Sie, dass der Durchschnitt nur jene berücksichtigt, die geantwortet haben. Einen Durchschnitt über alle Zeilen (einschließlich leerer) zu berechnen, verfälscht die Zahl; auch diese Verzerrung haben wir schon in einem Kundenbericht korrigiert.

Die Antwortquote vom Boden holen

Eine korrekte Konfiguration ist Voraussetzung; die Menge der Antworten ist ein anderer Kampf. Was in der Praxis funktioniert:

• Neue Tickets bis zur Antwort sperren mit Modul Pending Survey: Der Benutzer findet die offene Umfrage wieder, wenn er versucht, sein nächstes Ticket zu erstellen. Hiermit bewegen Sie am meisten.
• inquest_delay verringern, um die Umfrage nahe am Schließen zu erzeugen, solange die Bearbeitung noch frisch im Gedächtnis ist.
• Über einen weiteren Kanal benachrichtigen, zusätzlich zur E-Mail, zum Beispiel über WhatsApp.
• Einfach halten: 1 Bewertung und 1 optionaler Kommentar. Eine lange Umfrage senkt die Konversion.

Eine Falle bei inquest_rate: Die Auslosung erfolgt zum Zeitpunkt des Crons und ist nicht rückwirkend. Eine Senkung von 100 % auf 30 % „storniert“ keine bereits erzeugten Umfragen, und eine erneute Erhöhung holt keine Tickets zurück, die bereits durchgelaufen sind; max_closedate bewegt sich nur vorwärts.

Brauchen Sie eine Zufriedenheitsmessung, die wirklich misst, mit zuverlässigem Cron und gesunder Antwortquote? Der GLPI-Betriebsservice von NexTool übernimmt Konfiguration, Überwachung des Crons und monatliche Berichte für Ihren Betrieb. Lernen Sie unseren Support- und Betriebsservice kennen.

Geprüft vom Team von NexTool Solutions.