#19 Make or Buy

Jakob Hubloher: Stell dir vor, du sitzt als Geschäftsführer in einem Meeting, ihr redet über KI im Kundenservice und irgendwann kommt dieser Satz, den gerade glaube ich irgendwie so alle sagen, den Bot, den bauen wir einfach selbst. Das setzt doch ein Entwickler an einem Nachmittag mit Claude oder N8N, you name it, einfach ⁓ Ist doch viel günstiger und du kannst es viel besser auf dein Unternehmen individualisieren. Das klingt smart. Wenn man das jetzt auf den ersten Blick hört, klingt nach gespartem Geld. Und genau das ist gerade einer der Lieblingsvorschläge oder Beratungen, wie man sie auch immer nennen will, auf LinkedIn. Was ja aber keiner sagt, günstig selbst gebaut wird verdammt schnell sehr, sehr teuer. Kaufst du günstig, kaufst du teuer. Und genau das schauen wir heute mal ehrlich hin.

Maxi: Und damit herzlich willkommen bei Service Sells dem Podcast, der dir zeigt, wie dein Kundenservice nicht nur begeistert, sondern auch verkauft. Ich bin Maxi und sitze heute hier mit Jakob natürlich, meinem Co-Host, Hey Jakob.

Jakob Hubloher: Hey, grüßt euch!

Maxi: Du hast es ja schon angeleitet, was es heute geht. Wir reden über das ganze Thema Make or Buy, ja gerade in der KI-Bubble super groß ist, was wir vor allem auf LinkedIn auch total häufig lesen. Da lasst uns erstmal verstehen, warum gerade alle überhaupt so ein Make predigen. Woher kommt das eigentlich? Und ehrlich, ich verstehe es sogar. Ist bei uns intern der Firma auch ein großes Thema. Also wo früher halt Softwareentwicklung ja immer so locker 100.000 Euro oder mehr gekostet hat, macht heute irgendwie gefühlt jeder Entwickler das gleiche an einem Nachmittag. Du hast ja schon gesagt, mit Make, N8N, Claude, you name it. Und die Tools, die sind da, die sind zugänglich und gleichzeitig raten dir auch halt immer mehr Berater dazu. Baust doch selbst, dann kannst du es viel besser auf dein Unternehmen individualisieren. Ich sag mal so, die größte KI-Transformation in Deutschland ist gerade, dass eben genau diese Berater über Nacht irgendwie jetzt zu KI-Experten geworden sind.

Jakob Hubloher: Ja, also ich muss auch sagen, ich hab ja neulich auf LinkedIn dazu was gepostet und der Post ist einfach in diesem B2B-Umfeld ziemlich viral gegangen. Also von den Anzahl der Impressionen, die ich dann gesehen hab und das zeigt ja schon mal, dass es einen totalen Nerv trifft. Also ich hab's genau auch darauf aufgebaut zu sagen, ey guck mal, das was früher sehr viel Geld gekostet hat, das machst du heute gefühlt an einem Nachmittag halt eben in Dev. Und die Wahrheit ist ja, du kannst das ja superschnell aufsetzen, ich mein, ganz, ganz immer rund auch Vibe-Coding. Wir nutzen das ja intern selber, Vibe-Coding für gewisse Themen. Die Frage ist aber ja nicht, das ist so ein bisschen das, was in der Diskussion finde ich total falsch, also nicht kann man das bauen, sondern kann man das sinnvoll betreiben in einem Enterprise Kontext und da habe ich das Gefühl, da ist so diese Sollbruchstelle einfach massiv hoch aktuell.

Maxi: Genau, da sind wir eigentlich auch schon bei unserem ersten Reality-Check, den wir heute ansprechen wollen. Also einen Piloten oder eine Demo zum Laufen zu kriegen, das schafft heute fast jeder, wie du schon gesagt hast, mit Vibe-Coding. Aber der Reality-Check hier ist eigentlich die Wartung und die wird, finde ich, massiv unterschätzt und das kann auch dann häufig richtig wehtun.

