Fonio mit Warenwirtschaft und Shop verbinden: Verfügbarkeit abfragen, reservieren und Reklamationen anlegen

Das Telefon klingelt. Ein Kunde fragt, ob ein Artikel in der richtigen Größe noch vorrätig ist — oder ob seine Bestellung aus dem Onlineshop schon versandt wurde. Gleichzeitig nimmt ein Mitarbeiter an der Kasse eine Zahlung entgegen, ein anderer bearbeitet Retouren. Die Antwort auf den Anruf kostet zwei bis drei Minuten: nachschauen im Warenwirtschaftssystem, Kundennummer suchen, Bestellstatus heraussuchen, zurückrufen.

Das passiert nicht einmal täglich, sondern viele Male. Und jede dieser Unterbrechungen zieht den Mitarbeiter aus einem anderen Vorgang heraus.

Genau hier setzt die Fonio Warenwirtschaft Integration an: Fonio nimmt den Anruf entgegen, stellt gezielte Rückfragen, ruft über eine Schnittstelle Echtzeitdaten aus dem ERP- oder Shop-System ab — und gibt dem Kunden eine belastbare Auskunft. Ohne Warteschleife, ohne doppelte Erfassung.

Dieser Artikel erklärt, wie das technisch funktioniert, welche Prozesse sich eignen, wo die Grenzen liegen und wie ein sauberer Fallback aussieht.

Warum Bestandsabfragen per Telefon ein strukturelles Problem sind

Wer Filialen, ein Warenwirtschaftssystem und einen Onlineshop betreibt, kennt das Muster: Der Bestand ist in einem System gepflegt, die Mitarbeiter haben aber nicht immer direkten Zugriff — oder die Auskunft dauert, weil zunächst geprüft werden muss, ob der Artikelstamm aktuell ist.

Das Ergebnis ist ein Medienbruch: Der Anruf kommt rein, die Information liegt im System, aber zwischen beidem steht ein manueller Schritt. Fonio schließt diese Lücke — vorausgesetzt, die Systemlandschaft erlaubt eine Schnittstelle.

Typische Anruftypen, die sich für eine Integration eignen:

• „Haben Sie Artikel XY noch in Größe M auf Lager?"
• „Ich habe gestern online bestellt — ist das schon versandt?"
• „Ich würde einen Artikel reservieren und abholen — geht das telefonisch?"
• „Ich möchte eine Reklamation melden, ich habe eine fehlerhafte Lieferung erhalten."

Allen gemeinsam ist: Die Antwort liegt bereits im System. Was fehlt, ist der automatisierte Weg dorthin.

Was Fonio in dieser Integration leisten kann

Fonio ist ein KI-Telefonassistent, der Anrufe entgegennimmt, strukturierte Rückfragen stellt, Informationen erfasst und über Webhooks und API-Endpunkte mit externen Systemen kommuniziert. Für eine Warenwirtschaftsintegration bedeutet das konkret:

Lesende Abfrage: Fonio kann über eine REST-Schnittstelle den Bestand eines Artikels abfragen, eine Bestellnummer nachschlagen oder den Lieferstatus aus dem Shop-System abrufen — und das Ergebnis direkt im Gespräch ausgeben.

Schreibende Aktionen: Fonio kann strukturierte Datenpakete per Webhook an ein Backend übergeben, das dann im Zielsystem eine Reservierung anlegt, eine Reklamation eröffnet oder eine Rückrufaufgabe erstellt.

Gesprächsführung: Der Assistent stellt gezielte Rückfragen, wenn Eingaben fehlen — z. B. Artikelnummer, Kundennummer oder Bestellnummer — und wiederholt oder korrigiert sie, wenn die Spracherkennung unsicher ist.

Was Fonio hingegen nicht leistet: Es trifft keine eigenständigen Geschäftsentscheidungen, gewährt keine Rabatte ohne hinterlegtes Regelwerk und kann keine Rückfragen beantworten, die außerhalb des konfigurierten Wissensstands liegen. Sobald ein Gespräch diese Grenzen erreicht, ist eine saubere Übergabe an einen Mitarbeiter die richtige Reaktion — kein weiteres Nachfragen im Kreis.

