Der Aufbau einer Fin Procedure, die ein technisch komplexes Thema gut behandelt, erfordert Iteration. Dieser Artikel zeigt, wie eine echte Procedure, die Data Connectors Setup and Troubleshooting procedure, von Grund auf entworfen, über mehrere Iterationen verfeinert und durch sechs Prinzipien geprägt wurde, die sie kontinuierlich verbesserten. Verwenden Sie sie, um dasselbe Denken auf Ihre eigenen Procedures anzuwenden.

Dieser Artikel richtet sich an Teammitglieder, die Fin Procedures erstellen und iterieren. Es wird vorausgesetzt, dass Sie im Procedure Editor arbeiten und mindestens eine Procedure veröffentlicht haben.

Die Procedure behandelt die gesamte Bandbreite der Data Connector-Fragen: Ersteinrichtung, Authentifizierungsfehler, API-Aufruf-Fehler, Timeouts, Probleme bei der Antwortzuordnung und Regressionen. Sie deckt viel technischen Boden ab und verwendet einen eigenen Data Connector, der speziell entwickelt wurde, um vor der ersten Frage von Fin Live-Diagnosedaten über den Connector eines Kunden abzurufen. Diese Designentscheidung allein veränderte, wie die gesamte Procedure funktioniert.

Oberflächlich klingt „Hilfe bei Data Connectors“ nach einem Thema. In der Praxis umfasst es jedoch eine Reihe unterschiedlicher Situationen: eine Ersteinrichtung, einen Authentifizierungsfehler, einen fehlerhaften API-Aufruf, einen Timeout, ein Problem bei der Datenzuordnung, eine Regression (etwas, das früher funktionierte und jetzt nicht mehr), ein nicht unterstütztes Protokoll und einen Kunden, der noch nicht genau weiß, was er braucht. All dies in einer einzigen Procedure gut zu behandeln, ist nur möglich, wenn Fin früh im Gespräch erkennt, in welcher Situation es sich befindet.

Die bedeutendste Designentscheidung in der Procedure ist ein dedizierter Data Connector, der speziell entwickelt wurde, um Live-Gesundheitsdaten über den eigenen Connector eines Kunden abzurufen.

Wenn ein Kunde seine Connector-URL teilt, verwendet Fin die Connector-ID, um eine GET-Anfrage zu stellen. Es erhält zurück:

Fin verwendet diese Daten, um seine erste sinnvolle Antwort mit etwas Spezifischem zu beginnen, nicht mit etwas Allgemeinem. Das ist der Unterschied zwischen einer Procedure, die sich wie ein Support-Formular anfühlt, und einer, die sich anfühlt, als würde man mit jemandem sprechen, der Ihr Problem bereits untersucht hat, bevor er zum Telefon griff.

Die Procedure routet in zwei Stufen. Die erste ist automatisch – Fin liest die Diagnosedaten und routet, bevor es den Kunden etwas fragt. Die zweite basiert auf Absicht – wenn die erste Stufe den Pfad nicht bestimmt, liest Fin, was der Kunde beschreibt, und routet zur passenden Unter-Procedure.

Die folgende Tabelle zeigt die 13 unterschiedlichen Situationen, die die Data Connectors Setup and Troubleshooting procedure behandelt, wie Fin jede erkennt und zu welcher Unter-Procedure es routet.

Die sechs untenstehenden Prinzipien erklären, wie die Prozedur entstanden ist und wie Sie dasselbe Denken auf Ihre eigene Arbeit anwenden können.

Jedes Prinzip beinhaltet:

Bevor Fin ein einziges Wort zum Kunden sagt, sollte Fin herausfinden, worum es dem Kunden tatsächlich geht.

Unterschiedliche Absichten verdienen unterschiedliche Wege, und eine Prozedur, die jedem Kunden dieselben Einstiegsfragen stellt, verschwendet bei den meisten Zeit.

Fin führt Prozeduren auch nicht als festes Top-down-Skript aus. Es verwendet einen nicht-linearen Planungsansatz: Es kann frühere Schritte erneut besuchen, überspringen oder den Kurs ändern, während sich das Gespräch entwickelt. In einigen Fällen kann es sogar mitten im Gespräch zu einer anderen Prozedur wechseln, wenn eine andere besser passt.