Jakob Hubloher: Ja, meine, der schwere Teil ist es ja nicht, jetzt einen Prozess aufzubauen. ich meine, nehmen wir mal einen ganz einfachen, oder was ist denn, komplexen Case, aber einfach runtergebrochen. Du hast jetzt einen Reklamationsprozess. Und klar kannst du den jetzt erstmal vibe-coden, du kannst den über Claude erstellen, dass ein AI-Bot das zum Beispiel jetzt abfängt für dich. Aber was ja das Problem ist, ist, dass es hier in dem Prozess immer wieder neue Pfade sozusagen geben wird. Es kommen ja immer Kleinigkeiten dazu. Man kann sich das dann eigentlich vorstellen, dass du irgendwann natürlich einen riesen Baumdiagramm mehr oder weniger sozusagen hast oder einen riesen Prompt letzten Endes dahinter und das Problem ist, dass jede Prozessänderung eigentlich so ein if-Statement erzeugt, also eine neue Verzweigungslogik letzten Endes und meistens ist es so, es fällt mir extrem auf im Gespräch mit Unternehmen, wie viele Leute können diesen Prozess warten? Das eine Person in der Company, die das noch warten kann und deswegen ist es nicht das Problem das zu bauen, das Problem ist einfach so diese diese Maintenance und das ist eigentlich super Silo-Wissen ist, was auf eine Person aufgebaut wird, dass die diesen Workflow, diesen Prozess versteht und damit ist gar nicht mehr das Problem das aufzubauen initial, sondern dass du dein Knowledge auf eine Person transferierst und das wird meiner Meinung nach in der Maintenance massiv unterschätzt.

Maxi: Genau, das fiese daran ist, finde ich, auch der zweite Effekt. das, was dann noch mitkommt mit dieser Wartung. Also dein Team oder vielleicht auch nur diese eine Person in deinem die das wartet, hat irgendwann gar nichts Neues mehr. Also sie pflegt eigentlich nur noch das, was schon gebaut wurde. Und das liest man jetzt auch immer wieder, dass Teams schnell den Großteil ihrer Zeit halt mit dieser Warten und mit Fixen von Bugs einfach damit beschäftigt ist. meine, das sehen wir bei unserer eigenen Software. Und es muss immer jemanden geben, der sich halt auch mit der Weiterentwicklung beschäftigt. Und das kann auch ein ganzes Team sein. Der Klassiker ist da eben, solche Sachen, die man an Eigen gebaut hat, werden, und da habe ich auch eine Zahl letztens gelesen, werden im Schnitt 30 bis 50 Prozent teurer als ursprünglich geschätzt. Also einfach weil der Umfang während des Bounds immer weiter wächst und dann merken die Teams auf einmal, ist es doch mehr als wir jetzt am Anfang angenommen haben. Und dann fängst du an mit wir automatisieren mal den Bestellstatus und landest dann aber am Ende bei irgendwie einem Monster, das du aufgebaut hast und wo halt auch dann keiner mehr einen Überblick drüber hat.