Praxisbeispiel (hypothetisch): Ein Fachhandel mit mehreren Filialen

Das folgende Beispiel beschreibt einen fiktiven Ablauf zur Veranschaulichung der technischen Möglichkeiten — keine reale Referenz.

Ein Fachhandel für Sportartikel betreibt drei Filialen und einen Onlineshop. Das Warenwirtschaftssystem führt Bestände filialgetrennt. Täglich gehen Anrufe ein: Kunden fragen, ob ein bestimmtes Modell in einer bestimmten Filiale vorrätig ist — häufig für Click and Collect.

Ohne Integration: Ein Mitarbeiter nimmt den Anruf entgegen, wechselt in die Warenwirtschaft, sucht den Artikel, liest den Filialbestand ab, gibt mündlich Auskunft. Wenn der Bestand gerade null ist, sucht er alternativ in anderen Filialen.

Mit Fonio-Integration: Fonio nimmt den Anruf entgegen, fragt nach Artikelnummer oder Bezeichnung sowie nach der gewünschten Filiale. Es sendet eine Anfrage an einen Middleware-Endpunkt, der die Warenwirtschafts-API aufruft. Wenn der Bestand > 0 ist, gibt Fonio die Information sofort aus. Wenn der Bestand 0 ist, fragt es aktiv nach einer alternativen Filiale oder bietet einen Rückruf an, sobald Ware eingeht — je nach konfiguriertem Ablauf.

Liegt der API-Aufruf über dem konfigurierten Zeitlimit (z. B. 3 Sekunden ohne Antwort), teilt Fonio dem Anrufer mit, dass die Abfrage gerade nicht möglich ist, und leitet ihn entweder zu einem Mitarbeiter weiter oder plant einen Rückruf ein. Dieses Fallback-Verhalten ist kein optionales Extra, sondern sollte von Anfang an mitgeplant werden.

Bestandsabfrage technisch: API, Zeitlimit und Fallback

Eine Bestandsabfrage über Fonio funktioniert als synchroner API-Call während des laufenden Gesprächs. Das bedeutet: Fonio sendet eine Anfrage an einen konfigurierten Endpunkt und wartet auf die Antwort — bevor es dem Anrufer antwortet.

Daraus folgt eine technische Anforderung, die viele unterschätzen: Die Antwortzeit muss verlässlich unter 2–3 Sekunden liegen. Eine Warenwirtschaft, die intern viele Sekunden für eine Bestandsabfrage braucht, ist für diesen Anwendungsfall ohne Zwischenschicht nicht geeignet.

Sinnvolle Architekturentscheidungen:

Ob eine direkte Verbindung, ein n8n-Workflow oder ein individuelles Backend die richtige Architektur ist, hängt von der Systemlandschaft ab: Bietet die Warenwirtschaft eine REST-API oder nur Datenbankzugriff? Ist ein Middleware-System wie n8n bereits vorhanden? Gibt es eine Testumgebung?

Wichtig: Nicht jede Warenwirtschaftssoftware bietet eine offene, dokumentierte API. Ältere Systeme arbeiten häufig mit proprietären Schnittstellen oder exportieren Daten nur per Datei-Batch. In diesen Fällen ist eine direkte Echtzeit-Integration nicht möglich — und sollte nicht versprochen werden.

Reservierung per Telefon: Ablauf und Fristen

Eine telefonische Reservierung ist ein schreibender Vorgang: Fonio erfasst die nötigen Daten — Artikelnummer, Variante, Kundendaten, gewünschte Abholfiliale — und übergibt sie an das Zielsystem, das die Reservierung anlegt.

Typischer Ablauf einer Reservierung über Fonio:

1. Fonio fragt aktiv nach Artikel (Name oder Nummer), Variante, Abholort und Kundendaten (Vor-/Nachname, ggf. Telefonnummer oder E-Mail).
2. Fonio schickt die erfassten Daten per Webhook oder API-Call an das Backend.
3. Das Backend prüft den aktuellen Bestand, legt die Reservierung an und setzt eine Frist (z. B. 48 Stunden).
4. Fonio bestätigt dem Anrufer die Reservierung inklusive Frist und gibt ggf. eine Reservierungsnummer zurück.
5. Das System sendet optional eine E-Mail-Bestätigung über den regulären Kundenkommunikationskanal.

Kritische Punkte:

• Wenn zwischen Bestandsabfrage und Anlage der Reservierung zu viel Zeit vergeht, kann ein anderer Kunde denselben Artikel kaufen. Das Backend muss die Reservierung atomar anlegen, d. h. Bestand prüfen und sperren in einem Schritt.
• Fristmanagement liegt im Zielsystem, nicht in Fonio. Fonio gibt die konfigurierte Frist aus — wann die Reservierung verfällt, entscheidet die Branchensoftware.
• Bei mehreren Filialen mit getrennten Beständen muss das Backend wissen, welcher Filialbestand reserviert wird. Das klingt trivial, ist aber ein häufiger Fehlerfall, wenn Stammdaten nicht filialscharf gepflegt sind.

Lieferstatus aus dem Shop-System ausgeben

Für Bestellungen aus einem Onlineshop ist der Lieferstatus die häufigste Telefonanfrage nach dem Kauf. Fonio kann diesen Status abfragen, wenn der Shop eine API bereitstellt — bei gängigen Shopsystemen in der Regel über eine REST-Schnittstelle mit API-Key-Authentifizierung.

Fonio fragt den Anrufer nach der Bestellnummer oder einer anderen eindeutigen Kennung (z. B. E-Mail-Adresse + Postleitzahl), sendet die Anfrage ans Backend und gibt den Tracking-Status aus — etwa „Ihre Bestellung wird gerade kommissioniert" oder „Die Sendung wurde am [Datum] übergeben, die Trackingnummer lautet XY".

Grenzen dieses Anwendungsfalls:

• Wenn der Anrufer die Bestellnummer nicht kennt, ist eine Identifikation über andere Merkmale nötig. Das erhöht die Gesprächskomplexität und verlängert die Abfragezeit.
• Tracking-Status von externen Logistikdienstleistern liegt häufig im Shop-System als abgeleitetes Feld vor. Wenn die Synchronisierung verzögert ist, kann Fonio nur den zuletzt bekannten Status ausgeben — nicht den aktuellen Pakettransit-Stand.
• Wenn der Anrufer aus dem Ergebnis heraus weitergehende Aktionen möchte (z. B. Lieferadresse ändern, Bestellung stornieren), braucht es dafür einen eigenen, separat konfigurierten Dialogpfad — oder eine Weiterleitungen an einen Mitarbeiter.

Reklamation anlegen: Vorgang erfassen, Fotos nachreichen

Eine Reklamation telefonisch aufzunehmen ist ein klassischer Anwendungsfall für Fonio: Der Assistent erfasst strukturiert alle relevanten Felder und legt den Vorgang im Zielsystem an — ohne dass ein Mitarbeiter am Telefon mitstenografieren muss.

Was Fonio im Reklamationsgespräch erfasst:

• Kundendaten (Name, Kundennummer oder Bestellnummer)
• Artikel und beschriebener Mangel
• Gewünschte Lösung (Umtausch, Erstattung, Reparatur)
• Kontaktdaten für Rückfragen

Fotos oder Belege kann Fonio nicht direkt im Gespräch entgegennehmen — das Telefon ist kein Dateikanal. Der etablierte Workaround: Fonio teilt dem Anrufer am Ende des Gesprächs einen individualisierten Upload-Link mit (z. B. per SMS oder per Folge-E-Mail über das Backend), über den der Kunde Fotos oder Belege zum Vorgang nachreichen kann.

