Intercom Fin vs. maßgeschneiderte KI-Chatbots: Wer gewinnt im Kundenservice?

Sollten Sie Intercom Fin einsetzen oder einen eigenen KI-Chatbot für den Kundenservice bauen? Nach einem Dutzend Deployments bei Schweizer KMU überrascht die ehrliche Antwort: Die Plattform gewinnt fast immer — aber nicht aus den Gründen, die Anbieter auf ihre Slides schreiben.

Der echte Vergleich

Die meisten "Fin vs. Eigenbau"-Inhalte vergleichen die falschen Dinge. Preis pro Konversation gegen die Kosten eines OpenAI-API-Calls ist kein fairer Vergleich — er ignoriert alles, was aus einem rohen LLM einen Support-Agenten macht, der Sie nicht blamiert.

So sieht ein ehrlicher Vergleich aus:

Eine Anmerkung dazu, wofür Sie eigentlich bezahlen

Fins Preismodell ist ergebnisbasiert, und das Wort "Ergebnis" verbirgt eine nützliche Unterscheidung, die man verstehen sollte, bevor man irgendetwas vergleicht.

Der häufige Fall ist eine Resolution — Fin beantwortet die Frage eines Kunden und dieser bestätigt, dass es geholfen hat, oder geht weg, ohne nachzufragen. Das sind etwa 0,99 USD. Ein Procedure Handoff (Fin schliesst einen konfigurierten Workflow ab, der in einer Übergabe endet) wird zum gleichen Tarif abgerechnet.

Wenn Sie Fin jemals für Sales statt Support konfigurieren, gibt es eine zweite Stufe: eine Qualification — Fin gleicht einen Lead mit Ihren Kriterien ab und routet ihn — wird deutlich höher abgerechnet (rund 9,99 USD). In einem Standard-Support-Deployment treffen Sie das nicht, aber es ist relevant, wenn Sie Fin als Lead-Qualifizierungs-Layer ins Auge fassen, und es ist genau die Art von Detail, die ein Budget leise verändert.

Zwei praktische Hinweise für Schweizer Käufer: Im Standalone-Plan gibt es ein Minimum (50 Resolutions/Monat, ~49,50 USD), und abgerechnet wird in US-Dollar, egal wo Sie sitzen — kalkulieren Sie also die EUR/CHF-Konvertierung in jede Prognose ein, statt die nominale Zahl als Franken zu lesen.

Die versteckten Kosten eines eigenen KI-Chatbots

Wenn Teams einen Eigenbau kalkulieren, kalkulieren sie den Happy Path: ein LLM, eine Vektordatenbank, ein Chat-UI. Sie übersehen die Arbeit, die wirklich in Produktion läuft:

• Retrieval ohne Halluzinationen: Chunking-Strategie, Re-Ranking, Quellenattribution, Frische-Syncs
• Evaluations-Harness: ohne kann man keinen KI-Agenten ausliefern, und es muss bei jeder Produktänderung gepflegt werden
• Eskalationslogik: Wann übergibt der Bot? An wen? Mit welchem Kontext? Auf welchem Kanal?
• Analytik und Resolution-Scoring: Woher wissen Sie überhaupt, dass es funktioniert?
• Guardrails: PII-Redaktion, Prompt-Injection-Abwehr, Refusal-Patterns, Brand Voice
• On-Call-Verantwortung: Der Modell-Anbieter ändert das Pricing oder deprecatet einen Endpoint — jemand wird um 2 Uhr morgens geweckt

Für ein typisches Schweizer KMU bedeutet das einen Senior Engineer für sechs bis neun Monate, plus laufend 20–30 % seiner Kapazität, für immer. Und hier ist der Teil, den die meisten Eigenbau-Schätzungen komplett übersehen: Das Schwierige ist nicht das MVP. Etwas hinzustellen, das ein paar FAQs beantwortet, ist ein Wochenende. Daraus einen zuverlässigen, sicheren, produktionstauglichen Agenten zu machen — und ihn dort zu halten, während Modelle sich verschieben und Ihr Produkt sich ändert — dort bleiben die meisten internen Projekte stecken.

Anbindung an die Tools, die Sie bereits nutzen

Ein Agent, der nur Ihr Hilfecenter lesen kann, ist eine glorifizierte FAQ. Der Wert zeigt sich, wenn er eine Live-Bestellung prüfen, ein Abonnement nachschlagen oder tatsächlich eine Rückerstattung verarbeiten kann — was bedeutet, sich mit den Systemen zu verbinden, in denen diese Daten leben. Das ist die am meisten unterschätzte Zeile in jedem Build-Kostenplan, denn jede Integration ist ein kleines Produkt für sich: Authentifizierung, Fehlerbehandlung, Rate Limits, Schema-Änderungen, wenn sich die Upstream-API verschiebt.

