Vielen Dank, dass ich heute dabei sein darf, noch dazu bei der allerersten Ausgabe des Vibe Clubs. Der Gedanke dahinter ist ja, konkrete Anwendungsfälle zu zeigen, die ihr als E-Commerce-Unternehmen direkt für euch einsetzen könnt. Genau das versuche ich euch heute mitzugeben.

Ich hab mir vorher überlegt, was ich euch zeigen könnte, und bin dabei letztens über einen LinkedIn-Post von einer großen E-Com-Brand gestolpert. Die hat nach eigener Analyse herausgefunden, dass sie 468.000 Euro im Jahr verliert, weil Kunden ihre Pakete einfach nicht aus der Postfiliale oder der Packstation abholen. Die ganze Geschichte dazu erzähl ich euch gleich noch, aber schon mal so viel: spannend fand ich, dass sie das nur gefunden haben, weil sie systematisch analysiert haben. Solche Muster gehören nämlich meistens nicht zu den Standard-KPIs, die tauchen in keinem normalen Report auf.

Deshalb dachte ich mir: das wäre doch spannend, mit euch heute einen ähnlichen Fall mal näher anzuschauen und euch zu zeigen, wie ihr selbst solche Muster in euren eigenen Daten erkennen könnt. Denn das ist ja nur einer von vielen Fällen.

Retouren sind eines der teuersten Probleme im E-Commerce überhaupt. Im Schnitt kommt ungefähr jede fünfte Bestellung zurück, im Fashion-Bereich ist es sogar fast jede zweite. Und laut einer Erhebung der EHI zum Versand- und Retourenmanagement kostet jede einzelne Retoure zwischen 5 und 20 Euro, allein an Prozesskosten. Und das ist nur die Kostenseite. Der eigentliche Umsatzverlust kommt oben drauf, weil ihr den Umsatz ja schon verbucht hattet und ihn bei einer Retoure wieder rausrechnen müsst. Und je nachdem, was mit der Ware passiert, kommt oft noch Wertverlust dazu: rund 4 Prozent der zurückkommenden Ware ist so beschädigt, dass sie komplett entsorgt werden muss.

Die meisten von euch tracken das längst: Retourenquote, Retourengründe, teilweise auch Kosten je Retoure. Aber es gibt Muster, die in den meisten Reports einfach nicht auftauchen.

Genau das ist bei der Brand von eben passiert. Der Carrier markiert das Paket schon als zugestellt, sobald es in der Packstation oder Filiale abgegeben wird, nicht erst wenn der Kunde es abholt.

Holt er es dann nicht ab, geht es zurück an sie. Bei ihnen landet es ganz normal im Retouren-Datensatz, meistens ohne brauchbaren Grund. Es sieht aus wie jede andere Retoure und taucht in der Gesamtquote einfach mit unter. Genau deshalb verschwindet es im Rauschen.

Genau darum soll es heute gehen. Wir bauen einen Skill, der solche Muster in euren eigenen Daten zeigt und Maßnahmen mitgibt, wie ihr Retouren wirklich reduzieren könnt. Wir fangen ganz kurz bei den Grundlagen an, also was ein Skill überhaupt ist und wie er aufgebaut ist. Und wenn ihr das schon alles kennt, bleibt trotzdem dran: den größten Teil verbringen wir danach damit, wie dieser Skill hier wirklich entstanden ist, wie man einen Skill richtig baut und worauf es dabei ankommt. Da wird es dann konkret, und ihr könnt ihn im Grunde selbst bauen. Ich zeig euch, was er heute schon kann, und am Ende könnt ihr ihn euch runterladen, selbst testen und natürlich auch anpassen, wie ihr wollt.

Und damit ihr auch versteht, woher ich das eigentlich weiß: kurz zu mir.

Historisch komme ich aus fast 15 Jahren E-Commerce. Ich war bei ABOUT YOU, hab danach acht Jahre lang Lyska aufgebaut, meine eigene E-Commerce-Software-Beratung, und mehreren Unternehmen geholfen, ihre Tech- und E-Commerce-Prozesse zu skalieren. Zuletzt hab ich Tech und E-Commerce bei KarlvonDrais verantwortet und als Tech Lead Operations bei Liebscher & Bracht gearbeitet.