Dieser Link verweist auf eine Uploadseite, die mit der Vorgangsnummer verknüpft ist. Das Backend fügt die Uploads dann dem bereits angelegten Reklamationsvorgang bei. So entsteht ein vollständiger Vorgang, ohne dass der Anrufer alles in einem Zug erledigen muss.

Reklamationsvorgang-Datenstruktur (Beispiel):

{
  "type": "complaint",
  "customer_id": "...",
  "order_id": "...",
  "item": "...",
  "issue_description": "...",
  "desired_resolution": "exchange",
  "upload_token": "...",
  "created_via": "fonio",
  "status": "open"
}

Das Backend generiert einen Upload-Token, der zeitlich begrenzt und an die Vorgangsnummer gebunden ist. Fonio gibt dem Anrufer die Upload-URL aus — und das Gespräch ist damit abgeschlossen.

Grenzen und Fehlerfälle, die eingeplant werden müssen

Eine Fonio Warenwirtschaft Integration ist kein Selbstläufer. Wer die Grenzen kennt, kann sie einplanen — wer sie ignoriert, baut sich Probleme ins System.

Bestand ist nicht aktuell

Das häufigste Problem bei Einzelhandel mit Filialgeschäft: Der Bestand im System stimmt nicht mit dem tatsächlichen Regalbestand überein. Gründe sind Inventurdifferenzen, nicht gebuchte Wareneingänge oder verzögerte Kassenbuchungen. Fonio gibt in diesem Fall die Zahl aus dem System aus — die real abweichen kann.

