Fonio Disposition Integration: Einsatzdaten automatisch übergeben und Bereitschaft zuverlässig alarmieren

Es ist 2:17 Uhr. Ein Fahrer steht mit einem Reifenschaden auf der A12 und ruft die Pannendienst-Nummer an. Fonio nimmt den Anruf entgegen, fragt nach Straße, Kilometer, Fahrtrichtung, Fahrzeugart, Kennzeichen und Rückrufnummer — sauber, strukturiert, geduldig. Das Gespräch dauert drei Minuten. Dann beendet die KI die Verbindung, und die erfassten Daten … landen nirgendwo. Ein Mitarbeiter, der die Nacht eigentlich nicht durcharbeiten sollte, überprüft morgens früh die Gesprächsprotokolle, tippt die Daten in die Dispositionssoftware, ruft den Fahrer zurück — der längst bei einem anderen Dienst war.

Dieses Szenario ist kein Nischenfall. Es beschreibt den Medienbruch, der entsteht, wenn eine Telefon-KI zwar Gespräche führt, aber die erfassten Informationen nicht dorthin weitergibt, wo das Team tatsächlich arbeitet. Für Abschleppunternehmen, Pannendienste und technische Servicebetriebe mit Bereitschaftsdienst ist diese Lücke kein bloßes Komfortproblem — sie hebt den Nutzen der Automatisierung direkt wieder auf.

Dieser Artikel beschreibt, wie eine vollständige Fonio Disposition Integration aussieht: welche Einsatzdaten per Webhook übergeben werden, wie die Bereitschaft alarmiert und eskaliert wird, welche Architekturen dafür infrage kommen und wo die realen Grenzen dieser Lösung liegen.

Hinweis: Die allgemeinen Grundlagen des Bereitschaftsdienstes mit Telefon-KI — Dienstpläne, Kriterien, Eskalationsstufen — sind im Artikel Bereitschaftsdienst mit Telefon-KI steuern ausführlich behandelt. Dieser Artikel baut darauf auf und fokussiert die konkrete Datenübergabe und Integration.

Was passiert ohne Integration: Der Medienbruch kostet mehr als Zeit

Wenn Fonio Einsatzdaten erfasst, aber nicht übergibt, entstehen drei konkrete Probleme:

Doppelerfassung. Jemand liest das Gesprächsprotokoll und tippt die Informationen manuell in die Dispositionssoftware. Dabei entstehen Tippfehler, Übertragungsfehler, fehlende Felder — genau das, was die Telefon-KI eigentlich verhindern sollte.

Zeitverlust bei zeitkritischen Einsätzen. Ein Pannendienst-Einsatz auf der Autobahn duldet keinen Versatz von 20 Minuten bis zur Disposition. Wer zuerst bestätigt, bekommt den Auftrag. Wenn die Daten erst manuell übertragen werden müssen, verliert der Betrieb systematisch gegen Mitbewerber mit direkterer Prozesskette.

Lückenhaftes Protokoll für die Abrechnung. Viele Pannendienste rechnen gegenüber Automobilclubs oder Versicherungen ab und benötigen dafür lückenlose Zeitstempel: Wann ist der Anruf eingegangen, wann wurde der Einsatz angelegt, wann wurde der Fahrer alarmiert? Ohne automatische Datenübergabe fehlen diese Zeitstempel oder sie werden nachträglich geschätzt.

Der Nutzen von Fonio entfaltet sich erst dann vollständig, wenn die erfassten Daten unmittelbar und fehlerfrei dort ankommen, wo Disponenten und Bereitschaftsfahrer tatsächlich arbeiten.

Welche Einsatzdaten Fonio erfassen und übergeben kann

Fonio kann im Gespräch strukturierte Variablen erfassen und per Fonio API und Webhooks nach Gesprächsende an externe Systeme senden. Für den Einsatzkontext eines Abschleppdienstes oder Pannendiensts sind die folgenden Felder relevant:

Standortdaten mit aktiven Rückfragen

Einfache Ortsangaben reichen für die Disposition nicht aus. Fonio stellt deshalb gezielte Rückfragen, bis die Angaben präzise genug sind:

• Straße oder Autobahn — einschließlich Bundesstraßennummer oder Autobahnbezeichnung
• Kilometer — bei Autobahnen die Kilometermarke aus dem Streckenzeichen
• Fahrtrichtung — „Richtung Berlin" oder „Richtung Frankfurt", nicht „links" oder „rechts"
• Nächste Ausfahrt oder Ortschaft als Orientierungshilfe bei unklaren Angaben

Diese Rückfrage-Logik wird im Fonio-Prompt konfiguriert. Der Assistent fragt nach, wenn eine Angabe fehlt oder mehrdeutig ist, bevor er das Gespräch beendet. Das ist eine der wesentlichen Stärken gegenüber einem einfachen Voicemail-System.

Fahrzeugdaten

• Fahrzeugart — Pkw, Transporter, Motorrad, Anhänger
• Kennzeichen — buchstabiert oder direkt gesprochen, je nach Konfiguration der Spracherkennung
• Fahrzeugzustand — fährt noch an, blockiert die Fahrbahn, Schlüssel verloren

Das Kennzeichen ist ein bekannt fehleranfälliges Feld für Spracherkennungssysteme. Empfehlenswert ist eine Bestätigungsrückfrage im Prompt: Fonio liest das erkannte Kennzeichen zurück, und der Anrufer bestätigt oder korrigiert. Diese Bestätigung sollte in den Prompt eingebaut und im Webhook-Payload als eigenes Feld markiert werden.

Kontaktdaten und Dringlichkeit

• Rückrufnummer — idealerweise automatisch aus der Anrufer-ID übernommen, mit Abfrage falls unterdrückt
• Anzahl der Personen im Fahrzeug — relevant für die Priorisierung und Fahrzeugauswahl
• Dringlichkeitssignal — Autobahn, Tunnel, schlechte Witterung, medizinischer Bedarf

Die Dringlichkeit lässt sich entweder direkt abfragen oder vom Assistenten aus den Gesamtangaben ableiten. Bei Autobahn-Einsätzen empfiehlt sich eine automatische Hochsetzung der Priorität, die im Webhook-Payload als Flag übermittelt wird.

Der Webhook-Weg: Wie Daten die KI verlassen

Nach Gesprächsende sendet Fonio einen HTTP-POST-Request an eine konfigurierte Webhook-URL. Dieser Payload enthält alle im Gespräch erfassten Variablen, Gesprächsmetadaten (Start- und Endzeit, Anrufernummer, Gesprächsdauer) und den Gesprächsstatus.

Die empfangende Seite kann unterschiedlich aufgebaut sein — dazu mehr im nächsten Abschnitt. Wichtig für die Konfiguration:

• Die Webhook-URL muss erreichbar und abgesichert sein (HTTPS, idealerweise mit einem geteilten Secret zur Signaturprüfung).
• Der empfangende Endpunkt sollte den Request sofort mit HTTP 200 bestätigen und die Verarbeitung asynchron durchführen, um Timeouts zu vermeiden.
• Für kritische Einsatzdaten empfiehlt sich eine Idempotenzprüfung: Wenn Fonio denselben Webhook mehrfach sendet (z. B. bei Netzwerkproblemen), darf kein doppelter Einsatz angelegt werden.
• Ein Fallback-Mechanismus gehört zur Planung: Wenn der Webhook nicht zugestellt werden kann, muss eine Eskalation oder manuelle Prüfung ausgelöst werden.

Die technischen Details zu Fehlerbehandlung, Timeouts und Wiederholungslogik behandelt der Artikel Fonio API Fehlerhandling gesondert.

Integrationsarchitekturen: Drei Wege zur Dispositionssoftware

Wie Fonio-Daten in die Dispositionssoftware gelangen, hängt von der vorhandenen Software-Infrastruktur ab. Die Wahl der Architektur bestimmt Aufwand, Flexibilität und Wartungskosten.

Den konzeptionellen Überblick bietet der Artikel Fonio-Standardintegration, n8n oder individuelles Backend — hier die praxisnahe Einordnung für den Einsatz-Kontext:

Option 1: Fonio-Standardintegration (ohne eigenen Code)