Heute unterstütze ich mit Path to AI E-Com-Brands dabei, mit AI zu skalieren. Konkret setze ich AI ein, um ihre Sichtbarkeit in Google und AI-Suchen zu verbessern, SEA-Kampagnen effizienter zu machen und Shops so zu optimieren, dass mehr Besucher zu Kunden werden. Dafür arbeite ich mit Claude und spezialisierten Agents und kann so mehrere Disziplinen abdecken, für die eine Brand sonst jeweils eigene Experten bräuchte.

Skills nutze ich mittlerweile täglich in meiner Arbeit, genau wie meine Agents. Sie sorgen für reproduzierbare Ergebnisse und dafür, dass Claude und meine Agents auf Expertenniveau arbeiten. Genau darum geht es heute auch.

Bevor ich euch den Skill zeige, kurz die Basics, damit der Rest Sinn ergibt.

Ein Skill ist im Grunde einfach nur eine Textdatei, in der beschrieben steht, was Claude tun soll.

Ihr könnt euch das so vorstellen: Ihr habt eine neue Kollegin in eurem Team. Ihr erklärt ihr jeden Morgen aufs Neue, wie der Kaffee gekocht wird, wo die Tassen stehen, immer wieder dasselbe. Das nervt euch irgendwann extrem, und ihr überlegt euch: wie bring ich der Person das eigentlich bei?

Irgendwann klebt ihr einen Zettel an die Maschine, der alles erklärt, und anschließend weiß sie es, genau wie alle anderen, ohne dass es nochmal jemand erklären muss.

Genau so ist es auch mit Claude: entweder ihr promptet jeden Tag aufs Neue immer wieder dasselbe, oder ihr gebt Claude über einen Skill einmal die Anweisung, also den Zettel quasi an der Maschine, und bringt ihm damit eine Aufgabe einmal bei, mit kompletten Regeln, Eigenheiten und Format. Claude merkt sich das für immer, ganz gleich, wo ihr seid, in welchem Chat, in welchem Projekt. Die Information wird sich nämlich automatisch geholt, sobald die Aufgabe dazu passt.

Jetzt schauen wir uns an, wie das bei uns im Retouren-Analyse-Skill funktioniert.

Vorher lassen wir ihn kurz laufen, damit wir uns danach das Ergebnis anschauen können.

Wir rufen ihn über das Slash-Kommando auf und schmeißen die Testdaten rein, die wir haben. Das dauert jetzt einen Moment. In der Zwischenzeit schauen wir uns an, wie der Skill eigentlich aufgebaut ist und was das Besondere an einem Skill ist.

Das hier ist der Retouren-Skill, mit dem wir gerade arbeiten. Ein ganz normaler Ordner.

Ein Skill ist eigentlich ganz simpel aufgebaut. Oben stehen Name und Beschreibung, die werden immer in den Kontext geladen, rund 100 Tokens. Schauen wir uns die Beschreibung an: hier steht drin, was der Skill ist, welche Muster er erkennen soll, und ganz wichtig, welche Trigger er kennen muss, damit Claude weiß, wann er ihn überhaupt laden soll. Das ist keine Marketing-Zusammenfassung, das ist extrem gezielt geschrieben, weil es Claude nichts bringt, wenn da Marketing-Text steht statt echter Auslösebedingungen.

Darunter die eigentliche Anleitung, vier Phasen: Daten mappen, rechnen, interpretieren und berichten, Dashboard erzeugen. Das lädt, sobald der Skill triggert, unter 5.000 Tokens, selbst bei so einem inhaltlich vollen Skill wie diesem hier. Da drin stehen nicht nur die Schritte, sondern auch die Guardrails und alles, was Claude braucht, um die Aufgabe reproduzierbar und nach denselben Routinen durchzuführen, jedes Mal gleich, nicht mal so und mal so.

Und daneben liegt mehr: ein Ordner reference mit der kompletten Fachrecherche zu Retouren. Da steckt der eigentliche Wert drin, deshalb kurz, was da wirklich passiert ist.

Drin steht, was gemessen wirkt, aus echten A/B-Tests von Zalando und aus einem Feldtest, an dem OTTO beteiligt war. Dann, was nachweislich nicht wirkt, obwohl es überall empfohlen wird. Dazu Branchen-Baselines von bevh und EHI, damit man die eigenen Zahlen überhaupt einordnen kann. Und ein eigener Abschnitt nur mit Zahlen, die in Blogs und Verkaufsunterlagen kursieren und keiner Prüfung standgehalten haben.

