KI-Telefonie ins Portfolio aufnehmen: ein Pilot für Systemhaus-Partner

Welcher erste Prozess passt zu deinem Systemhaus?

Wenn alle im Gespräch sind, bleiben Störungsmeldungen trotzdem wichtig. Ein geeigneter Einstieg ist deshalb die Aufnahme von Anliegen bei Überlauf oder außerhalb der Bürozeiten. Der Assistent klärt das Anliegen und übergibt es an dein Team. Er soll weder jede Störung selbst lösen noch eine unbestätigte Lösung versprechen.

Wähle einen Prozess, dessen Ergebnis du prüfen kannst: zum Beispiel ein Ticket mit Kunde, betroffenem System, Beschreibung, Dringlichkeit und Rückrufmöglichkeit. Die nötigen Felder bestimmen dein Serviceprozess und dein Ticketsystem. Sammle keine Angaben, die für die Bearbeitung nicht gebraucht werden.

Die Systemhaus-Seite beschreibt die Einsatzmöglichkeiten. Dieser Leitfaden führt durch die Entscheidung für den ersten Pilot; Konditionen und Partnermodelle findest du im Partnerprogramm.

• Ein klarer Anruftyp und ein festgelegtes Zeitfenster sind ausgewählt.
• Pflichtfelder, zuständiges Team und Eskalationsgründe sind dokumentiert.
• Für unklare Angaben und nicht erreichbare Zielsysteme gibt es einen definierten Weg zum Menschen.
• Eine verantwortliche Person entscheidet anhand der Testfälle über den Start.

Reseller oder White-Label: die kaufmännische Entscheidung

Als Reseller bietest du smao deinen Kunden an; die Produktmarke bleibt sichtbar. Im White-Label-Modell kannst du KI-Telefonassistenz unter eigener Marke und Domain anbieten und deine Preisgestaltung steuern. Entscheide nach deiner Kundenbeziehung und deiner verfügbaren Betreuungskapazität, nicht nur nach der Oberfläche.

Kläre vor dem ersten Angebot, wer Beratung, Einrichtung, laufende Änderungen und den ersten Supportkontakt übernimmt. Halte fest, wann dein Team an smao eskaliert und wer den Kunden über den Stand informiert. Vertrags- und Provisionsdetails gehören in das aktuelle Partnerangebot; der Leitfaden ersetzt diese Vereinbarung nicht.

Der bestehende comTeam-Erfahrungsbericht zeigt einen Partnerblick auf KI-Telefonie und die Einbindung in Systemhaus-Prozesse. Er ist ein konkreter Erfahrungsbericht, aber kein Beleg für die Ergebnisse jedes neuen Partners oder eine On-Premises-Bereitstellung.

Telefonie und Ticketübergabe vor dem Pilot abnehmen

Prüfe zunächst, wie Anrufe aus der vorhandenen Telefonie zum Assistenten gelangen und wie eine Weiterleitung zurück zum Team funktioniert. Rufnummer, Routing, Zeitsteuerung und Verhalten bei Nichterreichbarkeit müssen zur tatsächlichen Umgebung passen. Aus einer allgemeinen SIP-Unterstützung folgt keine geprüfte Kompatibilität mit jeder Telefonanlage.

Für die Anbindung an Geschäftssoftware unterscheidet smao zwischen vorhandenen nativen Konnektoren und individuell geplanten Verbindungen. Für verbreitete Ticketsysteme im Systemhaus gibt es native Konnektoren, etwa für TANSS und Datto Autotask. Eine Nennung im Integrationsverzeichnis allein ersetzt nicht die Prüfung von Funktionen, Berechtigungen und Feldmapping für deinen Prozess.

Lege für jeden Testanruf das erwartete Ergebnis vorher fest. Vergleiche anschließend den tatsächlich gespeicherten Datensatz mit diesen Erwartungen. Eine erfolgreiche API-Antwort und ein korrektes Ticket sind getrennt zu prüfen.

• Normalfall: bekannte Firma, vollständige Angaben, genau ein korrekt zugeordnetes Ticket.
• Unklare Angaben: Rückfrage oder dokumentierte Unsicherheit statt erfundener Kunden- oder Gerätedaten.
• Dringender Fall: die vereinbarte Eskalation erreicht den zuständigen Weg.
• Abgewiesener Schreibzugriff oder Timeout: kein erfundener Erfolg; der definierte Ersatzweg ist sichtbar.
• Wiederholung: prüfe, wie doppelte Übergaben erkannt und behandelt werden.

Betriebsmodell und Datenpfade verbindlich klären

Die smao Cloud wird in Deutschland gehostet. Gespräche werden ohne OpenAI und ohne US-KI-Subprozessoren in der Gesprächsverarbeitung verarbeitet. Angeschlossene Kundensysteme und ihre Datenpfade prüfst du zusätzlich für das konkrete Projekt.

Wenn der Betrieb auf kundeneigener Infrastruktur erforderlich ist, gehört die Eignungsprüfung vor das Angebot. smao On Premises und die Architekturübersicht beschreiben lokale Dienste, externe Verbindungen und die abzustimmende Betriebsverantwortung. Eine White-Label-Oberfläche bedeutet nicht automatisch On-Premises-Betrieb.

Dokumentiere für den Pilot, wer auf Gesprächsergebnisse zugreifen darf, wie lange benötigte Daten aufbewahrt werden und wie sie gelöscht werden. Nutze beim technischen Test zunächst Beispieldaten und ein dafür vorgesehenes Zielsystem.

Wann ist der Ablauf bereit für den ersten Kunden?

Notiere vor dem Pilot die Zahl relevanter Anrufe, verpasster Anrufe und den heutigen Nachbearbeitungsaufwand, soweit diese Werte verfügbar sind. Erfasse im Pilot zusätzlich korrekte Übergaben, nötige Nacharbeit, fehlgeschlagene Übergaben und menschliche Eskalationen. Ein kürzeres Gespräch ist kein Fortschritt, wenn Pflichtangaben fehlen.

Ein praktikables Freigabekriterium ist: Alle vereinbarten Normal- und Fehlerfälle sind geprüft, offene Abweichungen haben eine verantwortliche Person, und das Team kann den Ersatzweg bedienen. Ein festes Einsparversprechen oder eine universelle Zahl von Pilottagen lässt sich daraus nicht ableiten.

Wähle den ersten Kunden anschließend nach dem getesteten Ablauf aus. Ein ähnlicher Prozess ist leichter abzugrenzen als ein gleichzeitig neues Ticketsystem, neue Telefonie und neue Eskalationsregeln. Ändert sich eine dieser Voraussetzungen, wiederhole die betroffenen Abnahmetests.

Den Partnerstart konkret vorbereiten

Für ein erstes Partnergespräch reichen eine kurze Beschreibung deiner Zielkunden, das gewünschte Modell, ein konkreter Telefonprozess und die vorhandenen Systeme. Damit lässt sich klären, was du selbst betreust und welche Unterstützung du brauchst.

Die aktuellen Modelle und den Anfrageweg findest du unter Partner werden. Bringe den ersten Pilotfall mit, damit aus dem Gespräch eine überprüfbare nächste Aufgabe wird.