Der Slack-Shortcut, den wir nie wieder losgeworden sind

Ab Tag eins in meiner letzten Firma mussten wir viel Zeit in das Onboarding und den Support unserer Kunden stecken. Das Produkt war sehr technisch und erklärungsbedürftig, ein sauberes Onboarding hochgradig relevant für den Nutzen unserer Kunden und damit auch für die Kaufentscheidung. Also haben wir nach dem Erstgespräch pro Kunde einen Slack-Channel angelegt, um nah dran zu sein. Das hat keine zwei Minuten gedauert. Alle waren sich einig, dass dies nur vorübergehend sei. Sobald es etwas ruhiger wird und die Organisation „professioneller“ ist, kaufen wir ein richtiges Support-Tool und verlagern die Kommunikation.

Plot-Twist: Es wurde nie ruhiger.

Ich sollte dazusagen, dass das größtenteils mein eigener Schlamassel war. Ich bin als Founding Sales Hire eingestiegen und habe am Ende Growth und Customer Success verantwortet, mit direktem Reporting an den CEO. Angefangen habe ich operativ, dann habe ich das Support-Team aufgebaut und skaliert, ein Portfolio von 200+ Accounts betreut und das komplette Success- und Support-System der Firma selbst gebaut. Anders gesagt: Ich bin die Person, die immer wieder entschieden hat, dass Slack noch ein weiteres Quartal klargeht.

Und lange Zeit war es besser als die Alternative. Kunden hatten eine direkte Leitung zu uns, ohne nerviges Ticketing oder Portal dazwischen. Anfragen liefen schneller, weil es keine Warteschlange gab und kein Formular, das man vorher ausfüllen musste. Es landete auch niemand in einem anonymen Postfach: Die Leute bekamen mehrere echte Personen mit Namen, in einem Tool, in dem sie ohnehin schon einen Großteil ihrer Zeit verbringen.

Was ich damals unterschätzt habe, ist der Effekt darauf, was Kunden überhaupt mit uns geteilt haben. Ein privater Slack-Channel fühlt sich an wie ein Gespräch, also sagen Leute dort Dinge, die sie sonst nie in ein Ticketformular eintragen würden: halbfertiges Feedback, was sie nächstes Quartal vorhaben, was sie nervt, aber nicht genug, um sich offiziell zu beschweren.

Drei Jahre später war aus dieser einen Entscheidung eine ganze Maschine geworden, auf der die Firma lief. Das Onboarding passierte in diesen Channels. Eskalationen liefen in diesen Channels. Produktfragen, Vertragsfragen, Bug-Reports, das gelegentliche „Ist jemand da?“ um 23 Uhr am Freitagabend: alles in geteilten Slack-Channels, verteilt über alle Kunden-Accounts und Partner, die wir hatten. Es funktionierte. Das war der verwirrende Teil. Deals kamen auch deshalb zustande, weil Interessenten über Dritte gehört hatten, dass wir gut erreichbar sind.

Irgendwann haben wir trotzdem versucht, das zurückzudrehen. Wir hatten genug gute Gründe. Nichts war gründlich durchsuchbar, niemand konnte einen Account sauber übergeben, unser Reporting war Fiktion und das Wissen darüber, was bei einem Kunden gerade passiert, lag ausschließlich bei dem Kollegen, der zuletzt im Slack-Channel unterwegs war.

Unsere Kunden fanden die Idee furchtbar. Unsere Partner noch mehr. Niemand wollte sich in ein Portal einloggen, um eine kurze Frage zu stellen, die er auch schnell in Slack hätte tippen können. Und wenn du einem B2B-Kunden diesen Zugang einmal gegeben hast, wirkt es wie ein krasser Rückschritt, ihn wieder wegzunehmen, egal wie gut du es verpackst.

Diese Reaktion hat mir mehr beigebracht als die zwei Jahre davor. Der Shortcut war richtig. Das Problem lag darunter.

Die Frage, die niemand beantworten konnte

Irgendwann im zweiten Jahr kam dieselbe Frage aus allen Richtungen: Customer Success vor Vertragsverlängerungen, Product beim Priorisieren der Roadmap, Marketing auf der Suche nach Case Studies, Engineering beim Research komplexer Probleme oder das Board im Quartals-Deck.

Mit welchen Kunden stehen wir eigentlich gut da?

