Fonio mit Tierarzt-Praxissoftware verbinden: Tier, Halter und Dringlichkeit richtig zuordnen

Das Telefon klingelt. Eine Halterin ruft an, weil ihr Hund seit heute Morgen nichts frisst und zittert. Die Rezeption ist besetzt, der Arzt operiert, und in der Warteschlange stecken noch fünf weitere Anrufe. Ein KI-Telefonassistent wie fonio.ai nimmt das Gespräch ab – aber was passiert danach mit den erfassten Informationen?

Wenn Fonio den Anruf entgegennimmt und dabei Name, Tier und Schilderung erfasst, diese Daten aber anschließend als unstrukturierte Nachricht in einem Postfach landen, ist wenig gewonnen. Jemand muss den Text lesen, den Halter in der Praxissoftware suchen, das richtige Tier auswählen und einen Vorgang anlegen – von Hand. Der Medienbruch hebt den Nutzen der Telefon-KI wieder auf.

Dieser Artikel beschreibt, wie die Integration zwischen Fonio und einer tierärztlichen Praxissoftware technisch und fachlich funktionieren kann: Welches Datenmodell liegt zugrunde, wie werden Halter und Tier einer eingehenden Rufnummer zugeordnet, wie steuert das System verschiedene Terminarten und Bestellwünsche, und was passiert, wenn ein Anruf von einer unbekannten Nummer kommt oder ein neues Tier gemeldet wird.

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

Jetzt eine Demo mit einem Praxisfall aus der Tierarztbranche testen: Fonio-Demo starten (Partnerlink)

Warum ein Anruf in einer Tierarztpraxis mehr Kontext braucht als in anderen Branchen

In einer Hausarztpraxis ist der Anrufende fast immer der Patient. In einer Tierarztpraxis ist das strukturell anders: Der Halter ruft an, das Tier ist der Patient. Ein Halter kann mehrere Tiere haben – einen Kater, zwei Hunde, vier Kaninchen. Wenn Frau Berger anruft und über „mein Tier" spricht, muss das System erst klären, welches Tier gemeint ist.

Das bedeutet: Eine bloße Rufnummernsuche im CRM reicht nicht. Das Gespräch muss eine zweite Abfrage enthalten, die das spezifische Tier identifiziert. Erst dann ist der Kontext vollständig genug, um einen Vorgang sinnvoll anzulegen.

Hinzu kommen verschiedene Anruftypen mit unterschiedlichen Anforderungen:

Diese Tabelle zeigt: Je nach Anruftyp variiert der benötigte Datensatz erheblich. Die Fonio-Konfiguration muss diesen Unterschied abbilden – durch bedingte Gesprächsäste, nicht durch ein einheitliches Formular.

Das Datenmodell: Wie Halter, Tier und Vorgang zusammenhängen

Bevor eine Schnittstelle gebaut werden kann, muss das Datenmodell der Praxissoftware verstanden sein. Typische tierärztliche Praxissoftware arbeitet mit einer dreistufigen Struktur:

Halter (Besitzer): Stammdatensatz mit Name, Kontaktdaten, Adresse und ggf. Kundennummer. Einem Halter sind eine oder mehrere Rufnummern zugeordnet.

Tier (Patient): Subdatensatz unter dem Halter. Felder: Name, Tierart, Rasse, Geschlecht, Geburtsdatum, Chip-Nummer, ggf. Versicherungsdaten. Einem Halter können mehrere Tiere zugeordnet sein.