Jakob Hubloher: Ich meine, die Frage, die ich dann immer stelle, an der Stelle ist, hast du eine Person, die Vollzeit nur dafür abgestellt ist, dieses Projekt zu machen? Oder am besten Fall sogar zwei Leute sozusagen, das zu becken. Und meistens ist es immer so, dass diese Personen andere Aufgaben noch nebenbei haben. Das heißt, die fuchsen sich dann da irgendwie rein. Das sind vielleicht auch Leute, die KI-affin sind. Wenn du diese Frage mit Ja beantworten willst, das habe ich dann good for you, dann bin ich da gar nicht sogar, da bin ich dabei okay. Es ist dann auch irgendwie okay, dann sozusagen zu entwickeln. Aber wenn du es nicht hast, dann verbringen diese Leute einfach auch Zeit auf den falschen Themen. Es ist so ein bisschen Schuster bleibt bei dein leisten. Das ist jetzt mal ganz einfach gesagt. Aber da steckt schon irgendwie relativ viel dahinter. Das andere was ich sehe, das ist so bisschen so diese zweite Dimension, wenn wir jetzt mal darüber reden von unserem Reality-Check, ist dass ich sehe, dass diese Tokenkosten ja total klein geredet werden. das hatten wir neulich mal das Gespräch mit einem Bestandskunden, der da auch super viel gecodet hat mit und der meinte, ja das ist ja gar nicht so ein krasser Log-in-Effekt, so die Preise werden ja eher günstiger, weil es ja immer mehr KI-Modelle gibt. Und ich weiß nicht wer sich wirklich mit Tokenkosten auseinandersetzt, also wenn du es mal wirklich tief machst, ist, dass die richtig teuer werden aktuell. Gerade Claude zieht die Preise ja massiv an und wir haben neulich auch mal, kann Jonas wahrscheinlich mehr erzählen als ich, haben wir neulich mal ein Projekt, einen Tag mit Claude, gecodet, hatten wir auf einmal ein 54 Euro Billing auf dem Tisch. Und das ist schon krass für einen Tag IT-Leistung. Und was ich immer argumentiere, ist du baust ja ein Business-Cash. Du rechnest ja jetzt zum Beispiel im Kundenservice damit, ich will TicX-Tickets einsparen und dann habe ich ja diesen Return on Invest. Aber wenn doch diese Token-Preise so krass massiv schwanken... Und auf einmal ist das Billing ganz anders, dann geht dieser Business Case doch gar nicht mehr auf. Und dann rede ich auf einmal davon, dass Leute, so Modelle überwachen müssen, immer die passenden Tokenkosten im Blick zu haben. Und die sind ja ehrlicherweise, und wir sind auch super intransparent mit den Zeichen und sowas. Da brauchst jemanden, der sich auch krass auskennt. Also das ist so eine Dimension. Ich weiß nicht, wie du es siehst, Maxi, aber finde ich auch irgendwie, das wird mir ein bisschen zu vereinfacht, die Diskussion.

Maxi: Ja, die Tokenkosten sind, wie du sagst, super intransparent noch und sie steigen halt auch immer weiter, weil da ist ja auch irgendwo ein Preiskrieg zwischen den ganzen LLMs und ich habe gerade erst eine Studie von Gartner dazu gelesen, die haben für 2028 vorausgesagt, dass die Codingkosten, die du über AI hast, ein durchschnittliches Entwicklergehalt übersteigen werden. Also finde ich auch total spannend den Ansatz. Ja, ja.

Jakob Hubloher: Crazy, Das ist doch crazy.

Maxi: Ja total, dass dann die KI dann doch irgendwann teurer wird als der Mensch. Muss man schauen, wie der Output sich dagegen rechnet. Aber ich glaube, das wird schon noch massiv unterschätzt. Weil du liest ja schon viel auch gerade über Unternehmen oder Berater, die sagen, ey, schmeißt alle eure Leute raus. So ganz radikal, ihr könnt jetzt alles mit KI machen. Ich weiß nicht, ob das so die Zukunft ist. Ich glaube, das wird so bisschen zu sehr gehypt gerade noch.