Für einfache Fälle — zum Beispiel die Übergabe von Einsatzdaten per E-Mail an eine Disposition, die ohnehin E-Mails verarbeitet — reicht unter Umständen die native Fonio-Integration aus. Fonio kann Gesprächsergebnisse per E-Mail, als strukturierte Zusammenfassung oder in einfache Webhook-Endpunkte schicken, die Drittdienste nativ verstehen.

Diese Option ist schnell aufgesetzt, hat aber klare Grenzen: Sie eignet sich nicht, wenn die Zielsoftware eine spezifische API-Authentifizierung erfordert, wenn Daten transformiert oder angereichert werden müssen oder wenn die Alarmierungslogik (Bereitschaft prüfen, eskalieren) in den Übergabeprozess integriert werden soll.

Option 2: n8n als Automatisierungsplattform

n8n ist eine selbst hostbare Workflow-Automatisierungsplattform, die Fonio-Webhooks als Trigger entgegennehmen, Daten transformieren und an eine Vielzahl von Zielsystemen weiterleiten kann. Für den Einsatz-Kontext sieht ein typischer Workflow so aus:

1. Fonio sendet den Webhook nach Gesprächsende.
2. n8n empfängt den Payload und validiert die Pflichtfelder (Standort, Kennzeichen, Rückrufnummer).
3. Falls Pflichtfelder fehlen, löst n8n eine Fallback-Benachrichtigung aus (SMS oder interne Benachrichtigung an die Disposition).
4. Bei vollständigen Daten: n8n schreibt den Einsatz in die Dispositionssoftware — per REST-API, per Datenbankzugriff oder per E-Mail mit definiertem Format.
5. Gleichzeitig löst n8n die Bereitschaftsalarmierung aus (siehe nächster Abschnitt).
6. n8n protokolliert den Vorgang inkl. Zeitstempel für die Abrechnung.

n8n ist für diesen Anwendungsfall gut geeignet, wenn die Dispositionssoftware eine halbwegs offene Schnittstelle bietet und die Workflow-Logik überschaubar bleibt. Der Wartungsaufwand ist real: Änderungen in der Dispositionssoftware oder neue Einsatztypen erfordern Anpassungen im Workflow.

Option 3: Individuelles Backend

Wenn die Dispositionssoftware keine offene API hat, wenn die Alarmierungslogik komplex ist (mehrere Bereitschaftsgruppen, Fahrzeugpool-Abfrage, geografische Zuordnung) oder wenn das Unternehmen eigene Reporting-Anforderungen hat, ist ein individuelles Backend der robustere Weg.

Das Backend empfängt den Fonio-Webhook, führt die gesamte Logik aus und kommuniziert mit allen beteiligten Systemen. Es kann zusätzlich eine interne Admin-Oberfläche bieten, über die Disponenten Einsätze einsehen, Status setzen und Protokolle abrufen.

Dieser Weg verursacht höheren Entwicklungsaufwand und laufende Wartungskosten — er ist aber der einzige, der alle Anforderungen ohne Kompromisse erfüllen kann. Ehrlich formuliert: Nicht jeder Abschleppbetrieb mit zwölf Fahrzeugen braucht ein individuelles Backend. Für Betriebe, die täglich viele Einsätze disponieren und deren Dispositionssoftware keine Schnittstelle bietet, ist er häufig der einzig gangbare Weg.

Bereitschaft alarmieren: Anruf, SMS und App

Die Datenübergabe an die Dispositionssoftware ist eine Seite der Integration. Die andere ist die Alarmierung: Wer wird wie benachrichtigt, wenn ein Einsatz eingeht?

Für Bereitschaftsdienste gibt es drei etablierte Alarmierungskanäle, die sich kombinieren lassen:

Anruf. Der bereitschaftshabende Fahrer oder Disponent erhält einen automatischen Anruf, der die Kerndaten des Einsatzes nennt und eine Bestätigung abfragt — z. B. durch Drücken einer Taste. Anrufe haben die höchste Aufmerksamkeitswirkung, besonders nachts. Die Nummer kann über die Telefonanlage (z. B. 3CX) oder einen SIP-Trunk direkt ausgespielt werden.

SMS. Parallel zum Anruf oder als Fallback bei nicht abgenommenen Anrufen erhält der Fahrer eine SMS mit den Einsatzdaten. SMS ist kanalredundant und funktioniert auch bei schlechter Mobilfunkverbindung besser als App-Push-Nachrichten.