Jeder Befund trägt eine Belegstufe, also wie gut er wirklich bewiesen ist. Und genau daraus zieht der Skill später seine Maßnahmen. Deshalb steht im Report am Ende nicht, was plausibel klingt, sondern was gemessen wurde.

Die 177 Zeilen werden dabei nicht automatisch geladen, die liest Claude erst, wenn er sie für die Maßnahmen wirklich braucht. Genau deshalb liegt das in einer eigenen Datei und nicht mit in der SKILL.md: die soll klein bleiben, unter 500 Zeilen empfiehlt Anthropic selbst, alles Schwere wandert daneben.

Und hier die harte Regel dahinter, bevor man sowas selbst baut: eine Datei darf nur auf eine weitere verweisen, nicht durch drei Ebenen verschachtelt sein. Sonst liest das Modell nur noch quer drüber, statt wirklich alles mitzunehmen.

Rechnen wir kurz zusammen: der ganze Ordner hier ist rund 1,3 Megabyte groß. Permanent im Kontext, ständig geladen, sind davon genau zwei Zeilen.

Und dieser Skill hier ist ja nicht der einzige, den ich hab. Schaut mal, so viele hab ich insgesamt installiert. Von jedem einzelnen davon liegt genau das, was wir gerade gesehen haben, dauerhaft im Kontext, Name und Beschreibung. Anders wüsste Claude ja gar nicht, welcher gerade passt.

Und da kommt die Frage, die mir am häufigsten gestellt wird: füllt das nicht euren Kontext zu, wenn ihr so viele Skills installiert habt? Berechtigte Frage.

Der Kontext ist der ganze Inhalt, den Claude in einem Gespräch aufnehmen und verarbeiten kann, quasi das Kurzzeitgedächtnis. Und der ist begrenzt. Wird er zu voll, komprimiert Claude ihn automatisch, und dabei können die Ergebnisse spürbar schlechter werden. Deshalb ist die Frage berechtigt.

Die gute Nachricht: die Anleitungen selbst füllen den Kontext nicht. Nur Name und Beschreibung sind dauerhaft geladen, so wie ihr's gerade gesehen habt. Erst wenn eine Aufgabe wirklich zu einem Skill passt, liest sich Claude die ganze Anleitung durch.

Heißt aber auch: dieser Zweizeiler wird bei jedem installierten Skill geladen, immer, jede Session. Eine Handvoll Skills mehr kostet euch praktisch nichts. Habt ihr aber hunderte installiert, summiert sich das. Auch hier gilt also: kuratiert schlägt vollgestopft.

Und genau deshalb ist diese kurze Beschreibung das Wichtigste am ganzen Skill, wichtiger als die Anleitung dahinter. Die entscheidet nämlich, ob Claude den Skill zieht oder nicht. Ist die schwammig, feuert der Skill nie, egal wie gut der Rest geschrieben ist.

Und da ist er auch schon fertig. Oben seht ihr vier Kacheln, die gehe ich kurz der Reihe nach durch.

Die erste ist die Retourenquote, die kennt ihr wahrscheinlich schon aus eurem eigenen Shop-System: wie viel Prozent der versendeten Artikel wieder zurückkommen. Vierzehn Komma eins Prozent, 1.159 von 8.214 Artikeln, also ungefähr jeder siebte verschickte Artikel.

Die zweite ist die Retourenquote nach Wert, mit fünfzehn Komma acht Prozent etwas höher. Die zählt nicht Stück, sondern Euro, und da wird's interessant: rechnet man das runter, kommt ein zurückgeschickter Artikel im Schnitt auf 70,99 Euro, ein versendeter Artikel im Schnitt nur auf 63,89 Euro. Die zurückgeschickten Artikel sind also gut elf Prozent teurer als der Durchschnitt im Sortiment. Das sieht man nur, wenn man nach Wert statt nach Stück rechnet.