Fin deckt das auf drei Arten ab, ohne dass Sie ein Backend schreiben. Es unterstützt benutzerdefinierte Integrationen über REST-API-Connectoren, Webhooks und das Model Context Protocol (MCP), und die Connectoren selbst sind No-Code — Sie konfigurieren sie in der Benutzeroberfläche, schränken ein, welche Felder der Agent sehen darf, und benennen Rohwerte in kundenfreundliche Sprache um. Sie sind nicht nur lesend: Ein Connector kann Aktionen ausführen wie das Verschieben einer Lieferung oder das Verarbeiten einer Rückerstattung in Ihrem externen System, mit einem Mensch-Prüf-Schritt, wo Sie ihn wünschen.

Speziell zu MCP — dem offenen Standard, der sich schnell zum Default entwickelt, wie Agenten mit Business-Tools sprechen — liefert Fin First-Party-Connectoren für Stripe, Shopify und Linear, und jedes MCP-kompatible oder REST-erreichbare Tool kann darüber hinaus angeschlossen werden (direkt, oder über ein Gateway, das auf hunderte SaaS-Apps über eine einzige Verbindung ausstrahlt). Diese Oberfläche selbst zu bauen und gesund zu halten, während sich jede Upstream-API ändert, ist genau die Art von permanenter Steuer, die nicht in einem Build-Kostenplan auftaucht. Wenn Sie neugierig sind, wie diese Connector-Schicht in Intercoms breitere Modellarchitektur passt, deckt unser Deep Dive zur Fin API Platform und Apex die gesamte Pipeline ab.

Zwei Dinge, die Sie für ein Schweizer Deployment bestätigen sollten, statt sie anzunehmen:

• Benutzerdefinierte API-Integrationen liegen auf den Professional- und Enterprise-Tarifen — vorgefertigte Connectoren sind in allen Plänen enthalten, aber benutzerdefinierte sind eingeschränkt, also planen Sie den richtigen Tarif in Ihre Schätzung ein.
• Der Intercom MCP-Server — der Ihre Intercom-Daten nach außen zu Tools wie Claude exponiert — ist derzeit nur in den USA gehostet. Das ist die umgekehrte Richtung von Fin, das Ihre Tools liest, und es ist ein Datenresidenz-Flag, das frühzeitig erwähnt werden sollte, wenn Ihre FADP-Prüfung das abdeckt.

Wo Fin wirklich verliert

Fin ist nicht für jeden die richtige Antwort. Aber der Build-Fall ist enger, als die meisten annehmen — und es lohnt sich, ihn genau zu treffen, denn der falsche Grund zu bauen ist teuer.

Das Erste, das geklärt werden muss: „reglementiert" ist kein Grund zu bauen. Das ist die Falle, die ich am häufigsten sehe. Teams im Gesundheitswesen, Finanz- oder Rechtswesen nehmen an, dass die Compliance-Schwelle einen Custom-Stack erzwingt. Das tut sie in der Regel nicht. Intercoms eigene veröffentlichte Fallstudie zu Numan — ein Gesundheits-Tech-Anbieter, der sensible, stigmatisierte Behandlungen von Gewichtsmanagement bis ED abwickelt — führt Fin über etwa 70.000 Konversationen pro Monat bei 90 % CSAT in genau dieser vertrauensintensiven, regulierten Umgebung. Sie haben nicht gebaut. Sie haben etwas Lehrreicheres gemacht: Sie haben klinische Entscheidungen vollständig aus dem Agenten ausgeschlossen und alles, was Medikamente, Behandlungen oder Nebenwirkungen betraf, direkt an einen lizenzierten Kliniker weitergeleitet, während Fin die operative Schicht übernahm — Lieferung, Plattform-How-to, Kontofragen. Ihre Auflösungsrate liegt bei etwa 47 % by design, nicht by limitation: Sie haben den Agenten bewusst auf die Hälfte des Supports begrenzt, die nicht die regulierte Entscheidung ist.

Das ist das Indiz. In einem regulierten Geschäft können Sie fast immer mit Guidance, Routing und deterministischen Procedures in Fin dorthin kommen — Procedures folgen einer nachvollziehbaren, schrittweisen Logik mit menschlichen Prüfpunkten, und Monitors ermöglicht es Ihnen, jede Konversation an Ihren eigenen Qualitätskriterien zu bewerten, sodass das Reasoning keine Black Box ist, die Sie selbst bauen müssten.

Also die wirklich verteidigbaren Gründe zu bauen sind:

1. Proprietäre Entscheidungslogik, die Ihr Produkt ist. Nicht reguliert — proprietär. Sie bauen nur, wenn die Konversation selbst Ihr Differentiator und Ihr IP ist: ein Triage-Tool, dessen Schlussfolgerung der Service ist, ein Therapie-Bot, bei dem der Dialog die Behandlung ist, ein Produkt, dessen gesamter Wert im Urteil der KI liegt. Im Moment, wo Sie das einer Plattform übergeben, geben Sie das ab, was Sie ausmacht. (Beachten Sie, dass selbst Numan im Gesundheitswesen entschieden hat, dass das nicht auf sie zutrifft — sie haben das klinische Urteil bei Menschen belassen, anstatt einen Agenten dafür zu bauen.)
2. Nicht-standardisierte Kanäle: ein Chatbot, der in einer Hardware-UI eingebettet ist, ein Telegram-Bot für eine Nische-Community, ein Custom-Voice-Agent. Intercoms Kanalabdeckung ist breit, aber nicht unendlich.
3. Volumen über etwa 500.000 Konversationen pro Monat: In diesem Maßstab hört die Preisgestaltung pro Auflösung auf, gegen einen gut konstruierten internen Stack mit eigenem Modellvertrag konkurrenzfähig zu sein. (Das ist eine Faustregel aus der Praxis, kein veröffentlichter Schwellenwert — aber dort kippt die Rechnung in meiner Erfahrung ungefähr.)