Niemand konnte sie beantworten. Was wir stattdessen gemacht haben? Archäologie. „Jemand“ scrollte den Channel zurück, um den Ton der letzten Wochen einzufangen, fragte den CSM, ob sich etwas komisch anfühlt, prüfte, wann das letzte echte Gespräch stattgefunden hatte und verglich Login-Zahlen, um zu sehen, ob die Nutzung eingebrochen war. Ein halber Tag pro Account und heraus kam eine Vermutung mit einem Chart daneben.

Das Muster war vorhersehbar. Vertragsverlängerungen haben uns in beide Richtungen überrascht. Accounts, die wir abgeschrieben hatten, verlängerten. Accounts, um die sich niemand Sorgen machte, kündigten und wenn wir post mortem danach den Channel durchgingen, standen die Anzeichen schwarz auf weiß da. Sechs Wochen früher, unformatiert in einer Nachricht im Slack-Thread, den ein Kunde an einem Dienstagnachmittag geschrieben hatte.

Das führte zwangsläufig zur nächsten Frage: „Warum ist uns das nicht früher aufgefallen?“ Diese Antwort ist simpel: Noise. Bei Hunderten internen und externen Slack-Channels arbeitet die schlechte Signal-to-Noise Ratio gegen dich. Dass solche Signale untergehen, ist normal. Ärgerlich? Absolut, aber normal.

Das ist der Teil, der bei mir hängen geblieben ist. Die Information war da. Sie schlummerte seit Wochen im Channel. Der Kunde sagte es uns in seinen eigenen Worten, bevor dieses Signal in einer Nutzungskurve sichtbar wurde. Nur hat niemand diese Worte richtig wahrgenommen oder interpretiert.

Was wir versucht haben

Wir waren einer der ersten Kunden von Pylon und es hat mehr geholfen als alles andere, was wir zu dem Zeitpunkt probiert hatten. Es gab uns ein echtes System auf Slack, zu einer Zeit, in der sich die meisten Alternativen überhaupt nicht mit Slack verbinden konnten. Zendesk und Intercom sind für eine andere Art von Business (B2C) gebaut. Im B2C bedeutet Support hohes Volumen von vielen Einzelpersonen, von denen du die meisten nie wieder hörst. Ein Support-Team verantwortet hier die gesamte Interaktion. Die Tools bilden das ehrlich ab. Ein Ticket kommt rein, ein Agent schließt es und der Vorgang ist vollständig.

So funktioniert B2B nicht. An einem einzigen Account arbeiten Support, Success, Product, Engineering und wer auch immer die kommerzielle Beziehung verantwortet. Und alle brauchen denselben Kontext für ihren Teil. Was tatsächlich passiert: Der Kontext wird in seine Einzelteile zerlegt. Support hat die Issue-Historie. Success hat die Notizen vom letzten Call. Product hat einen Feature Request, den vor drei Monaten jemand eingetragen hat, der inzwischen gar nicht mehr beim Kunden arbeitet. Engineering hat den Linear-Thread zu einem Bug, den außerhalb von Engineering niemand lesen kann (und möchte).

Also stellt ein Kunde eine Frage und die Antwort kostet vier Personen, drei interne Threads, zwei Syncs (damit alle auf demselben Stand der Dinge sind) und anderthalb Tage. Der Kunde erlebt das als Trägheit. Intern sieht es so aus, als würde jeder seinen Job ordentlich machen. Niemand macht etwas falsch und trotzdem schleicht das Ganze vor sich hin. Das ist genau die Sorte von Problem, die meist nie behoben wird, weil es keine einzelne Person beziehungsweise keinen einzelnen Prozess gibt, der daran schuld ist.

Die meisten Teams bauen sich stattdessen denselben Stack zusammen: ein Helpdesk, ein CRM, Notetaker und Zapier oder Make, die die Tools zusammenhalten. Dieser Stack muss ständig gepflegt werden. Und er schiebt Datensätze zwischen Systemen hin und her, ohne den Menschen jemals ein gemeinsames Bild zu geben.

Für uns blieben trotzdem Lücken. Unser Produkt war technisch und erklärungsbedürftig. Als wir uns angeschaut haben, wie wir KI implementieren und vor den Kunden einsetzen, kamen die Antworten genauso flach zurück, wie es jemand sofort merkt, der vierstellig im Monat für unser Produkt zahlt. Und ein Kunde in dieser Größenordnung will keine schnelle Standardantwort. Er will seinen Ansprechpartner, schneller und besser informiert.