Die dritte ist Bestellungen mit Retoure, zwanzig Komma sechs Prozent, 1.069 von 5.200 Bestellungen betroffen. Und ja, das wirkt erstmal komisch, denn absolut kamen mehr Artikel zurück als Bestellungen betroffen waren, 1.159 gegenüber 1.069. Der Grund liegt nicht oben in der Zahl, sondern unten in der Basis. Die Artikelquote rechnet gegen 8.214 Artikel, die Bestellquote nur gegen 5.200 Bestellungen. Und weil im Schnitt anderthalb Artikel in einer Bestellung stecken, reicht schon ein einziger zurückgeschickter Artikel, damit die ganze Bestellung als mit Retoure mitzählt. Deshalb kippt die Prozentzahl, obwohl die absolute Zahl kleiner ist.

Und die vierte, die spannendste, ist Rohertrag nach Retouren: 259.945 Euro. Rohertrag von 330.738 Euro minus 70.793 Euro Retourenkosten. Viele haben das an anderer Stelle schon feiner, als Deckungsbeitrag mit Versand und Marketing mit drin. Hier fehlt das noch, aber ihr habt auf einen Blick die Zahl, die zeigt, was von einer Bestellung nach allen Retouren tatsächlich übrig bleibt.

Ein Vorbehalt zu allen vier Zahlen, bevor's weitergeht: sie fassen den ganzen Zeitraum von Januar bis Juni zusammen, und drei von diesen sechs Monaten sind noch nicht vollständig gereift. Was das für die Quote bedeutet, zeige ich euch gleich am Verlauf.

Darunter die Rechnung dazu, Zeile für Zeile nachvollziehbar: vom Umsatz der versendeten Ware, über den Rohertrag vor Retouren, minus die Retourenkosten, bis zum Rohertrag nach Retouren, den knapp 260.000 Euro von vorhin.

Und jetzt zum stärksten Finding im ganzen Report. Retourenquote je Bestellmonat, und wichtig: nur abgeschlossene Monate sind wirklich vergleichbar. Ein Monat gilt erst als abgeschlossen, wenn das Rückgabefenster für alle Bestellungen daraus vorbei ist. Die abgeschlossenen Monate liegen im Schnitt bei 15,8 Prozent. Der jüngste Monat zeigt nur 7,4. Sieht nach Erfolg aus, oder? Ist es nicht. Retouren kommen später als die Bestellung, und sie werden trotzdem dem Bestellmonat zugerechnet, nicht dem Monat, in dem sie zurückkommen, genau damit der Vergleich fair bleibt. Würde man stattdessen den aktuellsten Monat einfach so nehmen, sähe das aus wie ein Erfolg, dabei ist einfach nur die Zeit noch nicht um. Deshalb die gestrichelte Linie bei den jüngsten Monaten, hochgerechnet, mit der Angabe, wie viel Prozent der erwarteten Retouren schon da sind. Und selbst die nehm ich beim jüngsten Monat nur mit Vorsicht, bei 58 Prozent ist da noch viel Luft nach oben.

Die Befunde sind nach Geldwert sortiert, der teuerste zuerst. Ganz oben: Hoodie Classic fällt klein aus. Hundertzwanzig größenbedingte Retouren, 12.238 Euro Retourenkosten für diesen einen Artikel, der teuerste Befund im ganzen Report.

Der Chart hier zeigt keine Prozente, sondern echte Stückzahlen je Größe: dreißig bei L, fünfundzwanzig bei M, je zweiundzwanzig bei S und XL, fünfzehn bei XS. Und das Muster zieht sich durch alle Größen, nicht nur eine. Hundertvierzehn Retouren mit dem Grund zu klein, nur sechs mit zu groß. Das ist kein Streuungsmuster, das ist ein Schnittfehler im Artikel selbst.

Die Maßnahme ist entsprechend konkret: ein Hinweis direkt an der Größenauswahl, fällt klein aus, eine Nummer größer nehmen, nicht irgendwo versteckt in der Größentabelle. Den Artikel nachmessen und die echten Maße eintragen, nicht die Herstellerangabe übernehmen. Bei durchgehender Abweichung die Gradierung mit dem Lieferanten klären. Und Größenberater-Software kommt zuletzt, die ist nach der Datenlage eher ein Conversion-Werkzeug als ein Retouren-Werkzeug.

Und ein Gegencheck ist gleich eingebaut: die Zahl der Mehrgrößen-Bestellungen darf dabei nicht steigen. Bei Zalando ist sie durch genau so einen Hinweis um elf Prozent gestiegen. Steigt sie stärker, als die Quote fällt, hat die Maßnahme unterm Strich nichts gebracht.

