Fin dazu zu bringen, Fragen zu beantworten, ist ein starker erster Schritt. Procedures gehen 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, das diese Systeme intern verwaltet, benötigen.
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 Fürsprache. 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 Vermeidung. Es geht um schnellere Lösungen, weniger repetitive manuelle Arbeit und ein reibungsloseres Kundenerlebnis bei Ihren Aufgaben mit hohem Volumen.
Ohne Procedures vs. mit Procedures
Ohne Procedures | Mit Procedures |
Fin erklärt einem Kunden, wie man einen Schadenersatzanspruch 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 Intercom's 2026 Customer Service Transformation Report berichten Teams, die KI in echte workflows integrieren, statt nur oberflächliche FAQs zu bedienen, von deutlich höherem ROI und verbesserten Kennzahlen. Die meisten Teams investieren in KI, aber nur eine kleine Minderheit hat eine reife Implementierung erreicht.
Vor dem Engineering starten: Was Sie jetzt tun können
Nicht jede Procedure erfordert Engineering-Arbeit. Bevor Sie technische Stakeholder einbeziehen, erkunden 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
Abläufe zur Durchsetzung von Richtlinien (z. B. Garantieanspruchsprüfungen basierend auf Kaufdatum)
Procedures mit dem Loop in teammate / agent Schritt:
Wenn eine Procedure Informationen aus einem anderen System benötigt, das Engineering aber noch nicht verfügbar ist, können Sie den Loop in teammate / agent-Schritt als Ersatz verwenden. Ein Kollege 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 über dessen Wirkung sammeln können.
Hier zu starten bietet 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, erklärt 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.
Für Ihr erstes Projekt starten Sie 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 zusammenhängen
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 Kollege nötig
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 vom Support-Team bereits gut verstanden.
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. Starten 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 Sie das Datum der Abonnementverlängerung
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 können und diese nutzen, um die Argumentation für Phase 3 aufzubauen.
Tipp: Das Recommendations-Dashboard Fin AI Agent > Analyze > Recommendations ist der schnellste Weg, Ihre besten Verfahren-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, sodass sie ein fertiges Briefing für Ihr Engineering-Gespräch ist. Ziehen Sie eine Stichprobe von Gesprächen aus dem Recommendations-Dashboard, identifizieren Sie spezifische Kundenabsichten, die zu Verfahren 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. Für den Zugriff auf Recommendations und andere KI-gesteuerte Einblicke benötigen Sie das Pro Add-on.
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)
Pro-Tipp: Erwägen Sie, den Prozess visuell in einem Tool wie Miro oder einem einfachen Flussdiagramm abzubilden. Das hilft allen, auch nicht-technischen Beteiligten, 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 Sie die Verfahrenslogik, Testszenarien und Erfolgsmetriken | Definieren Sie den Endpunkt, den Anfragetyp (z. B. GET, POST) und die spezifischen Felder, die Fin verwenden darf |
Verantwortung für Iterationen nach dem Start | 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 braucht, um ihn gut zu machen |
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 existieren, wer darauf zugreifen kann und welche Beschränkungen gelten |
Technischer Leiter | Entwickler, Architekt oder technischer Leiter für das zu verbindende System | Stimmt sich auf Machbarkeit ab, definiert den Endpunkt und erlaubte 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 rahmen Sie das Verfahren als direkten Beitrag zu einem dieser Ziele ein.
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 bereitzustellen, damit das Support-Team einen volumenstarken, 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, Aufwand und Zeitplan abzuschätzen.
Zum Zeitaufwand: Für Teams mit gut dokumentierten APIs ist die Einrichtung des Data Connectors in der Regel ein überschaubarer Arbeitsaufwand. 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 einem neuen System.
Für Support- und CX-Führungskräfte 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 vermeidbare menschliche Arbeit und lässt das Kundenerlebnis sofort wirken.“
Was zu teilen ist: Das Volumen der Gespräche, die dieses Verfahren bearbeiten würde, die aktuelle durchschnittliche Bearbeitungszeit und die erwartete Verbesserung der Lösungsrate.
Für die Führungsebene ist es am besten, sich an eine bestehende Priorität anzupassen
„Nennen Sie uns das Ziel, an dem Sie bereits gemessen werden – sei es CSAT, Bearbeitungszeit oder Reduzierung manueller Belastung – und wir werden dieses Verfahren so gestalten, 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 Kundenerfahrungswerte, schnellere Lösung und weniger Reibung in volumenstarken workflows. Kennen Sie Ihr Publikum und führen Sie mit dem, was ihnen am wichtigsten ist.
Umgang mit häufigen Einwänden
Sie sagen... | Sie sagen... |
„Wir haben keine Kapazität.“ | „Deshalb ist dies ein enger Pilot. Indem wir diese wiederkehrende manuelle Belastung vom Team entfernen, 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 zuerst die vollständige API.“ | „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, der es einem Teammitglied ermöglicht, diesen Schritt manuell abzuschließen, während der Connector gebaut wird, sodass Sie den gesamten Verfahrensablauf von Anfang bis Ende testen können. |
„Es 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 die Anleitung zum Erstellen von Data Connectors für Fin mit Ihrem Entwickler oder Systemverantwortlichen. Sie deckt den gesamten Einrichtungsprozess ab, einschließlich API-Verbindung, Authentifizierung, Datenumwandlung und Tests.
Wenn interne Ressourcen begrenzt sind
Manchmal ist der wahre Engpass der Zeitpunkt im Roadmap-Plan. Die Technik kann grundsätzlich unterstützend sein, ist aber erst im nächsten Planungszyklus 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 Fehlerbehebung, Triage-Flows und knowledge base-basierte Automatisierung schaffen jetzt Wert.
3. Verwenden Sie den Loop-in-Teammitglied-/Agent-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, geringfügige 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 wird.
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 zum Nachschlagen eines Abonnementstatus oder von 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.