Unterhalb dieser Schwelle lohnt sich der Engineering-Aufwand, Fin's Feature-Oberfläche zu matchen, fast nie.

Der "wir bauen das einfach selbst"-Instinkt

Es lohnt sich, das direkt zu benennen, denn es ist der häufigste Einwand und der teuerste Fehler.

Ihren eigenen Agenten zu bauen endet nicht, wenn er funktioniert. Sie haben eine neue interne Produktlinie geschaffen — Roadmap, QA, Monitoring, Content-Strategie, Safety-Reviews — die mit dem, was Ihr Unternehmen eigentlich verkauft, um Engineering-Aufmerksamkeit konkurriert. Jede grössere Verschiebung im Feld (neue Modelle, neue Safety-Techniken, neue Best Practices) wird zu einem Mini-Transformationsprojekt für Ihr Team. Viele hausgemachte Agenten fallen innerhalb eines Jahres leise hinter den State of the Art zurück.

Der Deal einer Managed Platform ist klar: Sie geben etwas Kontrolle über die Internals ab, und im Gegenzug sind das Roadmap-Risiko, die Wartung und die Modell-Upgrades nicht mehr Ihre. Intercom liefert kontinuierlich Verbesserungen, und die zugrunde liegenden Modelle aktualisieren sich, ohne dass Sie etwas neu deployen. Für die meisten Teams ist das der richtige Deal — Ihre Engineers bleiben am Kernprodukt, statt einen Support-Agenten zu warten.

Der Schweizer-KMU-Winkel

Schweizer Unternehmen haben einige Einschränkungen, die die Rechnung weiter Richtung Managed Platform kippen:

• Mehrsprachig per Default: Support muss auf Deutsch, Französisch, Italienisch und Englisch laufen. Das selbst zu bauen vervielfacht die Evaluations-Surface. Fin handhabt über 45 Sprachen in einem Deployment, mit Echtzeit-Übersetzung, die Lücken füllt, wo Sie keinen lokalisierten Content haben.
• DSG und DSGVO: Managed Platforms kommen mit erledigter Compliance-Papierarbeit. Eine eigene Stack heisst, Sie besitzen die Auftragsverarbeitungsverträge, die Löschflows und die Audits. Ein Punkt, den man verifizieren statt voraussetzen sollte: Intercom bietet EU-Datenresidenz, was die meisten Schweizer DSG-Reviews suchen — aber es gibt keine Schweizer Region, also bestätigen Sie, dass EU-Hosting Ihre spezifische Datenresidenz-Anforderung erfüllt, bevor Sie unterschreiben.
• Engineering-Knappheit: Senior KI-Engineers in Zürich und Genf sind teuer und rar. Einen davon auf einen Chatbot zu setzen, während Fin existiert, ist eine schlechte Allokation.

Wann was wählen

Eine einfache Entscheidungsregel:

Wenn Ihr Support-Workflow so aussieht wie "Fragen zu unserem Produkt beantworten, Edge Cases an Menschen eskalieren", deployen Sie Fin. Wenn Ihr Support-Workflow das Produkt ist, bauen Sie selbst.

Für etwa 90 % von B2B- und B2C-SaaS, E-Commerce und Service-Unternehmen gilt der erste Satz.

Der Test: Würde ein Kunde Sie noch bezahlen, wenn Sie Ihren Agenten durch einen Standard-Agenten ersetzen? Wenn ja, ist der Agent Overhead — kaufen. Wenn dieser Tausch Ihren Wert zerstört, ist der Agent das Produkt — bauen.

Anders gesagt: Wenn Ihr Ziel ist, ein KI-Produkt zu bauen, bauen Sie Ihr eigenes. Wenn Ihr Ziel ist, Support-Ökonomie und -Erfahrung so schnell und sicher wie möglich zu transformieren, kaufen Sie — und machen Sie die Implementierung zu der Sache, in die Sie investieren.

Erste Schritte

Wenn Sie diese Entscheidung für ein Schweizer Unternehmen abwägen, ist der schnellste Weg ein zweiwöchiger Fin-Pilot mit Ihren 20 häufigsten Support-Themen. Sie haben reale Auflösungsdaten — aus Ihrem eigenen Inhalt, nicht Hersteller-Benchmarks — bevor Sie sich für einen der beiden Wege entscheiden.

Beratungstermin vereinbaren →