Flow Builder an der Produktgrenze: Datentransformationen mit ZIS

Es gibt Anliegen, die ein Support-Team gar nicht lösen kann, weil ein anderer Anbieter zuständig ist. So ein Fall landete bei uns regelmässig im Chat: Die Kundschaft brauchte eine Information, für die wir nur die Durchgangsstation waren. Für das Team hiess das Aufwand ohne Ergebnis, für die Kundschaft Warten auf eine Antwort, die am Ende lautete: «Dafür müssen Sie sich an … wenden.» Der Schritt lag nahe: den Fall so automatisieren, dass sich die Kundschaft die Information selbst holt, durchgängig im Bot.

Die Grenze: API-Calls ja, Transformation nein

Der Plan klang einfach. Der Flow Builder, der klassische Zendesk-Bot, kann mitten im Dialog API-Calls machen und Antwortfelder anzeigen. Unser Fall brauchte mehr: Daten aus einem ersten System ziehen (personenbezogene Daten, Name und mehr), diese Daten umformen und mit dem Ergebnis einen Call in ein zweites System machen. Erst dessen Antwort enthielt, was die Kundschaft brauchte.

Da liegt die Produktgrenze: Der Flow Builder ruft APIs auf und reicht Felder durch, transformieren kann er nichts. Kein Umbauen von Werten, kein Zusammensetzen von Payloads aus mehreren Quellen, keine Zwischenlogik.

Der Umweg: ein Inbound Webhook zu ZIS

Die Lösung lief über Zendesk Integration Services (ZIS), die Integrations-Schicht, die in der Suite mitkommt, aber kaum jemand freiwillig anfasst. Die Architektur:

Kundschaft im Chat
   │
   ▼
Flow Builder ── API-Call ──► ZIS Inbound Webhook
                                 │
                                 ├─ Call System A (Daten holen)
                                 ├─ Transformation (Payload für System B bauen)
                                 ├─ Call System B (die eigentliche Antwort)
                                 └─ Ergebnis zwischenspeichern
   ┌─────────────────────────────┘
   ▼
Flow Builder liest das Ergebnis und antwortet –
löst das Anliegen oder verweist sauber an die zuständige Stelle

Der Bot schickt die Daten an den Inbound-Webhook-Flow, ZIS erledigt die Calls samt Umformung und legt alle wichtigen Informationen zwischengespeichert ab. Nach Abschluss greift der Bot auf diese Daten zu und schliesst den Fall ab: Entweder ist das Anliegen gelöst, oder die Kundschaft bekommt die Information, mit der sie beim zuständigen Anbieter sofort richtig ist. Auch das zweite ist eine echte Lösung: Deflection mit Substanz statt «da können wir nichts machen».

Was der Umweg kostete

ZIS hat einen Konstruktionsfehler, der im Alltag wehtut: keine Benutzeroberfläche. Flows werden als JSON-Definitionen gebaut und deployt. Jede Anpassung ist Handarbeit im Code, jedes Debugging ein Blindflug durch Logs statt ein Blick in einen visuellen Editor. Was im ersten Bau noch als sportliche Übung durchgeht, wird in der Wartung teuer: Wer den Flow ein halbes Jahr später anpassen muss, braucht wieder Expertenwissen statt fünf Minuten im Admin Center.

Dafür hatte der Umweg einen handfesten Vorteil: ZIS verursacht keine zusätzlichen Kosten. Die Rechnung lautete also: einmal Expertenaufwand gegen einen dauerhaft kostenlosen, vollautomatischen Fall. Sie ging auf. Der Fall lief, die Kundschaft bekam ihre Information ohne Umweg über uns, das Team hatte die Zeit zurück.

Die Bilanz

Würde ich es wieder so bauen? Nein. Was wir mit ZIS von Hand zusammensetzen mussten, bietet Zendesk heute als Produkt an. Action Flows machen Datenverarbeitung im Bot-Kontext über eine richtige Oberfläche zugänglich, intuitiv genug, dass man dafür keinen Integrations-Spezialisten mehr braucht. Sie haben eine grosszügige Nutzungslimite statt des Gratis-Etiketts von ZIS, aber der Unterschied im Unterhalt ist den Preis wert.

Wie der neue Weg aussieht, wo seine Grenzen liegen und welche alten ZIS-Konstrukte man heute ablöst, steht im Bauplan Action Flows: was den ZIS-Umweg heute ersetzt.