Fin dazu zu bringen, Fragen zu beantworten, ist ein starker erster Schritt. Procedures gehen noch weiter, indem sie Fin helfen, wiederholbare, mehrstufige Probleme zu lösen – nicht nur einen Prozess zu erklären, sondern ihn tatsächlich abzuschließen.
Dafür benötigt Fin in der Regel Zugriff auf Informationen oder Aktionen in Ihren internen Systemen, was bedeutet, dass Sie möglicherweise Unterstützung vom Engineering oder vom Team benötigen, das diese Systeme intern verwaltet.
Dieser Leitfaden richtet sich an Support- und Operations-Leiter, die Procedures intern vorantreiben. Er hilft Ihnen, den Umfang der Anfrage abzustecken, mit technischen Stakeholdern selbstbewusst zu sprechen und das erste Projekt klein genug zu halten, um genehmigt zu werden.
Warum das wichtig ist
Fin beantwortet bereits Informationsfragen gut. Procedures eröffnen einen anderen Wert: Probleme zu lösen, die von Echtzeitdaten oder Systemaktionen abhängen, wie z. B. den Bestellstatus zu prüfen, ein Abonnement nachzuschlagen oder eine Rücksendung zu bearbeiten.
Hier beginnt die interne Advocacy-Arbeit. Wenn ein Kundenproblem von Live-Daten oder einer Systemaktion abhängt, benötigt Ihr Team Data Connectors und API-Zugriff, um diese Erfahrung zu ermöglichen.
Die Chance liegt nicht nur in der Ablenkung. Es geht um schnellere Lösungen, weniger repetitive manuelle Arbeit und ein reibungsloseres Kundenerlebnis bei Ihren Aufgaben mit dem höchsten Volumen.
Ohne Procedures vs. mit Procedures
Ohne Procedures | Mit Procedures |
Fin erklärt einem Kunden, wie man einen Anspruch für eine beschädigte Bestellung einreicht. | Fin bearbeitet den Anspruch, prüft den Bestellstatus in Ihrer Datenbank und bestätigt den Ersatz – alles in einem Gespräch. |
Fin sagt einem Kunden, er solle sich anmelden, um das Verlängerungsdatum seines Abonnements zu prüfen. | Fin ruft das Verlängerungsdatum und den Abonnementstatus in Echtzeit ab und gibt dem Kunden sofort eine Antwort – ohne Anmeldung. |
Laut Intercoms Customer Service Transformation Report 2026 berichten Teams, die AI in echte workflows integrieren, anstatt nur oberflächliche FAQs zu bedienen, von deutlich höherem ROI und verbesserten Kennzahlen. Die meisten Teams investieren in AI, aber nur eine kleine Minderheit hat eine reife Implementierung erreicht.
Beginnen Sie vor dem Engineering: Was Sie jetzt tun können
Nicht jede Procedure erfordert Engineering-Arbeit. Bevor Sie technische Stakeholder einbeziehen, prüfen Sie, was Sie mit dem, was Sie bereits haben, bauen können.
Procedures, die keine Data Connectors benötigen:
Geführte Fehlerbehebungsabläufe mit knowledge base-Inhalten
Schritt-für-Schritt-Anleitungen, die Informationen sammeln und an das richtige Team weiterleiten
Triage-Procedures, die qualifizierende Fragen stellen, bevor sie eskalieren
Richtlinien-Durchsetzungsabläufe (z. B. Garantieanspruchsprüfungen basierend auf Kaufdatum)
Procedures mit dem Ask Teammate-Schritt:
Wenn eine Procedure Informationen aus einem anderen System benötigt, aber Engineering noch nicht verfügbar ist, können Sie den Ask Teammate-Schritt als Ersatz verwenden. Ein Teammitglied führt diesen Schritt manuell aus, während der Data Connector gebaut wird, sodass Sie den gesamten Procedure-Ablauf end-to-end testen und Daten zu dessen Wirkung sammeln können.
Der Start hier verschafft Ihnen zwei Vorteile: Sie lernen, wie man Procedures baut, und erzielen messbare Ergebnisse, die den Fall für Engineering-Investitionen untermauern, wenn Sie sie brauchen.
Tipp: Teams können jetzt Procedures mit natürlicher Sprache erstellen und verwalten, die nötigen Kontrollen und Daten für Genauigkeit anwenden und jedes Szenario testen, bevor es einen Kunden erreicht. Viele Bausteine wie Beschreibungen, Auslöser, Bedingungen und Anleitungen erfordern keine technischen Fähigkeiten.
Neu bei APIs und Data Connectors?
Wenn Sie mit diesen Begriffen neu sind, behandelt dieser Abschnitt, was Sie wissen müssen, um die Anfrage abzustecken und intern zu erklären.
Eine API (Application Programming Interface) ist eine strukturierte Methode, mit der Softwaresysteme Informationen austauschen. Wenn ein System Daten von einem anderen benötigt, sendet es eine Anfrage über eine API und erhält eine Antwort.
Ein Data Connector verwendet einen API-Aufruf, damit Fin sicher ein bestimmtes Stück Information abrufen oder senden kann, wie z. B. einen Bestellstatus oder ein Verlängerungsdatum eines Abonnements. Jeder Connector ist normalerweise für eine spezifische Aufgabe konzipiert. Erfahren Sie mehr über Data Connectors.
Eine Procedure verwendet diese Connectoren in einem mehrstufigen Prozess, sodass Fin mehr tun kann als nur eine Frage zu beantworten – es kann helfen, das Problem zu lösen. Erfahren Sie mehr über Procedures.
Beginnen Sie bei Ihrem ersten Projekt klein: ein wiederholbarer Prozess, ein System und nur die wenigen Datenfelder, die Fin tatsächlich benötigt. Je fokussierter die Anfrage, desto schneller der Fortschritt.
Beispiel: wie die Teile zusammenwirken
Kundenziel: „Prüfen Sie mein Verlängerungsdatum des Abonnements“
Procedure: Fin bestätigt die Identität, ruft das Abrechnungssystem auf und gibt das Verlängerungsdatum in einem Gespräch zurück
Data Connector: Ein schreibgeschützter API-Aufruf an die Abrechnungsplattform, der drei Felder zurückgibt: Verlängerungsdatum, Planname, Abonnementstatus
Ergebnis: Fin antwortet in Sekunden. Kein Teammitglied erforderlich
Fin benötigt keinen Zugriff auf Ihr gesamtes System. In der Regel braucht es nur einen sicheren Weg, um eine kleine Menge genehmigter Daten abzurufen oder zu senden. Engineering oder der Systembesitzer legt genau fest, auf welche Felder Fin zugreifen darf, nicht mehr.
Für die vollständige technische Einrichtung lesen Sie den Artikel Designing and using your APIs with Data connectors.
Wie Sie Ihre erste Procedure auswählen
Der beste interne Fall beginnt mit einem konkreten Prozess, nicht mit einem Feature-Pitch. Bevor Sie Engineering einbeziehen, schreiben Sie den genauen Prozess auf, den Sie automatisieren möchten, und die minimalen Daten, die Fin dafür benötigt.
Eine gute erste Procedure ist in der Regel eng, repetitiv und Ihrem Support-Team bereits gut bekannt.
Profi-Tipp: Wählen Sie den wertvollsten Prozess, den Sie mit den wenigsten Endpunkten und dem kleinsten Satz an Feldern automatisieren können. Eine Procedure, die wenige Felder aus einem System liest, wird viel leichter genehmigt, gebaut und gestartet als eine, die mehrere Systeme berührt. Beginnen Sie eng – Komplexität kann später kommen, sobald der erste Erfolg gesichert ist.
Auswahlkriterien
Verwenden Sie die folgenden Kriterien, um Ihren besten Kandidaten zu identifizieren:
Kriterien | Worauf Sie achten sollten |
Volumen | Ein häufig auftretendes Problem, das Ihr Team wiederholt bearbeitet |
Wiederholbarkeit | Ein Prozess mit konsistenten Schritten, der nicht jedes Mal menschliches Urteilsvermögen erfordert |
API-Verfügbarkeit | Eine gut dokumentierte API existiert bereits (z. B. Stripe, Shopify) oder kann schnell definiert werden |
Systemverantwortung | Sie wissen, welches interne Team oder Tool die Daten oder Aktion besitzt (z. B. „das ist in Salesforce“ oder „unser Abrechnungsteam kümmert sich darum“) |
Klarheit der Engineering-Anfrage | Sie können beschreiben, was Fin in einem Satz benötigt, ohne technische Begriffe zu verwenden. Fin benötigt nur eine kleine Anzahl von Feldern aus einem System |
Messbarkeit | Sie können eine klare Erfolgsmetrik definieren, bevor Sie bauen (z. B. Lösungsrate) |
Beispiel: ein gutes erstes Verfahren
Anwendungsfall: Überprüfen des Abonnementverlängerungsdatums
System: Abrechnungsplattform
Was Fin benötigt: Verlängerungsdatum, Planname, Abonnementstatus – drei Felder von einem Endpunkt
Erste Anfrage: „Wir benötigen einen schreibgeschützten Endpunkt, der diese drei Felder für einen authentifizierten Kunden zurückgibt.“
Warum es funktioniert: Hohe Menge, wiederholbar, geringes Risiko und leicht messbar. Erfordert keinen Schreibzugriff und minimalen Aufwand von Engineering oder Systemverantwortlichem.
Denken Sie in Phasen, nicht alles auf einmal
Die erfolgreichsten Teams führen Verfahren in Stufen ein:
1. Keine Integration erforderlich: Automatisieren Sie FAQ-ähnliche Abläufe, Fehlerbehebungsanleitungen und Routing-Logik nur mit knowledge base-Inhalten.
2. Schreibgeschützter Zugriff: Verbinden Sie Fin mit einem System, um Informationen abzurufen (z. B. Bestellstatus, Kontodetails, Abonnementdaten). Hier kommt der erste Data Connector zum Einsatz.
3. Schreibaktionen: Ermöglichen Sie Fin, in einem anderen System Aktionen durchzuführen (z. B. eine Rückerstattung verarbeiten, ein Abonnement kündigen, einen Datensatz aktualisieren). Dies erfordert tiefere Engineering-Beteiligung und erfolgt meist nach Vertrauensaufbau.
Mit Phase 1 oder 2 zu beginnen bedeutet, dass Sie schnell Ergebnisse zeigen und diese nutzen können, um die Argumentation für Phase 3 aufzubauen.
Tipp: Das Recommendations-Dashboard Fin AI Agent > Analyze > Recommendations ist der schnellste Weg, Ihre besten Procedures-Kandidaten zu finden.
Filtern nach Kundendatenlücken: wo Fin Informationen aus einem externen System wie Bestellstatus oder Kontodetails benötigte
Filtern nach Aktionslücken: wo Fin in einem anderen System eine Aktion ausführen musste, z. B. eine Bestellung stornieren oder einen Datensatz aktualisieren.
Jede Empfehlung enthält eine Anleitung, die die API und benötigten Daten beschreibt, und ist somit ein fertiges Briefing für Ihr Engineering-Gespräch. Ziehen Sie eine Stichprobe von Gesprächen aus dem Recommendations-Dashboard, identifizieren Sie spezifische Kundenabsichten, die zu Procedures werden könnten, und schätzen Sie die Verbesserung der Lösungsrate basierend darauf, wie oft diese Anfragen auftreten. So wird aus einer allgemeinen Idee ein konkreter, definierter Plan.
Den Prozess vor dem Meeting abbilden
Bevor Sie Engineering oder das Team, das das relevante System besitzt, ansprechen, legen Sie genau fest, was Sie automatisieren möchten. Dies ist der wichtigste Schritt – ein gut abgebildeter Prozess macht das technische Gespräch schneller und die Anfrage schwerer abzulehnen.
Wie man es abbildet
1. Schreiben Sie den Prozess Schritt für Schritt in einfacher Sprache auf. Was löst ihn aus? Was passiert bei jedem Schritt? Was erhält der Kunde am Ende?
2. Markieren Sie genau, wo Fin Daten aus einem anderen System benötigt oder eine Aktion ausführen muss. Dies sind Ihre Data Connector-Kontaktpunkte.
3. Listen Sie für jeden Kontaktpunkt die spezifischen Datenfelder auf, die Fin benötigt. Nicht die gesamte Datenbank – nur die minimalen Felder für diesen Prozess.
4. Identifizieren Sie, welches Team jedes System besitzt. Das ist nicht immer Engineering. Es könnte das Team sein, das Salesforce, Jira, Ihre Abrechnungsplattform oder ein anderes internes Tool verwaltet.
Was zum Meeting mitbringen
Den abgebildeten Prozess mit klaren Data Connector-Kontaktpunkten
Die spezifischen Felder, die Fin bei jedem Schritt benötigt (z. B. „Bestellstatus, Sendungsnummer, voraussichtliches Lieferdatum“)
Eine Erfolgsmetrik, die Sie vor und nachher messen können (z. B. „Lösungsrate für Anfragen zum Bestellstatus“)
Volumendaten, die zeigen, wie oft dieses Problem auftritt (ziehen Sie diese aus dem Recommendations-Dashboard oder Ihren Berichten)
Profi-Tipp: Erwägen Sie, den Prozess visuell in einem Tool wie Miro oder einem einfachen Flussdiagramm abzubilden. Das hilft allen, auch nicht-technischen Stakeholdern, das Gesamtbild zu sehen und zu erkennen, wo die eigentliche Engineering-Arbeit liegt.
Wer beteiligt ist und was sie tun
Der Aufbau eines Verfahrens erfordert zwei Arten von Abstimmung: Klarheit darüber, wer was im Tagesgeschäft besitzt, und Wissen, welche Stakeholder für die Genehmigung eingebunden werden müssen.
Tagesverantwortung
CX / Support-Team | Engineering-Team |
Schreiben und Aktualisieren des Verfahrens in natürlicher Sprache mit Schritten, Tools und Anleitungen innerhalb von Intercom | Systemzugang über Data Connectors bereitstellen (authentifizierte API-Aufrufe) |
Definieren der Verfahrenslogik, Testszenarien und Erfolgsmetriken | Definieren des Endpunkts, des Anfragetypen (z. B. GET, POST) und der spezifischen Felder, die Fin verwenden darf |
Iteration nach dem Start verantworten | Authentifizierungsheader oder Tokens festlegen und Sicherheitsbeschränkungen bestätigen
|
Wer muss im Raum sein
Rolle | Wer sie typischerweise sind | Was sie beitragen |
Champion | Support- oder Operations-Leiter, der die Initiative vorantreibt | Kartiert den Prozess von Anfang bis Ende und definiert, was Fin benötigt, um ihn gut auszuführen |
Direkter Sponsor | Leiter von Support, CX oder Operations | Genehmigt das Verfahren als Priorität und gibt dem Champion das Mandat, voranzukommen |
Systemverantwortlicher | Das Team oder die Person, die für das relevante interne Tool verantwortlich ist (z. B. Salesforce-Admin, Leiter des Abrechnungsteams, Jira-Verantwortlicher) | Bestätigt, welche Daten vorhanden sind, wer darauf zugreifen kann und welche Beschränkungen gelten |
Technischer Leiter | Entwickler, Architekt oder technischer Leiter für das zu verbindende System | Stimmt die Machbarkeit ab, definiert den Endpunkt und die erlaubten Felder und bestätigt den Zeitplan |
Dies ist nicht immer ein technisches Gespräch. Wenn die Daten, die Fin benötigt, in Salesforce, Jira, Ihrer Abrechnungsplattform oder einem anderen internen Tool liegen, kann der wichtigste Stakeholder das Team sein, das dieses System besitzt, nicht ein Softwareingenieur. Identifizieren Sie zuerst den Systemverantwortlichen und bestimmen Sie dann, ob eine technische Beteiligung erforderlich ist.
Der Business Case nach Stakeholder
Dasselbe Verfahren kann je nach Anwesenden sehr unterschiedlich dargestellt werden. Bevor Sie die Präsentation vorbereiten, finden Sie heraus, für welche Prioritäten Ihre Führung bereits verantwortlich ist, und stellen Sie das Verfahren als direkten Beitrag zu einem dieser Ziele dar.
Für technische Leiter ist es am besten, die Anfrage begrenzt zu halten
"Wir bitten die Technik nicht, einen AI workflow zu übernehmen. Wir bitten um Hilfe, einen sicheren Endpunkt freizugeben, damit das Support-Team einen hochvolumigen, wiederholbaren Prozess selbst automatisieren kann. Sobald der Endpunkt eingerichtet ist, baut und pflegt das CX-Team das Verfahren eigenständig, ohne fortlaufende technische Beteiligung."
Was zu teilen ist: Der spezifische Endpunkt, die benötigten Felder, der Anfragetyp (GET oder POST) und die Authentifizierungsmethode. Je präziser die Anfrage, desto einfacher ist es für einen Entwickler, den Aufwand abzuschätzen und einzuplanen.
Zum Zeitaufwand: Für Teams mit gut dokumentierten APIs ist die Einrichtung des Data Connectors in der Regel ein abgegrenztes Arbeitspaket. Wir haben gesehen, dass ein Entwicklerteam eines Kunden einen schreibgeschützten Connector in weniger als einer Stunde zum Laufen gebracht hat. Der Umfang ist vergleichbar mit der Erstellung jeder anderen API-Integration, nicht mit einem neuen System.
Für Support- und CX-Leitung ist es am besten, sich auf die Lösung zu konzentrieren
"Ohne diese Integration kann Fin nur den Prozess erklären. Mit ihr kann Fin den Prozess abschließen. Das reduziert vermeidbaren menschlichen Aufwand und lässt das Kundenerlebnis sofort wirken."
Was zu teilen ist: Das Volumen der Gespräche, die dieses Verfahren abwickeln würde, die aktuelle durchschnittliche Bearbeitungszeit und die erwartete Verbesserung der Lösungsrate.
Für die Geschäftsleitung ist es am besten, sich an einer bestehenden Priorität auszurichten
"Nennen Sie uns das Ziel, an dem Sie bereits gemessen werden – sei es CSAT, Bearbeitungszeit oder Reduzierung manueller Last – und wir gestalten dieses Verfahren so, dass es ein direktes Ergebnis dafür zeigt. Es braucht keinen eigenen Business Case. Es ist ein direkter Beitrag zu etwas, das Sie bereits verfolgen."
Ein Hinweis zur Darstellung: Für einige Organisationen ist der Dollarwert der Automatisierung erheblich. Für andere bewegen die finanziellen Einsparungen durch ein einzelnes Verfahren auf ihrer Skala vielleicht wenig. In diesen Fällen führen Sie mit der qualitativen Auswirkung: verbesserte Kundenzufriedenheitswerte, schnellere Lösungen und weniger Reibung in hochvolumigen workflows. Kennen Sie Ihr Publikum und führen Sie mit dem, was ihnen am wichtigsten ist.
Umgang mit häufigem Widerstand
Sie sagen... | Sie sagen... |
"Wir haben keine Kapazität." | "Deshalb ist dies ein enger Pilot. Indem wir diese wiederkehrende manuelle Last vom Team nehmen, schaffen wir tatsächlich Kapazität für zukünftige Sprints." |
"Wir wollen keinen breiten Systemzugang." | "Data Connectors sind auf spezifische Endpunkte und Antwortfelder begrenzt. Wir können mit schreibgeschütztem Zugriff beginnen, um die Sicherheit zu gewährleisten." |
"Wir brauchen die API erst vollständig gebaut." | "Wir können jetzt mit dem Design beginnen. Intercom unterstützt Beispiel-JSON-Antworten im Setup, und wir können die Logik mit Simulationen validieren, bevor die API live ist." Sie können auch den Ask teammate-Schritt als temporären Ersatz verwenden, damit ein Teammitglied diesen Schritt manuell abschließen kann, während der Connector gebaut wird, sodass Sie den gesamten Verfahrensablauf von Anfang bis Ende testen können. |
"Das steht dieses Quartal nicht auf unserer Roadmap." | "Verstanden. Können wir es in den nächsten Planungszyklus aufnehmen? In der Zwischenzeit werden wir den Prozess kartieren, die Felder dokumentieren und die Erfolgskennzahl definieren – sodass die Anfrage bereit ist, wenn Kapazität frei wird." |
Sobald Sie die technische Abstimmung haben, teilen Sie den Create data connectors for Fin-Leitfaden mit Ihrem Entwickler oder Systemverantwortlichen. Er deckt den gesamten Einrichtungsprozess ab, einschließlich API-Verbindung, Authentifizierung, Datenumwandlung und Tests.
Wenn interne Ressourcen begrenzt sind
Manchmal ist der wahre Engpass das Timing der Roadmap. Die Technik kann grundsätzlich unterstützend sein, ist aber bis zum nächsten Planungszyklus nicht verfügbar. Das ist ein vernünftiges Ergebnis, kein Scheitern.
Was zu tun ist, während Sie warten
1. Kartieren Sie den Prozess von Anfang bis Ende in einfacher Sprache. Dokumentieren Sie jeden Schritt, jedes Datenfeld und jeden Systemkontaktpunkt.
2. Erstellen Sie Verfahren, die keine Data Connectors benötigen. Geführte Fehlersuche, Triage-Flows und knowledge base-basierte Automatisierung schaffen jetzt Wert.
3. Verwenden Sie den Ask Teammate-Schritt als Brücke für Schritte, die schließlich einen Data Connector verwenden werden.
4. Sammeln Sie Volumendaten und verfolgen Sie die Ergebnisse der Verfahren, die Sie bereits erstellt haben – das wird zum Beweis für Ihre nächste Anfrage.
5. Begrenzen Sie den Umfang so weit wie möglich, damit die technische Anfrage bereit ist, wenn Kapazität frei wird.
Holen Sie sich externe Hilfe
Nehmen Sie an den wöchentlichen Intercom Community Meetup Office Hours für Fragen & Antworten und mentorengestützte Unterstützung teil
Um Hilfe bei der Abgrenzung zu erhalten, Blockaden zu besprechen und zu hören, wie andere Teams ähnliche interne Gespräche geführt haben. Allgemein nützlich und kostenlos teilnehmbar
Engagieren Sie einen Experten für persönliche 1:1-Unterstützung
Für eine praktischere, dedizierte Unterstützung verbindet das verifizierte Experts Program Sie mit unabhängigen Beratern und Entwicklern, die sich auf Fin und Data Connectors spezialisiert haben. Eine gute Option, wenn Sie 1:1-Anleitung wünschen und bereit sind, in einen maßgeschneiderten Weg zu investieren
Tipp: Der Schnellstart: Erstellen Sie eine Fin Procedure führt Sie Schritt für Schritt durch den Aufbau Ihrer ersten Procedure, einschließlich eines ausgearbeiteten Beispiels mit einem Data Connector.
Verwandte Ressourcen
FAQs
Müssen wir eine neue API erstellen, um Procedures zu verwenden?
Müssen wir eine neue API erstellen, um Procedures zu verwenden?
Nicht unbedingt, wenn bereits eine gut dokumentierte API existiert (z. B. Stripe oder Shopify), ist dies typischerweise eine überschaubare, einfache Integration. Die Technik muss nur den spezifischen Endpunkt und die Felder freigeben, die Fin verwenden darf.
Können wir eine Procedure testen, bevor die API bereit ist?
Können wir eine Procedure testen, bevor die API bereit ist?
Ja, Intercom unterstützt Beispiel-JSON-Antworten bei der Einrichtung, sodass Sie die Logik mit Simulationen aufbauen und validieren können, bevor die Live-API verbunden ist.
Muss die Technik die Procedure selbst erstellen?
Muss die Technik die Procedure selbst erstellen?
Normalerweise nicht, das Support- oder Operationsteam ist für die Procedure-Logik verantwortlich – das Schreiben der Schritte, das Testen und die Iteration nach dem Start. Die Technik oder der Systemverantwortliche stellt die Datenschicht bereit: den richtigen Endpunkt freigeben, definieren, auf welche Felder Fin zugreifen kann, und die Authentifizierungsmethode festlegen. Sobald das eingerichtet ist, kann das CX-Team die Procedure eigenständig erstellen und aktualisieren.
Was, wenn wir nur Lesezugriff auf die API zu Beginn erhalten?
Was, wenn wir nur Lesezugriff auf die API zu Beginn erhalten?
Das ist ein völlig gültiger Ausgangspunkt. Eine schreibgeschützte Procedure, zum Beispiel zur Abfrage des Abonnementstatus oder der Bestelldetails, reduziert dennoch bedeutende manuelle Arbeit und liefert ein messbares Ergebnis als Grundlage.
Wie lange dauert es typischerweise, bis die Technik einen Data Connector einrichtet?
Wie lange dauert es typischerweise, bis die Technik einen Data Connector einrichtet?
Das hängt von der Komplexität ab, aber für Teams mit gut dokumentierten APIs kann ein schreibgeschützter Data Connector relativ schnell eingerichtet werden – manchmal in weniger als einer Stunde. Der Umfang ähnelt dem Aufbau jeder Standard-API-Integration: Endpunkt definieren, Authentifizierung festlegen, Antwortfelder zuordnen. Das CX-Team übernimmt den Rest.
Können wir Procedures ohne technische Beteiligung erstellen?
Können wir Procedures ohne technische Beteiligung erstellen?
Ja. Procedures, die knowledge base-Inhalte, geführte Troubleshooting-workflows, Triage-Logik oder den Ask Teammate-Schritt verwenden, benötigen keine Data Connectors oder technische Arbeit. Dies ist ein guter Startpunkt, um Vertrauen aufzubauen, bevor man zu verbundenen Procedures übergeht.