Jakob Hubloher: Ja und ich glaube auch, diese Modelle, also da stecken ja auch Rieseninvestoren, die ja auch immer wirtschaftlich werden müssen. Und wenn ich mir das jetzt rein anschaue, klar, dieses eine Argument ist immer, es gibt mehr Anbieter, deswegen sinkt der Preis. Aber ich sehe es eher so, dass diese Modelle, richtig viel Rechenpower haben und die du dann auch von der Qualität haben willst, eigentlich eher Preise anziehen müssen, letzten Endes auch irgendwie selber in die Wirtschaftlichkeit sozusagen reinzukommen. Genau, aber da könnte man jetzt glaube ich Stunden drüber philosophieren. Ich glaube, was eine andere Dimension ist ja auch, ist ja auch nicht nur, dass es jetzt Riesen-Token-Kosten gibt, sondern was ja in dieser Dimension dazu passiert, ist ja, dass die Qualität sich massiv ändert. Da redet gar keiner drüber. Also wenn du jetzt von einem 4-5er-Modell auf ein 4-6er-Modell zum Beispiel wechselst, zum Beispiel OpenAI jetzt oder so ähnliches, dann gibt es was, das nennt sich Quality Degrees. Das heißt, dass die Qualität zwischen den Modellen abnimmt. Du würdest ja denken, jedes Modell ist automatisch eine Verbesserung zu dem vorherigen Modell, aber das ist nicht linear und das ist auch Riesenfehler. haben mal einen Kunden gehabt, lief super die AI, war richtig gut, dann habe ich das Modell umgestellt auf das höhere Modell, die Recognition viel schlechter für diesen spezifischen Prozess und das ist was, darüber redet keiner. Das heißt, ich muss nicht nur eine Token Dimension mehr betrachten, ich muss auch eine Qualitäts Dimension betrachten und dann frage ich, wer von euch im Unternehmen ist dafür zuständig die Qualität der Modelle zu evaluieren? Da brauchst du ja auch Leute, die diese Modelle fahren, die das pilotieren, die das in der Umstellung haben, die Staging-Umgebungen aufbauen, so einen produktiven Prozess umzuziehen. Also, neues Modell, nicht gleichzeitig bessere Quality. Und ich finde ich war es auch, dass in der Diskussion einfach vollkommen untergeht oder ich einfach nie höre tatsächlich, weil, und da bin ich der Meinung, sich niemand damit tief beschäftigt oder man Modelle umgestellt hat in der Praxis.

Maxi: Ich würde an der Stelle auch gerne einmal beleuchten, wie sieht das bei uns, also bei melibo genau aus. Also wir nutzen ja größtenteils für unsere AI-Agents eben das Modell von OpenAI. Das heißt, wenn die ihre Preise anziehen, dann spüren wir das auch direkt. Aber, und das ist hier, finde ich, wirklich der entscheidende Punkt, wir können eben das Modell auch wechseln. Wir können da relativ flexibel sagen, wenn der eine Anbieter zu teuer ist, dann können wir zum anderen switchen und das nicht nur innerhalb vom Anbieter, sondern auch in den Modellen. Also es gibt ja mittlerweile zig viele Modelle, also bei OpenAI muss ja auch entscheiden, je nachdem wie komplex die Anfrage ist, lasse ich die jetzt beantworten von einem GPT-3 oder einem GPT-4.0 mini oder brauche ich da das beste Modell? Selbe bei Anthropic mit Sonnet 4.6 oder jetzt auch Fable 5. Da unterscheiden sich die Tokenkosten ja noch mal extrem. und da kann man ja wirklich flexibel zwischen switchen und wenn dir jetzt OpenAI halt zu teuer wird, kannst du das Sprachmodell switchen. Das ist eine bewusste Architekturentscheidung auch von uns, die wir getroffen haben, damit wir eben nicht so abhängig von diesen Preisen sind. Und genau diese Flexibilität müsstest du, wenn du ein Make machst, also wenn du selbst baust, auch erstmal haben. Also dann musst du dir diese Architektur auch erstmal aufbauen und dann eben auch dauerhaft pflegen und du brauchst diese Expertise überhaupt, welches Modell, welche Anbieter kann welche Aufgabe am besten lösen und da muss sich ja auch erstmal intern jemand mit auseinandersetzen und es kostet auch einfach wieder mehr Ressourcen. Aber lass uns mal das Talkenthema dann erstmal hinten anstellen. Wir kommen dann zu unserem Reality-Check Nummer 3. Und das auch ein Denkfehler, der uns glaube ich häufig begegnet. Die Idee nämlich, es ein lernendes System ist. Also die Leute sagen immer, wenn unser ganzes Wissen erstmal in Claude liegt, dann lernt das System ja mit und wird automatisch besser.