App-Benachrichtigung. Wenn der Betrieb bereits eine Dispositions- oder Fahrzeug-App einsetzt, können Einsätze direkt darin eingesteuert werden. Der Fahrer sieht den Einsatz mit allen Daten, bestätigt per Tap und kann den Status aktualisieren. Das setzt voraus, dass die App Webhook- oder API-Eingabe unterstützt.

Eskalation, wenn niemand bestätigt

Der Alarmierungsprozess ist nur so gut wie sein Fallback. Wenn der erste Bereitschaftsfahrer nicht antwortet, muss das System automatisch eskalieren:

1. Kein Anruf angenommen nach X Sekunden → Wiederholungsanruf
2. Nach zweitem Fehlversuch → SMS mit Rückrufaufforderung
3. Nach definiertem Zeitfenster ohne Bestätigung → Alarmierung des nächsten Fahrers in der Bereitschaftsliste
4. Finale Eskalation → Benachrichtigung der Leitungsebene oder Notfallkontakt

Diese Logik ist in n8n abbildbar, erfordert aber sorgfältige Konfiguration der Zeitfenster und der Bereitschaftsliste. In einem individuellen Backend lässt sie sich robuster und transparenter implementieren, weil der Status jeder Eskalationsstufe zentral protokolliert wird.

Die Verbindung von Fonio mit einer 3CX-Telefonanlage für die Alarmierungsanrufe ist im Artikel Fonio mit 3CX verbinden beschrieben.

Praxisbeispiel (hypothetisch): Pannendienst mit n8n-Integration

Das folgende Beispiel ist ein hypothetisches Ablaufszenario und kein reales Kundenprojekt.

Ein mittelständischer Pannendienst mit acht Fahrzeugen und zwei Bereitschaftsfahrern pro Nacht konfiguriert Fonio als Nacht-Empfänger für alle eingehenden Anrufe ab 22 Uhr. Fonio erfasst im Gespräch: Standort mit Kilometermarke und Fahrtrichtung, Fahrzeugart, Kennzeichen (mit Bestätigungsrückfrage), Rückrufnummer und Angabe, ob das Fahrzeug die Fahrbahn blockiert.

Nach Gesprächsende sendet Fonio den Webhook an einen n8n-Endpunkt. n8n prüft, ob alle Pflichtfelder vorhanden sind. Sind sie es, schreibt ein HTTP-Request den Einsatz als neuen Auftrag in die Dispositionssoftware — über deren REST-API. Gleichzeitig startet n8n den Alarmierungsablauf: Anruf an Fahrer 1 über die 3CX-Anlage, parallel SMS mit den Einsatzdaten. Wenn Fahrer 1 nicht antwortet, wiederholt n8n nach 90 Sekunden und alarmiert nach weiterem Ausbleiben Fahrer 2. Jeder Schritt schreibt einen Zeitstempel in ein Google-Sheet, das als einfaches Abrechnungsprotokoll dient — bis eine dedizierte Reporting-Lösung eingeführt wird.

Fehlen Pflichtfelder im Webhook-Payload (z. B. weil der Anrufer aufgelegt hat), sendet n8n eine interne Benachrichtigung an den Nacht-Disponenten und markiert den Vorgang als „Rückruf erforderlich". So gehen keine Einsätze unter, auch wenn das Gespräch unvollständig war.

Protokoll für die Abrechnung: Was automatisch dokumentiert werden muss

Pannendienste, die gegenüber Automobilclubs oder Versicherungen abrechnen, benötigen lückenlose Zeitstempel. Ein vollständiges Protokoll enthält:

• Anrufeingang (Zeitstempel aus Fonio-Webhook)
• Erfasste Einsatzdaten (vollständig, mit Feldnamen)
• Zeitpunkt der Webhook-Übertraglung an die Dispositionssoftware
• Alarmierungszeitpunkt je Bereitschaftsfahrer
• Bestätigungszeitpunkt (wer hat den Einsatz angenommen)
• Einsatzbeginn und -abschluss (aus der Dispositionssoftware oder Fahrer-App)