Die Modelle waren in Ordnung. Das Problem lag auf beiden Seiten davon. Was wir als Input hineingegeben haben, war über mehrere Channels verteilt, die nie jemand den Accounts sauber zugeordnet hatte. Ein gutes Modell produzierte also selbstbewussten Output aus einem unvollständigen Bild und das ist schlimmer als gar kein Output.

Zurück kam ebenfalls nichts. Wenn ein Support Engineer einen Entwurf zu der Antwort umgeschrieben hat, die tatsächlich richtig war, ging diese Korrektur ausschließlich an den Kunden und sonst nirgendwohin. Es gab keinen Reinforcement-Loop, keinen Mechanismus, der die beste Antwort, die jemand im Team ohnehin schon geschrieben hatte, zur Antwort des Systems beim nächsten Mal gemacht hätte. Jede Frage fing bei null an. Das System wurde in unserem Produkt also nie besser, egal wie lange wir es laufen ließen.

Es gibt einen strukturellen Grund, warum sich das später schwer nachrüsten lässt. Viele Tools reduzieren ein Gespräch auf das, was in einen Ticket-Datensatz passt und syncen nur diesen Datensatz ins CRM. Vom Gespräch selbst bleibt nur eine substanzlose Zusammenfassung. Ein Modell, das du später obendrauf setzt, liest genau diese substanzlose Zusammenfassung. Was gesagt wurde und was zwischen den Zeilen stand, ist da nicht mehr drin. Wer lesen will, was Kunden tatsächlich gesagt haben, braucht das vollständige Gespräch von Anfang an, direkt am Account.

Dann hatte ich Zeit

Meine Rolle in der Firma endete und zum ersten Mal seit Jahren hatte ich freie Zeit. Ich habe sie genutzt, um meine Programmier-Skills zu schärfen; damit hatte ich sowieso schon vor einiger Zeit angefangen. Ein Teil der Lernkurve war steiler, als ich initial erwartet hatte, und das bedeutete viele Nächte mit Problemen, über die ich in einer VP-Rolle nie nachdenken musste. Um drei Uhr nachts fand mich meine Freundin vor einem YouTube-Video über JWTs, danach vor einem über AES. Ich habe mitgeschrieben und Notizen gemacht wie vor einer Prüfung in der Uni.

Aus dem Nebenprojekt wurde schneller etwas Größeres. Als es anfing, konkret nach etwas Echtem auszusehen, habe ich getan, was ich definitiv zuerst hätte tun sollen, und bin damit in den Markt gegangen: rund 20 Gespräche mit Support- und Success-Leads in B2B-Unternehmen. Ob es das Problem gibt, hatten drei Jahre bereits geklärt. Ich wollte wissen, ob andere Teams es noch als Problem empfinden oder sich still damit abgefunden haben. In fast jedem Call entstand dasselbe Bild, meist auch in demselben leicht verlegenen Ton, den ich aus meiner eigenen Version davon kannte. „Ja, wir machen das in Slack. Ja, wir wissen, dass der Prozess nicht optimal ist. Nein, wir können ad hoc nicht sagen, mit welchen Accounts wir gut dastehen.“

Das hat gereicht, um All-in zu gehen. Freunde, die CTOs in Tech-Unternehmen sind, haben mir bei Architektur und Infrastruktur geholfen. Den Rest baue ich selbst und es ist das erste Produkt, das ich von Anfang bis Ende gebaut habe.

Was Aloy ist

Gebaut habe ich letzten Endes das Tool, das ich mir drei Jahre lang gewünscht hatte. Ein Tool, in dem primär Customer Support und Customer Success Teams arbeiten, das die Zusammenarbeit mit anderen Customer-facing Teams verbessert und damit den Kontextverlust minimiert. Mein Core Principle dabei: Der interne Slack-Workspace, in dem nahezu die gesamte Kommunikation stattfindet, darf sich nicht wie ein Fremdkörper anfühlen. Aloy muss sich nahtlos in bestehende Systeme einfügen und die Menschen dort erreichen, wo sie ohnehin schon arbeiten.

Es spielt also keine Rolle, ob du direkt aus Slack heraus nach deinem eigenen System arbeitest oder dich in ein Webinterface einloggen möchtest. Nutzt du lieber Claude Code, Codex, Cursor oder eine andere IDE, sind unser MCP Server und die CLI im Handumdrehen eingerichtet. Du wählst, wie du arbeiten möchtest. Aloy strukturiert, organisiert und hält den gemeinsamen Kontext für deine Kollegen zusammen.