Jakob Hubloher: Ja, Ich weiß nicht, wie ich es anders sagen soll. wenn dein Wissen in Cloud liegt, dann ist das kein lernendes System. wirklich Punkt. Das ist kein lernendes System. Es wird dir überhaupt nicht besser. Also es beantwortet genau auf deiner Kundenbasis dann oder deiner Wissensdatenbank die Anfragen. Aber es lernt natürlich nicht mit, weil es keine Möglichkeiten gibt, Modell auf deine Daten fein zu tunen. So eine LLL-Optimierung sozusagen zu machen, das findet einfach faktisch nicht statt. Und dementsprechend wird das auch nicht mit den Kundenhistorien besser oder mit mehr Chats sozusagen besser. Es hat eine Qualität, die es am Anfang hat und die wird es danach sozusagen auch haben. Das heißt, es ist faktisch schon mal kein lernendes System. Was du ja brauchst, ist ein LLM, was du feintunen kannst auf deine Kundendaten und dafür brauchst du einen eigenen Trainingsbereich für dieses LLM-Modell und das bietet dir an Claude oder ähnliches, bietet es einfach nicht an. Ich finde die andere Sache, die man da auch beleuchten muss, ist also willst du, dass deine ganze Kundenhistorie in Claude liegt? Also kannst du die auch einfach mal beantworten. Ich weiß nicht. sehe ich jetzt auch irgendwie als nicht so mega gut an, wenn du da jetzt irgendwie deine ganzen sensiblen Kundendaten raus hast, bevor du ein Payment-Anbieter da liegen ja auch personenbezogene Daten drin und das ist was, das müsste man, finde ich, da auch nochmal mit einordnen. Also, das ist auch die andere Dimension.

Maxi: Auf Fall gerade im Dach- und EU-Raum ist halt immer die Frage, wer hat überhaupt Zugriff dann auch auf die ganze Chat-Historie, auf die Kundendaten und da muss ich ja auch fragen, ob das ganze DSGVO konform ist und das ist gerade auch ein super heißes Thema, weil wir jetzt zusätzlich auch den EU-AI-Act haben, steht ja jetzt schon länger fest, aber da werden jetzt ab 2. August kommen da jetzt auch noch mal paar neue Regeln, in Kraft gesetzt werden. Und das wird nicht lockerer, sondern eher strenger, was wir da sehen. Und das unterschätzen auch noch viele. Also da können echt richtig fette Bußgelder entstehen. Und allein bei der DSGVO sind die verhängten Strafen seit 2018 mittlerweile auf über 6 Milliarden Euro aufsummiert. Also nicht Millionen, Milliarden. Also das ist echt krass. Das ist wirklich krass. Also das wird schon unterschätzt.

Jakob Hubloher: Die haben wir nicht, Maxi zu bezahlen,

Maxi: Das ist jetzt Stand März 2026, war eine Studie vom CMS Enforcement Tracker. Und dann kommt eben EU AI Act noch obendrauf. Und da reden wir ja auch schon von Bußgeldern von bis zu 35 Millionen oder 7 Prozent des weltweiten Jahresumsatzes. Also das ist schon krass und sollte man auf keinen Fall unterschätzen. Und das sind eben keine... Nice to haves, über die man sich dann mal später Gedanken macht im Kundenservice, fasst du halt echte Kundendaten an für Accounts, Bestellungen, Rückerstattungen oder auch teilweise sensible Vorgänge und wenn du das selbst baust, bist du ab Tag eins irgendwie, kann man sagen, dein eigener KI-Anbieter und mit allem was dazu gehört und dann musst du dich halt auch im Themen wie Sicherheit, Datenschutz und so weiter halt, ja. beschäftigen und haft es dann auch im schlimmsten Fall Ich will dann aber nochmal überleiten. Ja, komm, ich stell dir jetzt mal die Frage, die bei jedem wahrscheinlich mal auftaucht. Ja, aber wenn ich jetzt das mit euch mache, also mit uns mit melibo dann bin ich doch auch von euch und euren Preisen abhängig. Was sagst du denen dann?