Diese Daten müssen von Anfang an im Integrationsdesign eingeplant werden. Ein Protokoll, das nur den Anruf dokumentiert, aber nicht die Übergabe an die Disposition, ist für Abrechnungszwecke unvollständig. Wenn das Unternehmen Gesprächsaufzeichnungen nutzt, ist vorab rechtlich zu klären, ob und wie lange diese gespeichert werden dürfen und ob Anrufer darüber informiert werden müssen — das ist eine DSGVO-Anforderung, die der Betrieb vor dem Go-live mit seinem Datenschutzbeauftragten oder Rechtsberater prüfen sollte.

Grenzen der Telefon-KI und wann Menschen übernehmen müssen

Fonio ist kein Allround-Disponent. Es gibt Situationen, in denen die KI die Verbindung an einen Menschen übergeben muss:

• Unklare Standortangaben trotz Rückfragen — wenn der Anrufer den Standort nicht beschreiben kann (z. B. Panik, Sprachbarriere, kein Netzempfang für Karte), muss ein Mensch übernehmen und gegebenenfalls über den Notruf koordinieren.
• Medizinischer Notfall — Fonio erkennt Schlüsselwörter wie „Verletzung" oder „brauche Arzt" und kann konfiguriert werden, sofort an den Notfalldienst weiterzuleiten oder einen menschlichen Disponenten zu verbinden.
• Technisch komplexe Fahrzeugschäden — wenn der Anrufer ein Fahrzeug beschreibt, das besonderes Equipment erfordert (Schwertransport, Gefahrgut), reicht die Standard-Rückfragen-Logik nicht aus.
• Beschwerden und eskalierende Gespräche — wenn ein Anrufer aufgewühlt ist oder die KI nicht akzeptiert, ist der Übergang zu einem Menschen notwendig, um den Einsatz nicht zu gefährden.

Die Übergabe an Menschen ist kein Versagen der KI — sie ist geplantes Design. Im Prompt wird klar definiert, bei welchen Signalen Fonio die Verbindung weiterleitet und was es dem Anrufer dabei kommuniziert. Wie eine solche Übergabe technisch und kommunikativ gestaltet wird, beschreibt der Artikel Telefon-KI-Übergabe: Mitarbeiter mit Kontext.

Der Artikel Telefon-KI für Handwerker und technische Servicebetriebe behandelt vergleichbare Übergabeszenarien für ähnliche Betriebe.

Datenschutz: Was vor dem Go-live zu klären ist

Die Integration berührt mehrere datenschutzrechtliche Anforderungen, die der Betrieb — nicht der Integrationsdienstleister — verantworten muss:

Auftragsverarbeitung. Fonio verarbeitet Gesprächsdaten im Auftrag des Unternehmens. Ein Auftragsverarbeitungsvertrag (AVV) mit dem Fonio-Anbieter ist Pflicht. Wenn n8n auf einem externen Server läuft oder ein Cloud-Dienst für die Alarmierung genutzt wird, müssen AVVs auch dort geprüft werden. Hinweise dazu liefert der Artikel Fonio Datenschutz.

Information der Anrufer. Anrufer müssen darüber informiert werden, dass ihr Gespräch von einer KI geführt wird und dass Gesprächsdaten verarbeitet werden. Diese Information erfolgt üblicherweise zu Gesprächsbeginn durch eine Ansage. Der genaue Wortlaut und der Zeitpunkt sind mit dem Datenschutzbeauftragten abzustimmen.

Gesprächsaufzeichnung. Wenn Fonio Aufzeichnungen speichert (z. B. für Qualitätssicherung oder Nachbearbeitung), gelten besondere Anforderungen an Speicherdauer, Zugriff und Löschfristen. Das ist vor der Inbetriebnahme verbindlich zu regeln.

Besondere Kategorien nach Art. 9 DSGVO. Wenn Anrufer im Gespräch Gesundheitsinformationen nennen (z. B. Verletzungen), gelten erhöhte Anforderungen an die Datenverarbeitung. Das ist für Pannendienste eher ein Randfall, aber kein auszuschließender.

Was nicht jede Branchensoftware bietet — und was das bedeutet

Ein häufiger Einwand gegen die Integration lautet: „Unsere Dispositionssoftware hat keine API." Das ist ein reales Hindernis, das ehrlich benannt werden muss.