Aloy verfolgt die Gespräche in den Channels, bereitet sie auf und stellt sie übersichtlich dar. Dabei werden auf Account- und Kontakt-Ebene zusätzliche Health-Signale wie zum Beispiel Vibe und Risk erfasst. Health ist der Teil, bei dem es mir mit am wichtigsten war, ihn richtig zu konzipieren. Andere Tools tracken die Proxys: Logins, Nutzung, Anzahl Issues, NPS, CSAT. Aloy trackt sie auch, weil das echte deterministische Signale sind, auf denen etablierte Customer Support & Success-Metriken basieren. Außerdem liest Aloy, was Kunden im Channel tatsächlich gesagt haben. Ein Proxy sagt dir, dass sich jemand nicht mehr einloggt. Das Gespräch sagt dir, warum und hat es meist schon Wochen vorher abgebildet.

Der Blick von oben ist mir dabei zunehmend wichtiger geworden. Wenn jede Konversation an einem Account hängt, wird dieselbe Frage, die von Kunde zu Kunde kommt, zu einem Muster, das man sehen kann: die Integration, die ständig bricht, der Wunsch, der immer wieder in leicht anderen Worten auftaucht, der Teil des Produkts, den man immer erklären muss. In meiner letzten Firma gab es diese Information auch. Sie war über Hunderte Channels und die Erinnerungen mehrerer Leute verteilt, was praktisch dasselbe ist, wie wenn es sie nicht gäbe.

Das meiste, was Aloy macht, passiert, bevor jemand überhaupt einen Vorschlag sieht. Aloy beobachtet die Channels, fängt Signale ein, sobald sie auftauchen und macht die undankbare Arbeit. So wird aus einem Strom von Nachrichten ein System, mit dem man arbeiten kann: zu welchem Account das gehört, zu welchem Kontakt, ob das ein neues Issue ist oder das vierte Nachfassen zu einem alten, ob das Beschriebene zu etwas passt, das letzten Monat ein anderer Kunde angesprochen hat. Diesen Teil will niemand bauen. Und genau dieser Teil entscheidet, ob die KI obendrauf nützlich ist oder selbstbewusst falsch.

Aloy schlägt vor, entwirft und macht sichtbar. Aloy OS handelt selbst, wenn die zugrunde liegenden Fakten gemessen sind und sich die Aktion rückgängig machen lässt. Alles andere kommt als Entwurf zu einem Menschen. Pylon hat sich inzwischen als Agentic Support Platform neu aufgestellt und ein großer Teil der Tool-Kategorie geht denselben Weg. Ich verstehe den Reiz und ich halte die Grundeinstellung für entscheidend: Im B2B, wo ein einzelner Account einen spürbaren Teil des Umsatzes ausmachen kann, merkt die Person auf der anderen Seite den Unterschied zwischen einer Antwort von deinem Team und einer Antwort von deinem KI-Stack.

Dieses Thema war in so ziemlich jedem Discovery Call der Punkt, an dem die Stimmung zu kippen drohte. Sobald ich aufgezeigt habe, wo Aloy selbst handelt und wie ein Mensch weiterhin im Loop bleibt, konnte man trotz des virtuellen Meetings und einer gewissen Distanz, die es zwangsläufig mit sich bringt, eine sichtbare Erleichterung beim Gegenüber wahrnehmen.

Wo Aloy gerade steht

Aloy startet im Oktober 2026 in den Early Access, die Registrierung ist bereits geöffnet. Während dieser Zeit ist Aloy kostenlos. Es existiert eine Warteliste und einen langen Backlog an Dingen, die noch umzusetzen sind.

Es gibt keine konkrete Zwei-Jahres-Roadmap, die in Stein gemeißelt ist. Was als Nächstes gebaut wird, richtet sich fast ausschließlich nach dem Feedback der User und danach, wie sich dies in meine Vision von Aloy einordnet.

Wenn du bereits mit Kunden über Slack oder Teams kommunizierst und dir Teile dieser Geschichte bekannt vorkommen, würde ich gern von dir hören. Schreib mir, wie ihr Accounts heute übergebt, Health einschätzt und verhindert, dass Absprachen im Channel verschwinden. Wenn Aloy zu eurem Setup passt, nehme ich euch gern in den Early Access auf.