Jakob Hubloher: Ja, also erstmal finde ich das eine total gute Frage. Ich hatte tatsächlich neulich mit dem CEO genau diese Diskussion. Tatsächlich, warum? Also wie kam überhaupt diese Diskussion? Vielleicht eine kleine Analogie aus einem echten Call, aus einem echten Vorhaben. Ich habe von einem sogenannten KI-Lock-In-Effekt gesprochen. Was ist ein KI-Lock-In-Effekt? Das heißt, wenn du dich auf ein Modell committest, bist du abhängig davon, wie deren Preise sich sozusagen entwickeln und dass du nicht mehr so einfach das Modell sozusagen umziehen kannst. So, das war... mein argument was ich gemacht habe und er hat gesagt ja jakob ich habe bei euch aber genau den selben lock in effekt wenn ich auf euch sozusagen setzt seid ihr ja genauso abhängig von den token kosten letzten endes was mein argument ist man muss jeder gucken was er daraus macht ist das stimmt ich mein wissen ja auch wir hängen auch an den preisen der llm modelle sozusagen dran das wäre ja falsch zu sagen dass wir das nicht abhängig sind also wir haben eine gewisse abhängigkeit mein argument war dann zu sagen ja das sind wir aber ich habe zwei leute im team die die der Verzuständigen sind LLM Modelle zu evaluieren und die dann diese Modelle wechseln können tatsächlich auch und diese Qualität auch überprüfen können. Das heißt ich kann zum Beispiel von einem OpenAI auf ein Entrophic Modell rüber wechseln, ich kann innerhalb der Modelle sozusagen gucken wie ich wechsle und ich habe ja auch diese Erfahrungswerte zum Beispiel brauche ich für eine Ticket Summary deutlich Günstigeres Modell als für eine komplexe Reklamation mit einer Antwortgenerierung dahinter oder für eine Kategorisierung. Da ich viel einfache Modelle. Mein Argument ist, dass ich das viel besser steuern kann, weil ich viel mehr Leute habe, die sich damit auseinandersetzen können sozusagen. Und der Unterschied ist einfach, wir kümmern uns diesen Modell-Switch, die Wartung und die Qualität. Und das ist, glaube ich, in meinen Augen der größte Unterschied sozusagen, dass du dafür dedizierte Personen hast, die das evaluieren können und die das von der Architektur umstellen können. Weil wenn du jetzt... bei Claude das ganze gecoded hast, dann kannst du dich einfach von Claude jetzt einfach mal rüber wechseln, sozusagen ist ja gar nicht möglich mit dem Export von deinen ganzen Sachen, die du da aufgebaut hast, auf ein anderes Tool einfach umzuziehen. Klar, wenn du das jetzt über Frameworks baust, wo du die APIs auch austauschen kannst, die LR-Modelle, dann hast du da weniger Login, aber trotzdem musst du das irgendwie hinkriegen, erstmal von der Qualität. Dementsprechend, ja, wäre das eigentlich so ein bisschen mein größtes Argument. dagegen warum du nicht so einen starken Lock-in-Effekt hast. Du hast einen Lock-in-Effekt, aber er ist meiner Meinung deutlich abgeschwächt und damit ein geringeres Risiko als Company.

Maxi: Genau, wir haben es ja vorher schon mal gesagt, wie wir es machen und so jetzt kein einseitiger Verkaufsplitsch hier werden. Wir sagen auch ausdrücklich nicht, ne, baut nie selbst. Also wir kaufen ja intern auch Software ein und überlegen mittlerweile, können wir das auch irgendwie selbst machen, haben ja auch ein großes IT Team, deswegen wäre es jetzt unehrlich von uns zu sagen, ne, baut nie selbst, kauft euch immer die Software. Es gibt... Es gibt Fälle, denen Make absolut Sinn macht für manche Teams, aber man muss einige Dinge bedenken und sich das genau überlegen, ob man da die Ressourcen intern für hat.