Und dann ein ganz anderer Fall, direkt im nächsten Befund: der Zip-Hoodie Heavy. Fünf Varianten, alle mit einer Quote zwischen 11,9 und 16,9 Prozent, völlig im normalen Bereich für Fashion. Zusammen kosten sie trotzdem 10.622 Euro Retourenkosten, fast so viel wie der Größenfehler eben.

Warum? Weil die Quote nichts über den Geldbetrag sagt. Der Zip-Hoodie ist ein Bestseller mit hohem Volumen, und genau deshalb kostet hier ein ganz normaler Prozentsatz absolut mehr als ein Ausreißer bei einem Nischenartikel. Ein Report, der nach Quote sortiert, zeigt diesen Artikel nie: ein Bestseller mit durchschnittlicher Quote taucht in so einem Ranking gar nicht erst auf.

Die Maßnahme ist deshalb auch nicht, die Quote senken zu wollen, sondern die absoluten Kosten. Ein Prozentpunkt weniger ist hier mehr wert als zehn bei einem Nischenartikel. Also erst die Retourengründe dieses Artikels ansehen: steckt da ein echtes Muster dahinter, oder ist das einfach der normale Branchenpegel für Fashion? Ist es der normale Pegel, gehört der Artikel in die laufende Kostenrechnung, nicht auf die Maßnahmenliste.

Und falls die Frage kommt, was in diesen Retourenkosten überhaupt steckt: keine Produktionskosten, sondern die entgangene Marge der zurückgeschickten Stücke, dazu die Bearbeitung je Vorgang und abgeschriebene Defektware. Die Ware selbst geht ja zurück ins Lager, verloren ist nur die Marge darauf.

Im Report stecken noch zwei weitere Befunde, nie abgeholte Sendungen und ein Qualitäts-Ausschlag bei den Sneaker Socken, dazu die Retourengründe insgesamt, jeder Artikel einzeln und ein Glossar mit allen drei Retourenquoten zum Nachschlagen. Die zeig ich jetzt nicht mehr einzeln, dafür reicht die Zeit nicht, aber ihr seht: alles ist da, zum Selbernachschauen.

Jetzt die eigentlich wichtigste Frage: wie ist der hier überhaupt entstanden? Ehrlich: ich hab ihn nicht heute gebaut, ich bau ihn euch jetzt auch nicht neu, das würde ewig dauern und wäre am Ende unehrlich vorgeführt. Ich zeig euch den echten Weg.

Kurz zur Einordnung, bevor ich zeige, wie ich vorgehe. Es gibt drei Wege, mit Claude zu arbeiten. Im Chat, ganz normal, so wie ihr es kennt. In Cowork, da arbeitet Claude selbstständig an euren Dateien. Und in Claude Code, das läuft direkt auf eurem Rechner.

Ich arbeite zu 99 Prozent in Claude Code, aus zwei Gründen. Cowork läuft in einer abgeschotteten Umgebung, Claude Code kommt direkt an alles ran, was ich brauche. Und ein Skill ist für mich sowieso ein kleines Softwareprojekt, das am Ende auf GitHub landet, also in einer Ablage für Code, in der jede Änderung nachvollziehbar bleibt.

Bauen könnt ihr einen Skill in allen dreien. Ich zeig euch meinen Weg.

Die meisten, wenn sie einen Skill bauen, machen zwei Schritte: Workflow erkennen, dann bau mir dafür einen Skill. Fertig. Genau das ist der Fehler.

Ich bin anders rangegangen, in acht Schritten.

Erst eine Session aufmachen und alles erzählen, was ich vorhab. Nicht mit einer Anweisung starten, sondern mit dem Vorhaben.

Dann alles reingeben, was ich weiß, am besten diktiert statt getippt. Beim Reden gibt man deutlich mehr Kontext raus als beim Tippen, und genau der Kontext entscheidet über die Qualität.

Dann lasse ich recherchieren: Gibt es das schon? Wenn es etwas Gutes gibt, nehme ich lieber das, statt selbst zu bauen. Sterne auf GitHub sind dabei ein erster Indikator, mehr aber auch nicht. Der Stern hängt nämlich meistens an einer ganzen Sammlung und nicht an dem einen Skill, den ich brauche. Zwei Sammlungen, die bei meiner Suche oben standen, haben zusammen fast 3.000 Sterne. Und wenn man nachschaut, wer da eigentlich mitgebaut hat, sind es zwei Leute.