Das bedeutet, dass die Schrittfolge nicht immer die Reihenfolge des Gesprächs bestimmt. Entwerfen Sie Prozeduren basierend auf der Absicht, die Fin bearbeiten muss, und nicht nach einem strikten Schritt-für-Schritt-Pfad.

Eine Prozedur, die Fragen zu Data Connectors behandelt, veranschaulicht dies gut.

"Data Connector-Frage" umfasst tatsächlich mindestens fünf verschiedene Gespräche:

Der erste Anweisungsschritt sagt Fin, die erste Nachricht des Kunden zu lesen und zu bestimmen, welche Situation zutrifft.

Bedingungsschritte weiter unten leiten das Gespräch dann entlang des passenden Pfads.

Die Steuerung erfolgt beim Auslöser, daher müssen Sie genau das testen – und das richtige Werkzeug ist Live-Testing, keine Simulationen. Simulationen umgehen die Absichtserkennung vollständig; sie führen eine Prozedur direkt aus, ohne den Auslöser zu durchlaufen, und können daher nicht sagen, ob Fin die richtige Prozedur von Anfang an auswählt.

Um die Steuerung zu testen, setzen Sie die Prozedur live mit dem Publikum auf sich selbst beschränkt – zum Beispiel eine Regel, bei der die E-Mail Ihre company domain enthält. Senden Sie zehn realistische Eröffnungsnachrichten und prüfen Sie zwei Dinge: dass diese Prozedur startet, wenn sie sollte, und dass sie nicht startet, wenn sie nicht sollte. Schließen Sie mehrdeutige Nachrichten ein; das sind die Fälle, die am wahrscheinlichsten falsch geroutet werden. Wenn eine Nachricht falsch geroutet wird, verfeinern Sie die Auslöserbeschreibung, um genauer zu definieren, wann Fin die Prozedur verwenden soll und wann nicht.

Listen Sie die verschiedenen Arten von Gesprächen auf, die Ihre Prozedur erhalten wird. Fragen Sie dann: Sind das dieselben Aufgaben mit kleinen Variationen oder wirklich unterschiedliche Aufgaben? Wenn sie wirklich unterschiedlich sind, haben Sie zwei Möglichkeiten: Teilen Sie sie in separate Prozeduren mit unterschiedlichen Auslösern auf oder behandeln Sie sie als Verzweigungen innerhalb einer Prozedur. Verwenden Sie separate Prozeduren, wenn die Aufgaben so unterschiedlich sind, dass Sie deren Leistung separat berichten möchten. Verwenden Sie Verzweigungen, wenn die Aufgaben eng verwandt sind und Sie die Logik an einem Ort behalten möchten.

Formulieren Sie Ihren Auslöser so, dass er beide Seiten klar macht: wann Fin diese Prozedur verwenden soll und wann nicht. Vage Auslöser sind die häufigste Ursache für Fehlleitungen. Bitten Sie Kunden innerhalb der Prozedur niemals, ihr eigenes Problem zu kategorisieren – Fin liest ihre Nachricht und routet danach. Die Aufgabe des Kunden ist es, sein Problem zu beschreiben, nicht es zu etikettieren.

Verwenden Sie den Bedingungsschritt für große, sich gegenseitig ausschließende Pfade – Situationen, in denen das, was Fin als Nächstes tut, je nach Antwort völlig unterschiedlich ist. Für kleinere Unterschiede halten Sie die Logik in einem Anweisungsschritt als natürliche Sprache. Das hält Prozeduren einfacher und leichter für Fin zu folgen.

Die folgenden Faktoren helfen Ihnen bei der Entscheidung, ob Sie Aufgaben in separate Prozeduren aufteilen oder als Verzweigungen innerhalb einer Prozedur behandeln:

Wenn Ihr Verfahren Zugriff auf einen Data Connector hat, der einen Teil der Kundenfrage beantworten kann, rufen Sie ihn auf, bevor Sie mit der Befragung des Kunden beginnen.

Kunden empfinden dies als Kompetenz. Verfahren, die zuerst befragen, wirken wie Formulare.

Wenn die Frage eines Kunden einen bestimmten Connector betrifft, fragt das Verfahren Data Connectors Setup and Troubleshooting einmal nach dem Namen des Connectors. Es ruft dann einen speziellen diagnostischen Data Connector auf und erhält folgende Felder zurück:

Fins erste sinnvolle Antwort verwendet diese Daten. Hier ist der Unterschied in der Praxis (Werte unten sind beispielhaft):