Jakob Hubloher: Ja, mir wichtig ist, ist, dass Makes sich für viel mehr Leute nicht lohnen, als für die Leute, es sich lohnt. Und das ist das, warum wir das auch so challengen. Es gibt Makes, die machen vollkommen Sinn. Also stell dir mal vor, du bist ein Unternehmen, das alles on-prem hosten muss, mega krasse Compliance-Richtlinien hat. Aber ich hab so den Take auf LinkedIn gemacht, für 90 % lohnt es nicht. Kann ich die Zeit für 90 % beweisen? Nee, kann ich nicht. Aber es ist etwas, was aus der Praxis sehen kann, dass es für viele sich einfach überhaupt nicht lohnt, weil die nicht das Personal haben, weil die nicht das Knowledge haben mit den LLM Modellen und weil die zum Beispiel, haben wir heute noch gar nicht darüber geredet, auch überhaupt nicht damit umgehen können, wenn die AI halluziniert. Ist ja auch ein riesen Topic. Also musst du ja auch mal drüber reden. Was machst du denn? Du hast bei jedem AI Projekt 5 % Hallucination Quote. Wie kriegst du das aus Claude weg? Jetzt gibt es Leute, die können es in der Eigenentwicklung vielleicht machen und finden gute Workarounds, aber dieses Fachwissen brauchst du ja auch und deswegen ist der Take, es lohnt sich für viel mehr Leute nicht als für die es sich lohnt. da werden deutsche Companies richtig viel Geld verbrennen, meiner Meinung nach. Und deswegen finde ich es einfach eine schlechte Beratung von Leuten, die in der Praxis niemals KI-Modelle gewechselt haben oder nicht mal auch, keine Ahnung, 170 Projekte umgesetzt haben. Das ist einfach ein Erfahrungsschatz, ich der Meinung bin, ich will, deutsche Unternehmen bessere Entscheidungen treffen. Und das gehört zu dieser Dimension dazu. Und das muss man für sich prüfen. Das kann man, finde ich, wunderbar machen, wenn du jetzt diese Punkte gegenüberstellst.

Maxi: Da muss einfach Klarheit sein, wie du sagst. Man muss sich überlegen, ist da wirklich ein echter Business Case da? Welche Prozesse sind überhaupt sinnvoll automatisierbar und welches Setup funktioniert eben auch langfristig, nicht nur in der schönen Demo, sondern eben auch in zwölf Monaten noch. Und ich meine, genau dafür gibt es uns ja. Wir haben ein Experten Team. dass sich seit Jahren mit nichts anderem auseinandersetzt. Da gibt es sicherlich auch viele Teams. Wir haben jetzt mittlerweile über 100 Projekte begleitet, wissen ziemlich genau, welche Prozesse sich automatisieren lassen und welche eben nicht. Und vor allem diese Themen mit der ganzen Modellauswahl, die Switchfähigkeit zwischen Anbietern, Wartung, Qualitätskontrolle, das DSGVO-Thema, das ist bei uns eben schon alles mit eingebaut und wir sind natürlich auch mal dran uns zu informieren, was eben jetzt neu ist auch in dem Markt und ich meine KI-Markt entwickelt sich einfach rasant, da muss man auch hinten dran sein. Deswegen finde ich es auch unrealistisch zu erwarten, dass das dann eine Person bei einem Unternehmen eben alles übernehmen kann.