Nicht jede Branchensoftware für Abschleppbetriebe oder Pannendienste bietet eine dokumentierte REST-API. Ältere Systeme laufen lokal, speichern in proprietären Formaten und haben keine Schnittstelle nach außen. In diesen Fällen gibt es mehrere Optionen:

• E-Mail-Trigger: Die Dispositionssoftware empfängt Einsätze per E-Mail in einem definierten Format. Weniger elegant, aber oft praktikabel.
• Datenbankzugriff: Wenn die Dispositionssoftware auf einer zugänglichen Datenbank läuft (MySQL, PostgreSQL), kann das Backend direkt schreiben — mit dem Risiko, bei Software-Updates Kompatibilitätsprobleme zu erzeugen.
• RPA (Robotic Process Automation): Formulare werden automatisch in der Software ausgefüllt. Sehr wartungsintensiv, aber manchmal der einzige Weg.
• Parallelbetrieb: Die Dispositionssoftware bleibt wie bisher, und Fonio-Daten werden in ein separates Einsatzprotokoll geschrieben, das die Disposition ergänzt — kein Ersatz, aber ein Start.

Bevor eine Architektur gewählt wird, muss die Schnittstellensituation der bestehenden Software geklärt sein. Das ist Bestandteil jeder seriösen Integrationsberatung.

Fonio als KI-Telefonassistent: Was SW Business Solutions als Partner einbringt

SW Business Solutions ist Fonio-Partner und konzipiert, entwickelt und betreibt die Schnittstelle zwischen Fonio und der Branchensoftware — von der Anforderungsanalyse über die Webhook-Konfiguration und den Alarmierungsworkflow bis zum Go-live-Test und dem laufenden Monitoring.

Das schließt ein:

• Analyse der vorhandenen Dispositionssoftware und deren Schnittstellen
• Wahl der passenden Integrationsarchitektur (Standard, n8n oder individuelles Backend)
• Konfiguration des Fonio-Prompts mit branchenspezifischen Rückfragen und Übergaberegeln
• Aufbau des Alarmierungsworkflows mit Eskalationsstufen
• Protokollierung für Abrechnungszwecke
• Monitoring und Fallback-Handling nach Go-live

Partnerhinweis: SW Business Solutions ist Fonio-Partner. Wenn Sie über unseren Partnerlink ein kostenpflichtiges Fonio-Angebot abschließen, kann SW Business Solutions eine Provision erhalten.

Demo mit einem Einsatz aus Ihrer Branche testen — kostenlos und ohne Installation.

Wer die Integration durch SWBS umsetzen lassen möchte, findet den Einstieg über Fonio integrieren lassen.

Wann die Integration sich nicht lohnt — und wann sie es tut

Eine Fonio Disposition Integration ist kein Projekt für jeden Betrieb. Sie lohnt sich, wenn:

• Einsätze regelmäßig außerhalb der Bürozeiten eingehen und heute manuell nachbearbeitet werden
• Der Bereitschaftsdienst mehr als einen Fahrer umfasst und die Alarmierung strukturiert ablaufen muss
• Die Abrechnungsgrundlage von lückenlosen Zeitstempeln abhängt
• Die Dispositionssoftware eine zugängliche Schnittstelle hat oder eine der alternativen Übergabewege gangbar ist

Sie lohnt sich weniger, wenn:

• Die Einsatzfrequenz so niedrig ist, dass manuelle Nachbearbeitung keinen messbaren Aufwand erzeugt
• Die Dispositionssoftware keine Schnittstelle hat und auch keine der alternativen Wege praktikabel ist
• Die Betriebsgröße den Einmalaufwand für Entwicklung und Einrichtung nicht rechtfertigt

Diese Abwägung ist Teil des ersten Beratungsgesprächs — nicht jeder Betrieb braucht dasselbe Setup. Wer unsicher ist, ob der eigene Betrieb ein sinnvoller Kandidat ist, kann das im kostenlosen Erstgespräch klären.

Den Branchenartikel dieser Serie — mit dem Fokus auf die gesamte Telefonie-Strategie für Abschleppe- und Pannendienste — finden Sie unter Telefon-KI für Abschlepp- und Pannendienste.