Deshalb gucke ich danach wirklich rein. Sagt mir das Framework selbst wenig, weil es zum Beispiel gar nichts mit E-Commerce zu tun hat, lasse ich mir trotzdem genau den Skill, um den es mir geht, nochmal einzeln analysieren, bevor ich ihn einsetze. Steckt da überhaupt etwas drin, das rechnet, oder ist es nur Text? Wer pflegt das?

Beim Retouren-Thema war die Antwort eindeutig: Was es gab, war im Grunde ein Gesprächsleitfaden, der mich nach meiner Retourenquote fragt und dann aus dem Bauch antwortet. Kein einziger Skill, der wirklich einen Export einliest und rechnet. Also habe ich ihn selbst gebaut.

Und dann: was weiß die Welt eigentlich schon über das Thema? Ich sag dann: nimm dir wirklich Zeit, recherchier nach Analysen, nach Studien, nach Tests mit wirklich relevanten Quellen, und hol mir alles dazu.

Aus alldem lasse ich dann eine erste Version aufbauen, aber ausdrücklich noch nicht als Skill. Dann gebe ich zum Beispiel einen Datensatz rein und lasse mir das Ergebnis wirklich ausspielen.

Dann prüfe ich das Ergebnis. Wo passt etwas nicht genau zu dem, was ich mir vorgestellt habe, wo ist vielleicht etwas falsch berechnet. Ich kontrolliere das wirklich, und dann iteriere ich weiter: ausspielen lassen, prüfen, ausspielen lassen, prüfen, so lange, bis ich sage, jetzt passt das Ergebnis wirklich.

Und genau hier liegt auch der Grund, warum dieses Prüfen kein unnötiger Zwischenschritt ist: ein Modell wie Claude oder ChatGPT weiß nicht von allein, was für euch ein gutes Ergebnis ist, das legt jeder für sich selbst fest. Sagt ihr das nicht, liefert das Modell trotzdem was, nur eben das, was es selbst für plausibel hält. Dann seid ihr am Ende enttäuscht und denkt, das Tool funktioniert nicht. Dabei hat's nur ein anderes Ziel verfolgt als das, was ihr im Kopf hattet.

Erst wenn das Ergebnis wirklich sitzt, sage ich: jetzt baue mir daraus einen Skill. Ganz konkret nutze ich dafür den Skill-Creator, ich sage einfach: nimm den Skill-Creator-Skill und bau mir daraus einen Skill. Dann habe ich schon eine richtig starke erste Version, mit einem richtig guten Ergebnis, die sich sofort einsetzen lässt.

Beim Retouren-Thema war das extrem wichtig, weil's da schon jede Menge Erkenntnisse gibt: wie Retouren vermieden werden können, wie sie reduziert werden können, wie man den Shop optimiert, damit weniger zurückkommt.

Und dabei kam einiges raus, das vorher plausibel klang und sich als falsch rausgestellt hat. Größenberater-Software zum Beispiel, klingt logisch, dass die Retouren senkt, tut sie aber nicht, das zeigt Zalandos eigener A/B-Test. Oder die Idee, Rechnungskauf einfach abzuschalten, weil der die höchste Retourenquote hat: bringt nichts, die Zahlart zieht das Verhalten nur an, sie erzeugt es nicht. Ohne diese Recherche wären zwei falsche Empfehlungen im Skill gelandet.

Aber auch danach ist nicht Schluss. Ist der Skill im Einsatz, prüfe ich weiter, was dabei rauskommt, und passe ihn an, wenn etwas nicht passt oder ich ihn erweitern will. Gerade bei so einem Fall kommen ja ständig neue Informationen dazu, neue Muster, die man in den Daten findet. Die fließen dann wieder mit ein, und der Skill wird immer weiter optimiert.

Der Wert steckt eben nicht im Schreiben der Datei, sondern in dem, was vorher passiert. Das Tippen der Datei übernimmt am Ende Claude.

Damit habt ihr gesehen, was ein Skill ist, wie er aufgebaut ist, wie er läuft, und wie er wirklich entstanden ist, nicht nur behauptet. Den gibt es jetzt zum Mitnehmen. Ladet ihn euch runter, testet ihn an euren eigenen Daten.

Und damit gebe ich zurück an Jörg für eure Fragen.