Lösungsansatz: Den Ausgabetext so formulieren, dass er keine Garantie suggeriert („Laut aktuellem Systemstand sind X Stück verfügbar — bitte prüfen Sie vor Ort oder lassen Sie sich reservieren."). Das ist kommunikativ etwas umständlicher, aber ehrlicher.

Mehrere Filialen mit getrennten Beständen

Wenn Fonio nach einer Filiale fragen muss, bevor es den Bestand abfragt, verlängert das den Dialog. Wenn der Anrufer keine Präferenz hat, braucht es eine Logik im Backend, die alle relevanten Filialen abfragt und das Ergebnis aggregiert zurückgibt — ein sogenannter „Multi-Location-Lookup". Das ist technisch lösbar, aber kein trivialer Standardfall.

API-Timeout und Systemausfall

Wenn die Warenwirtschafts-API nicht antwortet, darf Fonio nicht unbegrenzt warten — der Anrufer wartet am Telefon. Der konfigurierte Timeout sollte bei maximal 3–4 Sekunden liegen. Danach greift der Fallback: Fonio teilt mit, dass die Abfrage gerade nicht möglich ist, und bietet konkrete Alternativen an (Rückruf, Weiterleitung, Hinweis auf Online-Shop).

Nicht erkannte Spracheingaben

Artikelnummern, Produktnamen und Kundennummern sind für Spracherkennung anspruchsvolles Material. Sonderzeichen, Bindestriche und Produktkürzel werden häufig falsch erkannt. Fonio sollte in diesen Fällen die erkannte Eingabe wiederholen und bestätigen lassen, bevor sie weitergegeben wird. Ein nicht verifizierter Wert im Backend kann zu falschen Vorgängen führen, die nachträglich kaum zu korrigieren sind.

Übergabe an Mitarbeiter

Wenn ein Gespräch die Grenzen der automatisierten Bearbeitung erreicht — z. B. ein komplexer Reklamationsfall, ein verärgerter Anrufer oder eine nicht beantwortbare Rückfrage — muss Fonio sauber an einen Mitarbeiter übergeben. Diese Übergabe sollte den Gesprächskontext mitliefern: Was hat der Anrufer gesagt, welche Daten wurden bereits erfasst? Damit der Mitarbeiter nicht von vorne anfängt. Wie das technisch umgesetzt wird, erklärt der Artikel zur Telefon-KI-Übergabe und Mitarbeitereinbindung.

Datenschutz: Was vor dem Go-live zu prüfen ist

Die Integration von Fonio in Warenwirtschaft und Shop bedeutet, dass personenbezogene Daten — Kundennummern, Bestelldaten, Reklamationsinhalte — im Gespräch erfasst und an externe Systeme übergeben werden.

Folgende Punkte sind vor dem Go-live zu prüfen, nicht von SWBS oder diesem Artikel zu beurteilen, sondern von einem Datenschutzbeauftragten oder Rechtsberater:

• Auftragsverarbeitung: Fonio verarbeitet Sprachdaten im Auftrag. Ein Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter ist zu schließen und zu dokumentieren.
• Information der Anrufer: Anrufer müssen zu Beginn des Gesprächs darüber informiert werden, dass sie mit einem KI-gestützten System sprechen und dass Gesprächsdaten verarbeitet werden. Das ist sowohl datenschutzrechtlich als auch aus Transparenzgründen erforderlich.
• Gesprächsaufzeichnung: Wenn Gespräche aufgezeichnet werden (für Qualitätssicherung oder Transkription), bedarf das einer Rechtsgrundlage und einer klaren Information der Anrufer.
• Besondere Kategorien nach Art. 9 DSGVO: Wenn Reklamationsgespräche Gesundheitsinformationen, politische Einstellungen oder andere besonders schützenswerte Daten berühren könnten, ist das separat zu bewerten. Im Einzelhandel ist das selten ein Thema, aber bei bestimmten Produktkategorien (z. B. medizinische Hilfsmittel) relevant.
• Datenspeicherung und -löschung: Wo werden die erfassten Daten gespeichert, wie lange, und wer hat Zugriff?

Eine strukturierte Übersicht zum Betrieb von Telefon-KI unter DSGVO-Anforderungen bietet der Artikel Fonio Datenschutz: Telefon-KI DSGVO-konform planen und betreiben.

Integration planen: Drei Architekturwege im Vergleich

Je nach vorhandener Systemlandschaft gibt es unterschiedliche Wege, Fonio mit dem Warenwirtschaftssystem zu verbinden. Keiner davon ist universell richtig — der passende Weg hängt von der API-Situation der Warenwirtschaft, dem vorhandenen Know-how und dem Umfang der zu integrierenden Prozesse ab.

Weg 1: Fonio-Standardintegration

Fonio bietet für gängige Anwendungsfälle vorkonfigurierte Integrationen. Wenn das Zielsystem dort unterstützt wird und der Anwendungsfall einfach genug ist (z. B. Status abfragen ohne komplexe Geschäftslogik), kann das ein schneller Einstieg sein.

Grenzen: Kaum Anpassungsmöglichkeiten, keine eigene Fehlerbehandlung, keine Multi-System-Abfragen.

Weg 2: n8n-Workflow als Middleware

n8n ist eine Open-Source-Automatisierungsplattform, die als Middleware zwischen Fonio und dem Warenwirtschaftssystem arbeitet. Fonio sendet einen Webhook, n8n empfängt ihn, führt die Logik aus (Bestandsabfrage, Reservierung, Reklamationsanlage) und antwortet an Fonio.

Dieser Ansatz ist für viele mittlere Anwendungsfälle sinnvoll: Er ist schnell aufzubauen, visuell wartbar und erfordert keine eigene Serverentwicklung. Grenzen: Bei komplexer Fehlerbehandlung, sehr hohem Durchsatz oder proprietären Schnittstellenformaten stößt n8n an Grenzen.

Weg 3: Individuelles Backend

Ein dedizierter Backend-Dienst (z. B. in Node.js oder Python) übernimmt die gesamte Integrationslogik: Authentifizierung, Datentransformation, Fehlerbehandlung, Caching, Logging und die Kommunikation mit Fonio sowie dem Zielsystem. Dieser Weg ist aufwendiger in der Entwicklung, aber der flexibelste und robusteste.

Für Betriebe, bei denen die Telefonintegration ein kritischer Betriebskanal ist, ist ein individuelles Backend in der Regel die richtige Wahl — weil nur so Timeouts, Wiederholungslogik, Idempotenz und Monitoring wirklich kontrolliert werden können.

Die Entscheidung zwischen diesen Wegen ist eines der ersten Themen, das SWBS in einem Integrationsgespräch klärt. Eine ausführliche Darstellung der Auswahlkriterien findet sich im Artikel Fonio-Standardintegration, n8n oder individuelles Backend.

Was SW Business Solutions bei dieser Integration leistet

SW Business Solutions ist Fonio-Partner und konzipiert und entwickelt die Schnittstelle zwischen Fonio und der Branchensoftware — von der Anforderungsanalyse über die Umsetzung bis zum laufenden Betrieb.

Konkret bedeutet das:

• Analyse der Systemlandschaft: Welche API bietet die Warenwirtschaft? Gibt es eine Testumgebung? Welche Prozesse sollen automatisiert werden?
• Architekturentscheidung: Welcher der drei Wege (Standardintegration, n8n oder individuelles Backend) passt zu den Anforderungen und dem Budget?
• Entwicklung der Schnittstelle: Aufbau des Endpunkts, Fehlerbehandlung, Fallback-Logik, Timeout-Management.
• Tests: Gesprächstests, API-Tests, Fehlerfalltests (Timeout, leerer Bestand, ungültige Artikelnummer).
• Monitoring und Betrieb: Nachverfolgung von Gesprächsfehlern, API-Fehlerquoten und Fallback-Häufigkeit nach dem Go-live.

Der Artikel zum Thema Fonio integrieren lassen beschreibt den Projektablauf im Detail.

Für Unternehmen im Einzelhandel, die das Thema in einem breiteren Kontext betrachten möchten, empfiehlt sich der Serienartikel Fonio für den Einzelhandel: Verfügbarkeit, Abholung und Reklamationen — dort werden die Branchenspezifika von Click and Collect, Rückgabeprozessen und saisonalen Lastspitzen ausführlich behandelt.

Wann die Integration sich nicht lohnt

Nicht jede Warenwirtschaftsumgebung ist für eine Echtzeit-Telefonintegration geeignet. Es lohnt sich, das vorab ehrlich zu bewerten:

• Wenn die Warenwirtschaft keine API hat: Eine Integration über Dateiexporte oder Datenbank-Direktzugriff ist technisch möglich, aber aufwendig und fehleranfällig. Der Aufwand steht dann häufig in keinem sinnvollen Verhältnis zum Nutzen.
• Wenn das Anrufvolumen sehr gering ist: Wenn nur wenige Anfragen pro Woche über diesen Kanal eingehen, amortisiert sich der Integrationsaufwand erst auf sehr lange Sicht.
• Wenn die Datenqualität im System schlecht ist: Eine Telefon-KI, die veraltete oder fehlerhafte Bestandsdaten ausgibt, erzeugt Misstrauen. Bevor eine Integration sinnvoll ist, müssen die Stammdaten verlässlich gepflegt sein.
• Wenn der Prozess zu komplex für einen Telefonkanal ist: Komplexe Umtauschprozesse mit Ausnahmeregeln, preisabhängigen Entscheidungen oder mehrschichtigen Genehmigungen gehören nicht in einen automatisierten Telefonkanal — dort ist ein Mitarbeiter effizienter und kundenfreundlicher.

So starten Sie

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

Der schnellste Einstieg: Testen Sie die Kernfunktion — Bestandsabfrage oder Reklamationsanlage — mit einem typischen Anruf aus Ihrem Betrieb. Fonio bietet dafür eine kostenlose Demo-Umgebung:

Fonio Demo starten und einen Integrationsfall aus dem Einzelhandel testen

Wenn Sie die Integration direkt in Ihre Systemlandschaft besprechen möchten: SWBS analysiert den Ist-Stand, bewertet die API-Situation Ihrer Warenwirtschaft und schlägt einen konkreten Integrationsweg vor — inklusive realistischer Aufwandseinschätzung.

Jetzt Integrationsgespräch buchen