Codex für Facebook: Störungen klar erklären

Codex für Facebook

Wenn ein Buchungs- oder Zahlungsdienst ausfällt, suchen Kundinnen und Kunden häufig auf der Facebook-Seite des Unternehmens nach Informationen und hinterlassen Kommentare. Eine hilfreiche Meldung muss schnell, konkret und ehrlich sein, obwohl das Technikteam möglicherweise noch an der Störung arbeitet. Codex kann Incident-Notizen und den betroffenen Code auswerten und einen verständlichen Text vorbereiten. Tareno speichert den Entwurf für die Seite. Am Beispiel eines Ticketanbieters zeigen wir, wie bestätigte Fakten von Vermutungen getrennt werden und warum die verantwortlichen Personen den Text vor der Veröffentlichung prüfen müssen.

Beispiel: Ein Ticketanbieter meldet eine Störung beim Bezahlen

Bei einem Ticketanbieter schlägt die Kartenzahlung im Checkout fehl, während andere Zahlungsmethoden funktionieren. Die zuständige Person gibt Codex die Incident-Notizen und verweist auf das Zahlungsmodul. Codex liest die Notizen und den betroffenen Codepfad und unterstützt dabei, den bestätigten Umfang einzugrenzen. Nach Prüfung durch das Technikteam formuliert es eine Meldung von etwa 60 Wörtern: welche Zahlungsart betroffen ist, welche Alternative besteht und dass ein weiteres Update folgt – ohne eine feste Reparaturzeit zu versprechen. Es speichert die Meldung über create_drafts und bereitet einen zweiten, nicht terminierten Entwurf für die spätere Behebung vor. Die zuständige Person gleicht beide mit dem Incident-Kanal ab und beantragt die Veröffentlichung der ersten Meldung in Tareno.

Schritt für Schritt

1. 01

   Incident-Notizen bereitstellen

   Gib Codex den aktuellen Stand der Notizen und kennzeichne bestätigte Fakten und offene Vermutungen. Teile nur Informationen, die für die Meldung nötig sind. Eine Theorie darf nicht als Tatsache veröffentlicht werden.

2. 02

   Betroffenen Code lesen lassen

   Verweise auf das betroffene Modul. Codex kann untersuchen, welche Abläufe denselben Codepfad nutzen, etwa Kartenzahlungen, aber nicht Rechnungen. Das Technikteam muss den tatsächlichen Umfang bestätigen, bevor er öffentlich genannt wird.

3. 03

   Meldung und Folgeentwurf erstellen

   Bitte um eine kurze Meldung mit bestätigter Auswirkung, möglichen Alternativen und einem Hinweis auf ein weiteres Update. Ein zweiter Entwurf für die Behebung bleibt ohne unbestätigte Fakten und zunächst ohne Veröffentlichungstermin.

4. 04

   Unbestätigte Ursachen und Zeiten entfernen

   Prüfe den Entwurf auf Ursachen oder Reparaturzeiten, die nicht durch das Technikteam bestätigt sind, und entferne sie. Versprich ein weiteres Update statt einer unbelegten Behebungszeit.

5. 05

   Beide Entwürfe für die Seite speichern

   Codex prüft die Facebook-Seite über list_accounts und speichert beide Texte mit create_drafts. Die Veröffentlichung erfolgt als Seite und damit im Namen des Unternehmens; lies beide Entwürfe vor der Freigabe.

6. 06

   Erste Meldung anfragen und freigeben

   Frage den frühestmöglichen zulässigen Termin an. Laut Meta-Dokumentation benötigen über die API geplante Beiträge mindestens zehn Minuten Vorlauf. Die Anfrage bleibt ausstehend, bis du sie im Tareno-Dashboard freigibst.

Prompts zum Kopieren

Lies die folgenden Incident-Notizen und das Modul [payments/card]. Liste bestätigte Fakten, reine Vermutungen und Kundenabläufe auf, die den betroffenen Codepfad nutzen. Kennzeichne, was das Technikteam noch bestätigen muss. Formuliere keine Meldung, bevor ich die Liste geprüft habe: [Notizen].

Schreibe für unsere Facebook-Seite eine verständliche Störungsmeldung von etwa 60 Wörtern und verwende ausschließlich bestätigte Fakten. Nenne die betroffene Zahlungsart, eine bestätigte Alternative und ein späteres Update. Erfinde weder Ursache noch Reparaturzeit und vermeide technische Fachbegriffe.

Schreibe einen zweiten kurzen Beitrag für den Zeitpunkt nach der Behebung mit einem Platzhalter für die bestätigte Uhrzeit. Nenne keine Ursache, bevor ich sie liefere. Speichere beide Beiträge über Tareno als Entwürfe für unsere Facebook-Seite [Name] und gib die Entwurfs-IDs zurück.

Bitte Tareno, den Entwurf [ID der Störungsmeldung] zum frühestmöglichen zulässigen Zeitpunkt zu planen, und nenne mir den angefragten Zeitpunkt. Gib die ID der ausstehenden Aktion zurück und erinnere mich daran, dass der Beitrag erst nach meiner Freigabe im Tareno-Dashboard veröffentlicht wird.

Typische Fehler

• Eine Ursache zu früh nennen: Eine unbestätigte Vermutung kann sich als falsch erweisen und die nächste Beschwerde auslösen.
• Eine Reparaturzeit versprechen: Kündige lieber ein weiteres Update an und halte diese Zusage gegenüber den Kundinnen und Kunden ein.
• Den Vorlauf vergessen: Eine Anfrage kann nicht früher erfolgen, als die Plattform erlaubt. Plane und prüfe die Freigabe deshalb zügig.
• Den Folgeentwurf unvollständig lassen: Halte den Platzhalter sichtbar, damit niemand versehentlich einen unbestätigten Beitrag terminiert.