Vorgänge / Termine / Aufgaben: Aktionen, die einem Tier zugeordnet sind – Termine im Kalender, Behandlungsnotizen, offene Aufgaben (z. B. „Medikament bereitstellen"), Rückrufaufgaben.

Für eine funktionierende Fonio-Integration bedeutet das: Der Webhook, den Fonio nach dem Gespräch absetzt, muss mindestens Halter-ID, Tier-ID und die erfassten Gesprächsfelder (Anruftyp, Anliegen, gewünschte Zeit) übergeben. Das verarbeitende Backend – ob n8n, ein eigenes Backend oder eine Fonio-Standardintegration – schreibt diese Daten dann an die richtige Stelle in der Praxissoftware.

Halter über die Rufnummer erkennen – und was bei Fehlern passiert

Der einfachste Weg zur Identifikation: Fonio übermittelt die eingehende Rufnummer per Webhook an ein Backend, das darin eine Datenbankabfrage gegen die Praxissoftware auslöst.

Idealfall: Die Rufnummer ist einem einzigen Halter zugeordnet. Das Backend gibt Halterdaten und Tierliste an Fonio zurück. Der Assistent begrüßt die Halterin mit Namen und fragt, um welches Tier es geht.

Fehlerfälle, die explizit behandelt werden müssen:

• Unbekannte Nummer: Die Rufnummer ist in der Praxissoftware nicht hinterlegt. Fonio fragt nach Name und Tier, erfasst die Angaben und erzeugt eine Aufgabe mit dem Vermerk „Neuer Halter – Stammdaten anlegen". Das Team prüft nach dem Anruf.
• Rufnummer unterdrückt: Der Anrufer hat keine Nummer übermittelt. Fonio stellt dieselbe Rückfrage wie bei unbekannter Nummer, erkennt aber zusätzlich an, dass keine automatische Zuordnung möglich ist.
• Mehrere Halter mit gleicher Nummer: Kann vorkommen, wenn Familienmitglieder dieselbe Nummer hinterlegt haben. Fonio fragt nach dem Namen und löst die Zuordnung manuell auf.
• Rufnummer bekannt, aber kein Tier im Bestand: Halter hat alle Tiere aus der Kartei verloren oder hat ein neues Tier, das noch nicht erfasst ist. Fonio erfasst die Tierangaben als Freitext, legt eine Aufgabe an.

Wichtig: Jeder dieser Fehlerfälle muss im Gesprächsfluss explizit vorgesehen sein – nicht als Ausnahme, die das System abbricht, sondern als regulärer Dialogpfad. Ein abgebrochenes Gespräch erzeugt mehr Aufwand als ein kurzes, strukturiertes Rückfragegespräch.

Hypothetisches Beispiel: Wie ein vollständig integrierter Anruf abläuft

Das folgende Szenario ist hypothetisch und dient der Veranschaulichung. Es beschreibt keinen realen Kunden.

Frau M. ruft um 7:42 Uhr an – die Praxis öffnet um 8:00 Uhr. Fonio nimmt den Anruf ab und begrüßt sie. Das Backend hat ihre Mobilnummer erkannt und die Tierliste übergeben: zwei Hunde, „Luna" und „Balu".

Fonio fragt: „Geht es heute um Luna oder um Balu?" Frau M. antwortet: „Um Balu, er frisst seit gestern nichts und zittert." Fonio wertet die Symptombeschreibung als potenziellen Notfall, stuft die Dringlichkeit hoch ein und kündigt an: „Ich leite Sie jetzt an die Notfallnummer weiter. Sollte niemand abnehmen, hinterlasse ich eine Rückrufaufgabe mit höchster Priorität für das Team."

Die Weiterleitung schlägt fehl – kein Abnehmer. Fonio erzeugt einen Webhook-Aufruf, der im Backend eine Aufgabe in der Praxissoftware anlegt: Tier „Balu" (Halter-ID 4712), Anliegen „Frisst nicht, zittert – möglicher Notfall", Rückruf-Priorität hoch, eingehende Rufnummer hinterlegt. Das Team sieht diesen Vorgang beim Öffnen der Praxis als erstes in der Aufgabenliste.

Hätte Frau M. stattdessen einen Impftermin gewollt, hätte Fonio Tierart, Impfstoff-Typ und gewünschten Zeitraum abgefragt und einen Termin direkt im verknüpften Kalender eingetragen – ohne weiteren manuellen Schritt.

Terminarten im Gesprächsfluss unterscheiden

Fonio kann Terminarten nur dann korrekt zuordnen, wenn die Konfiguration die relevanten Kategorien kennt und im Gespräch abfragt. Für eine Tierarztpraxis sind das typischerweise:

Impftermin: Fonio fragt nach dem Tier und dem Impftyp (z. B. Tollwut, FSME-Kombination, Jahresimpfung). Der Kalender wird geprüft, ein freier Slot vorgeschlagen. Wichtig: Wenn die Praxissoftware eine Schnittstelle zum Kalender hat, kann Fonio direkt buchen; fehlt die Schnittstelle, legt Fonio eine Aufgabe „Impftermin anfragen" an.

OP-Vorgespräch: Hier reicht eine einfache Slot-Buchung nicht. Das Vorgespräch bindet ärztliche Zeit und setzt ggf. voraus, dass Unterlagen vorliegen. Fonio erfasst Tier, Art des geplanten Eingriffs und bevorzugte Zeitfenster und legt eine Aufgabe für die Rezeption an, die den Termin dann manuell koordiniert.

Kontrolltermin: Fonio fragt nach dem Tier und dem Bezug (z. B. „Nachsorge nach der Kastration"). Das Ergebnis landet als Terminanfrage mit diesem Kontext, damit der Arzt beim Öffnen der Akte sofort weiß, worum es geht.

Der Unterschied zwischen diesen Typen ist kein semantisches Detail – er bestimmt, ob ein Vorgang direkt gebucht oder manuell bearbeitet werden muss. Die Prompt-Konfiguration und die Webhook-Struktur müssen diese Unterscheidung abbilden.

Bestellwünsche als Aufgabe erfassen

Medikamentenbestellungen oder Futterbestellungen sind ein häufiges Anrufmuster in Tierarztpraxen. Der Halter ruft an, nennt ein Präparat (oft nur den Handelsnamen, gelegentlich den Wirkstoff), Tier und gewünschte Menge.

Für Fonio ist dieser Anruftyp technisch einfach zu erfassen – als strukturierte Aufgabe mit den Feldern: Halter, Tier, Produktbezeichnung (Freitext), Menge, Abholwunsch oder Lieferpräferenz. Das Backend legt die Aufgabe in der Praxissoftware an und weist sie der Rezeption oder dem Apothekenbereich zu.

Zwei Grenzen sind hier klar zu benennen:

Erstens: Fonio kann keine Rezeptpflicht prüfen und keine fachliche Einschätzung zur Dosierung geben. Der Assistent erfasst den Wunsch und verweist auf die Rückbestätigung durch das Praxisteam.

Zweitens: Wenn ein Präparat unter einen Rx-Vorbehalt fällt oder die letzte Verschreibung zu weit zurückliegt, muss das Team entscheiden – nicht das System. Der Gesprächsfluss sollte das kommunizieren: „Wir notieren Ihren Bestellwunsch und melden uns, sobald wir Verfügbarkeit und Verschreibungsstatus geprüft haben."

Notfall-Weiterleitung mit Rückfallebene

Notfallanrufe sind der kritischste Anruftyp in einer Tierarztpraxis. Fonio kann eine Notfall-Triage durch Schlüsselsätze und direkte Abfrage umsetzen – etwa: „Beschreiben Sie kurz, was Ihrem Tier passiert ist" – und anhand der Antwort zwischen regulärer Aufgabe und Notfallweiterleitung entscheiden.

Die Weiterleitung selbst funktioniert über die Telefonanlage. Fonio gibt den Anruf an eine definierte Nummer weiter – eine separate Notfallnummer, ein Mobiltelefon im Bereitschaftsdienst oder eine 3CX-Warteschlange. Die Notfallsteuerung mit Fonio lässt sich zeitabhängig konfigurieren: tagsüber an die Rezeption, nachts an das Bereitschaftsmobil.

Rückfallebene: Wenn die Weiterleitung fehlschlägt (kein Abnehmer, Leitung besetzt), muss Fonio nicht einfach auflegen. Stattdessen:

1. Fonio teilt dem Anrufer mit, dass kein Arzt erreichbar ist und nennt ggf. eine Notaufnahmeklinik.
2. Gleichzeitig erzeugt der Webhook eine Aufgabe mit höchster Priorität in der Praxissoftware und löst optional eine Push-Benachrichtigung oder SMS an die Bereitschaftsperson aus.
3. Alle erfassten Symptomangaben werden strukturiert an den Vorgang gehängt, damit der Arzt beim Rückruf sofort informiert ist.

Diese dreistufige Rückfallebene ist kein technischer Luxus – sie ist der Unterschied zwischen einem System, das im Ernstfall versagt, und einem, das verlässlich arbeitet.

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

Ein KI-Telefonassistent ist kein Triage-Arzt und kein Rezeptionsmitarbeiter mit Fachausbildung. Folgende Situationen müssen immer an einen Menschen übergeben werden:

• Unklare oder widersprüchliche Symptombeschreibungen, die medizinische Einschätzung erfordern
• Hochemotionale Anrufe (z. B. Tier hat einen Unfall, Besitzer ist in Panik) – hier ist Empathie gefragt, kein strukturiertes Abfrageprotokoll
• Reklamationen oder Beschwerden über frühere Behandlungen
• Anfragen, die Fachauskunft erfordern (Dosierung, Verträglichkeit, Diagnose-Erklärung)

Fonio erkennt diese Situationen nicht automatisch fehlerfrei. Deshalb ist eine explizite Ausweichoption im Gespräch notwendig: „Falls Sie lieber direkt mit jemandem sprechen möchten, sagen Sie bitte 'Mitarbeiter'." Diese Option sollte früh im Gespräch kommuniziert werden, nicht erst nach mehreren Abfrageschleifen.

Die Übergabe selbst muss mit Kontext funktionieren: Der Mitarbeiter, der das Gespräch übernimmt, sollte nicht von vorne anfangen müssen. Das setzt voraus, dass Fonio die bisherigen Gesprächsdaten vor der Weiterleitung an das CRM oder die Telefonanlage übergibt.

Datenschutz: Was vor dem Go-live geprüft werden muss

Tiergesundheitsdaten sind keine Gesundheitsdaten im Sinne des Art. 9 DSGVO – dieser schützt Daten über natürliche Personen. Dennoch verarbeitet eine Fonio-Integration personenbezogene Daten: Name und Rufnummer des Halters, Gesprächsinhalte, ggf. Aufzeichnungen.

Folgende Punkte müssen vor dem Produktivbetrieb rechtlich geprüft sein:

• Auftragsverarbeitung: Fonio verarbeitet personenbezogene Daten im Auftrag der Praxis. Ein Auftragsverarbeitungsvertrag (AVV) mit Fonio muss vorliegen.
• Information der Anrufer: Anrufer müssen zu Beginn des Gesprächs darüber informiert werden, dass ein KI-System das Gespräch führt und Daten erfasst werden. Diese Information gehört in den Gesprächseinstieg.
• Gesprächsaufzeichnung: Wenn Fonio Gespräche aufzeichnet (z. B. für Qualitätszwecke oder zur Nachbearbeitung), ist eine aktive Einwilligung oder ein legitimes berechtigtes Interesse erforderlich. Das muss im Einzelfall geprüft werden.
• Datenweitergabe an Dritte: Wenn das Backend oder die Integrationsplattform (n8n, ein eigenes Backend) Daten weitergibt, muss auch für diese Stellen ein AVV vorliegen.

Diese Aufzählung ersetzt keine Rechtsberatung – sie benennt die Punkte, die eine Praxis mit ihrem Datenschutzbeauftragten oder Anwalt klären muss.

Welche Integrationsarchitektur passt – und warum das von der Praxissoftware abhängt

Nicht jede tierärztliche Branchensoftware bietet eine offene REST-API. Das ist der wichtigste technische Vorbehalt bei diesem Thema.

Drei Szenarien in der Praxis:

Software mit offener API: Das Backend kann direkt gegen die API der Praxissoftware schreiben – Halter abrufen, Tier identifizieren, Termin anlegen, Aufgabe erstellen. Das ist die sauberste Architektur und ermöglicht eine vollständige Echtzeit-Integration.

Software mit eingeschränkter API oder Export/Import: Manche Systeme bieten nur Lesezugriff oder erlauben den Import über standardisierte Dateiformate. Hier ist die Integration aufwändiger: Fonio schreibt in eine Zwischendatenbank, die Software importiert regelmäßig. Latenzen und mögliche Konflikte müssen eingeplant werden.

Software ohne API: Die Integration ist nur über Umwege möglich – etwa über eine E-Mail-basierte Aufgabe, eine Web-Oberfläche mit Browser-Automation oder gar nicht. In diesem Fall ist Fonio weiterhin als Anruferfassung und Aufgabengenerator nützlich, aber eine direkte Systemintegration scheidet aus.

Die Architekturentscheidung – Fonio-Standardintegration, n8n als No-Code-Middleware oder ein individuelles Backend – hängt deshalb nicht nur von den Anforderungen der Praxis ab, sondern auch von den technischen Möglichkeiten der eingesetzten Praxissoftware. Der Artikel Fonio-Standardintegration, n8n oder individuelles Backend beschreibt diese Entscheidung ausführlich.

Für die tierärztliche Nische gilt eine zusätzliche Besonderheit: Branchensoftware für Tierarztpraxen ist ein vergleichsweise kleiner Markt mit einer Handvoll etablierter Anbieter. Ob ein konkretes System eine geeignete API mitbringt, muss im Einzelfall geprüft werden – pauschal lässt sich das für keine Plattform zusagen.

Fonio API und Webhooks: Wie die technische Verbindung funktioniert

Fonio überträgt Gesprächsergebnisse über Webhooks – HTTP-Requests, die nach dem Ende eines Gesprächs automatisch an eine konfigurierte URL gesendet werden. Der Payload enthält die im Gespräch erfassten Variablen: Rufnummer, identifizierter Halter (sofern vorab aufgelöst), Tiername, Anruftyp, Freitextfelder, Dringlichkeitseinstufung.

Wer die technischen Details der Fonio API und Webhooks kennt, weiß: Der eingehende Webhook-Payload muss validiert werden (Herkunft prüfen, Signatur verifizieren), und das Backend muss idempotent arbeiten – ein doppelt ausgelöster Webhook darf keinen doppelten Vorgang anlegen.

Für die Tierarztpraxis-Integration kommen zwei weitere Punkte hinzu:

Rückmeldung an Fonio vor dem Gespräch: Wenn das Backend während des Gesprächs auf eine Halter-Abfrage antwortet (Lookup-API), muss diese Antwort innerhalb weniger Sekunden erfolgen. Latenz hier führt zu langen Pausen im Gespräch – das wirkt unprofessionell. Das Backend muss entsprechend schnell sein, oder der Lookup muss zwischengespeichert werden.

Fehlerbehandlung: Wenn der Webhook-Empfänger nicht erreichbar ist (Praxissoftware offline, Backend-Fehler), muss Fonio das Gespräch trotzdem ordentlich beenden und der Webhook muss wiederholt werden. Retry-Mechanismus und Dead-Letter-Queue gehören zur Basisarchitektur – nicht zum Nice-to-have.

Was eine Integration realistisch kostet und wann sie sich lohnt

Eine Integration zwischen Fonio und einer Praxissoftware ist kein Plug-and-Play. Sie erfordert:

• Analyse der API oder Export-Möglichkeiten der Praxissoftware
• Konzeption des Gesprächsflows (Prompt-Konfiguration, Variablen, Fehlerpfade)
• Entwicklung des Backends oder n8n-Workflows
• Tests mit realen Anrufszenarien (bekannte Nummer, unbekannte Nummer, Notfall, Bestellung)
• Datenschutz-Prüfung und AVV-Dokumentation
• Einweisung des Teams und Monitoring nach dem Go-live

Der Aufwand variiert erheblich: Eine einfache Aufgaben-Integration über n8n (Fonio schreibt Aufgaben in eine Ticketliste, keine Echtzeit-Lookup) ist in einem Bruchteil der Zeit umsetzbar im Vergleich zu einer vollständigen bidirektionalen API-Anbindung mit Halter-Lookup, Tier-Auflösung und Kalenderintegration.

Eine Tierarztpraxis mit einem moderaten Anrufvolumen profitiert bereits bei der einfacheren Variante: Anrufe, die außerhalb der Öffnungszeiten eingehen, werden strukturiert erfasst statt auf der Mailbox zu landen. Das Team startet den Arbeitstag mit einer priorisierten Aufgabenliste statt mit einer Voicemailbox.

Der Aufwand für die vollständige Integration lohnt sich, wenn die Praxissoftware eine offene API hat und das Anrufvolumen hoch genug ist, um den einmaligen Entwicklungsaufwand zu rechtfertigen. Das ist eine betriebswirtschaftliche Abwägung, die für jede Praxis individuell zu treffen ist.

Nächste Schritte: Integration mit SW Business Solutions aufsetzen

SW Business Solutions konzipiert und entwickelt die Schnittstelle zwischen Fonio und Ihrer Praxissoftware – von der API-Analyse über die Prompt-Konfiguration bis zum produktiven Betrieb mit Monitoring. Dabei fließt Erfahrung aus Webhook-Integrationen, Fehlerbehandlung und der technischen Qualitätssicherung ein, wie sie auch aus anderen Branchen-Integrationsprojekten bekannt ist.

Mehr zum Thema Fonio für Tierarztpraxen im Branchenartikel: Telefon-KI Tierarztpraxis

Den technischen Einstieg in die Integrationsmöglichkeiten bietet Fonio in bestehende Systeme integrieren.

Wenn Sie bereits wissen, welche Architektur in Frage kommt, und die Schnittstelle entwickeln lassen möchten: Individuelle Fonio-Schnittstelle entwickeln lassen.

Für ein erstes Gespräch über die konkrete Situation Ihrer Praxis – Praxissoftware, Anrufvolumen, Öffnungszeiten-Modell und Notfallkonzept – steht das Team von SW Business Solutions bereit. Das Gespräch kostet nichts und schafft Klarheit darüber, was eine Integration leisten kann und was nicht.