Jakob Hubloher: Ja, also wir können auch mal ganz drüber reden, was passiert denn, wenn die Person krank wird, im Lotto gewinnt, was weiß ich, die Company wechselt. Also das ist doch auch ein total krasses Risiko einfach. jetzt überleg mal, wenn ich einen Kundenserviceleiter und ein CEO bin, mein Bauchgefühl, wenn ich eine Person habe, die den gesamten Workflow wartet, das wäre, ich finde das katastrophal, ehrlich gesagt. Also ich finde das irgendwie auch schon fast fahrlässig. Klar, wenn du jetzt ein dediziertes Team hast, von fünf bis sechs Leuten, du hast das Geld. Du kannst dich darum kümmern. ist ein ganz anderer Effekt. ich meine, diese eine Person, hart gesprochen, die kann morgen auch nicht mehr da sein. Und das ist auch eine Realität, die man irgendwie auch mit betrachten muss. Und deswegen ist es mir zu einfach. Mir ist es zu einfach. Ich verstehe die Trap. Du baust das, da kommt ein Dev, der zeigt dir in der Mittagspause, was er da gebaut hat mit Claude. Das sieht geil aus. Was dahinter dranhängt, das ist das, was du im Betrachtungsseitrum mitwissen musst. Da darf man sich nicht vom ersten Eindruck nur blenden lassen, bin ich der Meinung.

Maxi: Ja absolut. Lass uns gerne mal kurz zusammenfassen, was wir heute so alles besprochen haben. Also do-it-yourself-KI fühlt sich im ersten Moment günstig an, aber die eigentliche Rechnung kommt später. Wartung, Tokenkosten, der ganze Scope, die Berechnung davon. Und die richtige Frage ist nicht, kann ich das bauen, sondern kann ich das eben auch noch in zwölf Monaten weiter so betreiben und warten. Und eine Abhängigkeit hast du sowieso immer. Die einzige Frage ist, ob sie eben professionell gemanagt wird oder ob sie komplett bei dir hängen bleibt im Team.

Jakob Hubloher: Genau, ich würde meinen Tag wäre, lohnt sich nur, wenn KI dein Kernprodukt sozusagen ist oder du harte Compliance-Richtlinien hast, die du da irgendwie einhalten musst. Plus, würde ich noch Klammerauf hinten dransetzen, du ein dediziertes Team von mehr als zwei Personen hast, die sich darum kümmern können, Volltime. So, das würde ich erstmal dranhängen. Und ich bin der Meinung, dass es sich für KMUs, dass ein Buy immer einen Make schlägt. Immer günstiger tatsächlich. Weil der Provider ja dazu gezwungen ist, immer das beste Preis-Leistungsverhältnis zu machen. Du kannst ja nicht nur zu melibo gehen, du kannst ja noch zu Gefühl 20 anderen anbietern gehen. heißt wir stehen ja auch in einem wettbewerb untereinander. Das heißt die anbieter die saas anbieter werden immer das beste preis-leistungsverhältnis für dich raussuchen und mit den besten modellen immer arbeiten für die unternehmen. Das heißt es ist ein riesen thema. Reden man auch über preisbindungen das hast du bei anbietern ja auch. Das heißt du kriegst preisbindung für den business case. Und ich glaube einmal richtig investieren statt dauerhaft selbst zu warten ist einfach besser. Wie gesagt ich kann so sagen mein erster chef hat immer gesagt jakob kaufst du günstig kaufst du teuer.

Maxi: Das ist ein sehr guter Leitsatz. Zum Schluss noch mal ein kleiner Pitch von uns. Wenn du gerade genau vor dieser Make-or-Buy-Entscheidung stehst und ehrlich durchrechnen willst, was sich da für dich lohnt, dann buche dir gerne eine 1-2-1-Strategieberatung mit uns. Kannst direkt über die Webseite machen und dann reden wir sehr gerne über das Thema und berechnen mit dir zusammen auch den ROI. Ansonsten schaut gerne mal in die Show Notes rein. sind auch alle Quellen noch mal verlinkt zu den Zahlen, die wir heute genannt haben und auch unser ROI-Rechner, der dir eigentlich in ein paar Minuten schon zeigt, wie viel in deinem Kundenservice noch drin steckt. Zum Schluss gilt eigentlich noch zu sagen, abonniert gerne den Podcast, damit ihr keine Folge mehr verpasst und wir hören uns bei der nächsten Folge von Service Sells.