Nachdem der Data Connector ausgeführt wurde, lesen Sie Fins erste Nachricht laut vor. Wenn er Fragen stellt, die Sie bereits mit den abgerufenen Daten hätten beantworten können, nutzen Sie die Daten nicht aggressiv genug.

Verlagern Sie mehr Entscheidungen in Condition-Schritte, die die Daten lesen, anstatt sie dem Kunden aufzubürden.

Inventarisieren Sie die Data Connectors, die Ihrem Verfahren zur Verfügung stehen. Fragen Sie bei jedem: „Könnte ich diesen vor der ersten Kundenfrage anrufen statt danach?“ Wenn ja, strukturieren Sie um, sodass der Datenabruf zuerst erfolgt. Der Kunde sollte das Gefühl haben, dass Fin die Hausaufgaben bereits gemacht hat.

Sobald Sie diagnostische Daten abgerufen haben, verzweigen Sie direkt basierend auf diesen Daten. Lassen Sie den Kunden keinen Zustand beschreiben, den Sie bereits erkennen können.

Nachdem der Data Connector ausgeführt wurde, steht seine Antwort als temporärer Kontext zur Verfügung. Lesen Sie einzelne Felder mit der Aktion read attribute und verwenden Sie dann Condition-Schritte, die direkt auf diese Werte verzweigen.

Die folgende Tabelle zeigt, wie bestimmte Data Connector-Feldwerte auf Condition-Schritt-Zweige und die entsprechende Aktion von Fin abgebildet werden:

Jeder Zweig erzeugt eine andere Eröffnungsnachricht, die speziell für diesen Zustand geschrieben wurde.

Fragen Sie bei jedem Zweig: „Würde Fins Antwort in diesem Zweig Sinn ergeben, wenn ein echter Kunde in genau diesem Zustand sie lesen würde?“

Der Zweig für gesunde Connectoren ist oft der am schwierigsten richtig zu machen, weil der Instinkt darin besteht, weiter zu diagnostizieren. Widerstehen Sie dem. Wenn der Connector gesund aussieht, sagen Sie das und bringen Sie das Gespräch voran.

Betrachten Sie jedes Datenstück, das Sie abrufen, und fragen Sie, ob es einen Condition-Schritt steuern sollte.

Halten Sie die Logik präzise und schreiben Sie jeden Zweig so, als wäre es die einzige Antwort, die der Kunde je sehen wird.

Der häufigste Fehlerfall in einer datengetriebenen Prozedur ist kein Fehler vom Data Connector. Es ist ein erfolgreicher Aufruf, der keine Ergebnisse zurückgibt.

Normalerweise passiert dies, weil die Eingabe des Kunden nichts entspricht.

Data Connector URLs müssen exakt sein. Wenn Kunden URLs angeben, die nicht mit dem beabsichtigten Connector übereinstimmen, sei es durch Tippfehler, abschließende Schrägstriche oder andere Variationen, liefert der Data Connector oft leere Felder statt eines Fehlers.

Ohne explizite Behandlung könnte Fin fortfahren und Antworten basierend auf Daten generieren, die es nie tatsächlich gefunden hat.

Die Lösung ist ein Condition-Schritt, der prüft, ob Schlüsselfelder leer oder null sind. Falls ja, bittet Fin den Kunden, die Data Connector URL in den Data Connectors Einstellungen zu überprüfen und genau so anzugeben, wie sie erscheint. Der Data Connector wird dann mit der korrigierten URL erneut ausgeführt.

Versuchen Sie Eingaben, die fast passen, aber nicht:

Wenn die Prozedur diese Fälle nicht erkennt und darauf reagiert, ist der Fallback-Pfad nicht stark genug.

Jedes Mal, wenn Sie einen Data Connector aufrufen, fügen Sie sofort danach einen Condition-Schritt für „keine Ergebnisse“ hinzu.

In diesem Zweig:

Eine Prozedur wird durch Tests zuverlässig. Intercom bietet Ihnen drei Werkzeuge, die nacheinander unterschiedliche Probleme erkennen – verwenden Sie sie in der Reihenfolge, da jedes Probleme findet, die das vorherige nicht erkennt.

Klicken Sie im Prozedur-Editor auf Review (oben rechts, neben Test).

Review führt eine statische Analyse der Konfiguration Ihrer Prozedur durch und gibt eine Liste markierter Probleme mit spezifischen Lösungen zurück. Es erkennt Build-Zeit-Probleme wie:

Review führt kein Gespräch durch und zeigt nicht, wie Fin sich zur Laufzeit tatsächlich verhalten würde – es inspiziert nur die Konfiguration. Führen Sie es zuerst aus, um strukturelle Probleme zu beheben, bevor Sie Zeit mit Simulationen verbringen.

Simulationen führen die Prozedur von Anfang bis Ende gegen eine Eröffnungsnachricht aus, ohne kundenorientierte Ausgabe. Das Transkript zeigt mehr als die finale Antwort: Fins Gedanken bei jedem Schritt, welcher Zweig gewählt wurde, Attributaktualisierungen und Data Connector-Aufrufe. Sie können Erfolgskriterien anhängen, um die Antwort, Attributwerte, Connector-Aufrufe und das Ergebnis zu überprüfen und ein Szenario in eine wiederholbare Bestehen/Nicht-Bestehen-Prüfung zu verwandeln.

Simulationen umgehen die Intent-Erkennung vollständig – sie führen die Prozedur direkt aus und testen nicht, ob Ihr Trigger korrekt ausgelöst wird. Um die Intent-Routing zu testen, verwenden Sie Live-Tests, die auf Sie beschränkt sind (unten beschrieben).

Sobald Review sauber ist und Ihre Simulationen bestanden sind, testen Sie das echte End-to-End-Erlebnis. Setzen Sie die Prozedur live mit einer auf Sie beschränkten Zielgruppe – zum Beispiel eine Regel, bei der die E-Mail Ihre company domain enthält. So können Sie das volle Erlebnis in einem echten Gespräch testen, ohne es Kunden auszusetzen. Sobald Sie zufrieden sind, aktualisieren Sie die Zielgruppenregel, um alle Kunden einzubeziehen. Das Speichern der Regeländerung erstellt einen neuen Entwurf, also klicken Sie erneut auf Set live, damit die Änderung wirksam wird.

Live-Tests erfassen Dinge, die Simulationen nicht können – das korrekte Auslösen des Triggers, den tatsächlichen Gesprächsverlauf und das Gefühl jeder Antwort, wenn sie im Kontext ankommt.

Verfolgen Sie den Prozentsatz der Testgespräche, bei denen Fin's erste Antwort für den Kunden richtig gewirkt hätte. Fragen Sie nicht nur „Wurde es korrekt weitergeleitet?“, sondern „Würde ein aufmerksamer Mensch diese erste Antwort nützlich finden?“

Verbinden Sie dies im Laufe der Zeit mit bereits in Intercom verfügbaren objektiven Signalen: Auflösungsrate, CSAT und Gesprächszeit. Wenn eine Verfahrensverbesserung funktioniert, sollten Sie eine Veränderung sehen.

Arbeiten Sie die Ebenen der Reihe nach durch:

Jedes Mal, wenn Sie ein Verfahren live schalten, fordert Intercom Sie auf, eine ‚Was hat sich geändert?‘-Notiz zu schreiben. Behandeln Sie dieses Feld als echtes Änderungsprotokoll, nicht als Formalität. Es fühlt sich im Moment wie eine lästige Pflicht an, ist aber der Nachweis, der es Ihnen Wochen später ermöglicht, eine Metrikverschiebung mit einer bestimmten Änderung zu verbinden, anstatt zu raten.

Ein Verfahren ist nie fertig – Sie werden es ständig verfeinern, und jede Änderung ist eine kleine Wette darauf, dass das Verfahren besser wird. Der Versionsverlauf ist der Nachweis dieser Wetten. Wenn sich Auflösungsrate, CSAT oder Bearbeitungszeit nach einer Änderung verändern, zeigt eine klare Notiz, was sich wann geändert hat, sodass Sie die Verschiebung auf eine bestimmte Bearbeitung zurückverfolgen können, anstatt zu raten.

Schreiben Sie, was die Änderung bewirkt und warum, nicht nur, wo sie liegt:

Die zweite Version ist eine Notiz, auf die Sie sechs Wochen später reagieren können. Die erste nicht.

Wenn eine Änderung die Leistung verschlechtert, rollen Sie über den Versionsverlauf zurück:

Sie können auch eine bestehende Notiz (das Stiftsymbol im Versionsverlauf) bearbeiten, um zu klären, was eine frühere Änderung tatsächlich bewirkt hat.

Wenn eine Metrik sinkt, öffnen Sie zuerst den Versionsverlauf. Vergleichen Sie das Datum des Einbruchs mit Ihren Änderungsnotizen. Die Ursache ist meist die Änderung, die kurz davor veröffentlicht wurde.

Die erste Version des Data Connectors Setup and Troubleshooting-Verfahrens befragte Kunden, bevor es etwas nachschlug. Fin stellte drei oder vier Fragen, bevor er etwas Nützliches sagte. Es war technisch funktional, fühlte sich aber wie ein Formular an.

Der diagnostische Data Connector kam in der nächsten Iteration hinzu. Diese einzelne Ergänzung veränderte den Charakter des gesamten Verfahrens. Statt mit Fragen zu beginnen, konnte Fin mit spezifischen Beobachtungen starten – „Ihr Connector hat eine Erfolgsrate von 64 % in den letzten 7 Tagen und der jüngste Fehler war ein 401“ – und dann direkt zur Problemlösung übergehen.

Danach wurde das Intent Routing vom diagnostischen Ablauf getrennt. Kunden, die fragten, was Data Connectors können, erhielten einen anderen Pfad als Kunden mit einem defekten Connector. Das eliminierte viele irrelevante Diagnosefragen für Leute, die nur eine schnelle Antwort zu den Fähigkeiten brauchten.

Jede Iteration wurde durch ein spezifisches Fehlerbild in realen Gesprächen angetrieben: ein Kunde, der auf dem falschen Zweig landete, ein Fall, den das Routing nicht vorhergesehen hatte, eine Antwort, die technisch korrekt, aber im Kontext unhilfreich war. Keine Iteration entstand durch Raten. Jede basierte auf Beweisen.

Das klarste Signal, dass ein Verfahren funktioniert, ist die Qualität von Fin's erster Antwort. Bevor es dieses Verfahren gab, beantwortete ein Kunde mit einem fehlerhaften Connector mehrere Fragen, bevor er eine Anleitung erhielt. Mit dem Verfahren führt Fin's erste sinnvolle Antwort mit dem, was tatsächlich gefunden wurde: dem Zustand des Connectors, seiner Erfolgsrate der letzten Woche und dem jüngsten Fehlercode. Die Diagnose beginnt mit Daten, nicht mit einem Interview.

Auch die Routing-Tiefe ist wichtig. 13 verschiedene Pfade bedeuten, dass jede Situation eine passende Anleitung erhält. Ein Kunde, der nach SOAP-Integration fragt, bekommt eine direkte, ehrliche Antwort darüber, was unterstützt wird – nicht einen Troubleshooting-Ablauf, der ins Leere führt. Ein Kunde, dessen Connector gesund ist, dessen Daten aber nicht korrekt zugeordnet werden, wird nicht zuerst durch die Authentifizierungs-Fehlersuche geschickt.

Und wenn ein Gespräch einen menschlichen Agenten benötigt, enthält die Übergabenotiz bereits den Connector-Namen, die Connector-URL und die Problemkategorie. Der Teamkollege hat Kontext, bevor er eine einzige Kunden-Nachricht liest. Das ist aus Design-Sicht eine kleine Sache – ein Notizschritt am Ende des Verfahrens – aber es verwandelt die Übergabe von einem Neustart in eine Fortsetzung.

Wenn diese sechs Prinzipien kombiniert werden, folgt ein Verfahren wie das Beispiel Data Connectors meist einer vorhersehbaren Struktur:

Prinzip 6 – ein ehrliches Changelog zu führen – ist kein Schritt in der Struktur, aber es macht das Ganze im Laufe der Zeit verbesserbar. Ohne eine klare Aufzeichnung dessen, was sich wann geändert hat, ist jede Iteration eine Vermutung.

Die besten Fin Procedures werden nicht durch einen cleveren ersten Entwurf wirksam. Sie werden wirksam, weil jede Iteration durch Beweise aus echten Gesprächen angetrieben wird.

Beginnen Sie mit Ihrer Prozedur mit dem höchsten Volumen. Wenden Sie zuerst Prinzip 1 an: Kartieren Sie jede Absicht, die sie erhalten könnte, und überprüfen Sie, ob die Weiterleitung funktioniert. Bauen Sie dann darauf auf.

Die erste Version ist der Ausgangspunkt. Die gute Version ist die, die Sie wiederholt verfeinert haben.