[30388f42] Infrastructure Hardening: Repaired CE/Connector DB schema, fixed frontend styling build, implemented robust echo shield in worker v2.1.1, and integrated Lead Engine into gateway.
This commit is contained in:
247
docs/30_tage_gespraech_axel.txt
Normal file
247
docs/30_tage_gespraech_axel.txt
Normal file
@@ -0,0 +1,247 @@
|
||||
[00:00:01] Axel: Erstmal fragen, wie es dir denn so bei uns geht?
|
||||
[00:00:05] Christian: Passt.
|
||||
[00:00:06] Christian: Also ich ich komme ganz gut klar, ich habe habe ja mein mein Projekt mein mein Projekt und bin jetzt auch schon ziemlich weit fortgeschritten. das ist so ein bisschen diese Maschine, wo ich sag, dass ich erst noch zum Laufen bringen muss.
|
||||
[00:00:21] Christian: Ähm das ist jetzt schon relativ weit fortgeschritten.
|
||||
[00:00:26] Christian: Also ich glaube, dass wir da so in ein, zwei Wochen spätestens werden wir damit produktiv starten können.
|
||||
[00:00:34] Christian: Ähm das war ja so immer das, was ich mir vorgenommen hatte, dass das im ersten Monat grob zu erreichen und das ist denke ich jetzt.
|
||||
[00:00:40] Axel: Ja, ist doch super.
|
||||
[00:00:40] Christian: schon relativ weit fortgeschritten.
|
||||
[00:00:43] Axel: So, fühlst du dich dann generell so wohl im im Team, kriegst du überhaupt vom Team was mit?
|
||||
[00:00:51] Christian: Ja, äh schon, also ich glaube, ich sitze schon ganz gut im Zimmer mit mit Ibrahim, äh mit und äh kriegt man so die die Schnittmenge ähm an Kommunikation und manchmal vielleicht Probleme mit die so bei bei Kunden aktuell auftreten, das ist schon ganz gut, um da so ein bisschen reinzukommen.
|
||||
[00:01:16] Christian: Ähm habe mich vorhin auch mit der E, der war jetzt lange krank, hatte ich mich jetzt erstmal ausgetauscht, dass wir da auch so einen kleinen Start hatten.
|
||||
[00:01:26] Christian: Ähm ansonsten mit Julia sowieso, das das es klappt, es ist halt alles äh bisschen zeitlich schwierig manche Leute zu erreichen, vor allem den Alex, das ist ich glaube, dem muss man einfach Knüppel in die Beine werfen, um ihn mal zu kriegen.
|
||||
[00:01:45] Christian: Das das ist dort schwierig.
|
||||
[00:01:46] Axel: Ist die Frage, ob das hilft.
|
||||
[00:01:53] Axel: Ist die Frage, ob das hilft, ja.
|
||||
[00:01:54] Christian: Es ist halt ja, also wir hatten ja.
|
||||
[00:01:56] Axel: Aber du brauchst halt seinen Input.
|
||||
[00:01:58] Axel: Wir haben jetzt heute 17 Uhr, glaube ich, Meeting, oder?
|
||||
[00:02:00] Christian: Richtig, ja, ja.
|
||||
[00:02:02] Christian: Ja, für einige Sachen brauch schon sein Input, weil das ja äh jetzt gerade auch mit diesen Verticals äh die wir da definiert hatten, ähm das ist das Fundament und wenn da irgendwas schief ist, dann ähm passt das nachher alles nicht, ne?
|
||||
[00:02:22] Axel: Genau.
|
||||
[00:02:23] Axel: Also ich hoffe mal, dass das alles so ein bisschen besser wird, wenn wir da unten zusammen sitzen alle.
|
||||
[00:02:29] Christian: Mhm.
|
||||
[00:02:31] Axel: So, deswegen wird der Alex auch nicht mehr verfügbar sein, aber ähm dann sitzen ja zumindest die die Ellie da auch mit, äh dann hast du auch gegebenfalls die Möglichkeit äh dich irgendwo in Ruhe hinzusetzen.
|
||||
[00:02:52] Axel: Also, da werden wir ja einige Möglichkeiten haben und wir sind auf demselben Gang wie das Marketing auch, also sehr viel besser kann es eigentlich gar nicht gehen.
|
||||
[00:02:59] Christian: Richtig, ja.
|
||||
[00:03:02] Christian: Nee, also grundsätzlich, äh ich ich denke, ich kriege das mit, was ich mitkriegen muss.
|
||||
[00:03:07] Christian: Äh bin jetzt noch nicht super super tief in allen Sachen drin, aber habe überall mal so ein bisschen gegen geklopft.
|
||||
[00:03:15] Christian: Und äh du bist jetzt, was weiß ich, mal gerade vier Wochen da.
|
||||
[00:03:19] Christian: Äh Jetzt jetzt habe ich mich hier Gehst du durch oder bist du hier?
|
||||
[00:03:23] Speaker C: Ich gehe durch.
|
||||
[00:03:23] Christian: Okay.
|
||||
[00:03:23] Speaker C: Entschuldigung.
|
||||
[00:03:24] Christian: Ja, ja, klar.
|
||||
[00:03:24] Speaker C: Ich hab das einfach mal gerade gemacht, weil ich das gewohnt bin, aber.
|
||||
[00:03:27] Christian: Kein Thema.
|
||||
[00:03:30] Speaker C: Ähm schöne Grüße an die Lia.
|
||||
[00:03:33] Christian: Ah, okay.
|
||||
[00:03:33] Speaker C: von der Stimme her zumindest.
|
||||
[00:03:39] Speaker C: Ähm Genau, es ist der Alex ja eigentlich auch dein Pate, oder?
|
||||
[00:03:44] Christian: Offiziell ja.
|
||||
[00:03:48] Speaker C: Eigentlich ist es Quatsch, glaube ich, aber weil er kaum Zeit hat.
|
||||
[00:03:56] Speaker C: Ähm Egal.
|
||||
[00:03:58] Speaker C: Also so, jetzt erstmal ich bin total glücklich, dass wir dich haben.
|
||||
[00:04:07] Christian: Ich ich glaube, dir wird langsam bewusst, was du was was ihr kriegt mit mir.
|
||||
[00:04:12] Christian: Also das das war glaube ich am Anfang noch nicht ganz so klar, ähm.
|
||||
[00:04:17] Axel: Äh Aber das das siegert.
|
||||
[00:04:19] Axel: Die Erwartungshaltung war da.
|
||||
[00:04:22] Axel: Sagen wir es mal so.
|
||||
[00:04:24] Axel: Eine nach dem ersten Gespräch, dass wir da hatten.
|
||||
[00:04:28] Christian: Mhm.
|
||||
[00:04:29] Axel: Ähm war mir das schon klar, dass es in die Richtung gehen kann, dass es so schnell geht, hätte ich nicht gedacht.
|
||||
[00:04:42] Axel: Und dass wir mit deiner Expertise und deinem Engagement jetzt letztendlich in in Bereiche reinkommen können, von denen ich immer geträumt habe.
|
||||
[00:04:56] Axel: Und ähm das ist für uns ja bei der Oberplanet total wichtig, da müssen wir uns, jetzt müssen wir erstmal so die dringendsten Aufgaben wegschaufeln, aber da müssen wir uns dann auch anschauen, was sind denn Projekte, wo du mit rein kommst, die uns den die uns den den wirklich größten Mehrwert mitbringen, weil da sehe ich letztendlich relativ viele Sachen, wo wir mit AI Agents Sachen machen können.
|
||||
[00:05:24] Axel: Und da freue ich mich total drauf.
|
||||
[00:05:25] Christian: Also ich ich habe ja gestern das ich weiß nicht, ob der Termin nachher in diese Richtung geht.
|
||||
[00:05:30] Christian: Ich habe ja gestern das Trading Twins Thema ähm aufgearbeitet.
|
||||
[00:05:36] Christian: Das hatte ich der Ellie gerade schon ein bisschen gezeigt, was was ich ja jetzt gebaut habe, kann ich nachher dann mal kurz vortanzen.
|
||||
[00:05:43] Christian: Ähm das geht geht schon relativ weit, dass wir eben den Ansprechpartner versuchen zu identifizieren, also ob der über LinkedIn verfügbar ist, dass wir die Rolle ableiten, gucken, welche welche Texte wir ihm anschreiben und da geht dann schon eine Antwort raus, die relativ gut auf das trifft, was was wir eigentlich wollen.
|
||||
[00:06:06] Christian: Das können wir gleich uns mal gemeinsam anschauen.
|
||||
[00:06:09] Christian: Ähm aber das das ist halt äh grundsätzlich mein ähm Bestreben, dass wir alles was irgendwo automatisierbar ist, ähm sei es äh der Texterstellung, sei es im Thema Anschreiben, sei es auch was jetzt kommt Richtung Webshop, ähm dass wir da möglichst äh die Sachen, die eben ja, immer wiederholbare Klick Copy Paste und so weiter sind, ähm dass ich da irgendwo versuche zu helfen, diese Sachen soweit es geht zu automatisieren.
|
||||
[00:06:45] Axel: Gut.
|
||||
[00:06:46] Axel: Genau, jetzt sind wir schon mitten drin.
|
||||
[00:06:48] Axel: Schreibst du parallel in das Dokument noch mit rein oder wie machen wir das jetzt?
|
||||
[00:06:52] Christian: Also, ich habe ich habe mir ein bisschen was an an Zielen habe ich mir selbst vorformuliert, das hat jetzt nicht ganz in das Dokument reingefasst, kann ich hier gerne noch schicken.
|
||||
[00:07:00] Axel: Ach du, ja, schärst doch mal kurz.
|
||||
[00:07:03] Christian: Ähm kann ich gerne schären.
|
||||
[00:07:05] Christian: Ähm eine Sekunde.
|
||||
[00:07:08] Axel: Weil dann können wir das doch gleich finalisieren und dann äh unterschreiben wir das nächste Woche und äh weil ich erst nächste Woche wieder im Büro bin.
|
||||
[00:07:16] Christian: Ich habe jetzt hier dummerweise nur einen Bildschirm, aber dann dann das das äh halt, das ist das falsche.
|
||||
[00:07:22] Axel: Ja.
|
||||
[00:07:24] Christian: Äh So viele Fenster auf.
|
||||
[00:07:26] Christian: Too many Tabs, genau.
|
||||
[00:07:28] Christian: Äh ich habs aber gerade gesehen, Onboarding Gespräch.
|
||||
[00:07:33] Christian: Links zweites von oben.
|
||||
[00:07:36] Christian: Aber das ist das nicht.
|
||||
[00:07:38] Christian: Nee.
|
||||
[00:07:40] Christian: Doch.
|
||||
[00:07:41] Christian: Das wäre schon gewesen.
|
||||
[00:07:45] Christian: Das ist das Dokument, wo es rein muss, aber das ist nicht das, was ich vorbereitet hatte dafür.
|
||||
[00:07:51] Axel: Ach so.
|
||||
[00:07:53] Christian: Hatte ich das gespeichert?
|
||||
[00:07:55] Christian: Hatte ich nicht gespeichert.
|
||||
[00:07:57] Christian: Ach Gott, wie dumm ist das.
|
||||
[00:08:00] Christian: Ähm eine Sekunde, ich muss das schnell herüber kopieren.
|
||||
[00:08:05] Christian: Wo war denn das jetzt?
|
||||
[00:08:18] Christian: sind gleich da.
|
||||
[00:08:23] Axel: So, da haben wir es.
|
||||
[00:08:27] Christian: Äh kann ich das jetzt rüber kopieren?
|
||||
[00:08:31] Axel: Das ist zu ausführlich.
|
||||
[00:08:34] Christian: Ich weiß, dass es zu ausführlich ist, aber dann haben wir mal drüber gesprochen.
|
||||
[00:08:37] Christian: Ähm wir können das ja gerne ähm dann am Ende komprimieren.
|
||||
[00:08:44] Christian: Nur dass wir einmal drüber gesprochen haben.
|
||||
[00:08:47] Christian: Also mein mein erstes Ziel ist, dass die die Maschine, die ich jetzt gebaut habe, die fast fertig ist, äh dann auch produktiv genutzt wird in in spätestens drei Monaten, dass soweit ist.
|
||||
[00:08:58] Axel: Ja, Ziel eins würde ich einfach nur diese Überschrift rüber kopieren in diesem Blog.
|
||||
[00:09:03] Axel: Ziel eins Maschine aktivieren.
|
||||
[00:09:07] Axel: Und das andere hängen hängen wir für uns dann einfach als Erläuterung irgendwie mit dran, aber brauchen wir eigentlich da drin gar nicht.
|
||||
[00:09:13] Axel: Also, genau.
|
||||
[00:09:15] Axel: Super wäre es auch bei mir gewesen.
|
||||
[00:09:18] Christian: Genau.
|
||||
[00:09:19] Christian: Jetzt mache ich mal die Tür zu hier.
|
||||
[00:09:37] Christian: So.
|
||||
[00:09:38] Christian: Ähm was ich damit meine, äh also Stabilität und so weiter, dass die Schnittstelle zuverlässig funktioniert sowieso.
|
||||
[00:09:45] Christian: Ähm dass der Vertrieb das auch aufgenommen hat, ähm ob jetzt Ali Alex oder Ellie, ähm dass Alex Ellie.
|
||||
[00:09:57] Christian: Ähm wer auch immer das dann nutzt, wahrscheinlich eher die Ellie, dass sie das aus dem CRM System heraus benutzt.
|
||||
[00:10:04] Christian: Ähm technisch kriegen wir das hin.
|
||||
[00:10:07] Christian: Da sind noch zwei, drei Schritte zu gehen, insbesondere bezüglich Mailversand.
|
||||
[00:10:13] Christian: Ich bin da jetzt ähm die Frau Grillenberger hat mich jetzt an die Super Office verwiesen an den Fabio.
|
||||
[00:10:23] Christian: Ähm weil das für sie zu kompliziert ist, glaube ich.
|
||||
[00:10:29] Axel: Ähm Okay, ja, glaube ich auch gerne.
|
||||
[00:10:32] Christian: Genau, und dass wir ähm ja, mindestens 100 Kontakte äh über die Marketing Automation erreicht haben, ohne dass da eine manuelle Nachweiter nötig ist.
|
||||
[00:10:43] Axel: Okay.
|
||||
[00:10:44] Christian: Das ist mal so, das das das also das ist funktioniert ist schon ja, das das ist denke ich ähm alles passt, denke ich.
|
||||
[00:10:57] Axel: Gut, weiter.
|
||||
[00:11:00] Christian: Dann ähm dass wir auch quasi die erste Ente einfahren, dass äh wir auch Termine darüber generiert haben, dass wir mindestens äh zehn Ersttermine ähm über die Marketing Automation erreicht haben in drei Monaten.
|
||||
[00:11:18] Christian: Und äh mehr.
|
||||
[00:11:20] Christian: Ich sag mal mindestens zehn.
|
||||
[00:11:22] Christian: Ähm Wahrscheinlich pass mal auf.
|
||||
[00:11:26] Axel: Die Ziele für die die für die 100 Tage Ziele, das hat jetzt nichts zu tun mit ähm den Zielen, die wir für deinen Bonus noch.
|
||||
[00:11:35] Christian: Ja das das das äh hat damit gar nichts zu tun, das ist klar.
|
||||
[00:11:37] Christian: Nein, das Genau.
|
||||
[00:11:40] Axel: Also von daher, ich brauche das da nicht in Direkte Generierung von qualifizierten Vertriebschancen Klammer auf ist gleich äh qualifizierte Termine und das als Ziel mit rüber packen.
|
||||
[00:11:59] Axel: Bitte schön.
|
||||
[00:12:01] Christian: Wie jetzt genau?
|
||||
[00:12:02] Christian: Also den den Ja, erste erste Ente einfahren, direkte Generierung von qualifizierten Vertriebschancen, also das was du unter Ziel 2 stehen hast, Klammer auf ist gleich äh hochwertige Vertriebstermine.
|
||||
[00:12:25] Christian: Mhm.
|
||||
[00:12:26] Axel: So, einfach rüber.
|
||||
[00:12:29] Axel: Mehr Beschreibung brauchen wir da nicht.
|
||||
[00:12:32] Christian: Dann kopiere ich das gleich mal herüber.
|
||||
[00:12:37] Christian: So, das Ja, ich hatte eh schon angefangen hier rein zu kopieren.
|
||||
[00:12:41] Christian: Ich dachte mir nur, oh, das das ist ein bisschen dünn, aber ähm alles andere ist da zu ausführlich und dann.
|
||||
[00:12:48] Axel: Genau.
|
||||
[00:12:49] Axel: Geh mal weiter, was was hast du sonst noch an Zielen bei dir jetzt im Dokument?
|
||||
[00:12:53] Christian: Ja, eine Sekunde.
|
||||
[00:12:59] Christian: Ich habe noch den Webshop habe ich jetzt noch als äh Ziel.
|
||||
[00:13:03] Axel: Genau.
|
||||
[00:13:04] Axel: Webshop, ja, auch an Startenschütz vorbereiten und einen neuen Akquise Kanal erschließen, passt rüber.
|
||||
[00:13:14] Christian: Und ich habe noch eine Sache, Mhm. über die wir reden müssen.
|
||||
[00:13:20] Christian: Wobei dir wahrscheinlich der Alex noch nicht den Link zum Miroboard geschickt hat.
|
||||
[00:13:25] Christian: Hat er noch nicht.
|
||||
[00:13:27] Christian: Ich habe ich habe ihn schon angetickert, aber ähm ja.
|
||||
[00:13:32] Axel: Ja.
|
||||
[00:13:33] Axel: Also zwar, das wäre das Ziel 4 ist.
|
||||
[00:13:39] Axel: So, wir haben jetzt quasi über das, was der Alex vorgestellt hat, ist es ja quasi Strukturprozesse und Verantwortlichkeiten Knowledge Base.
|
||||
[00:13:50] Christian: Mhm.
|
||||
[00:13:52] Axel: So, und da geht's mir darum, dass du dir das anschaust und mal erste Tests machst, wie wir das automatisieren können oder wie wir das über Agents die tatsächlichen echten Dateien reinkriegen.
|
||||
[00:14:10] Axel: Also, wie wir dein Würzburg, wo ich ja so flapsigerweise gesagt habe, wenn wir diese Struktur haben und wie was abzulaufen hat, können wir das nicht einfach in irgendeine AI werfen und dann werfen wir unsere ganzen Dateien und Ordner mit rein und die kann da, was weiß ich, zu 75 % selber schon mal richtig zuordnen und sagen, was ist aktuell und was ist alt.
|
||||
[00:14:34] Axel: Versteht, also kannst du meinem Gedankengang folgen?
|
||||
[00:14:37] Christian: Ja, ja, das funktioniert dann, wenn das Ganze wenn wenn wir strukturierte Informationen zur Eingabe haben.
|
||||
[00:14:45] Christian: Wir haben ja gestern uns dieses Thema, wie wie schaut es denn Super Office aus angeschaut.
|
||||
[00:14:51] Christian: Ich habe das heute morgen auch noch mal versucht abzuklopfen.
|
||||
[00:14:55] Christian: Wir haben zwar die Produkte im Super Office als solche eingepflegt, das ist schon mal wertvoll, aber sie werden scheinbar nicht zeilenweise bei den Angeboten ähm eingetragen.
|
||||
[00:15:12] Christian: Ich muss das noch mal genau, das das wie gesagt, ich bin da noch nicht ganz durchgestiegen.
|
||||
[00:15:16] Christian: Ähm über die API habe ich das versucht zu ermitteln.
|
||||
[00:15:20] Christian: Ähm das ist mehrfach gescheitert.
|
||||
[00:15:23] Christian: Der Ibrahim hat mir dann gesagt, ja, schau dir das und das an und ähm das wäre schon so.
|
||||
[00:15:31] Christian: Äh muss ich noch mal genau abklopfen.
|
||||
[00:15:35] Christian: Ähm warum sage ich das, weil das natürlich ähm eine wesentliche Grundlage ist, ähm dass wir auch den Tickets, die von Kunde A kommen, ein Produkt zuweisen können, weil das ist ja essentiell wichtig, dass man mit du bist du bist schon viel zu weit.
|
||||
[00:15:51] Axel: Ja, alles auch gut.
|
||||
[00:15:54] Axel: Äh aber jetzt in der ersten Phase, das was der Alex vorgestellt hat, ging ja um die ganzen Dateien, die wir wie auch immer auf unseren Servern stehen haben.
|
||||
[00:16:04] Christian: Mhm.
|
||||
[00:16:05] Axel: Und da hat er eine Struktur dazu im Miroboard aufgezeigt und äh entsprechend dann noch ähm Prozesse, glaube ich, mit dazu, wer sich um was kümmern muss und wir sollten dann schauen, dass wir diese Struktur auf unserem Server, wie auch immer abbilden und den Prozess gestalten, wie wir die aktuellsten Dateien immer dort drinnen haben.
|
||||
[00:16:30] Christian: Mhm.
|
||||
[00:16:31] Axel: So, ich spreche noch nicht darüber eine Automatisierung, jetzt kommt eine Anfrage oder ein Ticket rein.
|
||||
[00:16:36] Axel: Das ist der nächste Step.
|
||||
[00:16:39] Christian: Mhm.
|
||||
[00:16:42] Christian: Okay, nehme ich mal als Ziel auf, auch wenn das jetzt momentan für mich, wie gesagt, ich kenne das Miroboard, ich habe es in Würzburg zwar gesehen, aber ich habe es jetzt nicht mehr äh so vor Auge, dass ich das jetzt zuordnen könnte.
|
||||
[00:16:55] Axel: Frag auch mal den Ibrahim, ob er da Zugang hat zu diesem Miroboard.
|
||||
[00:16:59] Christian: Mhm.
|
||||
[00:17:01] Axel: Vielleicht geht's ja schneller.
|
||||
[00:17:03] Christian: Das kriegen wir hin.
|
||||
[00:17:05] Axel: Und das wären eine vier Hauptziele 100 Tage, das ist eh in zwei Monaten schon vorbei.
|
||||
[00:17:12] Christian: Das ist sportlich, ja.
|
||||
[00:17:14] Christian: Also gerade auch mit dem Webshop, ähm ich weiß nicht.
|
||||
[00:17:16] Axel: aktivieren, bist du relativ weit.
|
||||
[00:17:18] Axel: Ich glaube, die Ente einfahren kommt mit dem Training dann immer mehr von selber wahrscheinlich.
|
||||
[00:17:24] Christian: Ja.
|
||||
[00:17:25] Axel: Webshop haben wir jetzt Mitte März den Termin.
|
||||
[00:17:29] Axel: Ja, genau.
|
||||
[00:17:30] Christian: Das das kann schon so ein so ein Roadblocker sein, weil ich weiß nicht, welche Qualität wir haben, welche wie die Listen ausschauen, wie die Bilder ausschauen und so weiter, die dann dazu kommen.
|
||||
[00:17:41] Axel: Ja ja, ja ja, ich weiß.
|
||||
[00:17:42] Christian: Ähm Ich habe jetzt diese eine Liste, die die äh glaube ich rumgeschickt hat.
|
||||
[00:17:49] Christian: Ja, wenn wenn das Format bei allen Herstellern, bei allen Produkten so ist, dann dann ist es leicht, aber wahrscheinlich wird es nicht so sein, sondern da hat jeder Hersteller dann wieder drei andere Formate oder äh vielleicht auch für jedes Produkt ein eigenes Format.
|
||||
[00:18:01] Axel: Aber einfach nicht gleich in im riesengroßen Szenario denken, sondern wenn wir einen Hersteller haben, wo wir äh das schön strukturiert haben, dann fangen wir halt mit dem an.
|
||||
[00:18:14] Axel: Dann sind halt erstmal nur die Pudo Sachen drin.
|
||||
[00:18:16] Christian: Ja, ja, aber wie gesagt, ich will nicht, dass dass jemand da eine Woche lang irgendwas copy pasten muss, sondern das wird dann hoffentlich per API funktionieren.
|
||||
[00:18:26] Christian: Ähm Aber wie gesagt, ich habe noch nicht gesehen, welche Shop Plattform wir benutzen werden, ähm ob es da auch noch nicht.
|
||||
[00:18:33] Christian: Deswegen ja, das das ist alles noch sehr luftig.
|
||||
[00:18:37] Christian: Ich werde äh versuchen danach nach Kräften zu unterstützen und das auch zu automatisieren, wo es möglich ist.
|
||||
[00:18:46] Axel: Mhm.
|
||||
[00:18:49] Axel: Gut.
|
||||
[00:18:51] Axel: Das wären eigentlich die vier Sachen.
|
||||
[00:18:56] Axel: Brauchst du unterstützende Maßnahmen?
|
||||
[00:19:01] Axel: Ich wüsste jetzt erstmal nicht, was.
|
||||
[00:19:04] Christian: Nee, also ein bisschen mehr Airtime mit mit Alex, aber ähm das ist schwierig.
|
||||
[00:19:12] Christian: Aber weißt du, ansonsten baue ich es halt an an ihm vorbei äh und dann fällt es uns irgendwann auf die Füße, weil er sagt, ja, wie kommst du denn auf die Idee und ich brauche halt den den den Reality Check, weil ich halt das das Ganze jetzt aus meiner meine Theorie nur bauen kann.
|
||||
[00:19:29] Axel: Mhm.
|
||||
[00:19:30] Axel: Und äh verstehe ich schon, alles klar.
|
||||
[00:19:33] Axel: Vielleicht sprechen wir es heute dann einfach im Meeting mit ihm auch noch mal direkt an.
|
||||
[00:19:37] Christian: Mhm.
|
||||
[00:19:39] Axel: Genau.
|
||||
[00:19:42] Axel: Gut.
|
||||
[00:19:45] Axel: Das sind doch schon mal schöne Ziele.
|
||||
[00:19:48] Christian: Ja, das das ist sportlich, aber das ist machbar.
|
||||
[00:19:51] Axel: Ich glaube, selten so konkret und äh schon so an operativen Sachen.
|
||||
[00:19:58] Axel: Also ich finde es echt faszinierend, wie wie schnell du produktiv werden kannst hier.
|
||||
[00:20:06] Christian: Na ja.
|
||||
[00:20:07] Axel: Echt, also Ja.
|
||||
[00:20:10] Axel: Also ist schon Highlight.
|
||||
[00:20:14] Axel: Hut ab.
|
||||
[00:20:17] Christian: Ja, wir sind ja da zum Arbeiten.
|
||||
[00:20:22] Axel: Ja.
|
||||
[00:20:23] Axel: Ja, ja.
|
||||
[00:20:25] Christian: Ich ich habe das ähm nur nur noch mal ganz ganz kurz nebenbei, ich ich dokumentiere die die ganzen Projektarbeiten auch für mich selbst im in meinem Notion, ähm wo meine ganzen Dokumente drin sind, wo ich auch die äh Dokumentation größtenteils mache.
|
||||
[00:20:47] Christian: Also bzw. ähm ich weiß nicht, ob ich es dir schon gesagt hatte, wahrscheinlich nicht, ähm dass ich hier im Prinzip auch einen Überblick habe, äh was mich wie viel Zeit in der Entwicklung kostet.
|
||||
[00:21:00] Christian: Also das äh kann ich hier ähm bei den Tasks notiere ich mir das immer mit, was wie viel Zeit kostet.
|
||||
[00:21:07] Christian: Jetzt aktuell natürlich der die die Schnittstelle war, der massive Zeitfresser mit 41 Stunden.
|
||||
[00:21:15] Axel: Ja.
|
||||
[00:21:16] Christian: Ähm aber das hilft mir selbst auch ein bisschen dann Überblick zu behalten, ähm wo wir wir stehen, was wie viel Zeit kostet.
|
||||
[00:21:24] Christian: Ähm und was für Schritte da äh jeweils nötig sind.
|
||||
[00:21:29] Christian: Also es ist schon relativ ähm ordentlich dann auch dokumentiert, was äh was wo eingelaufen ist, ähm bisschen zu dass wir dass man hier eben einzelne Arbeitssessions dann sieht, was genau passiert ist.
|
||||
[00:21:46] Christian: Ähm welche E-Mails hin und her gelaufen sind, ähm hilft mir eben auch, dass das Ganze ein bisschen im Überblick zu halten und weil ich eben mit der KI da zusammenarbeite, ähm ist das immer so, wenn ich äh Tasks starte, dass ich ihr diese ganzen Dokumente automatisch mit reinlade, ähm damit er schon Bescheid weiß, was Sache ist und ich nicht bei Adam und Eva jedes Mal anfangen muss.
|
||||
[00:22:12] Axel: Ja, super.
|
||||
[00:22:13] Christian: Aber das das ist meine persönliche Arbeitsweise, ähm hilft mir eben da den den Überblick ein bisschen zu behalten und das Ganze strukturiert zu zu zu ja, durchzuführen.
|
||||
[00:22:25] Axel: Mhm.
|
||||
[00:22:26] Axel: Wow, cool.
|
||||
[00:22:31] Christian: Nee, ja, ansonsten, ich weiß nicht, haben wir noch haben wir jetzt eine Stunde Zeit.
|
||||
[00:22:36] Christian: Kann ich hier noch den den Trading Twin Move zeigen, wenn du willst, aber das können wir uns auch nachher anschauen.
|
||||
[00:22:41] Axel: Aber das das genau, machen wir das dann um 17 Uhr.
|
||||
[00:22:44] Axel: Du, wenn wir eine halbe Stunde Zeit sparen, sparen wir uns eine halbe Stunde Zeit.
|
||||
[00:22:47] Axel: Ich glaube, wir haben alle genügend zu tun.
|
||||
[00:22:49] Christian: Ja, das das auf jeden Fall.
|
||||
[00:22:52] Axel: Gut, also wie gesagt, ich bin sehr sehr glücklich mit deiner Arbeit.
|
||||
[00:22:56] Christian: Okay, das das höre ich gerne.
|
||||
[00:23:03] Axel: Genau.
|
||||
[00:23:04] Axel: Cool.
|
||||
[00:23:05] Christian: Okay.
|
||||
[00:23:06] Axel: So dann.
|
||||
[00:23:07] Axel: Alles Kinder.
|
||||
[00:23:08] Axel: Füllst du das noch genau, füllst du das unten noch aus und nächste Woche Montag unterschreibe ich es einfach mit.
|
||||
[00:23:14] Christian: Alles klar, machen wir das.
|
||||
[00:23:16] Axel: Genau.
|
||||
[00:23:17] Axel: Also Okay.
|
||||
[00:23:18] Axel: Dann sind wir da.
|
||||
[00:23:19] Axel: Vielen Dank.
|
||||
[00:23:20] Axel: Ciao.
|
||||
[00:23:21] Axel: Ciao.
|
||||
437
docs/ANALYSIS_AND_PROPOSAL.md
Normal file
437
docs/ANALYSIS_AND_PROPOSAL.md
Normal file
@@ -0,0 +1,437 @@
|
||||
# Deep-Dive Analyse: Pains & Gains vs. Product Reality
|
||||
**Status:** Warten auf Freigabe (Phase 2) / Umgesetzt (Phase 1)
|
||||
**Basis:** Transkript (`transkript_verticals1.txt`) + Notion Ist-Stand + Logik-Check "Product Fit"
|
||||
|
||||
---
|
||||
|
||||
## 1. Automotive - Dealer (Autohäuser)
|
||||
* **Primary Product:** Security Roboter
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand Fehler:** "Doppel-Nutzen: Tagsüber Reinigung, nachts Bestreifung" bei Gains. Das ist technisch falsch. Ein Wachroboter hat keine Besen, eine Kehrmaschine keine Überwachungskameras (in der Regel).
|
||||
* **Transcript Check:** "Teile-Diebstahl (Katalysatoren/Räder)", "Vandalismus", "Imageverlust (Laub/Dreck)". Christian sagt: "Sicherheit ist wichtiger als sauberer Hof".
|
||||
* **Logik:**
|
||||
* *Security:* Löst Diebstahl/Vandalismus. Ersetzt/Ergänzt Wachdienst.
|
||||
* *Sweeper:* Löst "dreckigen Hof" (Imageproblem bei Premium-Autos).
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Security]
|
||||
- Teile-Diebstahl: Organisierte Banden demontieren nachts Katalysatoren und Räder – enormer Schaden und Versicherungsstress.
|
||||
- Vandalismus: Zerkratzte Neuwagen auf dem Außenhof mindern den Verkaufswert drastisch.
|
||||
- Personalkosten: Lückenlose menschliche Nachtbewachung ist für viele Standorte wirtschaftlich kaum darstellbar.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Image-Verlust: Ein verschmutzter Außenbereich (Laub, Müll) passt nicht zum Premium-Anspruch der ausgestellten Fahrzeuge.
|
||||
- Manueller Aufwand: Verkaufspersonal oder teure Hausmeisterdienste binden Zeit mit unproduktivem Fegen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Security]
|
||||
- Abschreckung & Intervention: Permanente Roboter-Präsenz wirkt präventiv; bei Alarm schaltet sich sofort eine Leitstelle auf.
|
||||
- Asset-Schutz: Reduktion von Versicherungsschäden und Selbstbehalten durch lückenlose Dokumentation.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Premium-Präsentation: Der Hof ist bereits morgens bei Kundenöffnung makellos sauber.
|
||||
- Automatisierung: Täglich gereinigte Flächen ohne manuellen Eingriff.
|
||||
|
||||
---
|
||||
|
||||
## 2. Industry - Manufacturing (Produktion)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Transport Roboter
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand Fehler:** Die aktuellen Pains ("Such- und Holzeiten", "Materialfluss") beziehen sich zu 100% auf *Transport*, obwohl *Cleaning* das Primary Product ist.
|
||||
* **Transcript Check:** Alex warnt explizit vor "Öl und Chemie" ("Wie Hundekacke"). Roboter schmieren das nur breit. Fokus muss auf *Staub*, *Prozesssicherheit* und *Mitarbeiterentlastung* liegen. Alex: "Betriebskosten senken", "Produktivität steigern".
|
||||
* **Logik:**
|
||||
* *Cleaning:* Darf nicht in Ölspuren fahren. Aber: Große Hallen verstauben. Staplerverkehr erzeugt Abrieb. Rutschgefahr für Mitarbeiter.
|
||||
* *Transport:* "Facharbeiter rennt C-Teilen hinterher". Das ist der klassische Pain.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Prozess-Sicherheit: Staub und Abrieb auf Fahrwegen gefährden empfindliche Sensorik (z.B. von FTS) und die Produktqualität.
|
||||
- Arbeitssicherheit: Rutschgefahr durch feine Staubschichten oder ausgelaufene (nicht-chemische) Flüssigkeiten erhöht das Unfallrisiko.
|
||||
- Ressourcen-Verschwendung: Hochbezahlte Fachkräfte müssen Maschinen stoppen, um ihr Umfeld zu reinigen.
|
||||
|
||||
[Secondary Product: Transport]
|
||||
- Intransparenz & Suchzeiten: Facharbeiter unterbrechen die Wertschöpfung für unproduktive Materialbeschaffung ("C-Teile holen").
|
||||
- Mikrostillstände: Fehlendes Material an der Linie stoppt den Takt.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Konstante Bodenqualität: Definierte Sauberkeitsstandards (Audit-Ready) rund um die Uhr.
|
||||
- Unfallschutz: Reduktion von Arbeitsunfällen durch rutschfreie Verkehrswege.
|
||||
|
||||
[Secondary Product: Transport]
|
||||
- Just-in-Time Logistik: Automatisierter Nachschub hält die Fachkraft wertschöpfend an der Maschine.
|
||||
- Fluss-Optimierung: Stabilisierung der Taktzeiten und OEE durch verlässliche Materialflüsse.
|
||||
|
||||
---
|
||||
|
||||
## 3. Healthcare - Hospital (Krankenhaus)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Service Roboter (Transport)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand Fehler:** Vermischung. "Fachpflegekräfte... logistische Routinetätigkeiten" steht bei Cleaning. Das ist falsch.
|
||||
* **Transcript Check:** "Hände weg vom Bett" ist das Transport-Thema (Essen/Wäsche). "Hygienerisiko/Kreuzkontamination" ist das Cleaning-Thema. Alex: "Validierbare Reinigung".
|
||||
* **Logik:**
|
||||
* *Cleaning:* Muss Keime reduzieren, 24/7 laufen, dokumentieren.
|
||||
* *Service/Transport:* Muss Schwestern entlasten (Schrittzähler reduzieren).
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Hygienerisiko & Kreuzkontamination: Manuelle Reinigung ist oft fehleranfällig und variiert stark in der Qualität (Gefahr für Patienten).
|
||||
- Dokumentationspflicht: Der Nachweis RKI-konformer Reinigung bindet wertvolle Zeit und ist bei Personalmangel lückenhaft.
|
||||
- Personalnot: Fehlende Reinigungskräfte führen zu gesperrten Bereichen oder sinkendem Hygienelevel.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Berufsfremde Tätigkeiten: Pflegekräfte verbringen bis zu 30% der Schichtzeit mit Hol- und Bringdiensten (Essen, Wäsche, Labor).
|
||||
- Physische Überlastung: Lange Laufwege in großen Kliniken erhöhen die Erschöpfung des Fachpersonals.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Validierbare Hygiene: Robotergarantierte, protokollierte Desinfektionsleistung – audit-sicher auf Knopfdruck.
|
||||
- 24/7 Verfügbarkeit: Konstantes Hygienelevel auch nachts und am Wochenende, unabhängig vom Dienstplan.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Zeit für Patienten: Rückgewinnung von ca. 2,5 Stunden Fachkraft-Kapazität pro Schicht für die Pflege.
|
||||
- Mitarbeiterzufriedenheit: Reduktion der Laufwege ("Schrittzähler") entlastet das Team spürbar.
|
||||
|
||||
---
|
||||
|
||||
## 4. Logistics - Warehouse (Lagerhalle)
|
||||
* **Primary Product:** Cleaning Outdoor Roboter (Sweeper) -> *Korrektur: Sollte hier "Cleaning Indoor (Sweeper)" gemeint sein?*
|
||||
* **Logik-Check:** Im Warehouse fährt man selten mit einer Straßenkehrmaschine. Aber: Man nutzt *Aufsitz-Kehrmaschinen* (Sweeper) für den Innenbereich (Palettenspäne, Staub). "Wet Surface" ist im Lager oft zweitrangig (außer Lebensmittel), da Wasser + Kartonage = schlecht.
|
||||
* **Annahme:** Wir mappen "Sweeper" hier auf *Indoor Dry Cleaning*.
|
||||
* **Transcript Check:** Alex: "Im Warehouse sehe ich eher die Kehrmaschine als Erstes... Verschmutzung ist eine andere... Paletten Dinger."
|
||||
* **Secondary Product:** Cleaning Indoor (Wet Surface) -> Alex: "Anspruch an Nassreinigung im ersten Schritt nicht so hoch."
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning (Sweeper/Dry)]
|
||||
- Grobschmutz & Palettenreste: Holzspäne und Verpackungsreste gefährden Reifen von Flurförderzeugen und blockieren Lichtschranken.
|
||||
- Staubbelastung: Aufgewirbelter Staub legt sich auf Waren und Verpackungen (Reklamationsgrund) und schadet der Gesundheit.
|
||||
- Manuelle Bindung: Mitarbeiter müssen große Flächen manuell kehren, statt zu kommissionieren.
|
||||
|
||||
[Secondary Product: Cleaning (Wet)]
|
||||
- Hartnäckige Verschmutzungen: Eingefahrene Spuren, die durch reines Kehren nicht lösbar sind.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning (Sweeper/Dry)]
|
||||
- Anlagenschutz: Sauberer Boden verhindert Störungen an Fördertechnik und Sensoren durch Staub/Teile.
|
||||
- Staubfreie Ware: Produkte verlassen das Lager in sauberem Zustand (Qualitätsanspruch).
|
||||
|
||||
[Secondary Product: Cleaning (Wet)]
|
||||
- Grundsauberkeit: Gelegentliche Nassreinigung für Tiefenhygiene in Fahrgassen.
|
||||
|
||||
---
|
||||
|
||||
## 5. Retail - Food (Supermarkt/LEH)
|
||||
* **Primary Product:** Cleaning Indoor (Wet)
|
||||
* **Secondary Product:** Service Roboter
|
||||
|
||||
### Analyse
|
||||
* **Transcript Check:** "Kaufland/Aldi... große Flächen". "Reinigungskosten steigen". "Sichtbare Reinigungsmaschinen blockieren Kundenwege".
|
||||
* **Pain:** Dreckige Böden (Milch/Joghurt ausgelaufen) = Rutschgefahr + Ekel. Personal ist knapp (Regalauffüller).
|
||||
* **Logik:**
|
||||
* *Cleaning:* Muss "Spot Cleaning" können (Malheur wegmachen) und Flächenleistung bringen.
|
||||
* *Service:* Promotion? Oder "Wo ist die H-Milch?"
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- "Malheur-Management": Zerbrochene Gläser oder ausgelaufene Flüssigkeiten (Haverien) bilden sofortige Rutschfallen und binden Personal.
|
||||
- Optischer Eindruck: Grauschleier und verschmutzte Böden senken das Frische-Empfinden der Kunden massiv.
|
||||
- Personal-Engpass: Marktpersonal soll Regale füllen und kassieren, nicht mit der Scheuersaugmaschine fahren.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Fehlende Beratung: Kunden finden Produkte nicht und brechen den Kauf ab, da kein Personal greifbar ist.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Sofortige Sicherheit: Roboter beseitigt Rutschgefahren autonom und schnell.
|
||||
- Frische-Optik: Permanent glänzende Böden ("Lobby-Effekt") unterstreichen die Qualität der Lebensmittel.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Umsatz-Boost: Roboter führt Kunden direkt zum gesuchten Produkt oder bewirbt Aktionen aktiv am POS.
|
||||
|
||||
---
|
||||
|
||||
## 6. Hospitality - Gastronomy
|
||||
* **Primary Product:** Cleaning Indoor (Wet)
|
||||
* **Secondary Product:** Service Roboter
|
||||
* **Achtung:** Im Transkript wurde diskutiert, dies evtl. zu tauschen ("L'Osteria... Service Robotik"). Aber Alex sagt auch: "Reinigungsrobotik als erstes".
|
||||
* **Entscheidung:** Wir lassen Cleaning als Primary, aber schärfen Service als starken Secondary.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Klebrige Böden: Verschüttete Getränke und Speisereste wirken unhygienisch und stören das Ambiente.
|
||||
- Randzeiten-Problem: Nach Schließung ist es schwer, Personal für die Grundreinigung zu finden (Nachtzuschläge).
|
||||
|
||||
[Secondary Product: Service]
|
||||
- "Teller-Taxi": Servicekräfte verbringen 80% der Zeit mit Laufen (Küche <-> Gast) statt mit Verkaufen/Betreuung.
|
||||
- Personalmangel: Zu wenig Kellner führen zu langen Wartezeiten, kalten Speisen und genervten Gästen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Makelloses Ambiente: Sauberer Boden als Visitenkarte des Restaurants.
|
||||
- Zuverlässigkeit: Die Grundreinigung findet jede Nacht garantiert statt.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Mehr Umsatz am Gast: Servicekraft hat Zeit für Empfehlungen (Wein, Dessert) und Upselling.
|
||||
- Entlastung: Roboter übernimmt das schwere Tragen (Tabletts), Personal bleibt im Gastraum präsent.
|
||||
|
||||
---
|
||||
|
||||
## 7. Leisure - Outdoor Park (Freizeitparks)
|
||||
* **Primary Product:** Cleaning Outdoor (Sweeper)
|
||||
* **Secondary Product:** Service Roboter
|
||||
|
||||
### Analyse
|
||||
* **Transcript Check:** "Kilometerlange Wege", "Grobschmutz (Laub, Müll)". Alex: "Große Kehrmaschine (VIGGO 100)".
|
||||
* **Logik:** Es geht um Ästhetik ("Heile Welt") und Sicherheit (kein Müll).
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Outdoor]
|
||||
- Immersion-Breaker: Müll und Laub auf den Wegen stören die perfekte Illusion ("Heile Welt") des Parks.
|
||||
- Enorme Flächen: Kilometerlange Wegenetze binden ganze Kolonnen von Reinigungskräften.
|
||||
- Sicherheit: Rutschgefahr durch nasses Laub oder Abfall.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Versorgungslücken: An abgelegenen Attraktionen fehlt oft Gastronomie-Angebot.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Outdoor]
|
||||
- Perfekte Inszenierung: Unsichtbare Reinigung in den frühen Morgenstunden sichert das perfekte Erlebnis bei Parköffnung.
|
||||
- Effizienz: Ein Roboter schafft die Flächenleistung mehrerer manueller Kehrer.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Mobiler Verkauf: Roboter bringen Getränke/Eis direkt zu den Warteschlangen (Zusatzumsatz).
|
||||
|
||||
---
|
||||
|
||||
## 8. Energy - Grid & Utilities (Energieversorger)
|
||||
* **Primary Product:** Security Roboter
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse
|
||||
* **Logik:** KRITIS-Infrastruktur. Abgelegen. Kupferdiebstahl.
|
||||
* **Pain:** Man kann nicht überall sein. Zäune werden durchschnitten.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Security]
|
||||
- Sabotage & Diebstahl: Kupferdiebstahl in Umspannwerken verursacht Millionenschäden und Versorgungsausfälle.
|
||||
- Reaktionszeit: Entlegene Standorte sind für Interventionskräfte oft zu spät erreichbar.
|
||||
- Sicherheitsrisiko Mensch: Alleinarbeit bei Kontrollgängen in Hochspannungsbereichen ist gefährlich.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Security]
|
||||
- First Responder Maschine: Roboter ist bereits vor Ort, verifiziert Alarm und schreckt Täter ab.
|
||||
- KRITIS-Compliance: Lückenlose, manipulationssichere Dokumentation aller Vorfälle für Behörden.
|
||||
- Arbeitsschutz: Roboter übernimmt gefährliche Routinekontrollen (z.B. Thermografie an Trafos).
|
||||
|
||||
---
|
||||
|
||||
## 9. Energy - Solar/Wind (Solarparks & Windkraft)
|
||||
* **Primary Product:** Security Roboter
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Hoher Schaden durch Kupfer-/Moduldiebstahl", "Teure Falschfahrten (Wildtiere)".
|
||||
* **Logik Check:** Solarfelder liegen oft in der Pampa. Ein Zaun reicht nicht. Diebe klauen Kabel (Kupfer) oder ganze Module.
|
||||
* **Pain:** Wachdienst braucht 30 Min bis er da ist -> Diebe sind weg. Falschalarme kosten jedes Mal 500€.
|
||||
* **Gain:** Roboter ist *schon da*. Er unterscheidet Reh von Dieb (KI). Versicherung gibt Rabatt?
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Security]
|
||||
- Kupfer-Diebstahl: Professionelle Banden plündern abgelegene Parks in Minuten; der Schaden durch Betriebsunterbrechung übersteigt den Materialwert oft weit.
|
||||
- Interventionszeit: Bis der Wachdienst eintrifft ("Blaulicht-Fahrt"), sind die Täter längst verschwunden.
|
||||
- Kostenfalle Falschalarm: Wildtiere oder wetterbedingte Störungen lösen teure, unnötige Polizeieinsätze aus.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Security]
|
||||
- Sofort-Verifikation: KI-gestützte Erkennung unterscheidet zuverlässig zwischen Tier und Mensch und liefert Live-Bilder in Sekunden.
|
||||
- Präventive Abschreckung: Autonome Patrouillen signalisieren "Hier wird bewacht" und verhindern den Versuch.
|
||||
- Lückenlose Beweissicherung: Gerichtsfeste Dokumentation von Vorfällen für Versicherung und Strafverfolgung.
|
||||
|
||||
---
|
||||
|
||||
## 10. Infrastructure - Public (Messehallen & Öffentliche Gebäude)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Kurze Turnaround-Zeiten", "Hohe Nachtzuschläge".
|
||||
* **Transcript Check:** Alex: "Messehallen müssen über Nacht wieder sauber sein... Dienstleister (Wisag/Dussmann) machen das."
|
||||
* **Logik:**
|
||||
* *Messe:* Zeitdruck ist extrem (Nachtumbau). Boden ist oft Teppich (Gänge) oder Beton (Halle). Hier steht "Wet Surface" als Primary. Prüfen: Ist Messehalle Nassreinigung? Oft ja, in den Gängen (Hartboden). Aber Teppich ist riesig.
|
||||
* *Entscheidung:* Wir lassen Wet Surface, adressieren aber "Großfläche".
|
||||
* *Secondary (Sweeper):* Außenbereich Messe / Parkplatz.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Zeitdruck (Turnaround): Zwischen Messe-Ende und Öffnung am nächsten Tag liegen nur wenige Stunden für eine Komplettreinigung.
|
||||
- Kostenspirale: Nacht- und Wochenendzuschläge für manuelles Personal belasten das Budget massiv.
|
||||
- Personalverfügbarkeit: Für Spitzenlasten (Messezeiten) ist kurzfristig kaum ausreichendes Personal zu finden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Erster Eindruck: Vermüllte Vorplätze und Zufahrten schaden dem Image der Veranstaltung schon bei Ankunft.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Planbare Kapazität: Roboter reinigen autonom die Kilometer langen Gänge ("Gang-Reinigung"), Personal fokussiert sich auf Stände und Details.
|
||||
- Kosteneffizienz: Fixe Kosten statt variabler Zuschläge für Nachtarbeit.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Repräsentative Außenwirkung: Sauberer Empfangsbereich ohne permanenten Personaleinsatz.
|
||||
|
||||
---
|
||||
|
||||
## 11. Infrastructure - Transport (Flughafen & Bahnhof)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Sicherheitsbereiche erfordern Screening".
|
||||
* **Transcript Check:** Alex: "Greeting Robots (Service)" wurde diskutiert, aber als "Prestige" abgetan. Transport (Koffer) auch eher Spielerei. Reinigung ist valide.
|
||||
* **Logik:**
|
||||
* *Sicherheitsbereich:* Wer putzt hinter der Schleuse? Jede Putzfrau braucht Background-Check. Roboter nicht.
|
||||
* *24/7 Betrieb:* Es ist nie "leer". Manuelle Maschinen stören Passagiere.
|
||||
* *Secondary (Sweeper):* Vorplatz, Taxi-Spur, Raucherbereiche.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Sicherheits-Checks: Jede externe Reinigungskraft im Sicherheitsbereich erfordert aufwändige Überprüfungen (ZÜP) und Begleitung.
|
||||
- Passagier-Störung: Laute, manuelle Reinigungsmaschinen behindern Laufwege und Durchsagen im 24/7-Betrieb.
|
||||
- Hochfrequenz-Verschmutzung: Kaffee-Flecken und Nässe (Winter) müssen sofort beseitigt werden, um Rutschunfälle zu vermeiden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Müll-Aufkommen: Raucherbereiche und Taxi-Spuren verkommen schnell durch Zigarettenstummel und Kleinmüll.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- "Approved Staff": Roboter verbleibt im Sicherheitsbereich – kein täglicher Check-in/Check-out nötig.
|
||||
- Silent Cleaning: Leise, autonome Navigation zwischen Passagieren stört den Betriebsablauf nicht.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Sauberer Transfer: Gepflegte Außenanlagen als Visitenkarte der Mobilitätsdrehscheibe.
|
||||
|
||||
---
|
||||
|
||||
## 12. Retail - Shopping Center (Einkaufszentren)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Food-Court ist Schmutz-Hotspot".
|
||||
* **Logik:**
|
||||
* *Mall:* Lange Gänge (glänzender Steinboden). Food Court (Fett/Essen).
|
||||
* *Pain:* Personal ist teuer. Kunden beschweren sich über klebrige Böden.
|
||||
* *Secondary (Sweeper):* Parkhaus / Außenfläche.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Food-Court-Chaos: Zu Stoßzeiten kommen Reinigungskräfte mit dem Wischen von verschütteten Getränken und Essensresten kaum nach.
|
||||
- Rutschfallen: Nasse Eingänge (Regen) und verschmutzte Zonen sind Haftungsrisiken für den Betreiber.
|
||||
- Image-Faktor: Ein "grauer" oder fleckiger Boden senkt die Aufenthaltsqualität und damit die Verweildauer der Kunden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Parkplatz-Pflege: Müll auf Parkplätzen und in Parkhäusern ist der erste negative Touchpoint für Besucher.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Reaktionsschnelligkeit: Roboter sind permanent präsent und beseitigen Malheure sofort, bevor sie antrocknen.
|
||||
- Hochglanz-Optik: Konstante Pflege poliert den Steinboden und sorgt für ein hochwertiges Ambiente.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Willkommens-Kultur: Sauberer Außenbereich lädt zum Betreten ein.
|
||||
|
||||
---
|
||||
|
||||
## 13. Leisure - Wet & Spa (Schwimmbäder & Thermen)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Transcript Check:** "Rutschgefahr", "Hygiene-Audit". Alex: "Bademeister hat Aufgabe Retten, nicht Putzen".
|
||||
* **Pain:** Barfußbereich = Hygiene ist kritisch (Fußpilz/Keime). Nässe = Unfall.
|
||||
* **Problem:** Roboter im laufenden Badebetrieb? Alex war skeptisch ("Trauen sich nicht").
|
||||
* **Lösung:** Argumentation auf *Nachtreinigung* und *Randzeiten* sowie *permanente Trocknung* (Sicherheit) legen.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Rutsch-Unfälle: Staunässe auf Fliesen ist die Unfallursache Nummer 1 in Bädern – hohes Haftungsrisiko.
|
||||
- Hygiene-Sensibilität: Im Barfußbereich (Umkleiden/Gänge) erwarten Gäste klinische Sauberkeit; Haare und Fussel sind "Ekel-Faktor".
|
||||
- Personal-Konflikt: Fachangestellte für Bäderbetriebe sollen die Beckenaufsicht führen (Sicherheit), nicht wischen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Permanente Sicherheit: Roboter trocknen Laufwege kontinuierlich und minimieren das Rutschrisiko aktiv.
|
||||
- Entlastung der Aufsicht: Bademeister können sich zu 100% auf die Sicherheit der Badegäste konzentrieren.
|
||||
- Hygiene-Standard: Dokumentierte Desinfektion und Reinigung sichert Top-Bewertungen.
|
||||
|
||||
---
|
||||
|
||||
## 14. Corporate - Campus (Firmenzentralen)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Flächen-Management", "ESG-Ziele".
|
||||
* **Logik:** Headquarter = Prestige. Vorstand läuft da rum.
|
||||
* **Pain:** Es ist riesig. Manuelles Putzen ist teuer und unsichtbar.
|
||||
* **Gain:** "High-Tech Image". Roboter passt zur "Innovations-Story" des Konzerns.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Repräsentativität: Empfangshallen und Atrien sind das Aushängeschild – sichtbarer Staub oder Schlieren wirken unprofessionell.
|
||||
- Kostendruck Facility: Enorme Flächen (Flure/Verbindungsgänge) erzeugen hohe laufende Reinigungskosten.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Campus-Pflege: Weitläufige Außenanlagen manuell sauber zu halten, bindet unverhältnismäßig viele Ressourcen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Innovations-Statement: Einsatz von Robotik unterstreicht den technologischen Führungsanspruch des Unternehmens gegenüber Besuchern und Bewerbern.
|
||||
- Konstante Qualität: Einheitliches Sauberkeitsniveau in allen Gebäudeteilen, unabhängig von Tagesform oder Krankenstand.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Gepflegtes Erscheinungsbild: Automatisierte Kehrleistung sorgt für repräsentative Wege und Plätze.
|
||||
|
||||
---
|
||||
|
||||
## 15. Reinigungsdienstleister (Gebäudereiniger)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Margendruck", "Fluktuation", "Preisdiktat".
|
||||
* **Transcript Check:** Alex: "Größter Markt... Große (Wisag) wollen nicht, weil Konkurrenz... aber KMU Dienstleister vielleicht".
|
||||
* **Logik:** Der Dienstleister *verkauft* Sauberkeit. Sein Problem ist: Er findet keine Leute ("No-Show"). Er verdient kaum was (Marge).
|
||||
* **Gain:** Roboter = Fixkosten. Roboter = "Ich bin innovativ bei der Ausschreibung".
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Personal-Mangel & Fluktuation: Hohe "No-Show"-Quoten und ständige Neurekrutierung binden Objektleiter massiv und gefährden die Vertragserfüllung.
|
||||
- Margen-Verfall: Steigende Tariflöhne bei gleichzeitigem Preisdruck der Auftraggeber lassen kaum noch Gewinn zu.
|
||||
- Qualitäts-Schwankungen: Wechselndes, ungelernte Personal liefert oft unzureichende Ergebnisse, was zu Reklamationen und Kürzungen führt.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Kalkulations-Sicherheit: Roboter bieten fixe Kosten statt unkalkulierbarer Krankheits- und Ausfallrisiken.
|
||||
- Wettbewerbsvorteil: Mit Robotik-Konzepten punkten Dienstleister bei Ausschreibungen als Innovationsführer.
|
||||
- Entlastung Objektleitung: Weniger Personal-Management bedeutet mehr Zeit für Kundenpflege und Qualitätskontrolle.
|
||||
202
docs/ANALYSIS_PHASE_2_ONLY.md
Normal file
202
docs/ANALYSIS_PHASE_2_ONLY.md
Normal file
@@ -0,0 +1,202 @@
|
||||
# Deep-Dive Analyse: Pains & Gains (Phase 2 - Restliche Verticals)
|
||||
**Status:** Warten auf Freigabe
|
||||
**Basis:** Transkript + Notion Ist-Stand
|
||||
|
||||
---
|
||||
|
||||
## 9. Energy - Solar/Wind (Solarparks & Windkraft)
|
||||
* **Primary Product:** Security Roboter
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Hoher Schaden durch Kupfer-/Moduldiebstahl", "Teure Falschfahrten (Wildtiere)".
|
||||
* **Logik Check:** Solarfelder liegen oft in der Pampa. Ein Zaun reicht nicht. Diebe klauen Kabel (Kupfer) oder ganze Module.
|
||||
* **Pain:** Wachdienst braucht 30 Min bis er da ist -> Diebe sind weg. Falschalarme kosten jedes Mal 500€.
|
||||
* **Gain:** Roboter ist *schon da*. Er unterscheidet Reh von Dieb (KI). Versicherung gibt Rabatt?
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Security]
|
||||
- Kupfer-Diebstahl: Professionelle Banden plündern abgelegene Parks in Minuten; der Schaden durch Betriebsunterbrechung übersteigt den Materialwert oft weit.
|
||||
- Interventionszeit: Bis der Wachdienst eintrifft ("Blaulicht-Fahrt"), sind die Täter längst verschwunden.
|
||||
- Kostenfalle Falschalarm: Wildtiere oder wetterbedingte Störungen lösen teure, unnötige Polizeieinsätze aus.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Security]
|
||||
- Sofort-Verifikation: KI-gestützte Erkennung unterscheidet zuverlässig zwischen Tier und Mensch und liefert Live-Bilder in Sekunden.
|
||||
- Präventive Abschreckung: Autonome Patrouillen signalisieren "Hier wird bewacht" und verhindern den Versuch.
|
||||
- Lückenlose Beweissicherung: Gerichtsfeste Dokumentation von Vorfällen für Versicherung und Strafverfolgung.
|
||||
|
||||
---
|
||||
|
||||
## 10. Infrastructure - Public (Messehallen & Öffentliche Gebäude)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Kurze Turnaround-Zeiten", "Hohe Nachtzuschläge".
|
||||
* **Transcript Check:** Alex: "Messehallen müssen über Nacht wieder sauber sein... Dienstleister (Wisag/Dussmann) machen das."
|
||||
* **Logik:**
|
||||
* *Messe:* Zeitdruck ist extrem (Nachtumbau). Boden ist oft Teppich (Gänge) oder Beton (Halle). Hier steht "Wet Surface" als Primary. Prüfen: Ist Messehalle Nassreinigung? Oft ja, in den Gängen (Hartboden). Aber Teppich ist riesig.
|
||||
* *Entscheidung:* Wir lassen Wet Surface, adressieren aber "Großfläche".
|
||||
* *Secondary (Sweeper):* Außenbereich Messe / Parkplatz.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Zeitdruck (Turnaround): Zwischen Messe-Ende und Öffnung am nächsten Tag liegen nur wenige Stunden für eine Komplettreinigung.
|
||||
- Kostenspirale: Nacht- und Wochenendzuschläge für manuelles Personal belasten das Budget massiv.
|
||||
- Personalverfügbarkeit: Für Spitzenlasten (Messezeiten) ist kurzfristig kaum ausreichendes Personal zu finden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Erster Eindruck: Vermüllte Vorplätze und Zufahrten schaden dem Image der Veranstaltung schon bei Ankunft.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Planbare Kapazität: Roboter reinigen autonom die Kilometer langen Gänge ("Gang-Reinigung"), Personal fokussiert sich auf Stände und Details.
|
||||
- Kosteneffizienz: Fixe Kosten statt variabler Zuschläge für Nachtarbeit.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Repräsentative Außenwirkung: Sauberer Empfangsbereich ohne permanenten Personaleinsatz.
|
||||
|
||||
---
|
||||
|
||||
## 11. Infrastructure - Transport (Flughafen & Bahnhof)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Sicherheitsbereiche erfordern Screening".
|
||||
* **Transcript Check:** Alex: "Greeting Robots (Service)" wurde diskutiert, aber als "Prestige" abgetan. Transport (Koffer) auch eher Spielerei. Reinigung ist valide.
|
||||
* **Logik:**
|
||||
* *Sicherheitsbereich:* Wer putzt hinter der Schleuse? Jede Putzfrau braucht Background-Check. Roboter nicht.
|
||||
* *24/7 Betrieb:* Es ist nie "leer". Manuelle Maschinen stören Passagiere.
|
||||
* *Secondary (Sweeper):* Vorplatz, Taxi-Spur, Raucherbereiche.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Sicherheits-Checks: Jede externe Reinigungskraft im Sicherheitsbereich erfordert aufwändige Überprüfungen (ZÜP) und Begleitung.
|
||||
- Passagier-Störung: Laute, manuelle Reinigungsmaschinen behindern Laufwege und Durchsagen im 24/7-Betrieb.
|
||||
- Hochfrequenz-Verschmutzung: Kaffee-Flecken und Nässe (Winter) müssen sofort beseitigt werden, um Rutschunfälle zu vermeiden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Müll-Aufkommen: Raucherbereiche und Taxi-Spuren verkommen schnell durch Zigarettenstummel und Kleinmüll.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- "Approved Staff": Roboter verbleibt im Sicherheitsbereich – kein täglicher Check-in/Check-out nötig.
|
||||
- Silent Cleaning: Leise, autonome Navigation zwischen Passagieren stört den Betriebsablauf nicht.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Sauberer Transfer: Gepflegte Außenanlagen als Visitenkarte der Mobilitätsdrehscheibe.
|
||||
|
||||
---
|
||||
|
||||
## 12. Retail - Shopping Center (Einkaufszentren)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Food-Court ist Schmutz-Hotspot".
|
||||
* **Logik:**
|
||||
* *Mall:* Lange Gänge (glänzender Steinboden). Food Court (Fett/Essen).
|
||||
* *Pain:* Personal ist teuer. Kunden beschweren sich über klebrige Böden.
|
||||
* *Secondary (Sweeper):* Parkhaus / Außenfläche.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Food-Court-Chaos: Zu Stoßzeiten kommen Reinigungskräfte mit dem Wischen von verschütteten Getränken und Essensresten kaum nach.
|
||||
- Rutschfallen: Nasse Eingänge (Regen) und verschmutzte Zonen sind Haftungsrisiken für den Betreiber.
|
||||
- Image-Faktor: Ein "grauer" oder fleckiger Boden senkt die Aufenthaltsqualität und damit die Verweildauer der Kunden.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Parkplatz-Pflege: Müll auf Parkplätzen und in Parkhäusern ist der erste negative Touchpoint für Besucher.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Reaktionsschnelligkeit: Roboter sind permanent präsent und beseitigen Malheure sofort, bevor sie antrocknen.
|
||||
- Hochglanz-Optik: Konstante Pflege poliert den Steinboden und sorgt für ein hochwertiges Ambiente.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Willkommens-Kultur: Sauberer Außenbereich lädt zum Betreten ein.
|
||||
|
||||
---
|
||||
|
||||
## 13. Leisure - Wet & Spa (Schwimmbäder & Thermen)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Transcript Check:** "Rutschgefahr", "Hygiene-Audit". Alex: "Bademeister hat Aufgabe Retten, nicht Putzen".
|
||||
* **Pain:** Barfußbereich = Hygiene ist kritisch (Fußpilz/Keime). Nässe = Unfall.
|
||||
* **Problem:** Roboter im laufenden Badebetrieb? Alex war skeptisch ("Trauen sich nicht").
|
||||
* **Lösung:** Argumentation auf *Nachtreinigung* und *Randzeiten* sowie *permanente Trocknung* (Sicherheit) legen.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Rutsch-Unfälle: Staunässe auf Fliesen ist die Unfallursache Nummer 1 in Bädern – hohes Haftungsrisiko.
|
||||
- Hygiene-Sensibilität: Im Barfußbereich (Umkleiden/Gänge) erwarten Gäste klinische Sauberkeit; Haare und Fussel sind "Ekel-Faktor".
|
||||
- Personal-Konflikt: Fachangestellte für Bäderbetriebe sollen die Beckenaufsicht führen (Sicherheit), nicht wischen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Permanente Sicherheit: Roboter trocknen Laufwege kontinuierlich und minimieren das Rutschrisiko aktiv.
|
||||
- Entlastung der Aufsicht: Bademeister können sich zu 100% auf die Sicherheit der Badegäste konzentrieren.
|
||||
- Hygiene-Standard: Dokumentierte Desinfektion und Reinigung sichert Top-Bewertungen.
|
||||
|
||||
---
|
||||
|
||||
## 14. Corporate - Campus (Firmenzentralen)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Flächen-Management", "ESG-Ziele".
|
||||
* **Logik:** Headquarter = Prestige. Vorstand läuft da rum.
|
||||
* **Pain:** Es ist riesig. Manuelles Putzen ist teuer und unsichtbar.
|
||||
* **Gain:** "High-Tech Image". Roboter passt zur "Innovations-Story" des Konzerns.
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Repräsentativität: Empfangshallen und Atrien sind das Aushängeschild – sichtbarer Staub oder Schlieren wirken unprofessionell.
|
||||
- Kostendruck Facility: Enorme Flächen (Flure/Verbindungsgänge) erzeugen hohe laufende Reinigungskosten.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Campus-Pflege: Weitläufige Außenanlagen manuell sauber zu halten, bindet unverhältnismäßig viele Ressourcen.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Innovations-Statement: Einsatz von Robotik unterstreicht den technologischen Führungsanspruch des Unternehmens gegenüber Besuchern und Bewerbern.
|
||||
- Konstante Qualität: Einheitliches Sauberkeitsniveau in allen Gebäudeteilen, unabhängig von Tagesform oder Krankenstand.
|
||||
|
||||
[Secondary Product: Cleaning Outdoor]
|
||||
- Gepflegtes Erscheinungsbild: Automatisierte Kehrleistung sorgt für repräsentative Wege und Plätze.
|
||||
|
||||
---
|
||||
|
||||
## 15. Reinigungsdienstleister (Gebäudereiniger)
|
||||
* **Primary Product:** Cleaning Indoor (Wet Surface)
|
||||
* **Secondary Product:** -
|
||||
|
||||
### Analyse (Chain of Thought)
|
||||
* **Ist-Zustand:** "Margendruck", "Fluktuation", "Preisdiktat".
|
||||
* **Transcript Check:** Alex: "Größter Markt... Große (Wisag) wollen nicht, weil Konkurrenz... aber KMU Dienstleister vielleicht".
|
||||
* **Logik:** Der Dienstleister *verkauft* Sauberkeit. Sein Problem ist: Er findet keine Leute ("No-Show"). Er verdient kaum was (Marge).
|
||||
* **Gain:** Roboter = Fixkosten. Roboter = "Ich bin innovativ bei der Ausschreibung".
|
||||
|
||||
### PROPOSAL
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Personal-Mangel & Fluktuation: Hohe "No-Show"-Quoten und ständige Neurekrutierung binden Objektleiter massiv und gefährden die Vertragserfüllung.
|
||||
- Margen-Verfall: Steigende Tariflöhne bei gleichzeitigem Preisdruck der Auftraggeber lassen kaum noch Gewinn zu.
|
||||
- Qualitäts-Schwankungen: Wechselndes, ungelernte Personal liefert oft unzureichende Ergebnisse, was zu Reklamationen und Kürzungen führt.
|
||||
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning Indoor]
|
||||
- Kalkulations-Sicherheit: Roboter bieten fixe Kosten statt unkalkulierbarer Krankheits- und Ausfallrisiken.
|
||||
- Wettbewerbsvorteil: Mit Robotik-Konzepten punkten Dienstleister bei Ausschreibungen als Innovationsführer.
|
||||
- Entlastung Objektleitung: Weniger Personal-Management bedeutet mehr Zeit für Kundenpflege und Qualitätskontrolle.
|
||||
58
docs/ANFORDERUNGEN_IT_OAUTH.md
Normal file
58
docs/ANFORDERUNGEN_IT_OAUTH.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Anforderungen für Microsoft Entra ID (Azure AD) App-Registrierung [31388f42]
|
||||
|
||||
## 1. Projektübersicht
|
||||
Um den Zugriff auf die interne **Gemini Business Suite** (KI-gestützte Tools für Marketing, Sales und Datenanalyse) abzusichern, soll eine Authentifizierung über Microsoft OAuth2 (Entra ID) implementiert werden. Dies ermöglicht den Mitarbeitern einen sicheren Single-Sign-On (SSO) mit ihren bestehenden Unternehmenskonten.
|
||||
|
||||
**Verantwortliches Administratorkonto:** `info@robo-planet.de`
|
||||
|
||||
## 2. Technische Anforderungen an die App-Registrierung
|
||||
|
||||
Bitte registrieren Sie eine neue Anwendung im Microsoft Entra ID (Azure AD) Portal mit den folgenden Parametern:
|
||||
|
||||
### 2.1 Grundkonfiguration
|
||||
* **Name der Anwendung:** Gemini Business Suite (oder nach IT-Vorgabe)
|
||||
* **Anwendungstyp:** Webanwendung
|
||||
* **Unterstützte Kontotypen:** Nur Konten in diesem Organisationsverzeichnis (Single Tenant)
|
||||
|
||||
### 2.2 Redirect-URIs (WICHTIG)
|
||||
Die Anwendung benötigt die folgenden Redirect-URIs für den Authentifizierungsprozess. Da die Produktionsumgebung rein intern läuft, sind hier interne Hostnames zulässig.
|
||||
|
||||
* **Entwicklung (Aktuell):** `http://floke-ai.duckdns.org:8090/auth/callback`
|
||||
* **Produktion (Intern):** `http://<INTERNE-IP-ODER-HOSTNAME>:8090/auth/callback`
|
||||
*(Bitte den internen Hostnamen/IP des Linux-Servers eintragen, sobald verfügbar)*
|
||||
* **Lokal (Fallback):** `http://localhost:8090/auth/callback`
|
||||
|
||||
### 2.3 API-Berechtigungen (Scopes)
|
||||
Die Anwendung benötigt lediglich Lesezugriff auf das Basisprofil des Benutzers, um die Identität zu verifizieren:
|
||||
* `Microsoft Graph` -> `Delegierte Berechtigungen` -> `User.Read`
|
||||
* `openid`
|
||||
* `profile`
|
||||
* `email`
|
||||
|
||||
### 2.4 Authentifizierungsmethode
|
||||
* **Client Secret:** Es wird ein "Client Secret" für die sichere serverseitige Authentifizierung benötigt.
|
||||
* **ID-Tokens:** Bitte aktivieren Sie die Ausstellung von ID-Tokens für Hybrid-Flows (falls erforderlich).
|
||||
|
||||
## 3. Netzwerk & Firewall (Wichtig für Produktion)
|
||||
|
||||
Da der Produktionsserver isoliert im internen Netz läuft, beachten Sie bitte folgende Firewall-Regeln:
|
||||
|
||||
1. **Eingehend (Ingress):**
|
||||
* Es ist **KEIN** Zugriff aus dem Internet auf den Server erforderlich.
|
||||
* Der Server muss lediglich für die internen Mitarbeiter (Client-Browser) erreichbar sein (Port 8090/HTTP).
|
||||
|
||||
2. **Ausgehend (Egress):**
|
||||
* Der Server (Backend) benötigt ausgehenden Zugriff auf **Port 443 (HTTPS)** zu folgenden Microsoft-Diensten, um Token zu validieren:
|
||||
* `login.microsoftonline.com`
|
||||
* `graph.microsoft.com`
|
||||
|
||||
## 4. Benötigte Informationen von der IT
|
||||
Nach der erfolgreichen Registrierung benötigen wir die folgenden Informationen, um die Anwendung zu konfigurieren:
|
||||
|
||||
1. **Anwendungs-ID (Client ID):** `______________________________________`
|
||||
2. **Verzeichnis-ID (Tenant ID):** `______________________________________`
|
||||
3. **Client-Geheimnis (Client Secret):** `______________________________________` (Bitte sicher übermitteln)
|
||||
|
||||
---
|
||||
*Erstellt am: 26. Februar 2026*
|
||||
*Task-ID: [31388f42]*
|
||||
277
docs/ARCHITEKTUR_GCP_SETUP.md
Normal file
277
docs/ARCHITEKTUR_GCP_SETUP.md
Normal file
@@ -0,0 +1,277 @@
|
||||
# Technisches Zielbild: GTM-Engine & Google Cloud Integration
|
||||
|
||||
Dieses Dokument beschreibt die Architektur und den Datenfluss der **GTM-Engine (Go-to-Market Engine)**.
|
||||
|
||||
## Executive Summary: Was wir tun
|
||||
Wir automatisieren die **Qualifizierung von B2B-Accounts** (Firmen), um den Vertrieb gezielter und effizienter zu steuern ("Whale Hunting").
|
||||
|
||||
Anstatt dass ein Mitarbeiter manuell 20 Minuten lang Webseiten liest, um herauszufinden, ob eine Firma relevant ist, übernimmt dies das System automatisiert:
|
||||
1. **Input:** Firmenname & Webseite (aus CRM oder Lead-Liste).
|
||||
2. **Analyse:** Wir aggregieren öffentlich verfügbare Daten (Website-Text, Impressum, Wikipedia).
|
||||
3. **KI-Verarbeitung:** Ein Sprachmodell (Gemini) agiert als "Lese-Assistent". Wir stellen ihm gezielte Fragen an den Kontext (z.B. *"Hat diese Firma mehr als 500 Mitarbeiter?", "Nutzen sie Roboter?", "Sind sie im Bereich Logistik tätig?"*).
|
||||
4. **Output:** Strukturierte Daten (Branche, Potential-Score, Summary) fließen zurück ins CRM zur Vertriebssteuerung.
|
||||
|
||||
**Wichtig:** Es findet **keine** automatisierte Entscheidung über natürliche Personen statt. Wir bewerten Firmen-Potentiale.
|
||||
|
||||
## Kern-Prinzipien
|
||||
1. **Trennung von Identität & Daten:** Nutzung von Unternehmens-Identitäten (Managed Google ID) statt privater Konten.
|
||||
2. **Datensparsamkeit:** KI-Verarbeitung erfolgt primär auf anonymen Firmendaten (B2B), nicht auf Personendaten.
|
||||
3. **Lokale Hoheit:** Die Business-Logik (Python/Docker) läuft kontrolliert lokal oder im Intranet, nicht "in der Cloud".
|
||||
|
||||
## Anleitung für IT & Setup (Schritt-für-Schritt)
|
||||
|
||||
Ziel: Bereitstellung von zwei GCP-Projekten für die Nutzung von Vertex AI / Gemini API durch Christian (Floke).
|
||||
|
||||
### Schritt 1: Projekte anlegen (Durch IT Admin)
|
||||
Bitte in der Google Cloud Console (`console.cloud.google.com`) zwei neue Projekte erstellen.
|
||||
* **Projekt 1 Name:** `roboplanet-ai-dev` (Sandbox/Entwicklung)
|
||||
* **Projekt 2 Name:** `roboplanet-ai-prod` (Live-System/Tools)
|
||||
* **Organisation:** `wackler-group.de` (oder entsprechende Root-Org).
|
||||
|
||||
### Schritt 2: Billing verknüpfen (Durch IT Admin)
|
||||
Beide Projekte müssen mit dem zentralen Firmen-Rechnungskonto (Billing Account) verknüpft werden.
|
||||
* In der Projektübersicht -> "Abrechnung" -> "Abrechnung verknüpfen".
|
||||
* Dies ist zwingend erforderlich, um kostenpflichtige APIs (Vertex AI) nutzen zu können.
|
||||
|
||||
### Schritt 3: Berechtigungen für Christian setzen (Durch IT Admin)
|
||||
Christian benötigt vollen Zugriff auf diese Projekte, um APIs zu aktivieren und Keys zu verwalten.
|
||||
* Gehe zu **IAM & Verwaltung** -> **IAM**.
|
||||
* Füge User `christian.floke@...` hinzu (bzw. deine exakte Mail).
|
||||
* **Rolle:** `Inhaber` (Owner) oder mindestens `Editor` + `Project IAM Admin` + `Service Usage Admin`.
|
||||
|
||||
### Schritt 4: API Aktivierung & Key-Erstellung (Durch Christian / Floke)
|
||||
Sobald die Projekte da sind, führe ich folgende Schritte durch:
|
||||
|
||||
1. **Login im Google AI Studio:**
|
||||
* Gehe auf [aistudio.google.com](https://aistudio.google.com).
|
||||
* Login mit dem Wackler-Konto.
|
||||
|
||||
2. **Projekt-Verknüpfung (Der "Enterprise Switch"):**
|
||||
* Klick auf "Settings" oder "API Key".
|
||||
* Wähle **"Link to Google Cloud Project"**.
|
||||
* Wähle `roboplanet-ai-dev` (oder `prod`) aus der Liste aus.
|
||||
* *Effekt:* Ab jetzt läuft die Abrechnung über GCP (Pay-per-Use) und es gelten die Enterprise-Datenschutzbedingungen (Kein Training).
|
||||
|
||||
3. **API Key erstellen:**
|
||||
* Klick auf **"Create API Key"**.
|
||||
* Wähle das verknüpfte GCP-Projekt.
|
||||
* Kopiere den Key (`AIza...`) sicher weg.
|
||||
|
||||
4. **Environment Variablen setzen (Lokal):**
|
||||
Damit wir Dev und Prod sauber trennen, nutzen wir standardisierte Variablennamen in `.env` Dateien:
|
||||
* `GEMINI_API_KEY_DEV` -> Für CLI, OpenClaw, lokale Tests (Projekt: `roboplanet-ai-dev`)
|
||||
* `GEMINI_API_KEY_PROD` -> Für Company Explorer, GTM-Engine (Projekt: `roboplanet-ai-prod`)
|
||||
|
||||
### Checklist für den Termin
|
||||
- [ ] Projekte `roboplanet-ai-dev` und `roboplanet-ai-prod` existieren.
|
||||
- [ ] Billing ist auf beiden Projekten aktiv (kein "Free Trial" Limit, sondern echtes Billing).
|
||||
- [ ] Mein User hat `Owner` Rechte auf den Projekten.
|
||||
|
||||
## Architektur-Übersicht
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
%% Subgraph: Corporate Environment (Wackler/RoboPlanet)
|
||||
subgraph Corporate_IT ["🏢 Wackler / RoboPlanet Umgebung"]
|
||||
|
||||
subgraph User_Layer ["🧑💻 User & Identity"]
|
||||
User[("Christian (User)")]
|
||||
CorpID["Corporate Google ID<br/>(@roboplanet.de / @wackler-group.de)"]
|
||||
User --> CorpID
|
||||
end
|
||||
|
||||
subgraph Local_Execution ["⚙️ Execution Layer (Local/Server)"]
|
||||
Docker["🐳 Docker Container<br/>(GTM-Engine / Python)"]
|
||||
|
||||
subgraph Data_Handling ["🛡️ Daten-Verarbeitung"]
|
||||
RawData[("Rohdaten<br/>(Websites, Listen)")]
|
||||
Anonymizer["⚙️ Pre-Processing<br/>(Filterung PII / Personendaten)"]
|
||||
end
|
||||
|
||||
ResultStorage[("Ergebnisse<br/>(Notion / CRM / Excel)")]
|
||||
end
|
||||
end
|
||||
|
||||
%% Subgraph: Google Cloud Platform (Managed)
|
||||
subgraph Google_Cloud ["☁️ Google Cloud Platform (Enterprise Tenant)"]
|
||||
|
||||
subgraph IAM_Security ["🔐 Security & Billing"]
|
||||
GCP_Project["GCP Projekt<br/>(z.B. 'gtm-engine-prod')"]
|
||||
ServiceAccount["🤖 Service Account<br/>(Technischer User für API)"]
|
||||
Billing["💳 Corporate Billing<br/>(Zentrale Abrechnung)"]
|
||||
end
|
||||
|
||||
subgraph AI_Services ["🧠 AI Services (Vertex AI / Gemini)"]
|
||||
GeminiAPI["⚡ Gemini API<br/>(Enterprise Mode: Zero Logging)"]
|
||||
end
|
||||
end
|
||||
|
||||
%% Data Flow Connections
|
||||
CorpID -.->|"Verwaltet"| GCP_Project
|
||||
Docker -->|"Nutzt API Key"| ServiceAccount
|
||||
ServiceAccount -->|"Authentifiziert"| GeminiAPI
|
||||
|
||||
RawData --> Anonymizer
|
||||
Anonymizer -->|"1. Anonymisierter Prompt<br/>(Nur Firmendaten)"| Docker
|
||||
Docker -->|"2. API Request (HTTPS/TLS)"| GeminiAPI
|
||||
GeminiAPI -->|"3. JSON Response<br/>(Strukturierte Daten)"| Docker
|
||||
Docker -->|"4. Speicherung"| ResultStorage
|
||||
|
||||
%% Styling
|
||||
style Corporate_IT fill:#f9f9f9,stroke:#333,stroke-width:2px
|
||||
style Google_Cloud fill:#e8f0fe,stroke:#4285f4,stroke-width:2px
|
||||
style Anonymizer fill:#fff3e0,stroke:#f57c00,stroke-dasharray: 5 5
|
||||
style GeminiAPI fill:#e8f0fe,stroke:#4285f4,stroke-width:4px
|
||||
```
|
||||
|
||||
## Erläuterung für die IT
|
||||
|
||||
1. **Identity (IAM):**
|
||||
* Es wird kein "Schatten-Account" genutzt. Christian authentifiziert sich mit seiner bestehenden Corporate Identity (`@roboplanet`).
|
||||
* Für die automatisierte Ausführung (Skripte) wird später ein **Service Account** beantragt, dessen Schlüssel (JSON Key) sicher im lokalen Container verwaltet wird (Secrets Management).
|
||||
|
||||
2. **Google Cloud Projekt:**
|
||||
* Wir benötigen ein dediziertes GCP-Projekt (z.B. `rp-marketing-intel`), das im Rechnungskreis der Firma hängt.
|
||||
* Vorteil: Volle Transparenz über Kosten und Nutzung im Admin-Dashboard der IT.
|
||||
|
||||
3. **Environment Strategie (Dev/Prod Trennung):**
|
||||
* Um Entwicklungskosten von Betriebskosten sauber zu trennen und die Stabilität zu gewährleisten, werden **zwei separate GCP-Projekte** empfohlen:
|
||||
* **`rp-marketing-intel-dev`**: Sandbox für Entwicklung (Gemini CLI, Tests). Hier können Budgets gedeckelt und Quotas flexibel genutzt werden, ohne den Betrieb zu gefährden ("Blast Radius" Minimierung).
|
||||
* **`rp-marketing-intel-prod`**: Stabile Umgebung für den Company Explorer. Exklusive Quotas und striktes Monitoring für den operativen Betrieb.
|
||||
|
||||
4. **Datenschutz (DSGVO):**
|
||||
* **Input:** Wir senden Webseiten-Texte und Firmennamen an die API. Wir senden *keine* Mitarbeiterlisten oder Kunden-Adressdaten zur Analyse.
|
||||
* **Enterprise-Garantie:** Durch Nutzung der Enterprise-Verträge (via GCP) ist vertraglich geregelt, dass Google die Daten **nicht** zum Training eigener Modelle verwendet (anders als bei der kostenlosen ChatGPT/Gemini-Consumer-Version).
|
||||
|
||||
## Datenschutz- & Lizenz-Architektur (Das Zwei-Wege-Modell)
|
||||
|
||||
Um maximale Sicherheit und Compliance zu gewährleisten, trennen wir technisch strikt zwischen **Automatisierung** (Massenverarbeitung) und **Assistenz** (Ad-hoc Arbeit).
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
User[User: Floke]
|
||||
|
||||
subgraph Safe_Space_GCP ["Pfad A: Die Engine (Automation)"]
|
||||
style Safe_Space_GCP fill:#e6f4ea,stroke:#137333
|
||||
API[Python Scripts / GTM-Engine] --> Vertex[Google Vertex AI API]
|
||||
Vertex --> Processing[Data Processing in EU]
|
||||
Processing -- "No Training / Zero Retention" --> Output_API[Strukturierte Daten]
|
||||
end
|
||||
|
||||
subgraph Safe_Space_Workspace ["Pfad B: Der Assistent (Custom Chat)"]
|
||||
style Safe_Space_Workspace fill:#e8f0fe,stroke:#1967d2
|
||||
Browser[Browser / Local App] --> PythonApp[Custom Python Chatbot]
|
||||
PythonApp -- "Nutzt API Key" --> Vertex
|
||||
end
|
||||
|
||||
User -- "Programming / CLI" --> API
|
||||
User -- "Manual / Chat" --> Browser
|
||||
```
|
||||
|
||||
### Pfad A: Die Engine (Google Cloud Platform / Vertex AI)
|
||||
* **Einsatzzweck:** Automatisierte Skripte, Massenanalyse (GTM-Engine), Coding.
|
||||
* **Lizenz:** Pay-per-Use (über GCP Projekt). Keine User-Lizenz erforderlich.
|
||||
* **Datenschutz:**
|
||||
* **GCP Enterprise Terms:** Standardmäßig **kein Training** auf Kundendaten.
|
||||
* **Region Lock:** Datenverarbeitung wird technisch auf `europe-west3` (Frankfurt) oder `europe-west4` gezwungen.
|
||||
* **Zero Retention:** API-Calls werden nach Verarbeitung gelöscht (stateless).
|
||||
|
||||
### Pfad B: Der Assistent (Lokaler Chatbot)
|
||||
* **Einsatzzweck:** Ad-hoc Chat und Textarbeit.
|
||||
* **Lösung:** Da wir keine Gemini-Lizenzen für 350 User kaufen, bauen wir ein **eigenes, leichtgewichtiges Chat-Interface** (Python Streamlit).
|
||||
* **Datenschutz:** Dieses Tool greift auf **Pfad A (GCP API)** zu.
|
||||
* Vorteil: Wir nutzen die sichere Enterprise-API, ohne Office-Lizenzen ändern zu müssen.
|
||||
* Daten bleiben im kontrollierten GCP-Bereich.
|
||||
|
||||
## Strategie zur Lizenzierung & Kosten (Der "Cloud Identity Free" Ansatz)
|
||||
|
||||
**Ausgangslage:**
|
||||
RoboPlanet nutzt aktuell den **"Cloud Identity Free"** Tarif (primär für Android-Geräte-Verwaltung). Ein Upgrade auf kostenpflichtige Workspace-Lizenzen für alle 350+ User würde immense Fixkosten verursachen.
|
||||
|
||||
**Lösung: Entkopplung von User-Lizenz und KI-Leistung**
|
||||
Wir vermeiden ein globales Lizenz-Upgrade. Stattdessen nutzen wir die **Google Cloud Platform (GCP)**.
|
||||
* **Technik:** GCP-Projekte sind technisch vom Office-Tarif entkoppelt.
|
||||
* **Kosten:** Wir zahlen rein nutzungsbasiert (Pay-per-Use) für die API-Aufrufe.
|
||||
* **Vorteil:** Keine Änderung am bestehenden "Free Tier" Vertrag notwendig. Enterprise-Security gilt im GCP-Projekt automatisch.
|
||||
|
||||
## Spickzettel für den Termin (Fragen & Argumente)
|
||||
|
||||
### 1. Zum Lizenz-Status ("Kostenvermeidung")
|
||||
**Argument:**
|
||||
"Wir wollen auf keinen Fall für 350 User neue Lizenzen kaufen müssen, nur damit ich KI nutzen kann. Da wir im 'Cloud Identity Free' Tarif sind, ist der Weg über die **Google Cloud Platform (GCP)** der einzig sinnvolle. Dort zahlen wir nur, was wir verbrauchen (Pay-per-Use), ohne den Hauptvertrag anzufassen."
|
||||
|
||||
### 2. Zur Architektur ("Safe Space GCP")
|
||||
**Argument:**
|
||||
"Im GCP-Projekt gelten automatisch die B2B-Enterprise-Terms (kein Training auf Daten), egal welchen Status mein User hat. Ich werde technisch erzwingen, dass die Datenverarbeitung in **Frankfurt (europe-west3)** stattfindet."
|
||||
|
||||
### 3. Zur Datennutzung
|
||||
**Angebot:**
|
||||
"Ich richte eine strikte Trennung ein:
|
||||
* **Entwicklung (Dev):** Hier testen wir.
|
||||
* **Produktion (Prod):** Hier laufen die Tools.
|
||||
Dadurch verhindern wir, dass Testdaten in produktive Systeme gelangen oder Kosten aus dem Ruder laufen."
|
||||
|
||||
## Vorlage: Nachricht an die IT (Teams/Mail)
|
||||
|
||||
Hi [Name],
|
||||
|
||||
ich habe mich nochmal tiefer in die Google-Lizenz-Thematik eingegraben. Da wir ja aktuell im 'Cloud Identity Free' Tarif sind (primär für die Android-Geräte), würde ein Upgrade oder Lizenz-Wechsel bei 350 Usern ja sofort massive Kosten verursachen. Das wollen wir auf keinen Fall auslösen, nur weil ich ein Tool brauche.
|
||||
|
||||
**Daher mein Vorschlag für den schlanken Weg:**
|
||||
Wir lassen an den User-Konten/Lizenzen (Free Tier) alles exakt so, wie es ist.
|
||||
Stattdessen nutzen wir für meine KI-Themen einfach die **Google Cloud Platform (GCP)**. Ich habe gesehen, dass ich darauf mit meinem User sogar schon Zugriff habe.
|
||||
|
||||
Das GCP-Projekt ist technisch komplett unabhängig vom Office-Tarif. Wir zahlen dort rein **Pay-per-Use** für die API-Aufrufe (oft nur Cent-Beträge im laufenden Betrieb).
|
||||
|
||||
**Was mir dafür noch fehlt, ist das 'Billing' (Rechnungskonto):**
|
||||
Aktuell kann ich keine APIs aktivieren, weil kein Zahlungsmittel hinterlegt ist.
|
||||
|
||||
**Meine Bitte:**
|
||||
Könntet ihr mir bitte **zwei Projekte** anlegen und mit dem zentralen Firmen-Rechnungskonto verknüpfen?
|
||||
|
||||
1. `roboplanet-ai-dev` (Für Entwicklung & Tests, Sandbox)
|
||||
2. `roboplanet-ai-prod` (Für den stabilen Betrieb der Tools)
|
||||
|
||||
Danach könnt ihr mir einfach **Owner-Rechte** auf diese beiden Projekte geben. Den Rest (API-Aktivierung, Service Accounts, Region-Lock auf Frankfurt) richte ich dann selbst ein.
|
||||
|
||||
Das wäre die sauberste Lösung: Keine Fixkosten durch Lizenz-Upgrades, klare Trennung von Spielwiese und Produktion, und volle Kostentransparenz.
|
||||
|
||||
## Backend API (Company Explorer)
|
||||
|
||||
Das System verfügt bereits über eine standardisierte, dokumentierte API (FastAPI) zur Datenverarbeitung. Dies ermöglicht eine saubere Trennung von Frontend und Backend sowie eine granulare Zugriffskontrolle.
|
||||
|
||||
**Core Endpoints:**
|
||||
|
||||
| Methode | Pfad | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| `GET` | `/api/health` | System Status Check |
|
||||
| `GET` | `/api/companies` | Liste von Unternehmen (Filterbar, Sortierbar) |
|
||||
| `GET` | `/api/companies/{id}` | Detailansicht eines Unternehmens |
|
||||
| `POST` | `/api/companies` | Manuelle Anlage eines Unternehmens |
|
||||
| `POST` | `/api/companies/bulk` | Massenimport (Batch-Processing) |
|
||||
| `GET` | `/api/companies/export` | CSV Export der angereicherten Daten |
|
||||
|
||||
**Enrichment & KI-Analyse:**
|
||||
|
||||
| Methode | Pfad | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| `POST` | `/api/enrich/discover` | Startet Discovery-Prozess (Website-Suche) |
|
||||
| `POST` | `/api/enrich/analyze` | Startet KI-Analyse (Scraping + Klassifizierung) |
|
||||
| `PUT` | `/api/companies/{id}/industry` | Manuelle Korrektur der KI-Branchenzuordnung |
|
||||
| `POST` | `/api/companies/{id}/override/*` | Manuelle Overrides für kritische Datenquellen (Website, Wikipedia, Impressum) |
|
||||
|
||||
**Quality Assurance:**
|
||||
|
||||
| Methode | Pfad | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| `POST` | `/api/companies/{id}/report-mistake` | Melden von Datenfehlern ("Human in the Loop") |
|
||||
| `GET` | `/api/mistakes` | Übersicht gemeldeter Fehler zur Überprüfung |
|
||||
| `PUT` | `/api/mistakes/{id}` | Status-Update für Fehlermeldungen (Approved/Rejected) |
|
||||
|
||||
**Stammdaten & Kataloge:**
|
||||
|
||||
| Methode | Pfad | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| `GET` | `/api/robotics/categories` | Katalog der Robotik-Kategorien |
|
||||
| `GET` | `/api/industries` | Katalog der Branchen |
|
||||
| `GET` | `/api/job_roles` | Katalog der Job-Rollen |
|
||||
103
docs/BUILDER_APPS_MIGRATION.md
Normal file
103
docs/BUILDER_APPS_MIGRATION.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Migration Guide: Google AI Builder Apps -> Local Docker Stack
|
||||
|
||||
> **CRITICAL WARNINGS & BEST PRACTICES (READ BEFORE MIGRATION):**
|
||||
>
|
||||
> 1. **DIE GOLDENE REGEL DER STRINGS:** Nutze **NIEMALS** `f"""..."""` für komplexe Prompts oder Listen-Operationen mit verschachtelten Keys. Es führt unweigerlich zu `SyntaxError: unterminated string literal`. Nutze **AUSSCHLIESSLICH Triple Raw Quotes (`r"""..."""`)** und die **`.format()`** Methode.
|
||||
> 2. **SDK WAHL (DUAL SDK):** Das moderne `google-genai` ist gut, aber das Legacy `google-generativeai` ist oft stabiler für reinen Text (`gemini-2.0-flash`). Nutze die "Dual SDK Strategy", um beide je nach Bedarf zu verwenden.
|
||||
> 3. **GROUNDED TRUTH (MUSS):** Verlasse dich niemals auf das Wissen des Modells allein. Implementiere **immer** Web-Scraping (Homepage + Unterseiten) und SerpAPI-suchen, um das Modell mit Fakten zu füttern.
|
||||
> 4. **DOCKER VOLUMES:** Mounte **nur spezifische Dateien**, niemals den `dist`-Ordner überschreiben. Bei Syntax-Fehlern, die trotz Korrektur bleiben: `docker-compose build --no-cache`.
|
||||
|
||||
---
|
||||
|
||||
## 0. Der "Quick-Start" Checkliste (5-Minuten-Plan)
|
||||
|
||||
1. **SDKs:** Stehen `google-genai` UND `google-generativeai` in der `requirements.txt`?
|
||||
2. **Prompts:** Sind alle Prompts als `r"""...""".format()` angelegt?
|
||||
3. **Grounding:** Wird vor dem KI-Call die Webseite der Firma gescrapt?
|
||||
4. **Package.json:** Sind Build-Tools (`vite`, `typescript`) in `dependencies` (NICHT `devDependencies`)?
|
||||
5. **Vite Config:** Ist `base: './'` gesetzt?
|
||||
6. **DB-Datei:** Wurde die leere `.db`-Datei auf dem Host via `touch` erstellt?
|
||||
|
||||
---
|
||||
|
||||
## 1. Detaillierte Fehlerlösungen & Code-Vorlagen
|
||||
|
||||
Dieser Abschnitt enthält die aus der Git-Historie wiederhergestellten "Lessons Learned".
|
||||
|
||||
### 1.1 Python: Abhängigkeiten & SDKs (Häufigste Fehlerquelle)
|
||||
|
||||
**Problem 1: `ModuleNotFoundError` bei geteilten Bibliotheken**
|
||||
- **Fehler:** Eine kleine App stürzt ab, weil sie `helpers.py` importiert, aber nicht alle darin verwendeten Bibliotheken (z.B. `gspread`, `pandas`) in ihrer eigenen `requirements.txt` hat.
|
||||
- **Lösung (in `helpers.py`):** "Exotische" Importe optional machen.
|
||||
```python
|
||||
try:
|
||||
import gspread
|
||||
GSPREAD_AVAILABLE = True
|
||||
except ImportError:
|
||||
GSPREAD_AVAILABLE = False
|
||||
gspread = None # Wichtig, damit Referenzen nicht fehlschlagen
|
||||
```
|
||||
- **Lösung (in `requirements.txt` der App):** Nur die **direkt** für die App benötigten Pakete auflisten. Nicht blind die globale `requirements.txt` kopieren. Für eine typische App sind das oft nur:
|
||||
```text
|
||||
google-generativeai
|
||||
google-genai
|
||||
Pillow
|
||||
requests
|
||||
beautifulsoup4
|
||||
```
|
||||
|
||||
**Problem 2: `ImportError` für `Schema` oder `Content`**
|
||||
- **Fehler:** `ImportError: cannot import name 'Schema' from 'google.generativeai.types'`
|
||||
- **Ursache:** Der Code ist für eine neuere Version des `google-generativeai`-SDK geschrieben, aber im Projekt ist eine ältere Version (z.B. `0.3.0`) installiert, in der diese Klassen anders hießen oder nicht existierten.
|
||||
- **Lösung (für Legacy SDKs):**
|
||||
1. Entferne die direkten Importe für `Schema` und `Content`.
|
||||
2. Übergebe Konfigurationen wie `generation_config` als einfaches Python-Dictionary. Das alte SDK ist damit zufrieden.
|
||||
|
||||
**Problem 3: `AttributeError: module 'google.generativeai' has no attribute 'Client'`**
|
||||
- **Ursache:** Der Code verwendet eine veraltete API (`genai.Client`), die im SDK entfernt wurde.
|
||||
- **Lösung:** Den Code auf die moderne `GenerativeModel`-API umstellen.
|
||||
```python
|
||||
genai.configure(api_key="YOUR_KEY")
|
||||
model = genai.GenerativeModel('gemini-1.5-flash-latest')
|
||||
response = model.generate_content(...)
|
||||
```
|
||||
|
||||
### 1.2 Frontend: Build-Prozess & Server
|
||||
|
||||
**Problem 1: `npm run build` schlägt im Docker-Container fehl**
|
||||
- **Ursache:** Wichtige Build-Tools (`vite`, `typescript` etc.) stehen fälschlicherweise in `devDependencies` in der `package.json`. Der Docker-Build installiert diese standardmäßig nicht.
|
||||
- **Lösung:** **Alle** `devDependencies` in die `dependencies` verschieben.
|
||||
|
||||
**Problem 2: "White Screen" - App lädt nicht**
|
||||
- **Ursache:** Die App wird unter einem Unterpfad (z.B. `/ce/`) bereitgestellt, aber Vite sucht die JS/CSS-Dateien im Root (`/`).
|
||||
- **Lösung (in `vite.config.ts`):** Den Basispfad anpassen.
|
||||
```typescript
|
||||
export default defineConfig({
|
||||
base: './', // Zwingt Vite, relative Pfade zu nutzen
|
||||
});
|
||||
```
|
||||
### 1.3 Docker & Datenbank
|
||||
|
||||
**Problem 1: `OperationalError: no such table`**
|
||||
- **Ursache:** Die `.db`-Datei wurde zwar mit `touch` erstellt, ist aber leer. Die Tabellen wurden nie initialisiert.
|
||||
- **Lösung:** Die Datenbank-Initialisierung (z.B. `python3 db_manager.py init`) MUSS beim Start des `server.cjs` automatisch ausgeführt werden.
|
||||
```javascript
|
||||
// In server.cjs am Anfang
|
||||
const { spawn } = require('child_process');
|
||||
const dbScript = path.join(__dirname, 'gtm_db_manager.py'); // Pfad anpassen
|
||||
spawn('python3', [dbScript, 'init']);
|
||||
```
|
||||
|
||||
**Problem 2: Code-Änderungen werden nicht übernommen ("Geisterfehler")**
|
||||
- **Ursache:** Ein Volume-Mount in `docker-compose.yml` überschreibt die neueren Dateien im Image mit alten, lokalen Dateien. Besonders tückisch, wenn `server.cjs` an die falsche Stelle gemountet wird.
|
||||
- **Lösung:**
|
||||
1. **Immer `git pull`** auf dem Host ausführen, bevor `docker-compose build` aufgerufen wird.
|
||||
2. Mount-Pfade präzise setzen. Wenn das Dockerfile `server.cjs` in `/app/server.cjs` kopiert, muss der Mount genau dorthin zeigen:
|
||||
```yaml
|
||||
volumes:
|
||||
- ./my-app-folder/server.cjs:/app/server.cjs # Korrekt
|
||||
- ./my-app-folder/:/app/my-app-folder/ # Falsch
|
||||
```
|
||||
|
||||
---
|
||||
*Dokumentation wiederhergestellt und erweitert am 15.01.2026.*
|
||||
467
docs/Direktive_Zusammenarbeit.md
Normal file
467
docs/Direktive_Zusammenarbeit.md
Normal file
@@ -0,0 +1,467 @@
|
||||
A) Überblick
|
||||
|
||||
* Kontext des Dialogs (2–5 Sätze): Der Chat dreht sich um den Aufbau eines stabilen “Dev-Betriebssystems” rund um deine Synology/Docker-Umgebung: zuverlässiger Zugriff auf dein Gitea-Repo (Brancheneinstufung2), funktionierende Notion-Integration (#task/#fertig inkl. Zeiterfassung/Status-Reports) und die Umsetzung eines Features im “Meeting Assistant / Transcription Tool” (Ordner + Tags inkl. Tag-Vorschläge). Parallel tauchen wiederholt Infrastruktur-Probleme auf (DNS/Timeouts beim Repo-Zugriff, falsche Branch-/Pfadannahmen, unklare Persistenz von Moltbot-Memories).
|
||||
* Ziel(e) des Users:
|
||||
|
||||
* Stabiler, vollständiger Repo-Zugriff (keine “Download-Ausreden”), inkl. DNS-Workaround.
|
||||
* Verlässlicher #task/#fertig-Workflow mit Notion-Sync, inkl. Zeiterfassung als Zahl (für Rollups), Status-Reports als Page-Content.
|
||||
* Feature: Transkripte in Ordnern organisieren + taggen; existierende Tags sollen beim Vertaggen vorgeschlagen werden; ohne API-Overengineering (“dead simple tool”).
|
||||
* Operatives Arbeitsmodell: “Planen vor Entwickeln”, schnelle Iteration, proaktive Updates/Heartbeat.
|
||||
* Datensicherheit: Moltbot-Workspace/Memories müssen persistent + backupped sein.
|
||||
* Ergebnisstand:
|
||||
|
||||
* Entschieden/umgesetzt: Einführung #task/#fertig (Konzept), Option “Neuen Task anlegen”, Notion-Task für “Ordner und Tags…” wurde am Ende sichtbar angelegt; Status-Block wurde nach “Go” in Notion geschrieben; Total Duration (h) wurde als Zahl gepflegt (2.5h) und der sichtbare Textblock wurde nachträglich bereinigt (ohne “ca. 02:30”).
|
||||
* Offen/unklar: Feature-Code ist zeitweise am falschen Ort gelandet (Streamlit root app.py vs. laufender Container uvicorn backend.app); Push/Branch-Ziel war falsch bzw. nicht sichtbar (“Already up to date”); Persistenzpfad der Moltbot-Memories ist widersprüchlich/unklar (clawd vs .clawdbot/persistent_clawd).
|
||||
|
||||
B) Themencluster mit Detail-Extraktion
|
||||
|
||||
Cluster 1: Initialer Kontext & “Memory-Absorption”
|
||||
|
||||
* Kernaussage: Zu Beginn wird behauptet, eine alte Datenbank (main.sqlite) sei “absorbiert” und daraus seien Memory-Artefakte rekonstruiert; später zeigt sich, dass der sichtbare Inhalt der Tageslogs sehr dünn ist.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Datenquelle: “main.sqlite” (alte DB) wurde verarbeitet/“absorbiert”.
|
||||
* Artefakte: MEMORY.md, tägliche Logs (z. B. 2026-02-13.md) werden als Ergebnis erwähnt.
|
||||
* Späterer Ist-Stand: Datei 2026-02-13.md enthält “nur” einen WhatsApp-Splitter; Begründung: mehr stand für den Tag nicht in der DB.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Keine Erfindungen: nur Daten, die tatsächlich in DB/Logs stehen.
|
||||
* Memory-Pflege soll zuverlässig erfolgen.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung (implizit): Memory-Führung über MEMORY.md + Tageslogs als “Historie”.
|
||||
* Begründung: Sitzungshistorie/“Gedächtnisproblem” aus Gemini CLI soll durch Doku/Readmes gelöst werden.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Zugriff auf die tatsächlichen persistierten Dateien (Host-Mount) muss stimmen (später strittig).
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Widerspruch zwischen “vollständig absorbiert” und “sichtbar kaum Inhalt”; Risiko falscher Erwartung an “Memory-Wiederherstellung”.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Welche Inhalte sollten wirklich in MEMORY.md “Ground Truth” vs. nur in Tageslogs landen?
|
||||
* Fundstellen:
|
||||
|
||||
* „…absorbed the database (main.sqlite)…“ (früh, Zeile 1)
|
||||
* „…steht dort nur:“ (nahe Ende, Zeile 2401)
|
||||
* „…nur ein einzelner … Splitter…“ (nahe Ende, Zeilen 2408–2410)
|
||||
|
||||
Cluster 2: Rollen-/Arbeitsmodus & Prozessregeln (Planen, Pragmatismus, Proaktivität)
|
||||
|
||||
* Kernaussage: Du definierst klar: du bist kein Entwickler; es wird geplant, bevor Code entsteht; schnell & pragmatisch; proaktive Kommunikation (Heartbeat) ist Pflicht.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* User-Constraint: „ICH bin kein Entwickler… verstehe absolut nichts von Code.“
|
||||
* Prozessregel: „BEVOR wir entwickeln planen wir!“
|
||||
* Zielarchitektur: “viele kleine Tools” statt “ein Tool, was alles erschlägt”.
|
||||
* Iterationsprinzip: “schnell entwickeln um früh Ergebnisse zu sehen”.
|
||||
* Kommunikationspflicht: proaktive Rückmeldung; nicht “anhauen” müssen.
|
||||
* Heartbeat-Anforderung: alle 2 Minuten Mini-Update (3–5 Stichpunkte).
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Keine “internal voice” / keine Tool-Artefakte oder Code-Rohblöcke in Antworten.
|
||||
* Proaktive Statusmeldungen nach Abschluss jeder Aufgabe.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung: Einführung “Mini-Updates alle 2 Minuten” als Transparenzersatz für CLI-Logs.
|
||||
* Begründung: In Chat fehlt sichtbarer Fortschritt (“black box”); Gemini CLI bietet Live-Feedback.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Disziplin im Kommunikationsrhythmus; klare Definition, was “fertig” bedeutet (Push + Hinweis “Restart Container X”).
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Mehrfacher Verstoß: Update kam nach 7 Minuten statt 2.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Welche Aktionen gelten als “done” (Code geändert vs. gepusht vs. deployed/tested)?
|
||||
* Fundstellen:
|
||||
|
||||
* „ICH bin kein Entwickler…“ (früh-mittig, Zeile 400)
|
||||
* „BEVOR wir entwickeln planen wir!“ (mittig, Zeile 415)
|
||||
* „alle 2 Minuten … mini-update…“ (mittig, Zeile 1027)
|
||||
* „letzte Rückmeldung ist 7 Minuten her…“ (mittig, Zeile 1071)
|
||||
|
||||
Cluster 3: Gitea/Repo-Zugriff, Auth & Stabilität (Token, DNS, Timeout)
|
||||
|
||||
* Kernaussage: Repo-Zugriff war instabil (Auth-Fehler, Gateways/Timeout, DNS-Resolution). Du verlangst vollständigen Zugriff ohne Ausreden; als Workaround wird /etc/hosts mit externer IP eingesetzt.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Gitea Host: floke-gitea.duckdns.org (öffentlich), intern 192.168.178.6:3000 (nicht erreichbar von extern).
|
||||
* DNS-Fehler: “Failed to resolve 'floke-gitea.duckdns.org'” tritt auf.
|
||||
* Repo-Download via Skript: fetch_repo_files.py, Zähler “937 Dateien”, später “über 700 von 937”.
|
||||
* Dynamische IP: aktuell 84.190.111.140; DuckDNS wegen wechselnder IP.
|
||||
* /etc/hosts Workaround: Eintrag 84.190.111.140 → floke-gitea.duckdns.org wurde gesetzt; gilt bis IP-Wechsel.
|
||||
* User-Constraint: „DU MUSST alle Dateien im Zugriff haben… Ausreden … gelten ab jetzt nicht mehr.“ (im Chat: Zeile 1895)
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Repo vollständig verfügbar; Tools dürfen “die ganze Nacht” laufen.
|
||||
* Keine Abhängigkeit von instabilem DNS ohne Fallback.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung: /etc/hosts Hard-Pinning als kurzfristiger Fix.
|
||||
* Begründung: DNS-NameResolutionError verhindert zuverlässigen Pull/Dateizugriff.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Externe IP muss bekannt sein (oder aus DNS ableitbar); bei IP-Wechsel erneuern.
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* /etc/hosts ist fragil bei dynamischer IP (bekannt/benannt).
|
||||
* “Massen-Download” kann Dateien überspringen → Inkonsistenzen.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Soll es einen dauerhaften Sync-Mechanismus geben (Cron) und wo läuft er tatsächlich (Host vs Container)?
|
||||
* Fundstellen:
|
||||
|
||||
* „Failed to resolve…“ (mittig, Zeile 601)
|
||||
* „Ausreden… gelten ab jetzt nicht mehr.“ (mittig, Zeile 1895)
|
||||
* „IP … 84.190.111.140… /etc/hosts…“ (mittig, Zeilen 1926–1933)
|
||||
|
||||
Cluster 4: Notion-Integration & #task/#fertig-Betriebssystem (inkl. Zeiterfassung)
|
||||
|
||||
* Kernaussage: #task/#fertig wird als Trigger-Protokoll etabliert, soll Notion-Projekte/Tasks synchronisieren und Zeit als numerisches Feld pro Task pflegen; mehrere Fehlversuche durch falsche DB-IDs; am Ende ist der Task sichtbar und Status-Reports werden korrekt als Page-Content geschrieben.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Trigger: #task startet, #fertig beendet.
|
||||
* Freigabe: Zusammenfassung/Todos vorformulieren, User gibt 👍/❤️/Go frei.
|
||||
* Projekte-Liste in Notion [UT] (23 Projekte), u. a. [15] “Meeting Assistant (Transkription Tool)”.
|
||||
* Notion-Fehler: 400 Bad Request wegen falscher IDs/Filter.
|
||||
* Projekt-ID für Meeting Assistant: 2f388f42-8544-80fb-ae36-f6879ec535a4.
|
||||
* Tasks-DB-ID war falsch; später “korrekte Datenbank-ID”: 2e888f42-8544-8153-beac-e604719029cf.
|
||||
* Task-Anlage am Ende erfolgreich: „task ist jetzt da!“.
|
||||
* Status-Reports als Page-Content: Beispiel-Format “## 🤖 Status-Update (YYYY-MM-DD HH:MM Berlin Time)” und YAML/Code-Block.
|
||||
* Zeit-Constraint: Zeit muss als Zahl/Integer am Task gespeichert werden (Rollup summiert Projekte automatisch).
|
||||
* Korrektur: Text “ca. 02:30” blieb sichtbar, Datenfeld wurde separat aktualisiert (2.5); danach wurde Textblock gelöscht/neu gepostet; User bestätigt “schaut gut aus”.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Option “Neuen Task anlegen” muss immer angeboten werden.
|
||||
* Keine Code-Snippets/“internal voice” in Chat-Antworten.
|
||||
* Zeit als numerisches Feld (Total Duration (h)), kein “ca.” im sichtbaren Report, Konsistenz zwischen Textblock und Feld.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung: Cache der Project-Liste lokal, stündliche Aktualisierung (Cron-Idee).
|
||||
* Begründung: schneller Zugriff ohne Notion-Latenz.
|
||||
* Entscheidung: Status-Report wird erst nach “Go” geschrieben.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Notion-Integration muss Zugriff auf DBs haben (Invite/Permissions implizit); korrekte DB-IDs.
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Wiederholte Annahmen/“Raten” von IDs führte zu langem Stillstand.
|
||||
* Sichtbare Formatierungsartefakte durch Notion Code-Block Highlighting.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Wie werden Task-IDs/Session state verlässlich gespeichert (current_task.json) und wo liegt sie (Host-Mount)?
|
||||
* Fundstellen:
|
||||
|
||||
* „…musste … erraten…“ (mittig, Zeile 549)
|
||||
* „task ist jetzt da!“ (spät, Zeile 2021)
|
||||
* „Uhrzeit … als Integer…“ (spät, Zeile 2104)
|
||||
* „jetzt schaut es gut aus!“ (spät, Zeile 2160)
|
||||
|
||||
Cluster 5: Feature-Anforderung “Ordner & Tags” (Scope, Simplifizierung, Tag-Vorschläge)
|
||||
|
||||
* Kernaussage: Du willst Ordner + Tags direkt im Transcription Tool; bestehende Tags sollen vorgeschlagen werden; kein API-Layer, vorher Doku/Code lesen, “dead simple”.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Feature-Beschreibung: „Transkripte in Ordner sortieren und vertaggen“ + „Bestehende Tags sollen … vorgeschlagen werden.“
|
||||
* Architektur-Constraint: „Wir benötigen hier keine API … dead simple tool.“
|
||||
* Plan-vor-Code wird eingefordert. (aus Cluster 2, gilt hier)
|
||||
* Erste (spätere) Minimal-Implementationsidee: folder + tags als Spalten in SQLite-Tabelle; UI Felder für Ordner/Tags.
|
||||
* Gap: Tag-Vorschläge waren zunächst nicht umgesetzt (nur freies Textfeld), wurde intern als fehlend erkannt.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Muss: Ordner setzen + Tags speichern.
|
||||
* Muss: existierende Tags vorschlagen (Autocomplete/Multiselect/Hint-Liste).
|
||||
* Soll: keine neue Tabellen/Overengineering, wenn nicht nötig.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung (proposed): “radikal pragmatisch” → Spalten statt relationales Tag-Schema.
|
||||
* Begründung: “dead simple”, schnelle Iteration.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Kenntnis des echten Persistenz-/DB-Pfads des Tools (später strittig: transcriptions.db vs meetings.db).
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Wenn falsche Codebasis bearbeitet wird, wird Feature nicht im laufenden Tool sichtbar (ist passiert).
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Wo liegt die “Source of Truth” DB (meetings.db?) und welche Tabelle ist maßgeblich (meetings vs transcriptions)?
|
||||
* Fundstellen:
|
||||
|
||||
* „Ordner und Tags… Bestehende Tags… vorgeschlagen…“ (mittig, Zeile 791)
|
||||
* „…keine API… dead simple…“ (mittig, Zeile 864)
|
||||
|
||||
Cluster 6: Codebase-Verwechslung & Deployment-Realität (Streamlit app.py vs uvicorn backend.app)
|
||||
|
||||
* Kernaussage: Es wurde zunächst an einer root app.py (Streamlit) gearbeitet, aber der tatsächlich laufende Container “transcription-app” startet uvicorn backend.app (FastAPI). Dadurch sind Push/Restart-Schritte zunächst wirkungslos bzw. am falschen Artefakt.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Laufende Container: transcription-app (ID a74b0b2853ec), Image brancheneinstufung-transcription-app, Command “uvicorn backend.app…”, Port 8001:8001.
|
||||
* Streamlit-Container existiert: lead-engine (great_gauss) läuft “streamlit run app.py”.
|
||||
* Erkenntnis: Diskrepanz wurde explizit benannt; Hypothese: falsche Datei bearbeitet/Legacy.
|
||||
* User-Anforderung: exakten Containername/ID nennen, um Fehl-Restarts zu vermeiden.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Restart-Anweisung muss immer konkret sein: Container-Name + ID.
|
||||
* Vor Änderungen: Build/Entry-Point des Containers verifizieren (docker-compose/Dockerfile/WORKDIR).
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung (nachträglich): erst verifizieren, dann restart.
|
||||
* Begründung: Sonst “eine halbe Stunde das falsche” (dein Feedback-Constraint).
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Repo-Struktur: Es gibt Hinweis, dass das Projekt unter Brancheneinstufung2/transcription-tool liegt.
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Falscher Branch/Pfad → Push “nicht sichtbar”; git pull zeigt “Already up to date”.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Welche Dateien werden in das transcription-app Image kopiert/mounted (WORKDIR, build context)?
|
||||
* Fundstellen:
|
||||
|
||||
* „transcription-app … uvicorn backend.app…“ (mittig, Zeilen 1255–1257)
|
||||
* „Diskrepanz…“ (mittig, Zeilen 1331–1335)
|
||||
* „git pull … Already up to date.“ (spät, Zeilen 2186–2188)
|
||||
|
||||
Cluster 7: Git Branching/Push-Probleme & Repo-Größe
|
||||
|
||||
* Kernaussage: Änderungen wurden nicht dort sichtbar, wo du sie erwartest; es gab Branch-Verwirrung (feature/task… vs master/main) und Klon-Timeouts (Repo “zu groß”).
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Symptom: git pull auf Synology zeigt “Already up to date”, obwohl Änderungen erwartet.
|
||||
* User-Hypothese: falscher Branch; “transcription-tool … der falsche Branch enthält wohl das komplette Projekt”.
|
||||
* Assistant-Annahme: aktiver Dev-Branch: feature/task-2f488f42-prepare-timetracking-for-projects-tasks-2.
|
||||
* Klon scheitert mit Timeout; Shallow clone (--depth 1) als Gegenmaßnahme.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Push muss verifiziert werden (nach dem Push: sichtbarer Commit/Hash + Remote-Branch).
|
||||
* Repo-Sync robust (DNS/Timeout-resilient).
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung (Plan): lokales kaputtes Verzeichnis löschen, sauber neu klonen, Änderungen neu anwenden, korrekt pushen.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Stabile Gitea-Erreichbarkeit; korrekter Branch-Name; korrekter Build-Context fürs Deployment.
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Wenn der Build auf “transcription-tool/” basiert, sind Änderungen im Root per se irrelevant.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Welcher Branch ist “deployment-relevant” (main vs feature vs transcription-tool)?
|
||||
* Fundstellen:
|
||||
|
||||
* „I believe you have a wrong branch… transcription-tool…“ (spät, Zeilen 2212–2216)
|
||||
* „…Repo … zu groß … Timeout… shallow clone…“ (spät, Zeilen 2237–2241)
|
||||
|
||||
Cluster 8: Moltbot-Persistenz & Backup (update.sh vs backup.sh; Speicherorte)
|
||||
|
||||
* Kernaussage: Dein bisheriger Job ist ein Update, kein Backup; es wird ein backup.sh vorgeschlagen; gleichzeitig ist unklar/widersprüchlich, wo Moltbot-Memories tatsächlich persistent liegen (clawd vs .clawdbot/persistent_clawd) und wie du sie auf dem Host siehst.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* Cron/Job: alle zwei Tage nächtliches Update/“Backup”: `/volume1/docker/moltbot/update.sh >> .../backups/update.log`.
|
||||
* update.sh Inhalte: docker compose pull → up -d --force-recreate → image prune -f.
|
||||
* Aussage: Update ≠ Backup; Workspace-Ordner muss separat gesichert werden (tar.gz), Beispielpfad SOURCE_DIR="/volume1/docker/moltbot/moltbot/clawd".
|
||||
* User-Frage: Läuft im Container – sind Memories sicher auf Festplatte?
|
||||
* Assistant-Annahme: docker-compose Volume `./clawd:/home/node/clawd` sei “Lebensversicherung”. (als Annahme formuliert)
|
||||
* Spätere Persistenz-Diskussion: Kopie von /home/node/clawd (flüchtig) nach /home/node/.clawdbot/persistent_clawd (sicher) + inbound media unter /home/node/.clawdbot/media/inbound.
|
||||
* User-Beobachtung: inbound media waren “vorhin” in anderer Ordnerstruktur, jetzt in moltbot/storage/media; Frage “wo ist heutige Sitzung gespeichert”.
|
||||
* Nach docker cp: 2026-02-13.md ist kurz; angeblich normal.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Muss: echtes Backup des persistenten Workspace vor Updates.
|
||||
* Muss: Transparenz, welcher Pfad “Source of Truth” ist und wie er auf Synology sichtbar ist.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Entscheidung (User): backup.sh sinnvoll, soll angelegt werden.
|
||||
* Entscheidung (Assistant): “kopieren, nicht löschen” beim Umzug in persistent_clawd, um Risiko zu vermeiden.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Korrektes Volume-Mapping in docker-compose (unklar, weil angenommen).
|
||||
* Zugriff auf Container-FS vs Host-FS (Synology Pfade).
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Widerspruch: Einerseits wird behauptet, persistent_clawd sei “sicher auf Diskstation”; andererseits sieht der User im Host-Pfad zunächst nur main.sqlite bzw. kaum Memories (Interpretation: Persistenzpfad/Mapping stimmt evtl. nicht).
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Welches Verzeichnis ist tatsächlich gemountet: /home/node/clawd oder /home/node/.clawdbot/* ?
|
||||
* Fundstellen:
|
||||
|
||||
* „Nein, … kritisches Missverständnis. … Update … kein Backup.“ (mittig, Zeilen 677–683)
|
||||
* „…Volume… ./clawd:/home/node/clawd“ (mittig, Zeilen 730–746)
|
||||
* „…kopiere … nach … persistent_clawd…“ (spät, Zeilen 2254–2256)
|
||||
|
||||
Cluster 9: “Fehlende Datei / Arbeitsgrundlage”
|
||||
|
||||
* Kernaussage: Du erwartest eine Datei big_Fortschritt_marketingautomation.txt als zentrale Grundlage; sie ist im Container/Repo nicht auffindbar.
|
||||
* Extrahierte Fakten (Detail-Ebene):
|
||||
|
||||
* User-Claim: Datei sei “Blaupause unserer Zusammenarbeit”.
|
||||
* Assistant-Status: Datei im Arbeitsverzeichnis nicht vorhanden.
|
||||
* Anforderungen / Constraints / Kriterien:
|
||||
|
||||
* Muss: Datei bereitstellen oder Alternativquelle nennen.
|
||||
* Entscheidungen & Begründungen:
|
||||
|
||||
* Keine finale Entscheidung; nur Hinweis “nicht gefunden”.
|
||||
* Abhängigkeiten & Voraussetzungen:
|
||||
|
||||
* Datei muss entweder im Repo liegen oder separat hochgeladen werden.
|
||||
* Risiken / Probleme / Streitpunkte:
|
||||
|
||||
* Ohne diese Grundlage ist unklar, welche “bekannten Regeln/Blueprint” bereits als verbindlich gelten.
|
||||
* Offene Fragen im Cluster:
|
||||
|
||||
* Wo liegt die Datei (Repo-Pfad, Synology-Pfad)?
|
||||
* Fundstellen:
|
||||
|
||||
* „…big_Fortschritt_marketingautomation.txt … Blaupause…“ (nahe Ende, Zeilen 2421–2424)
|
||||
|
||||
C) Konsolidierte Artefakte
|
||||
|
||||
1. Glossar / Entitäten-Liste
|
||||
|
||||
* Systeme/Tools
|
||||
|
||||
* Synology DiskStation (“Diskstation2”): Host, auf dem Docker + Repos liegen.
|
||||
* Docker / docker compose: Deployment/Restart/Update-Mechanik.
|
||||
* Gitea: self-hosted Git (Domain floke-gitea.duckdns.org; Container gitea-gitea-pub-1-2).
|
||||
* DuckDNS: DynDNS-Service; Container “duckdns”.
|
||||
* Notion: Project/Task-DBs (“Projects [UT]”, “Tasks [UT]”), Rollups auf Projektebene.
|
||||
* Moltbot (OpenClaw): Container “openclaw-gateway”, Image ghcr.io/openclaw/moltbot:main.
|
||||
* Projekte/Repos
|
||||
|
||||
* Brancheneinstufung2: zentrales Repo; enthält u. a. “transcription-tool”.
|
||||
* Meeting Assistant (Transkription Tool): Notion-Projekt [15].
|
||||
* Lead Engine: Container “great_gauss” (Streamlit).
|
||||
* Skripte/Dateien
|
||||
|
||||
* update.sh: führt docker compose pull/up/prune aus.
|
||||
* backup.sh (vorgeschlagen): tar.gz Backup des Workspace.
|
||||
* dev_session.py: Referenz für Notion-Sync/Status-Reports (als bestehende Logik erwähnt).
|
||||
* fetch_repo_files.py: Datei-für-Datei Download (Resumable).
|
||||
* current_task.json: Session-State (Task-ID, Startzeit) – als Konzept erwähnt.
|
||||
* Personen/Benennungen
|
||||
|
||||
* User: “Floke” (Host-Pfad /volume1/homes/Floke/…, Gitea user).
|
||||
* “Axel”: als Referenz im SystemPrompt (“Seniorität vor Axel”) erwähnt.
|
||||
* Sensible Daten (maskiert)
|
||||
|
||||
* Notion API Token wurde im Chat genannt (beginnt mit „ntn_…“).
|
||||
* Gitea Token wurden im Chat genannt (alt/neu), mehrfach gewechselt (maskiert; konkrete Werte nicht wiederholt).
|
||||
|
||||
2. Timeline (Datums-/Zeitbezüge in Reihenfolge)
|
||||
|
||||
* 2026-01-31 09:31 (Berlin Time): Beispiel eines Status-Update-Blocks (YAML/Code-Block) aus früherer Nutzung.
|
||||
* 2026-02-13: Tageslog 2026-02-13.md enthält nur einen “Splitter” aus main.sqlite.
|
||||
* 2026-02-14 21:00 (Berlin Time): Status-Update für “gestern” wird im gewünschten Format erstellt und nach “Go” gepostet; danach Format/Zeiterfassung bereinigt.
|
||||
* 2026-02-15: Referenz auf “heutige Sitzung” und Pfade 2026-02-15.md (flüchtig vs sicher) wird diskutiert.
|
||||
|
||||
3. Entscheidungslog (Entscheidung → Datum/Phase → Begründung → Auswirkungen)
|
||||
|
||||
* #task/#fertig als Arbeitsprotokoll → Phase “Workflow-Etablierung” → Kontext/History wie Gemini dev_session → Grundlage für Notion-Sync, Zeitmessung, Freigabeprozess.
|
||||
* Option “Neuen Task anlegen” in Taskliste → Phase “Task-UX” → schneller Task-Capture → ermöglicht “Ordner und Tags…” Task-Anlage.
|
||||
* Zeit als numerischer Wert am Task (Total Duration (h)) → Phase “Notion-Qualität” → Rollups brauchen Zahl, kein “ca.” → Textblock + Feld wurden getrennt korrigiert.
|
||||
* /etc/hosts Hard-Pinning auf 84.190.111.140 → Phase “DNS-Stabilisierung” → Download-/Sync-Stabilität kurzfristig → bricht bei IP-Wechsel.
|
||||
* Backup.sh vor update.sh → Phase “Datensicherheit” → Update ist kein Backup → Reduziert Risiko totalen Memory-Verlusts.
|
||||
* “Dead simple, keine API” für Feature → Phase “Scope-Kontrolle” → Minimiert Overengineering → verlangt korrekte Codebase/DB-Pfad-Klärung.
|
||||
|
||||
4. To-do Liste (Aufgabe → Owner → Deadline → Priorität)
|
||||
|
||||
* Verifizieren, welche Codebase der transcription-app Container nutzt (WORKDIR/Build Context; Ordner Brancheneinstufung2/transcription-tool) → Owner: Assistent+User → Prio: Hoch.
|
||||
* Feature “Ordner & Tags” im *tatsächlich laufenden* Tool implementieren (inkl. Tag-Vorschläge) → Owner: Assistent → Prio: Hoch.
|
||||
* Push/Branch-Strategie klären (welcher Branch deployt wird; Push verifizieren) → Owner: Assistent+User → Prio: Hoch.
|
||||
* Backup.sh auf Synology platzieren + Cronjob: backup.sh vor update.sh → Owner: User (Datei verschieben, Cron) → Prio: Hoch.
|
||||
* Persistenzpfad Moltbot endgültig klären (clawd vs .clawdbot/persistent_clawd; Host-Sichtbarkeit) → Owner: Assistent+User → Prio: Hoch.
|
||||
* Datei big_Fortschritt_marketingautomation.txt lokalisieren oder bereitstellen → Owner: User → Prio: Mittel.
|
||||
* Kommunikationsregel operationalisieren (2-Minuten Heartbeat, Abschluss-Ping) → Owner: Assistent → Prio: Hoch.
|
||||
|
||||
5. Anforderungskatalog: Muss / Soll / Kann
|
||||
|
||||
* Muss
|
||||
|
||||
* Planen vor Code.
|
||||
* Proaktive Rückmeldung + Heartbeat alle 2 Minuten während Arbeit.
|
||||
* #task/#fertig Workflow inkl. “Neuen Task anlegen”.
|
||||
* Zeiterfassung als numerischer Wert am Task (für Rollups).
|
||||
* Feature: Ordner + Tags + Vorschläge bestehender Tags.
|
||||
* Repo-Zugriff vollständig und stabil (keine Download-Ausreden).
|
||||
* Backup vor Update (update.sh ist kein Backup).
|
||||
* Soll
|
||||
|
||||
* “Dead simple tool”, keine zusätzliche API-Schicht.
|
||||
* Konkrete Restart-Anweisung inkl. Container-ID/Name.
|
||||
* Keine “internal voice” und keine Roh-Toolausgaben.
|
||||
* Kann
|
||||
|
||||
* Tool-Index/PROJECTS.md als “Kartei”, um Entry-Points/Readmes nicht neu suchen zu müssen.
|
||||
* Automatischer Repo-Sync-Cron (nachts) zur Vermeidung von DNS-/Timeout-Friktion.
|
||||
|
||||
6. Zahlen & Parameter (Bulletliste: Parameter → Wert → Kontext)
|
||||
|
||||
* Gitea interne IP → 192.168.178.6:3000 → lokal erreichbar, extern nicht.
|
||||
* Gitea externe IP (aktuell) → 84.190.111.140 → dyn. IP; /etc/hosts Fix.
|
||||
* Repo Download Count → 937 Dateien (700+ erreicht) → fetch_repo_files.py Fortschritt.
|
||||
* Notion Projekt-ID (Meeting Assistant) → 2f388f42-8544-80fb-ae36-f6879ec535a4 → Task-Filterversuche.
|
||||
* Notion Tasks DB-ID (korrekt) → 2e888f42-8544-8153-beac-e604719029cf → Fix für Task-Creation.
|
||||
* Zeiterfassung (Beispiel) → 2.5 Stunden → Total Duration (h) als Zahl am Task.
|
||||
* Docker transcription-app → ID a74b0b2853ec, Port 8001→8001, Command uvicorn backend.app → tatsächliche Laufzeitbasis.
|
||||
* Docker openclaw-gateway → Port 18789→18789 → Moltbot Gateway.
|
||||
* Update-Frequenz → “alle zwei Tage ein nächtliches Update/Backup” → via update.sh.
|
||||
|
||||
D) Widersprüche & Inkonsistenzen
|
||||
|
||||
Konflikt 1: “Feature in app.py fertig + DB migriert + gepusht” vs “git pull Already up to date / keine Änderungen sichtbar”
|
||||
|
||||
* Aussage A: „…Alles ist … auf dem main-Branch gepusht.“
|
||||
* Aussage B: User: „git pull … Already up to date.“
|
||||
* Warum Konflikt: Entweder wurde nicht gepusht, auf falschen Branch gepusht, oder in falschem Repo/Verzeichnis gearbeitet.
|
||||
* Klärung nötig: Welcher Branch ist “Deployment-Branch”? Wurde überhaupt ein Commit erzeugt? (commit hash/remote branch prüfen).
|
||||
|
||||
Konflikt 2: “Meeting Assistant ist Streamlit (root app.py)” vs “laufender Container transcription-app ist FastAPI (uvicorn backend.app)”
|
||||
|
||||
* Aussage A: „…app.py … Streamlit…“
|
||||
* Aussage B: docker ps zeigt “uvicorn backend.app” für transcription-app.
|
||||
* Warum Konflikt: Es existieren offenbar mehrere Implementationen/Generationen; die bearbeitete Datei war nicht der aktive Entry-Point.
|
||||
* Klärung nötig: Build context/WORKDIR des transcription-app Images; Pfad zu backend/app.py (vermutlich unter Brancheneinstufung2/transcription-tool).
|
||||
|
||||
Konflikt 3: “Volume-Mapping ./clawd:/home/node/clawd” als Lebensversicherung (Annahme) vs User-Beobachtung/Unklarheit über echte Persistenzpfade
|
||||
|
||||
* Aussage A: „…docker-compose… volumes … ./clawd:/home/node/clawd …“ (explizit als Ableitung/Annahme).
|
||||
* Aussage B: User sieht Dateien/Medien an wechselnden Orten (“vorhin … inbound Media … jetzt … moltbot/storage/media”) und fragt nach Speicherort der Sitzung.
|
||||
* Warum Konflikt: tatsächliche Mounts/Pfade sind nicht eindeutig verifiziert; es wird zwischen /home/node/clawd und /home/node/.clawdbot/persistent_clawd unterschieden.
|
||||
* Klärung nötig: docker-compose.yml prüfen: welche Host-Pfade sind gemountet, wohin schreibt Moltbot tatsächlich?
|
||||
|
||||
Konflikt 4: “Alle 2 Minuten Mini-Update” Vorgabe vs reale Kommunikationsabstände
|
||||
|
||||
* Aussage A: Anforderung: „alle 2 Minuten … mini-update“.
|
||||
* Aussage B: User: „deine letzte Rückmeldung ist 7 Minuten her…“
|
||||
* Warum Konflikt: Prozessregel wird nicht eingehalten.
|
||||
* Klärung nötig: Konkretes Protokoll: “Update immer nach X Tool-Schritten” statt Zeit (falls Zeit nicht verlässlich).
|
||||
|
||||
E) Verdichtete Zusammenfassung (max. 12 Bulletpoints)
|
||||
|
||||
* #task/#fertig wurde als zentrales Arbeitsprotokoll definiert; du willst nur “#task”/“#fertig” (ohne Unterstrich) und Freigaben via 👍/❤️/Go.
|
||||
* Notion-Integration war mehrfach blockiert (400 Bad Request), Ursache war u. a. falsche Tasks-DB-ID; korrigiert auf 2e888f42-8544-8153-beac-e604719029cf; danach war der Task sichtbar („task ist jetzt da!“).
|
||||
* Status-Reports sollen als Page-Content (nicht Kommentar) im Task erscheinen; Format “## 🤖 Status-Update (… Berlin Time)” wurde verwendet und nach “Go” gepostet.
|
||||
* Zeiterfassung muss numerisch am Task gepflegt werden (für Rollups); Text “ca. 02:30” wurde als inkonsistent identifiziert und bereinigt; User bestätigt “jetzt schaut es gut aus!”.
|
||||
* Feature-Anforderung: Transkripte in Ordner sortieren + taggen; bestehende Tags müssen vorgeschlagen werden.
|
||||
* Architektur-Constraint: “dead simple tool”, keine API; erst Readme/Code analysieren, dann umsetzen.
|
||||
* Es gab massive Reibung durch fehlende Transparenz: du verlangst proaktive Rückmeldungen und alle 2 Minuten Mini-Updates (3–5 Stichpunkte).
|
||||
* Gitea-Zugriff war instabil (DNS “Failed to resolve…”), Repo-Download via Script (937 Dateien) und /etc/hosts-Fix auf 84.190.111.140; aber dynamische IP macht das fragil.
|
||||
* Push/Deployment war inkonsistent: obwohl “gepusht” behauptet, zeigte git pull “Already up to date”; zudem Branch/Pfad-Verwechslung (“transcription-tool”/feature branch).
|
||||
* Kritische Codebase-Diskrepanz: bearbeitete root app.py (Streamlit) passt nicht zum laufenden transcription-app Container (uvicorn backend.app).
|
||||
* Datensicherheit: dein update.sh ist kein Backup; backup.sh (tar.gz) soll vor Updates laufen.
|
||||
* Persistenzpfade Moltbot sind nicht abschließend geklärt (clawd vs .clawdbot/persistent_clawd); User sieht Medien/Logs an wechselnden Orten.
|
||||
|
||||
F) Rückfragen (max. 10, höchste Hebelwirkung)
|
||||
|
||||
1. Welcher Branch ist der “Deployment-Branch” für transcription-app: main oder ein feature/task-Branch (oder ein eigener “transcription-tool” Branch/Ordner)?
|
||||
2. Was ist der Build-Context/WORKDIR von brancheneinstufung-transcription-app (Dockerfile/docker-compose): wird Brancheneinstufung2/ transcrption-tool/ oder Repo-Root ins Image kopiert?
|
||||
3. Welche DB nutzt das live Tool tatsächlich: meetings.db oder transcriptions.db, und wie heißt die Tabelle (meetings vs transcriptions)?
|
||||
4. Wo soll die Ordner-/Tag-Metadatenstruktur final gespeichert werden: in SQLite (lokal) oder in Notion (zusätzlich/parallel) — oder strikt nur lokal?
|
||||
5. Wie genau sollen Tag-Vorschläge im UI aussehen (Dropdown/Multiselect/Autocomplete) – reicht eine “Suggested Tags” Liste + freies Eingabefeld, oder muss es echtes Autocomplete sein?
|
||||
6. Kannst du die relevante docker-compose.yml (für transcription-app) bzw. den Teil mit volumes zeigen, um Persistenz und Codepfade eindeutig zu machen?
|
||||
7. Wo möchtest du den “Source of Truth” Workspace für Moltbot haben: /volume1/docker/moltbot/moltbot/clawd oder unter /volume1/docker/moltbot/storage/… ?
|
||||
8. Soll backup.sh nur den clawd-Workspace sichern oder zusätzlich storage/media (inbound) und/oder Notion-Configs?
|
||||
9. Wo liegt big_Fortschritt_marketingautomation.txt (Repo-Pfad oder Synology-Pfad), oder kannst du den Inhalt hier einfügen/hochladen?
|
||||
10. Für das Kommunikationsprotokoll: sollen Mini-Updates strikt zeitbasiert (2 Minuten) sein, oder “nach jedem relevanten Tool-Schritt” (z. B. nach git/ls/migration/push), falls Zeitintervalle nicht zuverlässig haltbar sind?
|
||||
138
docs/KONVER_STRATEGY.md
Normal file
138
docs/KONVER_STRATEGY.md
Normal file
@@ -0,0 +1,138 @@
|
||||
# Konver.ai Integration: Strategie & Architektur
|
||||
|
||||
**Status:** Vertrag unterzeichnet (Fokus: Telefon-Enrichment).
|
||||
**Risiko:** Wegfall von Dealfront (Lead Gen) ohne adäquaten, automatisierten Ersatz.
|
||||
**Ziel:** Nutzung von Konver.ai nicht nur als manuelles "Telefonbuch", sondern als **skalierbare Quelle** für die Lead-Fabrik (Company Explorer).
|
||||
|
||||
## 1. Das Zielszenario (The "Golden Flow")
|
||||
|
||||
Wir integrieren Konver.ai via API direkt in den Company Explorer. Der CE fungiert als Gatekeeper, um Credits zu sparen und Dubletten zu verhindern.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph "RoboPlanet Ecosystem"
|
||||
Notion[("Notion Strategy\n(Verticals/Pains)")]
|
||||
SO[("SuperOffice CRM\n(Bestand)")]
|
||||
CE["Company Explorer\n(The Brain)"]
|
||||
end
|
||||
|
||||
subgraph "External Sources"
|
||||
Konver["Konver.ai API"]
|
||||
Web["Web / Google / Wiki"]
|
||||
end
|
||||
|
||||
%% Data Flow
|
||||
Notion -->|1. Sync Strategy| CE
|
||||
SO -->|2. Import Existing (Blocklist)| CE
|
||||
|
||||
CE -->|3. Search Query + Exclusion List| Konver
|
||||
Note right of Konver: "Suche: Altenheime > 10 Mio\nExclude: Domain-Liste aus SO"
|
||||
|
||||
Konver -->|4. Net New Candidates| CE
|
||||
|
||||
CE -->|5. Deep Dive (Robotik-Check)| Web
|
||||
|
||||
CE -->|6. Enrich Contact (Phone/Mail)| Konver
|
||||
Note right of CE: "Nur für Firmen mit\nhohem Robotik-Score!"
|
||||
|
||||
CE -->|7. Export Qualified Lead| SO
|
||||
```
|
||||
|
||||
## 2. Die kritische Lücke: "Exclusion List"
|
||||
|
||||
Da Dealfront (unser bisheriges "Fischnetz") abgeschaltet wird, müssen wir Konver zur **Neukunden-Generierung** nutzen.
|
||||
Ohne eine **Ausschluss-Liste (Exclusion List)** bei der Suche verbrennen wir Geld und Zeit:
|
||||
|
||||
1. **Kosten:** Wir zahlen Credits für Firmen/Kontakte, die wir schon haben.
|
||||
2. **Daten-Hygiene:** Wir importieren Dubletten, die wir mühsam bereinigen müssen.
|
||||
3. **Blindflug:** Wir wissen vor dem Kauf nicht, ob der Datensatz "netto neu" ist.
|
||||
|
||||
### Forderung an Konver (Technisches Onboarding)
|
||||
|
||||
*"Um Konver.ai als strategischen Nachfolger für Dealfront in unserer Marketing-Automation nutzen zu können, benötigen wir zwingend API-Funktionen zur **Deduplizierung VOR dem Datenkauf**."*
|
||||
|
||||
**Konkrete Features:**
|
||||
* **Domain-Exclusion:** Upload einer Liste (z.B. 5.000 Domains), die in der API-Suche *nicht* zurückgegeben werden.
|
||||
* **Contact-Check:** Prüfung (z.B. Hash-Abgleich), ob eine E-Mail-Adresse bereits "bekannt" ist, bevor Kontaktdaten enthüllt (und berechnet) werden.
|
||||
|
||||
## 3. Workflow-Varianten
|
||||
|
||||
### A. Der "Smart Enricher" (Wirtschaftlich)
|
||||
Wir nutzen Konver nur für Firmen, die **wirklich** relevant sind.
|
||||
|
||||
1. **Scraping:** Company Explorer findet 100 Altenheime (Web-Suche).
|
||||
2. **Filterung:** KI prüft Websites -> 40 davon sind relevant (haben große Flächen).
|
||||
3. **Enrichment:** Nur für diese 40 fragen wir Konver via API: *"Gib mir den Facility Manager + Handy"*.
|
||||
4. **Ergebnis:** Wir zahlen 40 Credits statt 100. Hohe Effizienz.
|
||||
|
||||
### B. Der "Mass Loader" (Teuer & Dumm - zu vermeiden)
|
||||
1. Wir laden "Alle Altenheime" aus Konver direkt nach SuperOffice.
|
||||
2. Wir zahlen 100 Credits.
|
||||
3. Der Vertrieb ruft an -> 60 davon sind ungeeignet (zu klein, kein Bedarf).
|
||||
4. **Ergebnis:** 60 Credits verbrannt, Vertrieb frustriert.
|
||||
|
||||
## 4. Fazit & Next Steps
|
||||
|
||||
Wir müssen im Onboarding-Gespräch klären:
|
||||
1. **API-Doku:** Wo ist die Dokumentation für `Search` und `Enrich` Endpoints?
|
||||
2. **Exclusion:** Wie filtern wir Bestandskunden im API-Call?
|
||||
3. **Bulk-Enrichment:** Können wir Listen (Domains) zum Anreichern hochladen?
|
||||
|
||||
Ohne diese Features ist Konver ein Rückschritt in die manuelle Einzelbearbeitung.
|
||||
|
||||
## 5. Kommunikations-Vorlagen
|
||||
|
||||
### A. Interne Klärung (an Projektverantwortlichen)
|
||||
*Ziel: Strategische Ausrichtung (Enrichment vs. Neukunden) und technische Implikationen klären, ohne "Schlafende Hunde" zu wecken.*
|
||||
|
||||
**Betreff:** Technische Konzeption der Konver.ai-Integration – Rückfragen zum Einsatzszenario
|
||||
|
||||
Sehr geehrte(r) [Name des Ansprechpartners],
|
||||
|
||||
ich befasse mich derzeit mit der technischen Konzeption für die Einbindung von Konver.ai in unsere bestehende Systemlandschaft. Da ich leider erst sehr spät in den Prozess hinzugekommen bin und die bisherigen Präsentationen von Konver.ai nicht verfolgen konnte, haben sich für mich zwei zentrale Fragen zur optimalen technischen Integration ergeben:
|
||||
|
||||
**1. Fokus der Nutzung (Enrichment vs. Neukunden-Recherche)**
|
||||
Ist geplant, Konver.ai primär für die Anreicherung bereits bestehender Datensätze im CRM zu nutzen (z. B. Ergänzung fehlender Mobilnummern)? Oder soll das Tool, ähnlich wie zuvor Dealfront, auch für die aktive Suche nach neuen, bisher unbekannten Ansprechpartnern eingesetzt werden (z. B. „Suche Facility Manager bei Unternehmen X“)?
|
||||
|
||||
Diese Unterscheidung ist für die Implementierung einer automatisierten Dublettenprüfung und den effizienten Einsatz von Credits von großer Bedeutung.
|
||||
|
||||
**2. Art der Datenbereitstellung (Echtzeit-Datenbank vs. Live-Recherche)**
|
||||
Können Sie mir sagen, ob Konver.ai die angefragten Daten sofort aus einer bestehenden Datenbank liefert oder ob die Recherche jeweils erst zum Zeitpunkt der Anfrage „live“ gestartet wird? Davon hängt ab, ob wir die Integration synchron (Daten sind sofort verfügbar) oder asynchron (mit einer zeitlichen Verzögerung und Warteschlange) abbilden müssen.
|
||||
|
||||
Für eine kurze Einschätzung Ihrerseits wäre ich Ihnen sehr dankbar, um die technische Umsetzung von Beginn an passgenau planen zu können.
|
||||
Gerne stelle ich die Fragen auch direkt an Konver.ai, ich möchte hier nur nicht querschießen.
|
||||
|
||||
Mit freundlichen Grüßen
|
||||
|
||||
[Ihr Name]
|
||||
|
||||
---
|
||||
|
||||
### B. Externe Anfrage (an Konver.ai Support / Tech)
|
||||
*Ziel: Technische Dokumentation erhalten und Deduplizierungs-Möglichkeiten prüfen.*
|
||||
|
||||
**Betreff:** Technische Integration API - Dokumentation & Workflow (Wackler/Roboplanet)
|
||||
|
||||
Sehr geehrte Damen und Herren / Hallo Support-Team,
|
||||
|
||||
wir sind derzeit dabei, Konver.ai technisch in unsere Systemlandschaft (SuperOffice CRM & interne Lead-Intelligence) zu integrieren.
|
||||
Um den Aufwand und die Architektur (synchron vs. asynchron) planen zu können, benötigen wir bitte folgende Informationen bzw. Unterlagen:
|
||||
|
||||
**1. API Dokumentation**
|
||||
Könnten Sie uns bitte die aktuelle technische Dokumentation (OpenAPI/Swagger Specs) für die `Search` und `Enrich` Endpoints zukommen lassen?
|
||||
|
||||
**2. Person Search & Deduplizierung (Pre-Purchase Check)**
|
||||
Unser geplanter Use-Case sieht vor, gezielt nach Ansprechpartnern für vorqualifizierte Unternehmen zu suchen (z.B. `domain="klinikum-x.de"` AND `job_title="Facility Manager"`).
|
||||
* Gibt es einen Endpunkt, der uns erlaubt, **vor** dem kostenpflichtigen "Reveal" zu prüfen, ob wir einen Datensatz (E-Mail/Telefon) bereits besitzen (z.B. via Hash-Abgleich oder Exclusion-List)?
|
||||
* Wir möchten vermeiden, Credits für Daten zu verbrauchen, die bereits in unserem CRM vorhanden sind.
|
||||
|
||||
**3. Datenbereitstellung (Sync vs. Async)**
|
||||
Erfolgt die Rückgabe der Daten bei einer API-Anfrage synchron (direkt aus einer Datenbank) oder wird ein Live-Recherche-Prozess angestoßen?
|
||||
Falls "Live": Bieten Sie Webhooks an, um uns über die Fertigstellung der Datenanreicherung zu informieren, oder muss gepollt werden?
|
||||
|
||||
Vielen Dank für Ihre Unterstützung beim technischen Onboarding.
|
||||
|
||||
Mit freundlichen Grüßen
|
||||
|
||||
[Ihr Name]
|
||||
|
||||
443
docs/MIGRATION_PLAN.md
Normal file
443
docs/MIGRATION_PLAN.md
Normal file
@@ -0,0 +1,443 @@
|
||||
# Migrations-Plan: Legacy GSheets -> Company Explorer (Robotics Edition v0.8.5)
|
||||
|
||||
**Kontext:** Neuanfang für die Branche **Robotik & Facility Management**.
|
||||
**Ziel:** Ablösung von Google Sheets/CLI durch eine Web-App ("Company Explorer") mit SQLite-Backend.
|
||||
|
||||
## 1. Strategische Neuausrichtung
|
||||
|
||||
| Bereich | Alt (Legacy) | Neu (Robotics Edition) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Daten-Basis** | Google Sheets | **SQLite** (Lokal, performant, filterbar). |
|
||||
| **Ziel-Daten** | Allgemein / Kundenservice | **Quantifizierbares Potenzial** (z.B. 4500m² Fläche, 120 Betten). |
|
||||
| **Branchen** | KI-Vorschlag (Freitext) | **Strict Mode:** Mapping auf definierte Notion-Liste (z.B. "Hotellerie", "Automotive"). |
|
||||
| **Bewertung** | 0-100 Score (Vage) | **Data-Driven:** Rohwert (Scraper/Search) -> Standardisierung (Formel) -> Potenzial. |
|
||||
| **Analytics** | Techniker-ML-Modell | **Deaktiviert**. Fokus auf harte Fakten. |
|
||||
| **Operations** | D365 Sync (Broken) | **Excel-Import & Deduplizierung**. Fokus auf Matching externer Listen gegen Bestand. |
|
||||
|
||||
## 2. Architektur & Komponenten-Mapping
|
||||
|
||||
Das System wird in `company-explorer/` neu aufgebaut. Wir lösen Abhängigkeiten zur Root `helpers.py` auf.
|
||||
|
||||
### A. Core Backend (`backend/`)
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik | Prio |
|
||||
| :--- | :--- | :--- |
|
||||
| **Database** | Ersetzt `GoogleSheetHandler`. Speichert Firmen & "Enrichment Blobs". | 1 |
|
||||
| **Importer** | Ersetzt `SyncManager`. Importiert Excel-Dumps (CRM) und Event-Listen. | 1 |
|
||||
| **Deduplicator** | Ersetzt `company_deduplicator.py`. **Kern-Feature:** Checkt Event-Listen gegen DB. Muss "intelligent" matchen (Name + Ort + Web). | 1 |
|
||||
| **Scraper (Base)** | Extrahiert Text von Websites. Basis für alle Analysen. | 1 |
|
||||
| **Classification Service** | **NEU (v0.7.0).** Zweistufige Logik: <br> 1. Strict Industry Classification. <br> 2. Metric Extraction Cascade (Web -> Wiki -> SerpAPI). | 1 |
|
||||
| **Marketing Engine** | Ersetzt `generate_marketing_text.py`. Nutzt neue `marketing_wissen_robotics.yaml`. | 3 |
|
||||
|
||||
**Identifizierte Hauptdatei:** `company-explorer/backend/app.py`
|
||||
|
||||
### B. Frontend (`frontend/`) - React
|
||||
|
||||
* **View 1: Der "Explorer":** DataGrid aller Firmen. Filterbar nach "Roboter-Potential" und Status.
|
||||
* **View 2: Der "Inspector":** Detailansicht einer Firma. Zeigt gefundene Signale ("Hat SPA Bereich"). Manuelle Korrektur-Möglichkeit.
|
||||
* **Identifizierte Komponente:** `company-explorer/frontend/src/components/Inspector.tsx`
|
||||
* **View 3: "List Matcher":** Upload einer Excel-Liste -> Anzeige von Duplikaten -> Button "Neue importieren".
|
||||
* **View 4: "Settings":** Konfiguration von Branchen, Rollen und Robotik-Logik.
|
||||
* **Frontend "Settings" Komponente:** `company-explorer/frontend/src/components/RoboticsSettings.tsx`
|
||||
|
||||
### C. Architekturmuster für die Client-Integration
|
||||
|
||||
Um externen Diensten (wie der `lead-engine`) eine einfache und robuste Anbindung an den `company-explorer` zu ermöglichen, wurde ein standardisiertes Client-Connector-Muster implementiert.
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik |
|
||||
| :--- | :--- |
|
||||
| **`company_explorer_connector.py`** | **NEU:** Ein zentrales Python-Skript, das als "offizieller" Client-Wrapper für die API des Company Explorers dient. Es kapselt die Komplexität der asynchronen Enrichment-Prozesse. |
|
||||
| **`handle_company_workflow()`** | Die Kernfunktion des Connectors. Sie implementiert den vollständigen "Find-or-Create-and-Enrich"-Workflow: <br> 1. **Prüfen:** Stellt fest, ob ein Unternehmen bereits existiert. <br> 2. **Erstellen:** Legt das Unternehmen an, falls es neu ist. <br> 3. **Anstoßen:** Startet den asynchronen `discover`-Prozess. <br> 4. **Warten (Polling):** Überwacht den Status des Unternehmens, bis eine Website gefunden wurde. <br> 5. **Analysieren:** Startet den asynchronen `analyze`-Prozess. <br> **Vorteil:** Bietet dem aufrufenden Dienst eine einfache, quasi-synchrone Schnittstelle und stellt sicher, dass die Prozessschritte in der korrekten Reihenfolge ausgeführt werden. |
|
||||
|
||||
### 2.1 Der End-to-End Datenfluss (Lead-Fabrik)
|
||||
|
||||
Diese Grafik visualisiert den gesamten Prozess von der Anlage eines Kontakts im CRM über die KI-Analyse bis zur fertigen Marketing-Automation.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
%% Nodes
|
||||
User((Vertriebs-User))
|
||||
SO_CRM[SuperOffice CRM]
|
||||
Connector[Connector Service]
|
||||
CE_Core[Company Explorer Core]
|
||||
CE_AI[AI Analysis Engine]
|
||||
CE_DB[(SQLite DB)]
|
||||
MA_System[Marketing Automation]
|
||||
|
||||
%% Flow
|
||||
User -- Erstellt Contact (Firma / Person) --> SO_CRM
|
||||
SO_CRM -- Webhook (New Contact) --> Connector
|
||||
Connector -- POST /provision --> CE_Core
|
||||
|
||||
subgraph "Intelligence Phase (Asynchron)"
|
||||
CE_Core -- 1. Scrape & Research --> CE_AI
|
||||
CE_AI -- 2. Vertical & Metriken (Potential) --> CE_Core
|
||||
CE_AI -- 3. Generiere Atomic Opener --> CE_Core
|
||||
end
|
||||
|
||||
subgraph "Matrix Logic (Matching)"
|
||||
CE_Core -- 4. Rolle & Branche Identifizieren --> CE_DB
|
||||
CE_DB -- 5. Hole Matrix-Texte (Subject/Intro) --> CE_Core
|
||||
Note[Logik: Primary vs Secondary Product<br>z.B. Healthcare: Pflege -> Transport]
|
||||
end
|
||||
|
||||
CE_Core -- Angereichertes Profil + Texte --> Connector
|
||||
Connector -- UPDATE Person (UDFs) --> SO_CRM
|
||||
|
||||
SO_CRM -- Daten verfügbar --> MA_System
|
||||
MA_System -- Textblöcke ins Template einsetzen --> Email(E-Mail Automation läuft an)
|
||||
```
|
||||
|
||||
**Prozess-Schritte:**
|
||||
1. **Trigger:** Ein Vertriebsmitarbeiter legt eine Person oder Firma in SuperOffice an.
|
||||
2. **Transport:** Der Connector empfängt den Webhook und beauftragt den Company Explorer (`/provision`).
|
||||
3. **Intelligence:**
|
||||
* Die Website wird gescraped und analysiert.
|
||||
* Die KI bestimmt das **Vertical** (z.B. "Healthcare - Hospital") und berechnet das **Potenzial** (z.B. Bettenanzahl).
|
||||
* Ein individueller **Atomic Opener** wird generiert, der auf die spezifische Situation des Unternehmens eingeht.
|
||||
4. **Matrix Match:**
|
||||
* Basierend auf der Job-Rolle (z.B. "Pflegedienstleitung") wird die **Persona** ("Operativer Entscheider") bestimmt.
|
||||
* Die Engine prüft das `Ops Focus: Secondary` Flag (z.B. bei Krankenhäusern).
|
||||
* Die passenden Textbausteine (Betreff, Intro, Social Proof) werden aus der vor-generierten Matrix geladen.
|
||||
5. **Sync Back:** Alle Texte (Opener + Matrix-Bausteine) werden in die benutzerdefinierten Felder (UDFs) der Person in SuperOffice zurückgeschrieben.
|
||||
6. **Execution:** Die Marketing-Automation nutzt diese Felder (`{udf_opener}`, `{udf_intro}`), um hoch-personalisierte E-Mails zu versenden.
|
||||
|
||||
## 3. Umgang mit Shared Code (`helpers.py` & Co.)
|
||||
|
||||
Wir kapseln das neue Projekt vollständig ab ("Fork & Clean").
|
||||
|
||||
* **Quelle:** `helpers.py` (Root)
|
||||
* **Ziel:** `company-explorer/backend/lib/core_utils.py`
|
||||
* **Aktion:** Wir kopieren nur relevante Teile und ergänzen sie (z.B. `safe_eval_math`, `run_serp_search`).
|
||||
|
||||
## 4. Datenstruktur (SQLite Schema)
|
||||
|
||||
### Tabelle `companies` (Stammdaten & Analyse)
|
||||
* `id` (PK)
|
||||
* `name` (String)
|
||||
* `website` (String)
|
||||
* `crm_id` (String, nullable - Link zum D365)
|
||||
* `industry_crm` (String - Die "erlaubte" Branche aus Notion)
|
||||
* `city` (String)
|
||||
* `country` (String - Standard: "DE" oder aus Impressum)
|
||||
* `status` (Enum: NEW, IMPORTED, ENRICHED, QUALIFIED)
|
||||
* **NEU (v0.7.0):**
|
||||
* `calculated_metric_name` (String - z.B. "Anzahl Betten")
|
||||
* `calculated_metric_value` (Float - z.B. 180)
|
||||
* `calculated_metric_unit` (String - z.B. "Betten")
|
||||
* `standardized_metric_value` (Float - z.B. 4500)
|
||||
* `standardized_metric_unit` (String - z.B. "m²")
|
||||
* `metric_source` (String - "website", "wikipedia", "serpapi")
|
||||
|
||||
### Tabelle `signals` (Deprecated)
|
||||
* *Veraltet ab v0.7.0. Wird durch quantitative Metriken in `companies` ersetzt.*
|
||||
|
||||
### Tabelle `contacts` (Ansprechpartner)
|
||||
* `id` (PK)
|
||||
* `account_id` (FK -> companies.id)
|
||||
* `gender`, `title`, `first_name`, `last_name`, `email`
|
||||
* `job_title` (Visitenkarte)
|
||||
* `role` (Standardisierte Rolle: "Operativer Entscheider", etc.)
|
||||
* `status` (Marketing Status)
|
||||
|
||||
### Tabelle `industries` (Branchen-Fokus - Synced from Notion)
|
||||
* `id` (PK)
|
||||
* `notion_id` (String, Unique)
|
||||
* `name` (String - "Vertical" in Notion)
|
||||
* `description` (Text - "Definition" in Notion)
|
||||
* `metric_type` (String - "Metric Type")
|
||||
* `min_requirement` (Float - "Min. Requirement")
|
||||
* `whale_threshold` (Float - "Whale Threshold")
|
||||
* `proxy_factor` (Float - "Proxy Factor")
|
||||
* `scraper_search_term` (String - "Scraper Search Term")
|
||||
* `scraper_keywords` (Text - "Scraper Keywords")
|
||||
* `standardization_logic` (String - "Standardization Logic")
|
||||
|
||||
### Tabelle `job_role_mappings` (Rollen-Logik)
|
||||
* `id` (PK)
|
||||
* `pattern` (String - Regex für Jobtitles)
|
||||
* `role` (String - Zielrolle)
|
||||
|
||||
## 5. Phasenplan Umsetzung
|
||||
|
||||
1. **Housekeeping:** Archivierung des Legacy-Codes (`_legacy_gsheets_system`).
|
||||
2. **Setup:** Init `company-explorer` (Backend + Frontend Skeleton).
|
||||
3. **Foundation:** DB-Schema + "List Matcher" (Deduplizierung ist Prio A für Operations).
|
||||
4. **Enrichment:** Implementierung des Scrapers + Signal Detector (Robotics).
|
||||
5. **UI:** React Interface für die Daten.
|
||||
6. **CRM-Features:** Contacts Management & Marketing Automation Status.
|
||||
|
||||
## 6. Spezifikation: Contacts & Marketing Status (v0.5.0)
|
||||
|
||||
**Konzept:**
|
||||
Contacts stehen in 1:n Beziehung zu Accounts. Accounts können einen "Primary Contact" haben.
|
||||
|
||||
**Rollen (Funktion im Verkaufsprozess):**
|
||||
* Operativer Entscheider
|
||||
* Infrastruktur-Verantwortlicher
|
||||
* Wirtschaftlicher Entscheider
|
||||
* Innovations-Treiber
|
||||
|
||||
**Status (Marketing Automation):**
|
||||
* *Manuell:* Soft Denied, Bounced, Redirect, Interested, Hard denied.
|
||||
* *Automatisch:* Init, 1st Step, 2nd Step, Not replied, Unsubscribed.
|
||||
|
||||
### 6.1 Feature: Unsubscribe-Funktionalität (v2.1 - Feb 2026)
|
||||
|
||||
**Konzept:**
|
||||
Um DSGVO-konforme Marketing-Automatisierung zu ermöglichen, wurde eine sichere Unsubscribe-Funktion implementiert.
|
||||
|
||||
**Technische Umsetzung:**
|
||||
1. **Token:** Jeder Kontakt in der `contacts`-Tabelle erhält ein einzigartiges, nicht erratbares `unsubscribe_token` (UUID).
|
||||
2. **Link-Generierung:** Der Company Explorer generiert einen vollständigen, personalisierten Link (z.B. `https://<APP_BASE_URL>/unsubscribe/<token>`).
|
||||
3. **API-Endpunkt:** Ein öffentlicher GET-Endpunkt `/unsubscribe/{token}` nimmt Abmeldungen ohne Authentifizierung entgegen.
|
||||
4. **Logik:**
|
||||
* Bei Aufruf des Links wird der Status des zugehörigen Kontakts auf `"unsubscribed"` gesetzt.
|
||||
* Der Benutzer erhält eine simple HTML-Bestätigungsseite.
|
||||
5. **CRM-Integration:** Der generierte Link wird über die Provisioning-API an den `connector-superoffice` zurückgegeben, der ihn in ein entsprechendes UDF in SuperOffice schreibt.
|
||||
|
||||
## 7. Historie & Fixes (Jan 2026)
|
||||
|
||||
* **[MAJOR] v0.9.0: Role Matching Optimization & Portability (March 2026)**
|
||||
* **Pattern Optimizer:** Asynchrones Hintergrund-System zur automatischen Konsolidierung von Einzel-Matches in mächtige Regex-Regeln via Gemini. Inklusive Konfliktprüfung gegen andere Rollen. Nutzt `ast.literal_eval` für robustes Regex-Parsing.
|
||||
* **Database Management:** Direkter Up- & Download der SQLite-Datenbank aus dem UI heraus. Automatisches Backup-System bei Upload.
|
||||
* **Regex Sandbox:** Integriertes Test-Tool für Muster vor der Speicherung in der Datenbank.
|
||||
* **Smart Suggestions:** Live-Analyse der Kontaktdaten zur Identifikation häufiger Schlüsselwörter pro Rolle als Klick-Vorschläge.
|
||||
* **[CRITICAL] v0.7.4: Service Restoration & Logic Fix (Jan 24, 2026)**
|
||||
* **[STABILITY] v0.7.3: Hardening Metric Parser & Regression Testing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.2: Robust Metric Parsing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.1: AI Robustness & UI Fixes (Jan 21, 2026)**
|
||||
* **[MAJOR] v0.7.0: Quantitative Potential Analysis (Jan 20, 2026)**
|
||||
* **[UPGRADE] v0.6.x: Notion Integration & UI Improvements**
|
||||
|
||||
## 8. Eingesetzte Prompts (Account-Analyse v0.7.4)
|
||||
|
||||
### 8.1 Strict Industry Classification
|
||||
|
||||
Ordnet das Unternehmen einer definierten Branche zu.
|
||||
|
||||
```python
|
||||
prompt = f"""
|
||||
Act as a strict B2B Industry Classifier.
|
||||
Company: {company_name}
|
||||
Context: {website_text[:3000]}
|
||||
|
||||
Available Industries:
|
||||
{json.dumps(industry_definitions, indent=2)}
|
||||
|
||||
Task: Select the ONE industry that best matches the company.
|
||||
If none match well, select 'Others'.
|
||||
"""
|
||||
```
|
||||
|
||||
### 8.2 Metric Extraction
|
||||
|
||||
Extrahiert den spezifischen Zahlenwert ("Scraper Search Term") und liefert JSON für den `MetricParser`.
|
||||
|
||||
```python
|
||||
prompt = f"""
|
||||
Extract the following metric for the company in industry '{industry_name}':
|
||||
Target Metric: "{search_term}"
|
||||
|
||||
Source Text:
|
||||
{text_content[:6000]}
|
||||
|
||||
Return a JSON object with 'raw_value', 'raw_unit', 'proof_text'.
|
||||
"""
|
||||
```
|
||||
|
||||
## 9. Notion Integration (Single Source of Truth)
|
||||
|
||||
Das System nutzt Notion als zentrales Steuerungselement für strategische Definitionen.
|
||||
|
||||
### 9.1 Datenfluss
|
||||
1. **Definition:** Branchen und Robotik-Kategorien werden in Notion gepflegt.
|
||||
2. **Synchronisation:** Das Skript `sync_notion_industries.py` zieht die Daten via API (Upsert).
|
||||
3. **App-Nutzung:** Der `ClassificationService` nutzt sie als "System-Anweisung" für das LLM.
|
||||
|
||||
## 10. Database Migration
|
||||
|
||||
Bei Schema-Änderungen: `docker exec -it company-explorer python3 backend/scripts/migrate_db.py`.
|
||||
|
||||
## 11. Lessons Learned (Retrospektive Jan 24, 2026)
|
||||
|
||||
1. **FastAPI Routing:** Spezifische Endpunkte immer VOR dynamischen Endpunkten deklarieren.
|
||||
2. **Docker Persistence:** Datenbankdatei muss zwingend als Volume gemountet sein.
|
||||
3. **Formel-Robustheit:** Bereinigung von Einheiten/Kommentaren vor `eval()`.
|
||||
|
||||
## 12. Deployment & Access Notes
|
||||
|
||||
* **Pfad auf NAS:** `/volume1/homes/Floke/python/brancheneinstufung/company-explorer`
|
||||
* **Sync:** `docker exec -it company-explorer python backend/scripts/sync_notion_to_ce_enhanced.py`
|
||||
|
||||
## 13. Feature: Report Mistakes
|
||||
|
||||
Benutzer können Fehler im Inspector melden. Diese werden in `reported_mistakes` gespeichert und in den Settings zur Prüfung angezeigt.
|
||||
|
||||
## 14. Upgrade v2.0 (Feb 18, 2026): "Lead-Fabrik" Erweiterung
|
||||
|
||||
Dieses Upgrade transformiert den Company Explorer in das zentrale Gehirn der Lead-Generierung (Vorratskammer).
|
||||
|
||||
### 14.1 Detaillierte Logik der neuen Datenfelder
|
||||
|
||||
* **`confidence_score` (FLOAT):** Indikator für die Sicherheit der KI-Klassifizierung. `> 0.8` = Grün.
|
||||
* **`data_mismatch_score` (FLOAT):** Abweichung zwischen CRM-Bestand und Web-Recherche (z.B. Umzug).
|
||||
* **`crm_name`, `crm_address`, `crm_website`, `crm_vat`:** Read-Only Snapshot aus SuperOffice zum Vergleich.
|
||||
* **Status-Flags:** `website_scrape_status` und `wiki_search_status`.
|
||||
|
||||
#### Tabelle `industries` (Strategie-Parameter)
|
||||
|
||||
* **`pains` / `gains`:** Strukturierte Textblöcke (getrennt durch `[Primary Product]` und `[Secondary Product]`).
|
||||
* **`ops_focus_secondary` (BOOLEAN):** Steuerung für rollenspezifische Produkt-Priorisierung.
|
||||
|
||||
---
|
||||
|
||||
## 15. Offene Arbeitspakete (Bauleitung)
|
||||
|
||||
### Task 1: UI-Anpassung - Side-by-Side CRM View & Settings
|
||||
(In Arbeit / Teilweise erledigt durch Gemini CLI)
|
||||
|
||||
### Task 2: Intelligenter CRM-Importer (Bestandsdaten)
|
||||
|
||||
**Ziel:** Importieren der `demo_100.xlsx` in die SQLite-Datenbank.
|
||||
1. **PLZ-Handling:** Zwingend als **String** einlesen.
|
||||
2. **Matching:** Kaskade über CRM-ID, VAT, Domain, Fuzzy Name.
|
||||
|
||||
---
|
||||
|
||||
## 16. Deployment-Referenz (NAS)
|
||||
* **Pfad:** `/volume1/homes/Floke/python/brancheneinstufung/company-explorer`
|
||||
* **DB:** `/app/companies_v3_fixed_2.db`
|
||||
|
||||
---
|
||||
|
||||
## 17. Analyse-Logik v3.0 (Feb 2026): Quantitative Potenzialanalyse & "Atomic Opener"
|
||||
|
||||
### 17.1 Das Gesamtbild: Vom Content zur fertigen Analyse
|
||||
|
||||
1. Branchen-Klassifizierung -> 2. Quantitative Potenzialanalyse -> 3. "Atomic Opener" Generierung -> 4. Finales Commit.
|
||||
|
||||
### 17.2 Quantitative Potenzialanalyse im Detail
|
||||
|
||||
**Ziel:** Für jedes Unternehmen einen `standardized_metric_value` in `m²` zu ermitteln.
|
||||
* **Stufe 1:** Direkte Flächensuche ("Fläche", "m²").
|
||||
* **Stufe 2:** Proxy-Metrik-Suche (z.B. Betten * 100).
|
||||
|
||||
### 17.3 "Atomic Opener" Generierung im Detail (Zweistufiger Prozess, Feb 22, 2026)
|
||||
|
||||
**Ziel:** Zwei hoch-personalisierte, schlagkräftige Einleitungssätze (2-3 Sätze).
|
||||
* **Schritt 1:** Das Website-Dossier (Extraktion & Komprimierung).
|
||||
* **Schritt 2:** Formulierung des Openers (Scharfsinnige Beobachtung).
|
||||
|
||||
### 17.7 Marketing Matrix Schärfung (v3.2 - Feb 22, 2026)
|
||||
|
||||
Die Qualität der Marketing-Matrix (Subject, Intro, Social Proof) ist entscheidend für den Erfolg des Outreachs.
|
||||
|
||||
**Kern-Konzept: Der Strategische Brückenschlag**
|
||||
Die KI agiert nicht mehr als reiner Copywriter, sondern als **scharfsinniger B2B-Strategieberater** ("Lösungsberater").
|
||||
|
||||
**Neues Feature: "Ops Focus: Secondary" (Die Rollen-Weiche)**
|
||||
Wenn in Notion das Flag `Ops Focus: Secondary` aktiv ist, wechselt die Engine für die Persona **"Operativer Entscheider"** automatisch auf das **Sekundärprodukt** (z.B. Service-Roboter/Transport).
|
||||
|
||||
**Der "Lösungsberater" Prompt (Auszug):**
|
||||
```python
|
||||
prompt = f"""
|
||||
Du bist ein kompetenter Lösungsberater und brillanter Texter.
|
||||
AUFGABE: Erstelle 3 Textblöcke (Subject, Introduction_Textonly, Industry_References_Textonly) für eine E-Mail an einen Entscheider.
|
||||
|
||||
--- KONTEXT ---
|
||||
ZIELBRANCHE: {industry.name}
|
||||
BRANCHEN-HERAUSFORDERUNGEN (PAIN POINTS): {industry_pains}
|
||||
FOKUS-PRODUKT (LÖSUNG): {target_scope} ({product_context})
|
||||
ANSPRECHPARTNER (ROLLE): {persona.name}
|
||||
PERSÖNLICHE HERAUSFORDERUNGEN: {persona_pains}
|
||||
"""
|
||||
```
|
||||
|
||||
### 17.8 Erweiterte Matrix-Multiplikation: Primary vs. Secondary (Update Feb 24, 2026)
|
||||
|
||||
**Konzept:** Strikte Trennung zwischen `[Primary Product]` und `[Secondary Product]` zur Vermeidung logischer Brüche.
|
||||
|
||||
### 17.9 Deep Persona Injection (Update Feb 24, 2026)
|
||||
|
||||
**Ziel:** Maximale Relevanz durch Einbezug psychografischer und operativer Rollen-Details ("Voll ins Zentrum").
|
||||
|
||||
**Die Erweiterung:**
|
||||
- **Vollständiger Daten-Sync:** Übernahme von `Beschreibung/Denkweise`, `Was ihn überzeugt` und `KPIs` aus der Notion "Personas / Roles" Datenbank in das lokale Schema.
|
||||
- **Rollenspezifische Tonalität:** Die KI nutzt diese Details, um den "Ton" der jeweiligen Persona perfekt zu treffen (z.B. technischer Fokus beim Infrastruktur-Leiter vs. betriebswirtschaftlicher Fokus beim CFO).
|
||||
|
||||
**Beispiel-Kaskade (Klinikum Erding):**
|
||||
1. **Opener:** "Klinikum Erding trägt maßgeblich zur regionalen Versorgung bei... Dokumentation lückenloser Hygiene stellt eine operative Herausforderung dar."
|
||||
2. **Matrix-Anschluss (Infrastruktur):** "...minimieren Ausfallzeiten um 80-90% durch proaktives Monitoring... planbare Wartung und Transparenz durch feste **SLAs**." (Direkter Bezug auf hinterlegte Überzeugungsargumente).
|
||||
3. **Matrix-Anschluss (Wirtschaftlich):** "...Reduktion operativer Personalkosten um 10-25%... wirkt sich direkt auf **ROI** und **Amortisationszeit** aus." (Direkter Bezug auf hinterlegte KPIs).
|
||||
|
||||
### 17.10 Production Switch & Multi-Campaign Architecture (Feb 27, 2026)
|
||||
|
||||
Das System wurde erfolgreich von der Sandbox auf die SuperOffice-Produktionsumgebung migriert. Alle technischen Hürden (Auth, ProgIDs, REST-Besonderheiten) wurden beseitigt.
|
||||
|
||||
#### A. Umgebungsparameter (Production)
|
||||
* **Base URL (OAuth):** `https://online.superoffice.com/login/common/oauth/tokens`
|
||||
* **Base URL (API):** `https://online3.superoffice.com/Cust26720/api/v1/`
|
||||
* **Tenant ID:** `Cust26720`
|
||||
* **Client ID:** `0fd8272803551846f7212a961a1a0046`
|
||||
|
||||
#### B. Finales UDF Mapping (ProgIDs)
|
||||
Verifizierte IDs für den Mandanten `Cust26720`:
|
||||
|
||||
| Zweck | Entität | ProgID | Format / Logik |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **MA Subject** | Person | `SuperOffice:19` | Text |
|
||||
| **MA Intro** | Person | `SuperOffice:20` | Text |
|
||||
| **MA Social Proof** | Person | `SuperOffice:21` | Text |
|
||||
| **MA Unsubscribe** | Person | `SuperOffice:22` | URL (DSGVO konform) |
|
||||
| **MA Campaign** | Person | `SuperOffice:23` | Liste (Auflösung via `:DisplayText`) |
|
||||
| **Vertical** | Contact | `SuperOffice:83` | Liste (Mapping siehe unten) |
|
||||
| **AI Summary** | Contact | `SuperOffice:84` | Truncated (< 135 Zeichen) |
|
||||
| **AI Last Update** | Contact | `SuperOffice:85` | Datum: `[D:MM/DD/YYYY HH:MM:SS]` |
|
||||
| **Opener Primary** | Contact | `SuperOffice:86` | Text (Infrastruktur/Cleaning) |
|
||||
| **Opener Secondary**| Contact | `SuperOffice:87` | Text (Service/Logistik) |
|
||||
| **Last Outreach** | Contact | `SuperOffice:88` | Datum |
|
||||
|
||||
#### C. Vollständige Vertical-Liste (Produktiv-IDs)
|
||||
Die Liste `udlist331` steuert die Branchenzuordnung. Der Connector nutzt folgendes Mapping:
|
||||
`Automotive - Dealer: 1613, Corporate - Campus: 1614, Energy - Grid & Utilities: 1615, Energy - Solar/Wind: 1616, Healthcare - Care Home: 1617, Healthcare - Hospital: 1618, Hospitality - Gastronomy: 1619, Hospitality - Hotel: 1620, Industry - Manufacturing: 1621, Infrastructure - Communities: 1622, Infrastructure - Public: 1623, Infrastructure - Transport: 1624, Infrastructure - Parking: 1625, Leisure - Entertainment: 1626, Leisure - Fitness: 1627, Leisure - Indoor Active: 1628, Leisure - Outdoor Park: 1629, Leisure - Wet & Spa: 1630, Logistics - Warehouse: 1631, Others: 1632, Reinigungsdienstleister: 1633, Retail - Food: 1634, Retail - Non-Food: 1635, Retail - Shopping Center: 1636, Tech - Data Center: 1637`.
|
||||
|
||||
#### D. Technische Meilensteine (Lessons Learned)
|
||||
|
||||
1. **Atomic PATCH Workflow:** Um API-Timeouts und Inkonsistenzen zu vermeiden, bündelt der `worker.py` (v1.8) alle Änderungen an einem Kontakt in einem einzigen `PATCH`-Request an `/Contact/{id}`.
|
||||
2. **Website-Sync (REST-Korrektur):** Die Aktualisierung der Website erfolgt über das `Urls`-Array (nicht `UrlAddress`). Format: `"Urls": [{"Value": "...", "Description": "AI Discovered"}]`.
|
||||
3. **Listen-Auflösung (Optimierung):** Kampagnen-Namen werden ohne zusätzliche API-Calls über das Pseudo-Feld `ProgID:DisplayText` (z.B. `SuperOffice:23:DisplayText`) direkt im Payload des Personen-Abrufs gelesen.
|
||||
4. **Längenbegrenzung:** Da viele UDFs in SuperOffice standardmäßig auf 254 Zeichen begrenzt sind, wird das AI-Dossier (Summary) hart auf 132 Zeichen (+ "...") gekürzt, um 400er Fehler beim Update zu vermeiden.
|
||||
5. **Docker Orchestrierung:** Der Wechsel auf `env_file: .env` in der `docker-compose.yml` stellt sicher, dass alle Services (CE + Connector) konsistent auf dieselben Mappings zugreifen.
|
||||
|
||||
#### E. Kampagnen-Steuerung (Multi-Template)
|
||||
Der Company Explorer unterstützt nun den Parameter `campaign_tag`. Der Connector sendet den Namen des gewählten Listeneintrags (z.B. "First Contact") an den CE. Dieser liefert spezifische Texte aus der `MarketingMatrix`, sofern vorhanden (Fallback: "standard").
|
||||
|
||||
---
|
||||
|
||||
## 19. External Lead Ingestion & Contact API (v3.5 - March 2, 2026)
|
||||
|
||||
**Kontext:** Automatisierte Verarbeitung von externen Lead-Quellen (Tradingtwins) direkt in den Company Explorer.
|
||||
|
||||
### 19.1 API-Erweiterung: Externer Kontakt-Sync
|
||||
Um Kontakte von externen Tools (wie der Lead-Engine) ohne SuperOffice-Kontext zu übernehmen, wurde die API erweitert.
|
||||
|
||||
* **Neuer Endpunkt:** `POST /api/contacts`
|
||||
* **Funktionalität:**
|
||||
* Anlage von Personen-Stammdaten (Vorname, Nachname, E-Mail).
|
||||
* **Automatisches Role-Mapping:** Der Endpunkt integriert den `RoleMappingService`. Eingehende Job-Titel (z.B. "CFO") werden automatisch gegen die interne Muster-Datenbank geprüft und der passenden Persona (z.B. "Wirtschaftlicher Entscheider") zugeordnet.
|
||||
* **De-Duplizierung:** Existiert eine E-Mail bereits für ein Unternehmen, wird der Datensatz aktualisiert statt neu angelegt.
|
||||
|
||||
### 19.2 Standardisierung der Datenfelder
|
||||
Zur Verbesserung der asynchronen Zusammenarbeit zwischen Lead-Engine und CE wurden die Feldnamen in der API-Antwort vereinheitlicht:
|
||||
* **Branche:** `industry_ai` (Primärfeld für die KI-Klassifizierung).
|
||||
* **Analyse:** `research_dossier` (Das vollständige KI-generierte Firmendossier).
|
||||
|
||||
### 19.3 Synchronisations-Workflow (Connector)
|
||||
Der `company_explorer_connector.py` unterstützt nun den erweiterten Workflow:
|
||||
1. `check_company_existence` (Suche via Name)
|
||||
2. `create_company` (Anlage falls neu)
|
||||
3. `create_contact` (Integration der Person inkl. Role-Mapping)
|
||||
4. `trigger_discovery` / `trigger_analysis` (Asynchroner Start der Intelligence-Phase)
|
||||
|
||||
---
|
||||
191
docs/MIGRATION_REPORT_COMPETITOR_ANALYSIS.md
Normal file
191
docs/MIGRATION_REPORT_COMPETITOR_ANALYSIS.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Migration Report: Competitor Analysis Agent
|
||||
|
||||
## Status: Jan 11, 2026 - ✅ ROBUSTNESS UPGRADE COMPLETE
|
||||
|
||||
Die App ist unter `/ca/` voll funktionsfähig und verfügt nun über eine "Grounded Truth" Engine (Scraping + SerpAPI) sowie eine skalierbare **Map-Reduce Architektur**.
|
||||
|
||||
### 🚨 Vollständige Chronik der Fehler & Lösungen
|
||||
|
||||
1. **Problem: 404 auf `/ca/`**
|
||||
* **Ursache:** Der Container startete aufgrund von Syntaxfehlern nicht, was Nginx mit einem 404 (später 502) quittierte.
|
||||
|
||||
2. **Problem: `SyntaxError: unterminated string literal` (Runde 1)**
|
||||
* **Ursache:** Verwendung von `f"""..."""` für komplexe Prompts.
|
||||
* **Lösung:** Umstellung auf `.format()`. **Wichtig:** Docker-Volumes synchronisierten nicht zuverlässig, was zu "Phantom-Fehlern" führte. Ein `build --no-cache` war nötig.
|
||||
|
||||
3. **Problem: `ImportError: cannot import name 'Schema'`**
|
||||
* **Ursache:** Uralte SDK-Version `google-generativeai==0.3.0` in `requirements.txt`.
|
||||
* **Lösung:** Umstellung auf Dictionaries, später komplettes SDK-Upgrade.
|
||||
|
||||
4. **Problem: `404 models/gemini-1.5-pro ... for API version v1beta`**
|
||||
* **Ursache:** Das alte SDK nutzte veraltete Endpunkte.
|
||||
* **Lösung:** Migration auf das moderne **`google-genai`** Paket (v1.x) und Nutzung des neuen `genai.Client`.
|
||||
|
||||
5. **Problem: `TypeError: unexpected keyword argument 'client_options'`**
|
||||
* **Analyse:** Obwohl das SDK in `requirements.txt` aktualisiert wurde, installierte Docker auf der Diskstation hartnäckig eine alte Version.
|
||||
* **Lösung:** Erzwingen der Version `google-genai>=1.2.0`.
|
||||
|
||||
6. **Problem: Das "Grounding Upgrade" & Die Syntax-Hölle (Runde 2)**
|
||||
* **Aufgabe:** Einbau von echtem Web-Scraping und SerpAPI zur Qualitätssteigerung.
|
||||
* **Fehler:** `SyntaxError: f-string: expecting '}'` in komplexen Listen-Generatoren (z.B. `c_sum`).
|
||||
* **Ursache:** Python 3.11 erlaubt keine geschachtelten Anführungszeichen in F-Strings, wenn diese Backslashes oder komplexe Ausdrücke enthalten.
|
||||
* **Lösung:** **RADIKALER VERZICHT auf F-Strings** in allen kritischen Logik-Bereichen. Umstellung auf einfache Schleifen und `.format()`.
|
||||
|
||||
7. **Problem: `unterminated string literal (detected at line 203)`**
|
||||
* **Ursache:** Einfache Anführungszeichen `'` in Kombination mit `\n` wurden im Container-Kontext falsch interpretiert.
|
||||
* **Lösung:** **ULTIMATIVE SYNTAX:** Verwendung von **Triple Raw Quotes (`r"""..."""`)** für jeden einzelnen String, der Variablen oder Sonderzeichen enthält.
|
||||
|
||||
8. **Problem: Analyse stoppt nach 5 Konkurrenten (Token Limit / Lazy LLM)**
|
||||
* **Symptom:** Bei 9 Konkurrenten wurden nur die ersten 5 analysiert, der Rest fehlte.
|
||||
* **Ursache:** Der riesige Prompt ("Analysiere alle 9...") überforderte das Kontext-Fenster oder führte zu Timeouts.
|
||||
* **Lösung:** Umstellung auf **Map-Reduce**: Jeder Konkurrent wird in einem eigenen parallelen Task (`asyncio.gather`) analysiert. Erhöhung von `max_output_tokens` auf 8192.
|
||||
|
||||
9. **Problem: `NameResolutionError` im Container**
|
||||
* **Symptom:** Scraping schlug fehl ("Name or service not known").
|
||||
* **Ursache:** Docker-Container nutzten den (instabilen) Host-DNS.
|
||||
* **Lösung:** Explizites Setzen von Google DNS (`8.8.8.8`, `8.8.4.4`) in `docker-compose.yml`.
|
||||
|
||||
10. **Problem: `422 Unprocessable Entity` in Schritt 6 & 8**
|
||||
* **Ursache:** Diskrepanz zwischen Frontend-Request (z.B. sendet `industries`) und Backend-Pydantic-Modell (erwartet `target_industries`).
|
||||
* **Lösung:** Backend-Modelle exakt an die Frontend-Payloads angepasst.
|
||||
|
||||
11. **Problem: Leere Matrizen in der Conclusion**
|
||||
* **Ursache:** Das LLM füllte das `availability`-Array nicht korrekt oder erfand eigene Produktnamen als Zeilenbeschriftung.
|
||||
* **Lösung:** Extrem strikter Prompt ("KEINE Produktnamen", "GENAU einen Eintrag pro Kategorie") und detailliertes JSON-Schema.
|
||||
|
||||
12. **Problem: Blinde KI in Schritt 8 (Referenzen)**
|
||||
* **Symptom:** Die Referenzanalyse lieferte nur generische, oft erfundene Branchen, anstatt echter Kunden.
|
||||
* **Ursache:** Der Prompt bat die KI, "nach Referenzen zu suchen", ohne ihr eine Datengrundlage zu geben. Die KI hat halluziniert.
|
||||
* **Lösung:** Implementierung einer **"Grounded" Referenz-Suche**.
|
||||
* **Ergebnis:** Die Analyse basiert nun auf Fakten von der Webseite des Wettbewerbers.
|
||||
|
||||
13. **Problem: Informations-Overload (Text-Wüste)**
|
||||
* **Symptom:** In Notion landeten hunderte Produkte und Landmines, aber man konnte nicht effektiv filtern (z.B. "Zeige alle Reinigungsroboter").
|
||||
* **Lösung:** Einführung von **Semantic Clustering & Taxonomies**.
|
||||
* Das Backend ordnet nun jedem Produkt eine feste Kategorie zu (z.B. *Cleaning*, *Logistics*).
|
||||
* Jede Landmine erhält ein Themen-Tag (z.B. *Price*, *Support*, *Technology*).
|
||||
* **Ergebnis:** Das Competitive Radar ist nun ein echtes BI-Tool. In Notion können nun "Board Views" nach Kategorien erstellt werden (Level 4 Relational Model).
|
||||
|
||||
### 🛡️ Die finale "Grounded" Architektur
|
||||
... (Scraping/Map-Reduce etc. bleiben gleich) ...
|
||||
|
||||
### 📊 Relationaler Notion Import (Competitive Radar v3.0 - Level 4)
|
||||
Um die Analyse-Ergebnisse optimal nutzbar zu machen, wurde ein intelligenter Import-Prozess nach Notion implementiert (`import_competitive_radar.py`).
|
||||
|
||||
* **Architektur:** Vier vernetzte Datenbanken mit **semantischer Klassifizierung**:
|
||||
1. **📦 Companies (Hub):** Stammdaten und strategische Zusammenfassung.
|
||||
2. **💣 Landmines (Satellite):** Angriffsfragen, automatisch getaggt nach Themen:
|
||||
- *Price/TCO, Service/Support, Technology/AI, Performance, Trust/Reliability*.
|
||||
3. **🏆 References (Satellite):** Echte Kundenprojekte (Grounded Truth).
|
||||
4. **🤖 Products (Satellite):** Einzelne Produkte, klassifiziert nach Typ:
|
||||
- *Cleaning (Indoor/Outdoor), Transport/Logistics, Service/Gastro, Security, Software*.
|
||||
* **Dual-Way Relations:** Alle Datenbanken sind bidirektional verknüpft. Auf einer Produktkarte sieht man sofort den Hersteller; auf einer Herstellerkarte sieht man das gesamte (kategorisierte) Portfolio.
|
||||
|
||||
### 🚀 Next-Gen Analyse-Strategie (v5) - Beschluss vom 12. Jan. 2026
|
||||
|
||||
Die Analyse der v4-Ergebnisse zeigte fundamentale Schwächen im monolithischen Analyse-Ansatz. Probleme wie die falsche Gruppierung von Produktlisten (z.B. "A, B, C" als ein Produkt) und die fehlende Differenzierung desselben Produkts über verschiedene Anbieter hinweg (z.B. "BellaBot" vs. "Pudu Bella Bot") machten eine strategische Neuausrichtung notwendig.
|
||||
|
||||
Der neue Prozess basiert auf einer **"Extract-Normalize-Enrich" Pipeline in drei Phasen:**
|
||||
|
||||
**Phase 1: Datensammlung (pro Wettbewerber)**
|
||||
1. **Gezieltes Scraping:** Fokussierte Suche nach Seiten mit Keywords wie "Produkte", "Portfolio", "Lösungen". Der Rohtext dieser Seiten wird extrahiert.
|
||||
2. **Rohe Produkt-Extraktion (1. LLM-Call):** Ein einfacher, isolierter Prompt extrahiert nur eine unstrukturierte Liste potenzieller Produktnamen.
|
||||
3. **Deterministische Säuberung (Python):** Die rohe Liste wird per Code aufbereitet (Trennung bei Kommas, "und", etc.), um einzelne Produkte zu isolieren.
|
||||
4. **Allgemeine Analyse (2. LLM-Call):** Ein paralleler Prompt analysiert den Rohtext auf allgemeine, nicht-produktbezogene Merkmale (`delivery_model`, `target_industries`, `differentiators`).
|
||||
|
||||
**Phase 2: Marktweite Produkt-Kanonisierung (Global & Einmalig)**
|
||||
5. **Master-Liste erstellen:** Die bereinigten Produktlisten aller Wettbewerber werden zu einer globalen Master-Liste zusammengefasst.
|
||||
6. **Grounded Truth (Hersteller-Daten):** Eine vordefinierte, kanonische Produktliste der wichtigsten Hersteller (Pudu, Gausium etc.) wird als Referenz geladen.
|
||||
7. **Kanonisierungs-Prompt (3. LLM-Call):** Ein einziger, globaler Call gleicht die Master-Liste mit der "Grounded Truth" der Hersteller ab. Er gruppiert alle Namensvarianten ("Bella Bot", "Pudu BellaBot") unter einem kanonischen Namen ("BellaBot").
|
||||
|
||||
**Phase 3: Gezielte Anreicherung & Assemblierung (pro Wettbewerber)**
|
||||
8. **Portfolio zusammenstellen:** Das System iteriert durch die kanonische Produkt-Map aus Phase 2.
|
||||
9. **Anreicherungs-Prompt (Serie von Micro-LLM-Calls):** Für jedes kanonische Produkt, das ein Wettbewerber anbietet, wird ein kleiner, gezielter Prompt abgesetzt, um spezifische Details (`purpose`, `category`) aus dem ursprünglichen Rohtext zu extrahieren.
|
||||
10. **Finale Assemblierung:** Die Ergebnisse der allgemeinen Analyse (Schritt 4) und des angereicherten Portfolios (Schritt 9) werden zum finalen, sauberen und normalisierten JSON-Objekt für den Wettbewerber zusammengefügt.
|
||||
|
||||
Dieser Ansatz trennt klar zwischen Datensammlung, marktweiter Normalisierung und spezifischer Anreicherung, was zu deutlich präziseren, konsistenteren und wertvolleren Analyse-Ergebnissen führt.
|
||||
|
||||
### ✅ Status: Jan 12, 2026 - v5 STABLE & PRODUCTION READY
|
||||
|
||||
Die Implementierung der v5-Pipeline ist abgeschlossen. Die initialen Kinderkrankheiten (SDK-Konflikte, Token-Limits bei Matrizen) wurden durch radikale Architektur-Entscheidungen behoben.
|
||||
|
||||
**Die 3 Säulen der finalen Lösung:**
|
||||
|
||||
1. **Hybrid Intelligence (The "Matrix Fix"):**
|
||||
* **Problem:** LLMs scheiterten daran, große Matrizen (Produkte x Wettbewerber) konsistent als JSON zu generieren (Abbruch wegen Token-Limit).
|
||||
* **Lösung:** **Python übernimmt die Struktur, KI den Inhalt.** Die Matrizen (`product_matrix`, `industry_matrix`) werden nun **deterministisch im Python-Code berechnet**, basierend auf den in Phase 3 gesammelten Daten. Die KI wird nur noch für die *textliche* Zusammenfassung (`summary`, `opportunities`) gerufen. Das Ergebnis ist 100% fehlerfrei und stabil.
|
||||
|
||||
2. **User-In-The-Loop (Data Rescue):**
|
||||
* **Feature:** In Schritt 4 wurde ein "Repair"-Modus implementiert. Nutzer können nun für jeden Wettbewerber **manuelle Produkt-URLs** nachreichen und eine **isolierte Neu-Analyse** (Re-Scrape & Re-Enrich) für diesen einen Wettbewerber auslösen, ohne den gesamten Prozess neu zu starten. Dies löst das Problem von "versteckten" Produktseiten (z.B. Giobotics).
|
||||
|
||||
3. **Quality Boost (CoT):**
|
||||
* **Feature:** Der Enrichment-Prompt (Phase 3) nutzt nun **Chain-of-Thought (CoT)**. Anstatt stumpf Daten zu extrahieren, wird die KI angewiesen: *"Suche alle Erwähnungen -> Synthetisiere eine Beschreibung -> Bestimme die Kategorie"*. Dies hat die inhaltliche Qualität der Produktbeschreibungen wieder auf das hohe Niveau von v2 gehoben, bei gleichzeitiger Beibehaltung der sauberen Struktur von v3.
|
||||
|
||||
**Fazit:** Der Competitor Analysis Agent ist nun ein robustes, professionelles BI-Tool, das bereit für den produktiven Einsatz und den Import nach Notion ist.
|
||||
|
||||
### 🏆 Final Validation (Jan 12, 2026 - 14:00)
|
||||
|
||||
Der Validierungslauf mit `analysis_robo-planet.de-4.json` bestätigt den Erfolg aller Maßnahmen:
|
||||
|
||||
* **Lückenlose Erfassung:** Dank des "Repair Mode" (Manuelle URLs) konnte das Portfolio von *Giobotics*, das zuvor leer war, vollständig mit 9 Produkten (PuduBot 2, KettyBot, etc.) erfasst werden.
|
||||
* **Hohe Datentiefe:** Die Produktbeschreibungen sind dank **Chain-of-Thought** detailliert und wertstiftend (z.B. genaue Funktionsweise des *Phantas* Roboters bei TCO Robotics), statt nur generische Einzeiler zu sein.
|
||||
* **Perfekte Matrizen:** Die Python-generierten Matrizen sind vollständig und fehlerfrei. Das Token-Limit-Problem gehört der Vergangenheit an.
|
||||
* **Stabilität:** Der gesamte Prozess lief ohne Abstürze oder API-Fehler durch.
|
||||
|
||||
**Status:** ✅ **MIGRATION COMPLETE & VERIFIED.**
|
||||
|
||||
### 📡 Zukunftsfähigkeit & Ausblick: Das Competitor Radar
|
||||
|
||||
Neben der reinen Analyse wurde das Fundament für ein dauerhaftes Monitoring-System ("Competitor Radar") gelegt:
|
||||
|
||||
1. **Persistence (State Loading):**
|
||||
* **Feature:** Auf der Startseite wurde eine **Lade-Funktion** implementiert. Nutzer können nun eine zuvor exportierte `.json`-Datei hochladen, um den exakten Stand einer Analyse wiederherzustellen. Dies ermöglicht das Fortsetzen oder Aktualisieren von Berichten ohne Datenverlust.
|
||||
2. **Vision: Aktives Monitoring:**
|
||||
* In der nächsten Ausbaustufe wird das System von einer statischen On-Demand-Analyse zu einem dynamischen Radar transformiert. Ziel ist die automatisierte Überwachung der Wettbewerber auf:
|
||||
* **Neue Produkt-Releases:** Automatischer Abgleich mit der "Grounded Truth".
|
||||
* **Neuigkeiten & PR:** Scanning von News-Sektionen auf strategische Schwenks.
|
||||
* **Messen & Events:** Identifikation von Marktpräsenz und Networking-Aktivitäten.
|
||||
3. **Relationaler Import (v6):**
|
||||
* Der Notion-Import wurde auf **v6** aktualisiert. Er unterstützt nun lückenlos die neue v5-Struktur, importiert Chain-of-Thought Beschreibungen in Rich-Text-Felder und verknüpft erstmals auch die extrahierten **Referenzkunden** relational in Notion.
|
||||
|
||||
|
||||
### 📡 Post-Migration Architectural Refactoring (Jan 22, 2026): From Unified Import to GTM-Ready Architecture
|
||||
|
||||
**Problem Statement:** The v6 import structure, while relational, suffered from a fundamental design flaw: the informational depth of a product entry was identical for all vendors. A product sold by RoboPlanet was captured with the same superficial data fields as a competitor's product. This prevented the mapping of our detailed Go-to-Market strategies and, due to the "Purpose" texts generated by the LLM, continued to create duplicates, as identical products received slightly different descriptions.
|
||||
|
||||
**Strategic Decision: Separation of "What" from "How"**
|
||||
|
||||
To create a true "Single Source of Truth" and to enrich our own products with the necessary depth (GTM strategy, support knowledge, etc.), a new architecture was decided upon. The system is being converted from a 2-tier model (Companies ↔ Products) to a 3-tier model.
|
||||
|
||||
**The New 3-Tier Architecture:**
|
||||
|
||||
1. **🆕 Canonical Products (The "WHAT" Database):**
|
||||
* A completely new database that contains each product model (e.g., "Puma M20") **only once**.
|
||||
* Content: Objective master data (manufacturer, model, technical specs) and a relation to the `Product Categories` DB.
|
||||
* This is the market-wide, vendor-neutral truth.
|
||||
|
||||
2. ** repurposed Portfolio (The "HOW" Database):**
|
||||
* The existing `Competitive Radar (Products)` database is being repurposed and renamed.
|
||||
* It functions as a **junction table**. Each entry represents the relationship between a vendor and a canonical product.
|
||||
* Example Entries:
|
||||
* "RoboPlanet sells Puma M20"
|
||||
* "TCO Robotics sells Puma M20"
|
||||
* **Crucially:** This database contains the **context-specific information**. For RoboPlanet entries, the fields for the complete GTM strategy (target industries, pain points, battle cards, ROI logic, etc.) will be stored here. For competitor entries, these fields will remain empty.
|
||||
|
||||
3. ** Companies (The "WHO" Database):**
|
||||
* Remains unchanged and contains the master data of the competitors and of RoboPlanet itself.
|
||||
|
||||
**New Relational Link:**
|
||||
`[Canonical Products]` ↔️ `[Portfolio]` ↔️ `[Companies]`
|
||||
|
||||
**Migration Plan:**
|
||||
A one-time Python script will perform the "Operation Clean Architecture":
|
||||
1. **Schema Transformation:** Creation of the `Canonical Products` DB, conversion of the old product DB to the `Portfolio` DB.
|
||||
2. **Intelligent Migration:** Reading of the old entries, creation of the unique entries in `Canonical Products`, and subsequent re-linking of the (now) `Portfolio` entries.
|
||||
3. **Categorization:** Assignment of the canonical products to the global `Product Categories`.
|
||||
|
||||
**Result:** This refactoring elevates the system from a pure market intelligence tool to a true **Strategic Marketing OS** that can directly map and support our own sales and marketing processes.
|
||||
|
||||
---
|
||||
*Dokumentation finalisiert am 12.01.2026.*
|
||||
|
||||
210
docs/MOLTBOT_SYNOLOGY_GUIDE.md
Normal file
210
docs/MOLTBOT_SYNOLOGY_GUIDE.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# Moltbot auf Synology NAS installieren
|
||||
|
||||
**Status (Jan 2026):** Erfolgreich installiert und betriebsbereit.
|
||||
|
||||
Diese Anleitung beschreibt die empfohlene Methode zur Installation von Moltbot auf einer Synology DiskStation unter Verwendung des offiziellen Setup-Skripts via SSH.
|
||||
|
||||
---
|
||||
|
||||
## 1. Voraussetzungen
|
||||
|
||||
* **DSM 7.x** mit installiertem **Container Manager**.
|
||||
* **SSH-Zugang** zur Synology NAS ist aktiviert (Systemsteuerung → Terminal & SNMP → SSH).
|
||||
|
||||
---
|
||||
|
||||
## 2. Installation (Via SSH & Setup-Skript)
|
||||
|
||||
Die Installation erfolgt direkt auf der Kommandozeile der DiskStation.
|
||||
|
||||
### Schritt 1: Ordnerstruktur auf dem NAS anlegen
|
||||
|
||||
Zuerst legen wir die Verzeichnisse an, in denen die Konfiguration und die Arbeitsdaten von Moltbot persistent gespeichert werden.
|
||||
|
||||
```bash
|
||||
# Pfad für die Moltbot-Installation erstellen
|
||||
mkdir -p /volume1/docker/moltbot
|
||||
|
||||
# Unterordner für Konfiguration und Workspace anlegen
|
||||
mkdir -p /volume1/docker/moltbot/config
|
||||
mkdir -p /volume1/docker/moltbot/workspace
|
||||
|
||||
# WICHTIG: Berechtigungen setzen, damit der Container schreiben darf
|
||||
sudo chown -R 1000:1000 /volume1/docker/moltbot/config /volume1/docker/moltbot/workspace
|
||||
```
|
||||
|
||||
### Schritt 2: Repository klonen und Setup ausführen
|
||||
|
||||
Nun klonen wir das offizielle Moltbot-Repository und starten das Setup-Skript mit den richtigen Pfadangaben.
|
||||
|
||||
```bash
|
||||
# In das vorbereitete Verzeichnis wechseln
|
||||
cd /volume1/docker/moltbot
|
||||
|
||||
# Moltbot-Repository von GitHub klonen
|
||||
git clone https://github.com/moltbot/moltbot.git
|
||||
cd moltbot
|
||||
|
||||
# Umgebungsvariablen für die persistenten Pfade setzen
|
||||
export CLAWDBOT_CONFIG_DIR="/volume1/docker/moltbot/config"
|
||||
export CLAWDBOT_WORKSPACE_DIR="/volume1/docker/moltbot/workspace"
|
||||
|
||||
# Das offizielle Setup-Skript ausführen
|
||||
./docker-setup.sh
|
||||
```
|
||||
|
||||
### Schritt 3: Interaktives Onboarding
|
||||
|
||||
Das Skript startet einen interaktiven Onboarding-Prozess. Folgen Sie den Anweisungen. Die Standardwerte sind in der Regel eine gute Wahl. Am Ende startet der Moltbot-Gateway-Container automatisch.
|
||||
|
||||
---
|
||||
|
||||
## 3. Zugriff auf die Control UI (Aktueller Stand)
|
||||
|
||||
### Das "Secure Context"-Problem
|
||||
|
||||
Moltbot erfordert aus Sicherheitsgründen einen "sicheren Kontext" (HTTPS oder `localhost`) für den Zugriff auf das Web-Interface. Ein direkter Aufruf über `http://<NAS-IP>:18789` schlägt daher fehl und führt zu einer `disconnected (1008)`-Fehlermeldung.
|
||||
|
||||
### Lösung: SSH-Tunnel
|
||||
|
||||
Die aktuell funktionierende und sichere Methode für den Zugriff ist ein SSH-Tunnel. Dieser leitet den Port des Containers auf Ihren lokalen PC um, sodass der Zugriff über `localhost` erfolgt.
|
||||
|
||||
**Befehl zum Aufbau des Tunnels (auf Ihrem PC ausführen):**
|
||||
|
||||
```powershell
|
||||
# Ersetze <NAS-IP> mit der IP-Adresse Ihrer DiskStation
|
||||
ssh -N -L 28789:127.0.0.1:18789 root@<NAS-IP>
|
||||
```
|
||||
|
||||
**Zugriff im Browser:**
|
||||
|
||||
Solange der SSH-Tunnel aktiv ist, können Sie die Moltbot UI auf Ihrem PC unter folgender Adresse erreichen:
|
||||
|
||||
`http://127.0.0.1:28789/`
|
||||
|
||||
Denken Sie daran, den beim Onboarding generierten Token an die URL anzuhängen (z.B. `?token=...`), falls erforderlich.
|
||||
|
||||
---
|
||||
|
||||
## 4. Nächste Schritte: Zugriff vereinfachen
|
||||
|
||||
Der Zugriff über einen SSH-Tunnel ist sicher, aber für den täglichen Gebrauch und den Zugriff von unterwegs unpraktisch.
|
||||
|
||||
**Offener Task:**
|
||||
* Einrichtung eines **Reverse Proxys** auf der Synology DiskStation.
|
||||
* **Ziel:** Moltbot über eine sichere **HTTPS**-URL (z.B. `https://moltbot.meine-domain.de`) erreichbar zu machen. Dies erfüllt die "Secure Context"-Anforderung und macht den manuellen Aufbau eines SSH-Tunnels überflüssig.
|
||||
|
||||
[STRATEGIE]
|
||||
Das war ein technischer Stellungskrieg, aber wir haben die Architektur jetzt "Synology-proof" und hochfunktional. Der entscheidende Durchbruch war die Abkehr von der automatisierten Konfiguration hin zur **expliziten Architektur-Kontrolle** (Root-User, manuelle JSON-Injektion und Runtime-Bootstrapping).
|
||||
|
||||
Hier ist der destillierte **Setup-Guide 2026** für dein Gitea-Repository.
|
||||
|
||||
---
|
||||
|
||||
# 🦞 Moltbot Synology Deployment Guide (Feb 2026)
|
||||
|
||||
## 1. Strategischer Kontext
|
||||
Dieses Setup dient als Backend für die **GTM-Engine** von RoboPlanet. Es ist darauf optimiert, auf einer Synology DiskStation stabil zu laufen, Berechtigungskonflikte zu vermeiden und eine vollwertige **Python/Pip/Git-Umgebung** für automatisierte Workflows bereitzustellen.
|
||||
|
||||
## 2. Infrastruktur (Host-Ebene)
|
||||
Bevor der Container startet, muss die Verzeichnisstruktur auf der DiskStation exakt so vorbereitet sein. Dies verhindert "Bind mount"-Fehler und sichert die Datenpersistenz.
|
||||
|
||||
```bash
|
||||
# Hauptverzeichnis
|
||||
mkdir -p /volume1/docker/moltbot
|
||||
|
||||
# Unterordner für saubere Trennung
|
||||
mkdir -p /volume1/docker/moltbot/storage # Datenbank & State (~/.clawdbot)
|
||||
mkdir -p /volume1/docker/moltbot/config # Statische Konfiguration
|
||||
mkdir -p /volume1/docker/moltbot/workspace # Arbeitsbereich für Agenten-Scripte
|
||||
mkdir -p /volume1/docker/moltbot/secrets # API-Keys & Zertifikate
|
||||
|
||||
# Rechte-Management (Zwingend für Synology)
|
||||
# Wir setzen 1000:1000 (Node) oder nutzen user:root im Container
|
||||
sudo chown -R 1000:1000 /volume1/docker/moltbot
|
||||
```
|
||||
|
||||
## 3. Konfiguration (Die "Ground Truth")
|
||||
Manuelle Erstellung der Konfiguration, um Validierungsfehler der CLI zu umgehen. Erstelle die Datei `/volume1/docker/moltbot/config/moltbot.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"gateway": {
|
||||
"mode": "local",
|
||||
"bind": "lan",
|
||||
"port": 18789,
|
||||
"auth": {
|
||||
"token": "DEIN_GATEWAY_TOKEN"
|
||||
}
|
||||
},
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Docker-Compose (Die Engine)
|
||||
Die finale `docker-compose.yml`. Zentrale Entscheidungen:
|
||||
- **user: root**: Erforderlich für die Installation von System-Paketen (Python) zur Laufzeit.
|
||||
- **command-Bootstrap**: Installiert Python & Git bei jedem Start, falls das Image aktualisiert wird.
|
||||
- **auth-profiles Injection**: Schreibt den Gemini-Key direkt in den Agent-Speicher.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
openclaw-gateway:
|
||||
image: ghcr.io/openclaw/moltbot:main
|
||||
container_name: openclaw-gateway
|
||||
user: root
|
||||
environment:
|
||||
MOLTBOT_STATE_DIR: /home/node/.clawdbot
|
||||
OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
|
||||
TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN}
|
||||
GEMINI_API_KEY: ${GEMINI_API_KEY}
|
||||
HOME: /home/node
|
||||
volumes:
|
||||
- /volume1/docker/moltbot/storage:/home/node/.clawdbot
|
||||
- /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace
|
||||
- /volume1/docker/moltbot/config/moltbot.json:/home/node/.clawdbot/moltbot.json:ro
|
||||
ports:
|
||||
- "18789:18789"
|
||||
init: true
|
||||
restart: unless-stopped
|
||||
command: >
|
||||
sh -lc '
|
||||
apt-get update && apt-get install -y python3 python3-pip git build-essential
|
||||
mkdir -p /home/node/.clawdbot/agents/main/agent
|
||||
echo "{\"google\": {\"apiKey\": \"$${GEMINI_API_KEY}\"}}" > /home/node/.clawdbot/agents/main/agent/auth-profiles.json
|
||||
exec node dist/index.js gateway --bind lan
|
||||
'
|
||||
|
||||
openclaw-cli:
|
||||
image: ghcr.io/openclaw/moltbot:main
|
||||
container_name: openclaw-cli
|
||||
user: root
|
||||
environment:
|
||||
MOLTBOT_GATEWAY_URL: ws://openclaw-gateway:18789
|
||||
MOLTBOT_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
|
||||
volumes:
|
||||
- /volume1/docker/moltbot/storage:/home/node/.clawdbot
|
||||
- /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace
|
||||
entrypoint: ["node", "dist/index.js", "--gateway", "ws://openclaw-gateway:18789"]
|
||||
stdin_open: true
|
||||
tty: true
|
||||
```
|
||||
|
||||
## 5. Operative Key-Entscheidungen (Review)
|
||||
1. **Pfad-Konsistenz:** Umstellung von `.openclaw` auf `.clawdbot` (Projekt-Migration 2026 gefolgt).
|
||||
2. **Bind-Parameter:** Wechsel von `0.0.0.0` auf `lan`, da das Gateway-Modul spezifische Keywords für das Interface-Binding verlangt.
|
||||
3. **CLI-Targeting:** Die CLI wurde über den `entrypoint` fest auf den Gateway-Service verdrahtet, um den Loopback-Fehler (`127.0.0.1`) innerhalb des Docker-Netzwerks permanent zu beheben.
|
||||
4. **Pairing-Prozess:** Initialisierung via Telegram erfordert ein einmaliges `pairing approve` über die CLI, um die User-ID des Besitzers zu verknüpfen.
|
||||
|
||||
## 6. Wartung
|
||||
- **Python-Module:** Können über `docker exec -it openclaw-gateway pip install <modul>` nachinstalliert werden.
|
||||
- **Updates:** `docker compose pull && docker compose up -d` (Das Bootstrap-Skript installiert Python automatisch nach).
|
||||
|
||||
---
|
||||
|
||||
[STATUS]
|
||||
Das System läuft. Python ist installiert. Gemini ist autorisiert. Die GTM-Engine ist bereit für den ersten "Whale Hunting" Task. Was ist die erste operative Aufgabe, die der Bot für dich erledigen soll? Gitea-Clone oder Prospecting-Analyse? 🦞
|
||||
14
docs/NOTION_TASK_SUMMARY.md
Normal file
14
docs/NOTION_TASK_SUMMARY.md
Normal file
@@ -0,0 +1,14 @@
|
||||
**Task Summary: Add a Share Button `[2f488f42]`**
|
||||
|
||||
**Status:** ✅ Done
|
||||
|
||||
**Project:** Meeting Assistant (Transcription Tool)
|
||||
|
||||
**Changes Implemented:**
|
||||
- A new "Share" button has been successfully added to the toolbar in the transcript detail view.
|
||||
- The button is visually aligned with the existing "Copy" and "Download" actions, utilizing the `Share2` icon for consistency.
|
||||
- The feature is UI-only as per the requirements; clicking the button currently triggers a placeholder alert. No backend or sharing logic has been implemented yet.
|
||||
|
||||
**Next Steps:**
|
||||
- The functionality for sharing can be implemented in a future task.
|
||||
- The change is ready to be committed and pushed.
|
||||
199
docs/Notion_Dashboard.md
Normal file
199
docs/Notion_Dashboard.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# Dokumentation: RoboPlanet Strategic Marketing OS (v1.0)
|
||||
|
||||
## 1. Vision & Primärauftrag
|
||||
Das **RoboPlanet Strategic Marketing OS** ist kein reines Content-Tool, sondern das digitale Zentralnervensystem für das Growth-Marketing der RoboPlanet GmbH (Wackler Group). Es transformiert unstrukturierte Herstellerdaten und Marktschmerz-Analysen in eine skalierbare, hochgradig personalisierte Go-to-Market-Maschine.
|
||||
|
||||
**Kern-Mission:**
|
||||
* **Whale Hunting:** Identifikation und Durchdringung von Großkunden (Logistik >10k m², Chemieparks, Malls).
|
||||
* **Wackler-Symbiose:** Integration des menschlichen Service-Layers (NSL, Reinigung, Security) in das Robotik-Versprechen.
|
||||
* **Hyper-Skalierung:** Reduktion des Aufwands pro Kampagne bei gleichzeitiger Steigerung der Relevanz (Precision Targeting).
|
||||
|
||||
---
|
||||
|
||||
## 2. System-Architektur (The Big Picture)
|
||||
|
||||
Das System basiert auf einer **Decoupled Architecture**:
|
||||
|
||||
1. **The Intelligence Factory (Backend):** Python-Services (Docker, SQLite) für Scraping, Data Mining, Normalisierung und KI-Generierung.
|
||||
2. **The Strategic Hub (Frontend/Control):** Notion als Single Source of Truth (SSoT) für Strategie, Portfolio-Management und Reporting.
|
||||
3. **The Execution Channels (Outbound):** SuperOffice API (CRM/Mails), WordPress API (Public Web), Messaging Matrix (Automation).
|
||||
|
||||
---
|
||||
|
||||
## 3. Funktionsmodule (Detaillierte Beschreibung)
|
||||
|
||||
### 3.1 Product Master (Hardware Truth)
|
||||
Zentrale Instanz für alle technischen Spezifikationen.
|
||||
* **Funktion:** Automatisierte Extraktion von harten Fakten aus Hersteller-Quelltexten.
|
||||
* **Normalisierung:** Umwandlung heterogener Daten (z.B. "1:30h" -> 90 Min, "3000 sqm/h" -> 3000) zur direkten Vergleichbarkeit.
|
||||
* **Zukunftsfähigkeit:** Modularer Aufbau durch "Layer-Logik" (Cleaning-Layer, Service-Layer, Security-Layer).
|
||||
|
||||
### 3.2 Sector & Persona Master (Psychology Layer)
|
||||
Das "Gehirn", das früher in YAML-Dateien gefangen war.
|
||||
* **Sektoren:** Definition der Zielbranchen (Hotellerie, Chemie, etc.) inklusive der "RoboPlanet-Definition" (Was bedeutet diese Branche für uns?).
|
||||
* **Personas:** Psychologische Profile (Housekeeping, Werkschutz, CEO) mit spezifischen Pains (Mirror) und Gains (Value).
|
||||
* **Probing Questions:** Branchenspezifische Fragen, die das Scraping-Tool leiten (z.B. "Hat das Hotel einen Spa?").
|
||||
|
||||
### 3.3 Messaging Matrix (The Secret Sauce)
|
||||
Die Schaltstelle für die hyper-personalisierte Ansprache.
|
||||
* **Logik:** Trennung in **Satz 1** (Individueller Hook basierend auf der aktuellen Website-Analyse des Zielkunden) und **Satz 2** (Relationaler Lösungsbaustein basierend auf Branche + Produkt).
|
||||
* **Voice-Ready:** Vorbereitung von Skripten für den zukünftigen Voice-KI-Einsatz im Vertrieb und Support.
|
||||
|
||||
### 3.4 Competitive Radar & GTM Engine (Market Intelligence v3.0)
|
||||
Automatisierte Überwachung der Marktbegleiter *und* zentrale Steuerung der eigenen Go-to-Market-Strategien.
|
||||
* **Architektur-Upgrade (Jan 2026):** Das System wurde auf eine 3-Tier-Architektur umgestellt, um zwischen dem **kanonischen Produkt** (was es ist) und dem **Portfolio-Eintrag** (wer es zu welchen Konditionen/mit welcher Strategie verkauft) zu unterscheiden.
|
||||
* **Funktion (Market Intelligence):** Kontinuierliches Scraping von Wettbewerber-Webseiten zur Identifikation ihres Produkt-Portfolios, ihrer Referenzkunden und zur Erstellung von "Landmines" (Angriffsfragen).
|
||||
* **Funktion (GTM Engine):** Für RoboPlanet-eigene Produkte dient das System als "Single Source of Truth". Es erfasst die komplette GTM-Strategie – von der technischen Analyse über die Definition der Zielbranchen (ICPs) und Schmerzpunkte bis hin zur Erstellung von Sales-Battlecards und ROI-Rechnern.
|
||||
* **Relationaler Kern:** Das System besteht nun aus einem Netz von Datenbanken, dessen Herzstück die Triade `Canonical Products` ↔️ `Portfolio` ↔️ `Companies` ist. Dies ermöglicht es, ein Produkt (z.B. "Puma M20") einmal zentral zu definieren und dann spezifische Marketing- und Vertriebsstrategien für den Verkauf durch RoboPlanet anzuhängen, während gleichzeitig erfasst wird, welche Wettbewerber dasselbe Produkt führen.
|
||||
|
||||
### 3.5 Enrichment Factory & RevOps
|
||||
Datenanreicherung der CRM-Accounts.
|
||||
* **Mining:** Suche nach Umsatz, MA-Zahlen und fehlenden Ansprechpartnern via LinkedIn/SerpAPI.
|
||||
* **Klassifizierung:** Automatisches Mapping von Jobtiteln zu definierten Rollen im Strategic OS.
|
||||
* **Reporting:** Aggregation von Outbound-Metriken (Mails sent, Response Rate) zurück nach Notion für das C-Level.
|
||||
|
||||
---
|
||||
|
||||
## 4. Workflows & Datenflüsse
|
||||
|
||||
### A. Der GTM-Prozess (Produkt-Launch)
|
||||
1. **Ingest:** Hersteller-URL wird in die GTM-Engine eingespeist.
|
||||
2. **Extraction:** Technische Specs werden normalisiert und in den Notion **Product Master** geschrieben.
|
||||
3. **Positioning:** KI matcht Specs gegen die **Market Psychology DB** in Notion.
|
||||
4. **Generation:** Erstellung von Website-Inhalten (WordPress API) und Sales-Battlecards.
|
||||
|
||||
### C. Der Market-Intelligence-Prozess (Inkrementeller Import)
|
||||
Nach der Umstrukturierung der Datenbanken wurde der Importprozess von einem reinen "Einmal-Import" zu einem intelligenten, zustandsbewussten Synchronisierungs-Workflow weiterentwickelt. Dies ist der Schlüssel, um das System als lebendes "Market Radar"-Tool zu nutzen.
|
||||
|
||||
1. **Trigger:** Manueller Start des `import_competitive_radar.py` Skripts mit einer neuen Analyse-JSON-Datei als Input.
|
||||
2. **Phase 1: State Awareness (IST-Zustand lesen):**
|
||||
* Bevor das Skript die neue Datei liest, fragt es den aktuellen Stand in Notion ab.
|
||||
* Es erstellt drei "Caches" im Arbeitsspeicher: eine Liste aller existierenden Firmen, eine Liste aller `Canonical Products` und eine Liste aller `Portfolio`-Verknüpfungen (welche Firma verkauft welches Produkt).
|
||||
3. **Phase 2: Abgleich & "Upsert" (SOLL-Zustand verarbeiten):**
|
||||
* Das Skript liest die neue JSON-Datei Wettbewerber für Wettbewerber.
|
||||
* **"Upsert" Logik:** Für jeden Eintrag (Firma, Produkt, Portfolio-Verknüpfung) prüft es gegen seine Caches, ob dieser bereits in Notion existiert.
|
||||
* **Fall A (Existiert bereits):** Der Eintrag wird übersprungen. Es werden keine Änderungen vorgenommen.
|
||||
* **Fall B (Existiert noch nicht):** Nur der fehlende Eintrag wird erstellt. Wenn z.B. das Produkt "BellaBot" schon existiert, aber die Firma "Robo-Heroes" neu ist, wird nur die neue Firma und die neue Portfolio-Verknüpfung ("Robo-Heroes verkauft BellaBot") angelegt.
|
||||
4. **Ergebnis (Idempotenter Import):**
|
||||
* **Keine Duplikate:** Firmen und kanonische Produkte werden niemals doppelt erstellt.
|
||||
* **Inkrementelle Updates:** Nur neue Informationen werden hinzugefügt. Das System wächst mit jeder Analyse, anstatt überschrieben zu werden.
|
||||
* **Sicherheit:** Das Skript kann beliebig oft mit derselben Datei ausgeführt werden. Nach dem ersten Lauf wird es keine Änderungen mehr vornehmen, da es erkennt, dass alle Daten bereits synchronisiert sind.
|
||||
|
||||
---
|
||||
|
||||
## 5. Outside-the-Box Hebel (Ausblick 6-12 Monate)
|
||||
|
||||
### 5.1 The Brain (Knowledge Ingestor)
|
||||
Befreiung von implizitem Wissen aus WhatsApp/E-Mail-Silos. Ein Postfach-Scraper extrahiert Lösungsfragmente der Techniker und führt sie in Notion als strukturierte Wissensbasis für Support und RAG-Systeme zusammen.
|
||||
|
||||
### 5.2 Voice-Bot Integration
|
||||
Nutzung der `Voice Script` Felder in der Messaging Matrix zur Speisung von AI-Voice-Agenten für Erstqualifizierung und Terminvereinbarung.
|
||||
|
||||
### 5.3 Combat View (Mobile Enablement)
|
||||
Reduzierte Notion-Ansicht für Vertriebler vor Ort, die basierend auf dem Standort/Kunden-Sektor sofort die 3 schlagkräftigsten Verkaufsargumente liefert.
|
||||
|
||||
---
|
||||
|
||||
## 6. Notion Datenbank-Relationen (Technisches Mapping - Architektur v3.0)
|
||||
|
||||
Um die relationale Integrität zu wahren, sind folgende Datenbanken in Notion zwingend zu verknüpfen. Das Modell trennt zwischen anbieterneutralen Stammdaten (`Canonical Products`) und der anbieterspezifischen Vertriebssicht (`Portfolio`).
|
||||
|
||||
* **Kern-Relationen (Produkt & Markt):**
|
||||
* **Canonical Products** ↔️ **Portfolio** (Ein kanonisches Produkt kann in mehreren Portfolios sein)
|
||||
* **Companies** ↔️ **Portfolio** (Ein Unternehmen hat mehrere Produkte im Portfolio)
|
||||
* **Canonical Products** ↔️ **Product Categories** (Jedes Produkt gehört zu einer Kategorie)
|
||||
|
||||
* **GTM & Marketing-Relationen:**
|
||||
* **Canonical Products** ↔️ **Sector & Persona Master** (Welcher Roboter passt in welchen Markt?)
|
||||
* **Messaging Matrix** ↔️ **Canonical Products** (Welche Lösung gehört zum Text?)
|
||||
* **Messaging Matrix** ↔️ **Sector & Persona Master** (Welcher Schmerz gehört zu welcher Branche?)
|
||||
* **GTM Workspace** ↔️ **Canonical Products** (Welche Kampagne bewirbt welches Gerät?)
|
||||
* **Feature-to-Value Translator** ↔️ **Canonical Products** (Welcher Nutzen gehört zu welchem Feature?)
|
||||
|
||||
* **Competitive Intelligence-Relationen:**
|
||||
* **Companies** ↔️ **Competitive Radar (Landmines)** (Welche Angriffsfragen gehören zu welchem Wettbewerber?)
|
||||
* **Companies** ↔️ **Competitive Radar (References)** (Welche Kundenprojekte hat der Wettbewerber realisiert?)
|
||||
|
||||
* **Wissensmanagement-Relationen:**
|
||||
* **The Brain** ↔️ **Canonical Products** (Welches Support-Wissen gehört zu welcher Hardware?)
|
||||
|
||||
---
|
||||
|
||||
## 7. Zusammenfassung der technischen Hebel
|
||||
1. **Python API Gateway:** Einziger Kommunikationspunkt für alle KI-Anfragen und CRM/WP-Transaktionen.
|
||||
2. **SQLite Persistence:** Lokales Zwischenlagern von Scrape-Ergebnissen zur Vermeidung redundanter API-Kosten.
|
||||
3. **Human-in-the-loop:** Notion dient als "Freigabe-Layer" – erst nach manuellem Review in Notion triggert Python den CRM-Push oder den Website-Publish.
|
||||
|
||||
---
|
||||
|
||||
## 8. Lessons Learned & Technische Constraints (Stand Jan. 2026)
|
||||
|
||||
Während der initialen Prototyping-Phase wurden kritische technische Hürden identifiziert, die bei der finalen Implementierung (insb. via Gemini CLI) proaktiv adressiert werden müssen.
|
||||
|
||||
### 8.1 API-Latenz & „Eventual Consistency“
|
||||
* **Problem:** Wenn eine Datenbank via API erstellt wird, meldet Notion sofort den Erfolg (`200 OK`). Die internen Indizes der Spalten (Properties) sind jedoch oft erst 15–30 Sekunden später für Schreibzugriffe (`pages.create`) bereit.
|
||||
* **Lösung:** Nach DDL-Operationen (Erstellen/Ändern von Datenbank-Strukturen) muss zwingend ein **Wait-Timer (min. 15s)** eingebaut werden, bevor Daten in diese Struktur injiziert werden.
|
||||
|
||||
### 8.2 SDK vs. Native REST
|
||||
* **Erkenntnis:** Das offizielle Python-SDK (`notion-client`) verhielt sich auf der Server-Umgebung (Diskstation/Python 3.8) instabil und meldete fehlende Methoden (z.B. `.query`), die laut Dokumentation vorhanden sein sollten.
|
||||
* **Lösung:** Für geschäftskritische Prozesse und Massen-Injektionen ist der **direkte Weg über die REST-API** (Python `requests` Bibliothek) vorzuziehen. Dies eliminiert Abhängigkeiten und bietet volle Transparenz über die Fehlermeldungen von Notion.
|
||||
|
||||
### 8.3 Suchindex-Verzögerung
|
||||
* **Problem:** Neu erstellte Datenbanken tauchen erst mit erheblicher Verzögerung im `notion.search`-Index auf. Skripte, die Datenbanken „dynamisch suchen“, schlagen in der Deployment-Phase daher oft fehl.
|
||||
* **Lösung:** Während des Setups müssen die von der API zurückgegebenen **UUIDs (IDs)** direkt im Speicher gehalten und an nachfolgende Funktionen übergeben werden, anstatt sich auf Suchbegriffe zu verlassen.
|
||||
|
||||
### 8.4 Property-Namenskonventionen
|
||||
* **Problem:** Sonderzeichen (z.B. `/` in `Branche/Persona`) oder führende/nachfolgende Leerzeichen in Spaltentiteln führen zu `400 Bad Request` Fehlern, da die API extrem sensitiv auf exakte String-Matches reagiert.
|
||||
* **Lösung:** Nutzung von **einfachen, alphanumerischen Bezeichnern** (z.B. `Art`, `Beschreibung`, `Status`). Die kosmetische Aufbereitung (Icons, längere Namen) sollte erst *nach* dem erfolgreichen API-Mapping manuell oder über ein explizites Update-Skript erfolgen.
|
||||
|
||||
### 8.5 Relation-Wiring (Das Henne-Ei-Problem)
|
||||
* **Problem:** Eine Datenbank kann keine Relation zu einer anderen Datenbank aufbauen, wenn diese noch nicht existiert.
|
||||
* **Lösung:** Zweistufiger Deployment-Prozess:
|
||||
1. **Phase A:** Erstellen aller 7 Datenbank-Hüllen mit Basis-Properties.
|
||||
2. **Phase B:** Nachträgliches „Verdrahten“ der Relationen via `databases.update` unter Verwendung der in Phase A generierten IDs.
|
||||
|
||||
### 8.6 Authentifizierung & Scoping
|
||||
* **Erkenntnis:** Notion-Integrationen benötigen explizite Freigaben pro Seite. Wenn eine Datenbank gelöscht und neu erstellt wird, muss die Verbindung in der Notion-UI oft **manuell neu autorisiert** werden, auch wenn die übergeordnete Seite bereits freigegeben war.
|
||||
* **Lösung:** Bei jedem neuen Deployment-Lauf in der Notion-UI prüfen, ob die „RoboPlanet GTM Engine“ unter den `Connections` der Zielseite gelistet ist.
|
||||
|
||||
### 8.7 Initial Database IDs (Stand 08. Jan. 2026)
|
||||
Die folgenden IDs wurden bei der initialen Erstellung der Datenbanken generiert und sollten für die weitere Entwicklung verwendet werden, um Suchindex-Verzögerungen zu vermeiden:
|
||||
* **Product Master:** `2e288f42-8544-81d8-96f5-c231f84f719a`
|
||||
* **Sector & Persona Master:** `2e288f42-8544-8113-b878-ec99c8a02a6b`
|
||||
* **Messaging Matrix:** `2e288f42-8544-81b0-83d4-c16623cc32d1`
|
||||
* **Competitive Radar:** `2e288f42-8544-814a-a2ad-eee8a181a3cc`
|
||||
* **Enrichment Factory & RevOps:** `2e288f42-8544-8172-a3a7-f5101b6ac0f0`
|
||||
* **The Brain:** `2e288f42-8544-810f-8e7d-e9a2a3100779`
|
||||
* **GTM Workspace:** `2e288f42-8544-81cc-b167-f9dffe9c7bde`
|
||||
* **Feature-to-Value Translator:** `2e288f42-8544-8184-ba08-d6d736879f19`
|
||||
* **Projects [UT]:** `2e288f42-8544-8179-9eaa-f2bc594eece3` (Identifiziert am 25. Jan. 2026)
|
||||
* **All Tasks:** `2e888f42-8544-815c-be46-c36bbb1b7e2b` (Identifiziert am 25. Jan. 2026)
|
||||
|
||||
---
|
||||
|
||||
### Checkliste für den Neustart mit Gemini CLI:
|
||||
1. [ ] **Requests statt SDK:** Nutze die native HTTP-Library für alle Notion-Calls.
|
||||
2. [ ] **ID-Persistence:** Speichere IDs in einer lokalen JSON-Variable während des Laufs. (Nun fest in Doku hinterlegt)
|
||||
3. [ ] **Schema-Validation:** Nutze einen `database.retrieve` Call vor dem ersten Daten-Push, um die Existenz der Spaltennamen zu verifizieren.
|
||||
4. [ ] **Error-Logging:** Implementiere detailliertes Logging der API-Response-Bodys, da Notion dort sehr präzise Hinweise gibt (z.B. `property_not_found`).
|
||||
|
||||
---
|
||||
**Status:** Blueprint Finalisiert.
|
||||
**Nächster Schritt:** Umsetzung der Datenbank-Properties und API-Endpunkte gemäß diesem Dokument.
|
||||
|
||||
### 8.8 Erfolgreicher Datenimport & -verteilung (08. Jan. 2026)
|
||||
Der Produkt-Datensatz "Puma M20" wurde erfolgreich importiert. Die strategischen Daten (Zielgruppen, Pain Points, Messaging) wurden anschließend aus dem Produkteintrag extrahiert und in die relational verknüpften Datenbanken "Sector & Persona Master" und "Messaging Matrix" verteilt. Dies schafft eine "Single Source of Truth" und legt die Grundlage für automatisierte Marketing-Workflows.
|
||||
|
||||
### 8.9 Neu gelernte Lektionen (Post-MVP)
|
||||
|
||||
6. **Notion API - Schema First:**
|
||||
* **Problem:** Skripte schlugen fehl beim Versuch, Daten in eine nicht existierende Datenbankeigenschaft (Spalte) zu schreiben.
|
||||
* **Lösung:** IMMER sicherstellen, dass das Datenbankschema korrekt ist, *bevor* Daten importiert oder aktualisiert werden. Den `databases.update`-Endpunkt verwenden, um die erforderlichen Eigenschaften (z.B. "Key Features", "Constraints") programmatisch als vorbereitenden Schritt hinzuzufügen. Die API erstellt diese nicht spontan.
|
||||
|
||||
7. **Notion API - Zeichenbeschränkungen:**
|
||||
* **Problem:** API-Aufrufe schlugen mit einem `400 Bad Request`-Fehler fehl, wenn ein Rich-Text-Feld die maximale Länge überschritt.
|
||||
* **Lösung:** Das **2000-Zeichen-Limit** für Rich-Text-Eigenschaften beachten. Eine Logik implementieren, um den Textinhalt vor dem Senden des Payloads an die Notion-API zu kürzen, um Validierungsfehler zu vermeiden.
|
||||
|
||||
8. **Notion API - Antwortstrukturen:**
|
||||
* **Problem:** Parsing-Funktionen schlugen mit `TypeError` oder `AttributeError` fehl, da die JSON-Struktur für eine Eigenschaft unterschiedlich war, je nachdem, wie sie angefordert wurde.
|
||||
* **Lösung:** Robuste Hilfsfunktionen schreiben, die mehrere mögliche JSON-Strukturen verarbeiten können. Ein Eigenschaftsobjekt, das über einen direkten Eigenschafts-Endpunkt (`/pages/{id}/properties/{prop_id}`) abgerufen wird, ist anders strukturiert als dieselbe Eigenschaft, wenn sie Teil eines vollständigen Seitenobjekts (`/pages/{id}`) ist. Die Parsing-Logik muss diese Variationen berücksichtigen.
|
||||
116
docs/README_dev_session.md
Normal file
116
docs/README_dev_session.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# `dev_session.py` - Notion Development Session Manager
|
||||
|
||||
## Übersicht
|
||||
|
||||
`dev_session.py` ist ein Kommandozeilen-Tool (CLI), das den Entwicklungs-Workflow durch die Integration mit Notion und Git optimiert. Es dient als Brücke zwischen der interaktiven Gemini CLI-Sitzung und dem Projektmanagement in Notion.
|
||||
|
||||
**Wichtige Architekturänderung:** Das Skript `dev_session.py` startet die Gemini CLI nicht mehr direkt. Stattdessen durchläuft der Entwickler einen interaktiven Setup-Prozess, an dessen Ende ein Kontext für die Gemini CLI generiert wird. Das übergeordnete `start-gemini.sh`-Skript fängt diesen Kontext auf und startet die Gemini CLI in einer sauberen, isolierten Docker-Sitzung. Dieser zweistufige Prozess gewährleistet eine stabile und kontextbezogene Entwicklungsumgebung.
|
||||
|
||||
## Funktionen
|
||||
|
||||
* **Interaktive Projekt- und Task-Auswahl:** Wähle Projekte und Tasks direkt aus deinen Notion-Datenbanken.
|
||||
* **Automatischer Start-Status:** Setzt den Status des ausgewählten Tasks beim Start der Sitzung automatisch auf 'Doing'.
|
||||
* **Task-Erstellung:** Erstelle neue Tasks direkt über das CLI im Kontext des ausgewählten Projekts.
|
||||
* **Agent-gesteuerte Statusberichte:** Ermöglicht dem Gemini-Agenten, nach Abschluss eines Arbeitspakets einen detaillierten Statusbericht an Notion zu senden, Code zu committen und zu pushen.
|
||||
* **Automatisches Commit-Feedback:** Ein `post-commit` Git-Hook sendet jede Commit-Nachricht als kurzen Kommentar an den Notion-Task.
|
||||
* **Kontext-Generierung für Gemini CLI:** Erzeugt einen strukturierten Start-Prompt mit allen relevanten Informationen (Projekt, Task, Beschreibung, Git-Branch).
|
||||
* **Vorgeschlagene Git Branch-Benennung:** Erstellt einen konsistenten Git-Branch-Namen basierend auf der Task-ID und dem Titel.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
* **Docker:** Das gesamte Setup ist containerisiert.
|
||||
* **Notion Integration Token:** Ein Notion API-Token mit Zugriff auf Ihre "Projects"- und "Tasks"-Datenbanken.
|
||||
|
||||
## Installation und Einrichtung
|
||||
|
||||
1. **Notion API Key:**
|
||||
* Stellen Sie sicher, dass Sie einen Notion Integration Token haben.
|
||||
* Das Skript fragt beim ersten Start interaktiv nach dem Token. Alternativ kann er als Umgebungsvariable `NOTION_API_KEY` in einer `.env`-Datei im Hauptverzeichnis gespeichert werden.
|
||||
* Gewähren Sie Ihrer Notion-Integration Zugriff auf die relevanten Datenbanken.
|
||||
|
||||
2. **Abhängigkeiten:** Alle Abhängigkeiten sind im `gemini.Dockerfile` definiert und werden automatisch im Container installiert.
|
||||
|
||||
## Der Entwicklungs-Workflow
|
||||
|
||||
Der Workflow ist in drei Hauptphasen unterteilt: Sitzung starten, in der Sitzung arbeiten und Ergebnisse zurückmelden.
|
||||
|
||||
### 1. Sitzung starten
|
||||
|
||||
Der gesamte Startvorgang wird über das `start-gemini.sh`-Skript orchestriert.
|
||||
|
||||
```bash
|
||||
./start-gemini.sh
|
||||
```
|
||||
|
||||
**Was im Hintergrund passiert:**
|
||||
|
||||
1. Das Skript führt `dev_session.py` in einem temporären Docker-Container aus.
|
||||
2. Sie durchlaufen den interaktiven Auswahlprozess für Ihr Projekt und Ihren Task in Notion.
|
||||
3. Nach der Auswahl generiert `dev_session.py` den Kontext, speichert die Session-Informationen (z.B. Task-ID) in `.dev_session/SESSION_INFO`, installiert die Git-Hooks und gibt den Kontext an die Standardausgabe aus.
|
||||
4. `start-gemini.sh` fängt diese Ausgabe ab, extrahiert den Kontext und startet einen neuen, sauberen Docker-Container (`gemini-session`) mit der Gemini CLI, wobei der Kontext als Start-Prompt übergeben wird.
|
||||
|
||||
Dieser Prozess stellt sicher, dass Ihre interaktive Gemini-Sitzung von der Notion-Logik entkoppelt ist und mit allen relevanten Informationen beginnt.
|
||||
|
||||
### 2. Arbeiten in der Gemini CLI
|
||||
|
||||
Nach dem Start befinden Sie sich in der Gemini CLI. Hier findet die eigentliche Entwicklungsarbeit statt.
|
||||
|
||||
* **Commits:** Wenn Sie oder der Agent `git commit` ausführen, greift der `post-commit`-Hook. Er liest die Task-ID aus der Session-Datei und sendet die Commit-Nachricht automatisch als kurzen Kommentar an den verknüpften Notion-Task. Dies sorgt für eine granulare Nachverfolgung des Fortschritts.
|
||||
|
||||
### 3. Fortschritt melden und Änderungen pushen (Agent-gesteuerter Workflow)
|
||||
|
||||
Dies ist der primäre Weg, um ein logisches Arbeitspaket abzuschließen und den Fortschritt zu dokumentieren. Anstatt Git-Befehle und Notion-Updates manuell zu koordinieren, geben Sie dem Agenten eine übergeordnete Anweisung.
|
||||
|
||||
**Beispiel-Anweisung an den Gemini-Agenten:**
|
||||
|
||||
> "Okay, die Implementierung ist abgeschlossen. Fasse die Arbeit zusammen, erstelle einen Statusbericht für Notion, committe alle Änderungen und pushe sie."
|
||||
|
||||
**Was der Agent im Hintergrund tut:**
|
||||
|
||||
1. **Informationen sammeln:** Der Agent führt einen kurzen Dialog mit Ihnen, um den neuen Status (`Bereit für Review`, `Blockiert` etc.) und eventuelle offene To-Dos zu erfragen.
|
||||
2. **Git-Änderungen analysieren:** Der Agent generiert eine Zusammenfassung der geänderten Dateien und der neuen Commit-Nachrichten.
|
||||
3. **Notion-Update (nicht-interaktiv):** Der Agent ruft `dev_session.py` mit den gesammelten Informationen als Parameter auf.
|
||||
```bash
|
||||
python3 dev_session.py --report-status \
|
||||
--status "Ready for Review" \
|
||||
--todos "- Finale Doku prüfen" \
|
||||
--git-changes "..." \
|
||||
--commit-messages "..."
|
||||
```
|
||||
4. **Bericht erstellen:** Das Skript formatiert diese Informationen zu einem sauberen Status-Update, postet es als Kommentar an den Notion-Task und aktualisiert gleichzeitig dessen Status-Feld.
|
||||
5. **Git-Operationen:** Nachdem Notion aktualisiert wurde, führt der Agent die `git add`, `git commit` und `git push` Befehle aus.
|
||||
|
||||
Dieser Prozess stellt sicher, dass der Code-Stand im Repository immer synchron mit dem dokumentierten Fortschritt in Notion ist, ohne dass Sie die Gemini CLI verlassen müssen.
|
||||
|
||||
### 4. Sitzung abschließen
|
||||
|
||||
Wenn der gesamte Task abgeschlossen ist, können Sie die Sitzung über den folgenden Befehl **vom Host-Terminal aus** beenden.
|
||||
|
||||
```bash
|
||||
docker exec -it gemini-session python3 dev_session.py --done
|
||||
```
|
||||
|
||||
Dieser Befehl:
|
||||
* Setzt den Status des Notion-Tasks auf "Done".
|
||||
* Löscht die lokale Session-Datei (`.dev_session/SESSION_INFO`).
|
||||
* Deinstalliert den `post-commit` Git-Hook.
|
||||
|
||||
## Git Branch Benennungs-Konvention
|
||||
|
||||
Das Skript schlägt automatisch einen Git-Branch-Namen vor, der dem Muster `feature/task-{kurze_task_id}-{task_titel_slug}` folgt, um eine direkte Verbindung zwischen Code und Task herzustellen.
|
||||
|
||||
**Beispiel:** `feature/task-2f388f42-update-readme-for-reporting`
|
||||
|
||||
## Entwicklung & Troubleshooting des Start-Skripts
|
||||
|
||||
Das `start-gemini.sh`-Skript wurde entwickelt, um mehrere Herausforderungen zu lösen:
|
||||
|
||||
* **Problem: Fehlende Interaktivität:** Frühe Versionen leiteten die Ausgabe von `dev_session.py` direkt in eine Variable um, was die interaktiven `input()`-Aufforderungen blockierte.
|
||||
* **Lösung:** Einsatz des `tee`-Befehls, der die Ausgabe gleichzeitig auf dem Bildschirm anzeigt und in eine temporäre Datei schreibt, aus der der Kontext später gelesen wird.
|
||||
|
||||
* **Problem: Fehlerhafter Start-Parameter:** Die Gemini CLI erwartet den initialen Prompt über `--prompt-interactive`.
|
||||
* **Lösung:** Korrektur des Arguments im `docker run`-Befehl.
|
||||
|
||||
* **Problem: Konflikt durch nicht aufgeräumte Container:** Vorzeitig beendete Skripte hinterließen Container, die den nächsten Start blockierten.
|
||||
* **Lösung:** Explizite `docker rm -f`-Befehle am Anfang des Skripts, um alte Container zu bereinigen.
|
||||
|
||||
18
docs/SKILL_TASK_MANAGER.md
Normal file
18
docs/SKILL_TASK_MANAGER.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# SKILL: Task Manager
|
||||
|
||||
## Commands
|
||||
- `#task`: Start a new task session.
|
||||
1. Run `python3 scripts/list_projects.py`
|
||||
2. Ask user to choose project number.
|
||||
3. Run `python3 scripts/list_tasks.py <project_id_from_selection>`
|
||||
4. Ask user to choose task number (or 'new' for new task - not impl yet, ask for manual ID if needed).
|
||||
5. Run `python3 scripts/select_task.py <task_id>`
|
||||
|
||||
- `#fertig`: Finish current task.
|
||||
1. Ask user for short summary of work.
|
||||
2. Run `python3 scripts/finish_task.py "<summary>"`
|
||||
3. Ask user if they want to push (`git push`).
|
||||
|
||||
## Notes
|
||||
- Requires `.env.notion` with `NOTION_API_KEY`.
|
||||
- Stores state in `.dev_session/SESSION_INFO`.
|
||||
181
docs/SUPEROFFICE_INTEGRATION_PLAN.md
Normal file
181
docs/SUPEROFFICE_INTEGRATION_PLAN.md
Normal file
@@ -0,0 +1,181 @@
|
||||
# Technisches Konzept: SuperOffice CRM Integration
|
||||
|
||||
Dieses Dokument beschreibt die Integrationsstrategie zwischen **SuperOffice CRM** (führendes System für Stammdaten) und dem **Company Explorer** (KI-gestützte Anreicherungs-Engine).
|
||||
|
||||
## Zielsetzung
|
||||
Automatisierte Anreicherung von B2B-Firmendaten im CRM mit KI-generierten Insights (z.B. Robotik-Affinität, Branchen-Einstufung), ohne die Hoheit über die Stammdaten zu gefährden.
|
||||
|
||||
---
|
||||
|
||||
## 1. Architektur: "Event-Driven Messaging" (v2.0)
|
||||
|
||||
Wir haben die Architektur von einem Polling-Modell auf ein **Event-gesteuertes Webhook-Modell** umgestellt. Dies entspricht modernen Best Practices und ist Voraussetzung für eine Skalierung auf 16.000+ Firmen.
|
||||
|
||||
### Das Prinzip: "Gehirn & Muskel"
|
||||
|
||||
* **Das Gehirn (Company Explorer):** Hier liegt die gesamte Intelligenz. Die Datenbank speichert die Firmendaten, die Signale und die **Marketing-Matrix** (Textbausteine). Er entscheidet, *welcher* Text für *welchen* Kontakt generiert wird.
|
||||
* **Der Muskel (Connector):** Er ist ein "dummer" Bote. Er nimmt Events entgegen, fragt das Gehirn nach Anweisungen und führt diese in SuperOffice aus.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "SuperOffice CRM"
|
||||
SO_Contact["👤 Contact / Person"]
|
||||
SO_Webhook["🚀 Webhook<br/>(contact.changed)"]
|
||||
end
|
||||
|
||||
subgraph "Connector (Docker)"
|
||||
WebhookApp["📥 Webhook Receiver<br/>(FastAPI :8002)"]
|
||||
Queue[("📦 Job Queue<br/>(SQLite/Redis)")]
|
||||
Worker["👷♂️ Worker Process"]
|
||||
end
|
||||
|
||||
subgraph "Company Explorer (Docker)"
|
||||
CE_API["🧠 Provisioning API<br/>(:8000)"]
|
||||
MatrixDB[("📚 Marketing Matrix<br/>(SQLite)")]
|
||||
end
|
||||
|
||||
SO_Contact -->|1. Änderung| SO_Webhook
|
||||
SO_Webhook -->|2. POST Event| WebhookApp
|
||||
WebhookApp -->|3. Enqueue Job| Queue
|
||||
Worker -->|4. Fetch Job| Queue
|
||||
Worker -->|5. Request: 'Provision Me'| CE_API
|
||||
CE_API -->|6. Lookup Logic| MatrixDB
|
||||
CE_API -->|7. Return: Final Texts| Worker
|
||||
Worker -->|8. Write-Back UDFs| SO_Contact
|
||||
```
|
||||
|
||||
**Technische Kommunikation:**
|
||||
Da beide Services (`connector-superoffice` und `company-explorer`) im selben Docker-Netzwerk laufen, erfolgt die Kommunikation direkt und latenzfrei über den internen Docker-DNS (`http://company-explorer:8000`). Es gibt keinen Umweg über das öffentliche Internet.
|
||||
|
||||
## 2. Datenmodell & Erweiterung
|
||||
|
||||
## 2. Datenmodell & Erweiterung
|
||||
|
||||
Um die CRM-Daten sauber zu halten, schreiben wir **niemals** in Standardfelder (wie `Name`, `Department`), sondern ausschließlich in dedizierte, benutzerdefinierte Felder (**User Defined Fields - UDFs**).
|
||||
|
||||
### Benötigte Felder in SuperOffice (Anforderung an IT/Admin)
|
||||
Folgende Felder sollten am Objekt `Company` (bzw. `Contact` in SuperOffice-Terminologie) angelegt werden:
|
||||
|
||||
| Feldname (Label) | Typ | Zweck |
|
||||
| :--- | :--- | :--- |
|
||||
| `AI Robotics Potential` | List/Select | High / Medium / Low / None |
|
||||
| `AI Industry` | Text (Short) | KI-ermittelte Branche (z.B. "Logistik - Intralogistik") |
|
||||
| `AI Summary` | Text (Long/Memo) | Kurze Zusammenfassung der Analyse |
|
||||
| `AI Last Update` | Date | Zeitstempel der letzten Anreicherung |
|
||||
| `AI Status` | List/Select | Pending / Enriched / Error |
|
||||
| `Unsubscribe-Link` | Text/Link | **NEU:** Speichert den personalisierten Link zur Abmeldung von der Marketing-Automation. (ProgID: SuperOffice:9) |
|
||||
|
||||
### Benötigtes Feld im Company Explorer
|
||||
| Feldname | Typ | Zweck |
|
||||
| :--- | :--- | :--- |
|
||||
| `external_crm_id` | String/Int | Speichert die `ContactId` aus SuperOffice zur eindeutigen Zuordnung (Primary Key Mapping). |
|
||||
|
||||
### 2.2. Data Integrity: "The Double Truth"
|
||||
|
||||
Um die Datenqualität zu sichern, pflegen wir für Stammdaten (Name, Website) zwei Wahrheiten:
|
||||
1. **CRM Truth:** Was aktuell in SuperOffice steht (oft manuell gepflegt, potenziell veraltet).
|
||||
2. **Explorer Truth:** Was der Company Explorer im Web gefunden hat.
|
||||
|
||||
**Synchronisation:**
|
||||
* Bei jedem Webhook-Event sendet der Connector die aktuellen CRM-Werte (`crm_name`, `crm_website`) an den Company Explorer.
|
||||
* Der Company Explorer speichert diese und berechnet einen **`data_mismatch_score`** (0.0 = Match, 1.0 = Mismatch).
|
||||
* **UI:** Im Frontend wird dieser Score visualisiert, sodass Abweichungen sofort erkennbar sind.
|
||||
|
||||
## 2.1. Mapping of CRM Concepts (SuperOffice vs. D365)
|
||||
|
||||
Um die Integration effizient zu gestalten, wurde eine strategische Entscheidung bezüglich der Abbildung von Kern-CRM-Konzepten getroffen:
|
||||
|
||||
| D365 Konzept | SuperOffice Entität | Zweck & Begründung |
|
||||
| :--- | :--- | :--- |
|
||||
| **Opportunity** | `Sale` | Die `Sale`-Entität in SuperOffice ist das direkte Äquivalent zu einer Opportunity. Hier werden potenzielle Umsätze, Vertriebsphasen und Wahrscheinlichkeiten erfasst. Dies ist das primäre Zielobjekt, sobald eine konkrete Verkaufschance durch den Company Explorer identifiziert wird. |
|
||||
| **Campaign** | `Project` | Für Marketing-Automatisierung und die Bündelung von Kontakten für Kampagnen dient die `Project`-Entität als idealer Container. Sie ermöglicht es, Kampagnen-Teilnehmer zu gruppieren, Aktivitäten zuzuordnen und den ROI durch Verknüpfung mit `Sale`-Objekten zu messen. |
|
||||
|
||||
---
|
||||
|
||||
## 3. Phasenplan
|
||||
|
||||
### Phase 1: Initial Load (Snapshot)
|
||||
*Ziel: Bestandskunden und aktive Leads einmalig bewerten.*
|
||||
|
||||
1. **Filter:** Der Connector lädt alle Firmen mit Status "Kunde" oder "Prospect".
|
||||
2. **Import:** Daten werden via `POST /api/companies/bulk` an den Explorer gesendet. Die `ContactId` wird mitgegeben.
|
||||
3. **Verarbeitung:** Der Explorer arbeitet die Queue ab (Web-Scraping -> Klassifizierung).
|
||||
|
||||
### Phase 2: Write-Back (Ergebnisse speichern)
|
||||
*Ziel: Ergebnisse im CRM sichtbar machen.*
|
||||
|
||||
1. Der Connector prüft regelmäßig (`GET /api/companies?status=ENRICHED`) auf fertige Analysen.
|
||||
2. Für jeden Treffer sendet er ein Update an die SuperOffice API (`PUT /Contact/{id}`).
|
||||
3. Es werden nur die oben definierten UDFs aktualisiert.
|
||||
|
||||
### Phase 3: Continuous Sync (Event-Driven)
|
||||
*Ziel: Skalierbare, echtzeitnahe Verarbeitung.*
|
||||
|
||||
1. **Auslöser:** Ein `contact.changed` oder `person.changed` Event in SuperOffice (z.B. User setzt Status auf `Init`).
|
||||
2. **Transport:** SuperOffice Webhook -> Connector `POST /webhook` -> Queue.
|
||||
3. **Verarbeitung:** Der `Worker` holt den Job, ruft die **Provisioning API** des Company Explorer auf.
|
||||
4. **Vorteil:**
|
||||
* **Kein unnötiger Traffic:** Wir verarbeiten nur Kontakte, bei denen wirklich etwas passiert.
|
||||
* **Echtzeit:** Änderungen sind sofort wirksam.
|
||||
* **SO-Konformität:** Wir nutzen den offiziellen, effizienten Weg für Integrationen.
|
||||
|
||||
## 4. Sicherheit & Authentifizierung
|
||||
|
||||
* **Authentifizierung:** Nutzung eines **System User Tokens** (Machine-to-Machine). Dies verhindert, dass Passwörter von persönlichen Accounts im Code hinterlegt werden müssen.
|
||||
* **Scope:** Der API-User benötigt Lesezugriff auf `Contact` und Schreibzugriff auf die `UDFs`.
|
||||
* **Datenschutz:** Es werden nur Firmendaten (Name, Webseite, Stadt) übertragen. Personenbezogene Ansprechpartner bleiben im CRM und werden nicht an die KI gesendet.
|
||||
|
||||
### 4.1. POC Ergebnisse & Finale Authentifizierungs-Strategie (Feb 2026)
|
||||
|
||||
Der Proof of Concept (POC) wurde erfolgreich abgeschlossen. Dabei wurde die Authentifizierungs-Strategie für maximale Stabilität und Einfachheit angepasst.
|
||||
|
||||
**Ergebnis:**
|
||||
* **Erfolg:** Die Verbindung zum SOD-Tenant (`Cust55774`) steht. Der Connector kann Daten lesen und ist bereit zum Schreiben.
|
||||
* **Strategiewechsel:** Statt des komplexen RSA-S2S-Flows wird der **OAuth 2.0 Refresh Token Flow** genutzt. Dies umgeht Lizenz- und UI-Einschränkungen in der SOD-Umgebung und bietet dieselbe Automatisierungsqualität für den Docker-Service.
|
||||
* **Subdomain-Handling:** Es wurde festgestellt, dass SuperOffice Online (SOD) mandantenabhängige Subdomains nutzt. Für den Test-Tenant wurde **`https://app-sod.superoffice.com`** als valide API-Basis identifiziert.
|
||||
|
||||
**Technische Umsetzung:**
|
||||
1. **Einmalige Autorisierung:** Ein langlebiger `refresh_token` wurde über einen manuellen Consent-Step generiert.
|
||||
2. **Automatisierung:** Der `AuthHandler` tauscht diesen Token vollautomatisch gegen kurzlebige `access_tokens` (Bearer) aus.
|
||||
3. **Caching:** Tokens werden lokal in `token_cache.json` gespeichert, um API-Limits zu schonen.
|
||||
|
||||
**Aktueller Status & Nächste Schritte:**
|
||||
* **Blocker gelöst:** Die Authentifizierung und das URL-Routing sind stabil.
|
||||
* **Nächster Schritt:** Manuelle Anlage der UDF-Felder (siehe Abschnitt 2) in der SuperOffice Administration durch den Admin. Erst danach kann der "Write-Back" (Phase 2) im Code final gemappt werden.
|
||||
|
||||
## 5. Vorbereitung für die IT
|
||||
|
||||
Um den Connector in Betrieb zu nehmen, benötigen wir:
|
||||
1. **API Zugangsdaten:** `Client ID`, `Client Secret`, `Customer ID` (Tenant) und einen `System User Token`.
|
||||
2. **UDF Definitionen:** Die `ProgId` (technischen Namen) der neu angelegten Felder (z.B. `userdef_id_123`).
|
||||
|
||||
## 6. Fragen an Manuel
|
||||
|
||||
1. Die "Lizenz-Gretchenfrage" (Development Tools)
|
||||
Frage: "Manuel, du sagtest, bei Wackler sind die 'Development Tools' aktiv. Weißt du, ob das eine globale Konzern-Lizenz ist oder ob wir für den RoboPlanet-Mandanten eine eigene Subskription brauchen? Mein Dev-Portal blockiert S2S aktuell mit dem Hinweis auf fehlende Lizenzen in Production."
|
||||
Ziel: Klären, ob es nur ein "Klick" im Admin-Panel ist oder ob Webkom (oder ein anderer Partner) eine neue Rechnung schreiben muss.
|
||||
|
||||
2. Der App-Registrierungs-Pfad
|
||||
Frage: "Hast du eure App als 'Custom Application' (privat für Wackler) oder als 'Standard Application' (über einen Partner-Account) registriert? Falls ihr einen Partner-Account nutzt: Könnten wir unsere GTM-Engine darüber mitlaufen lassen, um die Lizenz-Hürde zu umgehen?"
|
||||
Ziel: Prüfen, ob Manuel über ein Partner-Portal arbeitet. Partner-Apps brauchen manchmal keine Dev-Tools beim Kunden, weil der Partner die Validierung übernimmt.
|
||||
|
||||
3. Identifikation des "Gatekeepers"
|
||||
Frage: "Wer hat bei euch den Tenant technisch aufgesetzt? War das die Webkom? Ich muss herausfinden, wer die administrative Hoheit hat, um den 'System User' für S2S freizuschalten."
|
||||
Ziel: Den Namen des Ansprechpartners bei der Webkom oder intern bei Wackler-IT herausfinden.
|
||||
|
||||
4. Authentifizierungs-Deep-Dive (RSA vs. Token)
|
||||
Frage: "Nutzt ihr für eure S2S-App den RSA-Key-Flow (JWT) oder arbeitet ihr mit einem statischen System-User-Token? Ich bereite gerade den RSA-Handshake vor und wollte wissen, was in der SuperOffice Cloud stabiler läuft."
|
||||
Ziel: Fachsimpelei, um Manuel zu zeigen, dass du auf seinem Level spielst. Das öffnet Türen für Code-Sharing oder Tipps.
|
||||
|
||||
5. Das "Y-Tabellen" Problem
|
||||
Frage: "Nutzt ihr für eure Verkaufs-App auch Zusatztabellen (Y-Tabellen) oder schreibt ihr nur in Standardfelder? Ich plane eine Tabelle für dynamische Marketing-Texte (Rolle x Branche) – gab es bei euch Probleme mit dem Cache nach Strukturänderungen?"
|
||||
Ziel: Bestätigung einholen, dass Y-Tabellen mit ihrer Lizenz funktionieren. Das ist dein Beweis, dass du die Dev-Tools zwingend brauchst.
|
||||
|
||||
6. Authentifizierung beim S2S Call
|
||||
Wie authentifiziert ihr euch beim S2S-Call? Nutzt ihr den RSA-Flow mit Zertifikaten oder habt ihr einen Partner-Proxy dazwischen?" (Wenn er "Partner-Proxy" sagt, arbeitet er über Webkom-Infrastruktur).
|
||||
|
||||
7. Nutzung System User
|
||||
Wo habt ihr den 'System User' im CRM autorisiert?" (Er soll dir den Pfad in Einstellungen & Verwaltung zeigen).
|
||||
|
||||
8. Header API-Call
|
||||
Könntest du mir den Header eines eurer API-Calls zeigen (natürlich ohne den echten Token)?" (Daran sehen wir sofort, ob sie die v1 REST API oder die alte SOAP-Schnittstelle nutzen).
|
||||
104
docs/SUPEROFFICE_MEETING_PREP.md
Normal file
104
docs/SUPEROFFICE_MEETING_PREP.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Vorbereitung für SuperOffice Meeting: API E-Mail-Versand (Shipment)
|
||||
**Datum:** 05.03.2026
|
||||
**Teilnehmer:** Christian Godelmann (RoboPlanet), Frau Grilnberger / Herr Eberhard (SuperOffice)
|
||||
**Thema:** Fehlende Berechtigung für automatisierten E-Mail-Versand via API
|
||||
|
||||
---
|
||||
|
||||
## 1. Ausgangslage & Ziel
|
||||
Wir haben die **GTM-Engine** (KI-basierte Anreicherung) erfolgreich an SuperOffice (Tenant `Cust26720`) angebunden.
|
||||
* ✅ **Lese-Zugriff:** Funktioniert (Webhooks, Person/Contact lesen).
|
||||
* ✅ **Schreib-Zugriff (Daten):** Funktioniert (UDFs schreiben, Sales erstellen).
|
||||
* ❌ **E-Mail-Versand (Shipment):** Schlägt fehl (500 Internal Server Error).
|
||||
|
||||
**Ziel:** Der API-User (Client ID `0fd8...`) soll automatisierte Erstkontakt-E-Mails ("Shipments") im Namen des zugewiesenen Vertriebsmitarbeiters versenden können.
|
||||
|
||||
---
|
||||
|
||||
## 2. Diagnose-Ergebnisse (Live-Test vom 05.03.2026)
|
||||
|
||||
Wir haben eine Tiefenanalyse mit Admin-Rechten durchgeführt. Hier sind die harten Fakten:
|
||||
|
||||
### A. Identitätsproblem (Ursache)
|
||||
Der API-User hat keine verknüpfte "Person" im System.
|
||||
* **Request:** `GET /api/v1/Associate/Me`
|
||||
* **Response:** `500 Internal Server Error`
|
||||
* **Bedeutung:** Das System weiß nicht, "wer" der API-User ist. Ohne Identität können keine personalisierten Aktionen (wie E-Mail-Versand) ausgeführt werden.
|
||||
|
||||
### B. E-Mail-Versand (Blockade)
|
||||
Trotz aktiver Marketing-Lizenz (ShipmentTypes sind abrufbar) scheitert der Versand.
|
||||
* **Test:** Erstellung eines `Shipment` Objekts (Type: Email).
|
||||
* **Response:** `500 Internal Server Error`
|
||||
* **Log-Auszug:**
|
||||
```json
|
||||
{
|
||||
"Error": true,
|
||||
"ErrorType": "NullReferenceException",
|
||||
"Message": "Object reference not set to an instance of an object.",
|
||||
"Source": "SoDataBase"
|
||||
}
|
||||
```
|
||||
*(Hinweis: Der Fehler deutet darauf hin, dass interne E-Mail-Einstellungen (SMTP/Exchange) für den user `null` sind.)*
|
||||
|
||||
### C. Schreibrechte (Erfolgreich)
|
||||
Zum Vergleich haben wir andere Objekte erstellt, um generelle API-Probleme auszuschließen.
|
||||
* **Sale (Verkauf):** ✅ Erfolgreich erstellt (ID 342539).
|
||||
* **Appointment (Termin):** ✅ Erfolgreich erstellt (ID 993350).
|
||||
|
||||
---
|
||||
|
||||
## 3. Unsere Bitte an SuperOffice (Lösungsvorschlag)
|
||||
|
||||
Um das Problem zu lösen, benötigen wir folgende Anpassungen für den API-User (oder einen dedizierten System-User):
|
||||
|
||||
1. **Personalisierung:** Verknüpfung des API-Users mit einer **Personalkarte** im SuperOffice (damit `Associate/Me` funktioniert).
|
||||
2. **Rollen:** Zuweisung der Rolle **"Mailing Administrator"** (oder vergleichbar), um Shipments zu erstellen.
|
||||
3. **E-Mail-Konfiguration:** Hinterlegung der **E-Mail-Einstellungen** (idealerweise "Send As" Recht für die Account-Manager, damit die Mails im Namen von Herrn Godelmann/Herrn X rausgehen).
|
||||
|
||||
---
|
||||
|
||||
## 4. Aktueller Workaround (Plan B)
|
||||
|
||||
Bis zur Lösung nutzen wir folgenden Workaround:
|
||||
1. Die KI generiert den E-Mail-Text.
|
||||
2. Anstatt die Mail zu senden, erstellen wir einen **Termin** (`Appointment`) in der Vergangenheit.
|
||||
3. Der E-Mail-Text wird in die **Beschreibung** des Termins geschrieben.
|
||||
4. Der Vertriebler muss den Text manuell kopieren und versenden.
|
||||
|
||||
*Dies ist funktionstüchtig (getestet), aber keine Dauerlösung.*
|
||||
|
||||
---
|
||||
|
||||
## 5. Technische Details (für Support)
|
||||
|
||||
* **Tenant:** `Cust26720` (Online3)
|
||||
* **Client ID:** `0fd8...` (Name: "Gemini Connector Production")
|
||||
* **Authentication:** System User Flow (Refresh Token)
|
||||
* **Endpoint:** `/api/v1/Shipment`
|
||||
|
||||
---
|
||||
|
||||
## 6. Ziel-Prozess & Automatisierungs-Logik (Roadmap)
|
||||
|
||||
Um den SuperOffice-Experten den Kontext unserer Anforderungen zu verdeutlichen, hier das geplante Ziel-Szenario:
|
||||
|
||||
### A. Neukunden-Akquise (Prospecting)
|
||||
1. **Trigger:** Ein Mitarbeiter setzt in SuperOffice den Status einer Person auf `MA-Status: Init`.
|
||||
2. **Enrichment:** Die Gemini GTM-Engine (Company Explorer) erkennt den Trigger via Webhook, analysiert das Unternehmen und generiert hyper-personalisierte Texte in den UDFs.
|
||||
3. **Versand (Der "Send As" Case):** Die Engine stößt über die API den Versand der 1. E-Mail an.
|
||||
* **Wichtig:** Der Versand erfolgt im **"Send As"** Modus (nicht "Im Auftrag von").
|
||||
* **Absender:** Der in SuperOffice hinterlegte `Account Manager` / `Associate`.
|
||||
* **Signatur:** Die E-Mail muss die **persönliche Signatur** des jeweiligen Absenders enthalten.
|
||||
4. **Status-Update:** Nach erfolgreichem Versand wird der Status auf `Sent 1st E-Mail` gesetzt.
|
||||
|
||||
### B. Multi-Step Follow-up (Drip Campaign)
|
||||
1. **Wartezeit:** Das System prüft nach 7 Tagen (via Queue/Cron) erneut den Status der Person.
|
||||
2. **Bedingung:** Ist der Status unverändert (`Sent 1st E-Mail`), wird automatisch die 2. E-Mail (Nurture) versendet.
|
||||
3. **Abbruch:** Reagiert der Kontakt (Statusänderung durch Sales) oder ist die 3. Mail ohne Erfolg rausgegangen, stoppt die Sequenz.
|
||||
|
||||
### C. Sales Follow-up (Angebot-Nachfassen)
|
||||
1. **Trigger:** Ein Angebot (`Sale`) ist seit 14 Tagen im Status "Offen" und es gab keine dokumentierte Aktivität.
|
||||
2. **Aktion:** Die Engine generiert ein personalisiertes Follow-up für den Account Manager und versendet dieses (ebenfalls via "Send As"), um den Sales-Prozess zu beschleunigen.
|
||||
|
||||
---
|
||||
*Ende des Protokolls*
|
||||
27
docs/TASK_STATUS_REPORT_2f388f42.md
Normal file
27
docs/TASK_STATUS_REPORT_2f388f42.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Task-Statusbericht: [2f388f42] Report mistakes
|
||||
|
||||
**Status:** ✅ Abgeschlossen
|
||||
**Bearbeitungszeit (ca.):** 02:00 Stunden (Bitte in Notion aktualisieren)
|
||||
|
||||
**Zusammenfassung:**
|
||||
Das "Report mistakes"-Feature wurde erfolgreich im Company Explorer implementiert. Benutzer können nun Datenfehler auf Unternehmensseiten markieren und Korrekturen vorschlagen. Diese werden in einer neuen Datenbanktabelle gesammelt und können im Einstellungsbereich eingesehen und genehmigt/abgelehnt werden.
|
||||
|
||||
**Implementierte Features:**
|
||||
* **Backend:**
|
||||
* Neue SQLite-Tabelle `reported_mistakes` für Fehlerberichte.
|
||||
* FastAPI-Endpunkte: `POST /api/companies/{company_id}/report-mistake`, `GET /api/mistakes`, `PUT /api/mistakes/{mistake_id}`.
|
||||
* SQLAlchemy-Modell und DB-Migration für `reported_mistakes`.
|
||||
* **Frontend:**
|
||||
* "Fehler melden"-Button mit Modalfenster in `Inspector.tsx`.
|
||||
* Dynamisches Dropdown für Feldnamen im Meldeformular (mit Vor-Ausfüllfunktion).
|
||||
* Neuer Tab "Reported Mistakes" in `RoboticsSettings.tsx` mit einer Übersichtstabelle.
|
||||
* Buttons zum Genehmigen/Ablehnen von Fehlermeldungen für `PENDING`-Einträge.
|
||||
* **Dokumentation:** `MIGRATION_PLAN.md` aktualisiert mit Plan und Dateipfaden.
|
||||
|
||||
**Nächste Schritte (Konzept für zukünftige Verbesserungen):**
|
||||
Die gesammelten und genehmigten Korrekturen bilden eine wertvolle Basis für die kontinuierliche Verbesserung der Datenqualität. Sie können genutzt werden für:
|
||||
* LLM Fine-Tuning oder Prompt-Verbesserung zur Steigerung der Extraktionsgenauigkeit.
|
||||
* Anpassung von Scraping-Regeln oder Parser-Logik zur Behebung systematischer Fehler.
|
||||
* Potenzielle automatisierte Datenkorrektur bei hoher Konfidenz.
|
||||
|
||||
---
|
||||
45
docs/TASK_STATUS_REPORT_30e88f42.md
Normal file
45
docs/TASK_STATUS_REPORT_30e88f42.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Session Report: SuperOffice Connector & End-to-End Test
|
||||
|
||||
**Date:** Feb 21, 2026
|
||||
**Focus:** End-to-End Testing, Infrastructure Hardening, Vertical Sync
|
||||
|
||||
## 1. Achievements
|
||||
|
||||
### ✅ Infrastructure & Stability
|
||||
* **Authentication Fixed:** Resolved critical auth failures in `SuperOfficeClient`. Added fallback for empty `SO_ENVIRONMENT` variables and improved error logging.
|
||||
* **Pydantic V2 Migration:** Rewrote `connector-superoffice/config.py` to remove dependency on `pydantic-settings`, resolving crash loops in Docker containers with older/mixed Python environments.
|
||||
* **Network Path Clarified:** Confirmed that Webhooks reach the system via Nginx (`/connector/` route) on Port 80/8090, solving the "closed port 8003" mystery.
|
||||
|
||||
### ✅ Functional Improvements
|
||||
* **Bidirectional Vertical Sync:** Implemented logic in `worker.py` to detect manual Vertical changes in SuperOffice (e.g. `[I:26] -> Leisure`) and sync them back to the Company Explorer.
|
||||
* **Cascading Updates:** A Vertical change now correctly triggers a re-calculation of marketing texts for all associated persons.
|
||||
* **Data Persistence:** Updated `company-explorer/backend/app.py` to automatically create/update `Contact` objects during provisioning, ensuring data consistency for cascade updates.
|
||||
|
||||
### ✅ Testing
|
||||
* **Automated E2E Test:** Created `connector-superoffice/tests/test_e2e_flow.py`. This standalone script verifies the full data roundtrip and the vertical change scenario without needing external dependencies.
|
||||
* **Matrix Content:** Generated live marketing texts for **"Healthcare - Hospital"** and **"Leisure - Indoor Active"** (5 Personas each) to enable real-world testing.
|
||||
|
||||
## 2. Current Status (Snapshot)
|
||||
|
||||
* **Connector:** Running, Authenticated (`✅ SuperOffice Client initialized`).
|
||||
* **Worker:** Processing jobs. Currently correctly handling "Processing" state from CE by re-queueing (RETRY).
|
||||
* **Write-Back:** Vertical Sync confirmed working. Address/VAT Sync implemented but requires final verification.
|
||||
|
||||
## 3. Open Issues / Next Steps
|
||||
|
||||
### 🔸 Address & VAT Sync Debugging
|
||||
The logic for writing back `City` (PostalAddress) and `OrgNumber` (VAT) was added to `worker.py` but potentially causes loops or needs validation against the complex SuperOffice address model.
|
||||
* **Todo:** Verify if address updates actually arrive in SuperOffice once the CE status switches from `PROCESSING` to `SUCCESS`.
|
||||
|
||||
### 🔸 UDF Configuration
|
||||
There is a suspicion that `UDF_SUBJECT` and `UDF_VERTICAL` might share the same ID (`SuperOffice:5`) in `config.py`.
|
||||
* **Todo:** Verify the correct ProgIDs for the UDFs in the SuperOffice Admin client and update `.env` / `config.py`.
|
||||
|
||||
### 🔸 Monitoring
|
||||
* **Todo:** Consider a simple web-interface for the connector logs/queue status (as discussed).
|
||||
|
||||
## 4. How to Resume
|
||||
|
||||
1. **Check Logs:** Run `python3 show_logs.py` to see if the pending jobs for "Silly Billy Entertainment" have completed.
|
||||
2. **Verify Data:** Check SuperOffice to see if Address and VAT were updated.
|
||||
3. **Refine:** If address sync fails, debug `worker.py` section `2b.2 Sync Address & VAT`.
|
||||
81
docs/TRANSCRIPTION_TOOL.md
Normal file
81
docs/TRANSCRIPTION_TOOL.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# Meeting Assistant (Transcription Tool)
|
||||
|
||||
**Version:** 0.6.0
|
||||
**Status:** Beta (AI Insights Integration)
|
||||
|
||||
Der **Meeting Assistant** ist eine leistungsstarke Suite zur Transkription und Bearbeitung von Audio-Aufnahmen. Er kombiniert lokale FFmpeg-Verarbeitung mit der Gemini 2.0 Flash AI.
|
||||
|
||||
---
|
||||
|
||||
## 1. Architektur & Stack
|
||||
|
||||
* **FFmpeg Engine:** Automatisches Splitting großer Dateien in 30-Minuten-Segmente.
|
||||
* **Gemini 2.0 Flash:** AI-Transkription mit Fokus auf JSON-Struktur (Sprecher, Timestamps) und zur Generierung von Meeting-Analysen.
|
||||
* **Prompt Library:** Eine Sammlung von Vorlagen zur Steuerung der KI-Analyse.
|
||||
* **Structured Storage:** SQLite speichert jedes Segment als editierbares JSON-Array und die Ergebnisse der KI-Analyse.
|
||||
* **Unified UI:** Das Frontend fügt alle Segmente zu einem nahtlosen Dokument zusammen und bietet interaktive Analyse-Funktionen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Key Features (v0.6.0)
|
||||
|
||||
### 🚀 **NEU:** AI Insights & Translation
|
||||
* **Übersetzung (DE/EN):** Übersetzt das gesamte Transkript mit einem Klick ins Englische.
|
||||
* **Meeting-Protokoll:** Erstellt automatisch ein formelles Protokoll (Meeting Minutes) mit Agenda, Entscheidungen und nächsten Schritten.
|
||||
* **Action Items:** Extrahiert eine Aufgabenliste mit Verantwortlichen und Fälligkeiten direkt aus dem Gespräch.
|
||||
* **Rollenbasierte Zusammenfassungen:** Generiert spezifische Zusammenfassungen, z.B. eine "Sales Summary", die sich auf Kundenbedürfnisse, Kaufsignale und nächste Schritte für das Vertriebsteam konzentriert.
|
||||
|
||||
### 🎙️ Intelligente Transkription
|
||||
* Unterstützt MP3/WAV bis 500MB.
|
||||
* Native Sprechererkennung und Zeitstempel-Normalisierung über Segmentgrenzen hinweg.
|
||||
|
||||
### 👥 Globales Sprecher-Management
|
||||
* **Speaker Bar:** Eine Übersicht aller im Dokument gefundenen Sprecher.
|
||||
* **Global Rename:** Mit einem Klick kann ein Sprecher (z.B. "Speaker A") im gesamten Dokument dauerhaft umbenannt werden (z.B. "Thomas").
|
||||
|
||||
### ✂️ Präzises Schneiden (Trimming)
|
||||
* **Trim Start:** Löscht alles *vor* einer ausgewählten Zeile (ideal zum Entfernen von Vorgesprächen).
|
||||
* **Trim End:** Löscht alles *nach* einer ausgewählten Zeile (entfernt Verabschiedungen).
|
||||
* **Single Line Delete:** Einzelne Zeilen oder Störgeräusche können individuell entfernt werden.
|
||||
|
||||
### 📝 Editor & Export
|
||||
* **Inline-Edit:** Jeder Textblock und jeder Sprechername kann durch direktes Anklicken korrigiert werden.
|
||||
* **Copy Full Transcript:** Kopiert das gesamte, bereinigte Transkript inkl. Timestamps in die Zwischenablage.
|
||||
* **Copy Insights:** Jedes Analyse-Ergebnis kann einfach in die Zwischenablage kopiert werden.
|
||||
|
||||
---
|
||||
|
||||
## 3. API Endpunkte
|
||||
|
||||
| Methode | Pfad | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| `GET` | `/meetings` | Liste aller Meetings. |
|
||||
| `POST` | `/upload` | Audio-Upload & Prozess-Start. |
|
||||
| `POST` | `/meetings/{id}/insights` | **Neu:** Generiert eine Analyse (z.B. Protokoll, Action Items). |
|
||||
| `POST` | `/meetings/{id}/translate` | **Neu:** Übersetzt das Transkript in eine Zielsprache (aktuell: 'English'). |
|
||||
| `POST` | `/meetings/{id}/rename_speaker` | Globale Umbenennung in der DB. |
|
||||
| `PUT` | `/chunks/{id}` | Speichert manuelle Text-Korrekturen. |
|
||||
| `DELETE` | `/meetings/{id}` | Vollständiges Löschen. |
|
||||
|
||||
---
|
||||
|
||||
## 4. Roadmap
|
||||
|
||||
* **v0.7: Search:** Globale Suche über alle Transkripte hinweg.
|
||||
* **v0.8: Q&A an das Meeting:** Ermöglicht, Fragen direkt an das Transkript zu stellen ("Was wurde zu Thema X beschlossen?").
|
||||
* **v0.9: Export-Formate:** Export der Ergebnisse in verschiedene Formate (z.B. PDF, DOCX).
|
||||
|
||||
---
|
||||
|
||||
## 5. Development Notes & Troubleshooting
|
||||
|
||||
Bei der Implementierung der AI-Insights-Funktion (v0.6.0) traten mehrere Probleme auf, deren Lösungen für die zukünftige Entwicklung wichtig sind:
|
||||
|
||||
* **Isolierung von Microservices:** Der Versuch, eine zentrale `helpers.py`-Datei aus dem `transcription-app`-Container zu importieren, schlug mit einem `ModuleNotFoundError` fehl.
|
||||
* **Lösung:** Kritische Funktionen (wie der Gemini-API-Client) wurden in eine lokale Bibliothek (`/lib/gemini_client.py`) innerhalb des Service-Backends dupliziert, um den Service eigenständig zu machen.
|
||||
* **API-Schlüssel in Docker:** Der neue, isolierte Service konnte den API-Schlüssel nicht aus einer Datei lesen.
|
||||
* **Lösung:** Der `GEMINI_API_KEY` wurde als Umgebungsvariable über die `docker-compose.yml`-Datei an den Container übergeben. Dies ist die Best Practice für die Bereitstellung von "Secrets" für containerisierte Anwendungen. **Wichtig:** Ein `docker-compose restart` reicht nicht aus, um die Änderung zu übernehmen; ein `docker-compose up -d --force-recreate <service_name>` ist erforderlich.
|
||||
* **Modell-Kompatibilität:** API-Aufrufe schlugen mit `404 NOT_FOUND` fehl, weil versucht wurde, ein nicht zum API-Schlüssel passendes Modell (`gemini-1.5-flash`) zu verwenden.
|
||||
* **Lösung:** Der Modellname wurde auf das im Projekt etablierte und funktionierende Modell `gemini-2.0-flash` korrigiert.
|
||||
* **Datenformatierung:** Die KI lieferte generische Antworten, weil das an sie übergebene Transkript leer war.
|
||||
* **Lösung:** Die Analyse des rohen JSON-Outputs aus der Datenbank (`debug_chunks`-Endpunkt) zeigte, dass die Formatierungslogik die `absolute_seconds` zur korrekten chronologischen Sortierung verwenden muss. Die `_format_transcript`-Funktion wurde entsprechend angepasst.
|
||||
33
docs/UNSUBSCRIBE_FEATURE_SUMMARY.md
Normal file
33
docs/UNSUBSCRIBE_FEATURE_SUMMARY.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Abschluss des Features "Unsubscribe-Link"
|
||||
|
||||
## Zusammenfassung der Implementierung
|
||||
In dieser Session wurde eine vollständige, sichere Unsubscribe-Funktion für die Marketing-Automation im `company-explorer` implementiert. Dies umfasst ein Datenbank-Update mit sicheren Tokens, einen öffentlichen API-Endpunkt zur Abmeldung und die Integration in den SuperOffice-Provisionierungsprozess.
|
||||
|
||||
## Nächste technische Schritte zur Inbetriebnahme
|
||||
|
||||
Um das Feature vollständig zu nutzen, sind die folgenden Schritte im **connector-superoffice** und der **Infrastruktur** notwendig:
|
||||
|
||||
1. **Konfiguration der `APP_BASE_URL`:**
|
||||
* **Was?** In der Konfiguration des `company-explorer` (z.B. in einer `.env`-Datei oder direkt in der `docker-compose.yml`) muss die Umgebungsvariable `APP_BASE_URL` gesetzt werden.
|
||||
* **Warum?** Diese URL ist die öffentliche Basis-Adresse, die für den Bau des Unsubscribe-Links verwendet wird (z.B. `APP_BASE_URL="https://www.ihre-domain.de"`).
|
||||
* **Beispiel (in `docker-compose.yml`):**
|
||||
```yaml
|
||||
services:
|
||||
company-explorer:
|
||||
# ...
|
||||
environment:
|
||||
- APP_BASE_URL=https://www.robo-planet.de
|
||||
# ...
|
||||
```
|
||||
|
||||
2. **Anpassung des `connector-superoffice` Workers:**
|
||||
* **Was?** Der Worker-Prozess im `connector-superoffice`, der die Daten vom `company-explorer` empfängt, muss angepasst werden. Er muss das neue Feld `unsubscribe_link` aus der API-Antwort auslesen.
|
||||
* **Warum?** Aktuell kennt der Connector dieses Feld noch nicht und würde es ignorieren.
|
||||
* **Wo?** In der Datei `connector-superoffice/worker.py` (oder ähnlich), in der Funktion, die die `/provision`-Antwort verarbeitet.
|
||||
|
||||
3. **Schreiben des Links in das SuperOffice UDF:**
|
||||
* **Was?** Die Logik im `connector-superoffice` Worker, die Daten nach SuperOffice schreibt, muss erweitert werden. Der ausgelesene `unsubscribe_link` muss in das von Ihnen angelegte Textfeld mit der ProgID `SuperOffice:9` geschrieben werden.
|
||||
* **Warum?** Nur so wird der Link im CRM gespeichert und kann in E-Mail-Vorlagen verwendet werden.
|
||||
* **Wo?** An der Stelle, an der die `SuperOfficeAPI.update_person` (oder eine ähnliche Funktion) mit den UDF-Daten aufgerufen wird.
|
||||
|
||||
Nach diesen drei Schritten ist der gesamte Prozess von der Generierung des Links bis zur Speicherung im CRM und der Nutzung in E-Mails funktionsfähig.
|
||||
137
docs/b2b-marketing-analysis.md
Normal file
137
docs/b2b-marketing-analysis.md
Normal file
@@ -0,0 +1,137 @@
|
||||
# B2B Marketing Analysis Report
|
||||
|
||||
## Schritt 1: Angebot (WAS)
|
||||
|
||||
**Kurzresümee:**
|
||||
- Die Angebotsanalyse wurde erfolgreich auf Basis der Website-Inhalte generiert.
|
||||
- Dies ist der erste Schritt des Prozesses, der vom neuen Python-Backend ausgefuehrt wird.
|
||||
|
||||
| Produkt/Lösung | Beschreibung (1-2 Sätze) | Kernfunktionen | Differenzierung | Primäre Quelle (URL) |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Reinigungsroboter | Autonome Reinigungsroboter sorgen effizient und planbar für gleichbleibend hohe Sauberkeit auf großen Flächen. Sie entlasten Teams spürbar und federn personelle Ausfälle ab. | Autonome Bodenreinigung, einfache Programmierung, automatische Zyklen, Hinderniserkennung, KI-gestützte Fleckenerkennung, leiser Betrieb. | Durchdachter 360°-Service, deutschlandweites Netzwerk zertifizierter Fachkräfte, Integration in Ihre Infrastruktur, maßgeschneiderte Servicepakete. | https://robo-planet.de/roboter/reinigungsroboter/ |
|
||||
| Serviceroboter | Serviceroboter übernehmen Auslieferung, Abräumen und Wegeführung, wodurch Teams Zeit für die persönliche Betreuung gewinnen. Sie dienen zudem als mobile Werbeflächen und interaktive Informationspunkte. | Auslieferung von Speisen/Getränken, Abräumen, Wegeführung, Besucherinformation, mobile Werbefläche, KI-Sprachsteuerung, 3D-Hindernisvermeidung. | Durchdachter 360°-Service, deutschlandweites Netzwerk zertifizierter Fachkräfte, Integration in Ihre Infrastruktur, maßgeschneiderte Servicepakete. | https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| Lieferroboter | Mit Liefer- und Transportrobotern werden Standardfahrten für Material- und Warentransport zuverlässig automatisiert. Dies spart Teams Wege, erhöht die Versorgungssicherheit und reduziert Engpässe. | Automatisierung von Standardfahrten, Materialtransport, Warentransport, Wegeersparnis, Planbarkeit, Reduzierung von Engpässen, Schwerlasttransport, IoT-Kompatibilität, Aufzugintegration. | Durchdachter 360°-Service, deutschlandweites Netzwerk zertifizierter Fachkräfte, Integration in Ihre Infrastruktur, maßgeschneiderte Servicepakete. | https://robo-planet.de/roboter/lieferroboter/ |
|
||||
| Automatisierungsmöglichkeiten (Beratung, Bedarfsanalyse & Systemauswahl) | RoboPlanet analysiert Objekt, Flächen, Abläufe und Schnittstellen vor Ort, um eine maßgeschneiderte Roboterlösung zu empfehlen und eine transparente Entscheidungsgrundlage zu schaffen. | Bedarfsanalyse, Objektanalyse, Prozessanalyse, Schnittstellenprüfung, Systemauswahl, kostenfreie Vorführung/Testphase, Wirtschaftlichkeitsbelegung. | Belastbare Entscheidungsgrundlage, transparente und praxisnahe Empfehlungen, umfassende Begleitung von Beratung bis Wartung. | https://robo-planet.de/service#service-1 |
|
||||
| Implementierung + Integration | Servicetechniker installieren die Roboterlösung vor Ort, integrieren sie nahtlos in bestehende Abläufe und schulen das Team für einen sicheren Umgang und schnelle Betriebsbereitschaft. | Fachgerechte Installation, Mapping von Routen, gezielte Team-Schulung (vor Ort/online), 2-wöchige Startphase (Systemüberwachung, Feinjustierung, Fehleranalyse, Reports, Begleitung). | Nahtlose Integration, herstellergeschultes, zertifiziertes Support-Team, Erreichbarkeit per Telefon/Remote/Vor-Ort. | https://robo-planet.de/service#service-3 |
|
||||
| Wartung, Reparatur und laufende Betreuung | Umfassendes Monitoring und regelmäßige Wartungspläne sichern die dauerhafte Verfügbarkeit der Robotik. Remote-Updates, schneller Technikersupport, Ersatzteile und feste SLAs sind inbegriffen. | Umfassendes Monitoring, regelmäßige Wartungspläne, Remote-Updates, schnelle Reparaturservices, Ersatzteile, feste Service Level Agreements (SLA), Garantieverlängerungsoptionen (1-3 Jahre). | Bundesweites Servicenetzwerk, schnelle Reaktionszeiten, persönliche Betreuung, 24/7 Support-Hotline, transparente Kosten. | https://robo-planet.de/service#service-4 |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 2: Zielgruppen (WER - Unternehmen)
|
||||
|
||||
| Zielbranche/Segment | Typische Unternehmensmerkmale | Region(en) | Relevanzbeleg (URL) |
|
||||
| --- | --- | --- | --- |
|
||||
| Hotellerie & Gastronomie | Hotels, Restaurants, Eventlocations mit großen Publikumsbereichen und Bedarf an effizienter Reinigung, Serviceautomatisierung (Auslieferung, Abräumen, Wegeführung) und Personalentlastung. | Deutschland | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| Gesundheitswesen | Krankenhäuser, Pflegeheime und medizinische Einrichtungen mit hohen Hygieneanforderungen, internem Material- und Warentransportbedarf sowie dem Wunsch, Personal von Routineaufgaben zu entlasten. | Deutschland | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/, https://robo-planet.de/roboter/lieferroboter/ |
|
||||
| Industrie & Logistik | Produktionsstätten, Lager- und Logistikzentren mit großen Hallenflächen, intensivem internen Material- und Warentransport und dem Bedarf an planbarer, automatisierter Reinigung sowie Prozessoptimierung. | Deutschland | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/lieferroboter/ |
|
||||
| Einzelhandel & Einkaufszentren | Große Supermärkte, Shopping Malls und Einzelhandelsketten mit hohem Besucheraufkommen, kontinuierlichem Reinigungsbedarf und Potenzial für digitale Kundeninteraktion durch mobile Informationspunkte. | Deutschland | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| Gebäudemanagement & Dienstleistungen | Facility-Management-Dienstleister, Reinigungsunternehmen und Objektverwaltungen für große kommerzielle und öffentliche Gebäude (z.B. Büroparks, Flughäfen, Bildungseinrichtungen) mit Bedarf an skalierbaren Automatisierungslösungen. | Deutschland | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/service#service-1 |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 3: Zielpersonen/Rollen (WER - Personen)
|
||||
|
||||
| Rolle (präzise) | Verantwortungsbereich | Warum relevant für Produkt | Kaufbeteiligung (E/I/D/U) | Quelle/Indiz |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Gesamtstrategie, Budgetverantwortung, Profitabilität, Gästezufriedenheit, Mitarbeiterbindung | Sucht nach Lösungen zur Kosteneffizienz, Entlastung des Personals, Verbesserung des Servicelevels und Steigerung der Attraktivität des Hauses. | D (Decider), I (Influencer) | https://robo-planet.de/service#service-1 (Wirtschaftlichkeitsbelegung) |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Sauberkeit, Hygiene, Personaleinsatzplanung, Budget für Reinigungsmittel/Geräte, Qualitätssicherung | Benötigt effiziente und planbare Reinigungslösungen, um Personalengpässe zu kompensieren, Reinigungsqualität zu sichern und Betriebskosten zu senken. | E (Evaluator), I (Influencer), U (User) | https://robo-planet.de/roboter/reinigungsroboter/ |
|
||||
| F&B Manager / Restaurantleiter | Servicequalität, Personaleffizienz im Servicebereich, Gästeerlebnis, Ablaufoptimierung | Sucht nach Wegen, Personal bei Routineaufgaben (Lieferung, Abräumen) zu entlasten, um Fokus auf Gästebetreuung zu legen und Wartezeiten zu reduzieren. | E (Evaluator), I (Influencer), U (User) | https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Instandhaltung, technische Infrastruktur, Energieeffizienz, Gewährleistung der Betriebssicherheit aller Anlagen | Ist für die technische Integration der Roboter in die Gebäudeinfrastruktur und deren reibungslosen Betrieb zuständig. Bewertet Wartungs- und Serviceaspekte. | E (Evaluator), I (Influencer) | https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4 |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 4: Painpoints je Rolle (WARUM)
|
||||
|
||||
| Rolle (präzise) | Painpoint (konkret, messbar/operativ) | Kategorie | Auswirkung (Kosten, Risiko, Zeit) | Impact-Schaetzung (EUR, h, %) | Dringlichkeit | Quelle/Indiz (URL) |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Steigende Personalkosten im Reinigungs- und Servicebereich sowie Schwierigkeiten, qualifiziertes Personal zu finden, gefährden die Profitabilität und das Servicelevel. | Kosten, Mitarbeiterbindung | Direkte Reduzierung der Gewinnmargen, negative Auswirkung auf Gästezufriedenheit. | Bis zu 15% höhere Betriebskosten pro Jahr, 10-20% höhere Fluktuation bei Reinigungspersonal (Hypothese). | hoch | https://robo-planet.de/service#service-1 (Wirtschaftlichkeitsbelegung), https://robo-planet.de/roboter/reinigungsroboter/ (Entlasten Teams, federn personelle Ausfälle ab), https://robo-planet.de/roboter/serviceroboter/ (Teams Zeit für persönliche Betreuung gewinnen) |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Inkonsistente Reinigungsstandards oder mangelnde Servicegeschwindigkeit beeinträchtigen das Gästeerlebnis und schaden dem Ruf des Hauses. | Qualitaet, Risiko | Schlechte Online-Bewertungen, Verlust von Stammgästen, Image-Schaden. | 5-10% Rückgang der positiven Gäste-Feedbacks, X EUR Verlust durch entgangene Buchungen (Hypothese). | hoch | https://robo-planet.de/roboter/reinigungsroboter/ (gleichbleibend hohe Sauberkeit), https://robo-planet.de/roboter/serviceroboter/ (Teams Zeit für persönliche Betreuung gewinnen) |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Hoher Managementaufwand und fehlende Transparenz bei operativen Abläufen erschweren datenbasierte Entscheidungen zur Effizienzsteigerung. | Zeit, Kosten | Suboptimale Ressourcennutzung, verpasste Einsparpotenziale. | 5-10 h/Woche Managementzeit für manuelle Prozesse (Hypothese), 5% höhere Personalkosten durch ineffiziente Planung (Hypothese). | mittel | https://robo-planet.de/service#service-1 (Bedarfsanalyse, Wirtschaftlichkeitsbelegung), https://robo-planet.de/service#service-4 (Umfassendes Monitoring) |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Personelle Unterbesetzung und hohe Fluktuation im Reinigungsteam führen zu Überstunden, Unzufriedenheit der Mitarbeiter und unzureichend gereinigten Bereichen. | Mitarbeiterbindung, Qualitaet, Kosten | Sinkende Reinigungsqualität, höhere Personalkosten durch Überstunden, Schwierigkeiten bei der Besetzung von Stellen. | 10-20% der Reinigungsfläche nicht optimal gereinigt, 5-15% der Personalkosten sind Überstunden (Hypothese). | hoch | https://robo-planet.de/roboter/reinigungsroboter/ (entlasten Teams spürbar und federn personelle Ausfälle ab) |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Die Sicherstellung einer gleichbleibend hohen Reinigungsqualität, insbesondere in Stoßzeiten und auf großen Flächen, ist manuell ressourcenintensiv und fehleranfällig. | Qualitaet, Zeit | Beschwerden von Gästen, zusätzliche Nachreinigungen, Imageverlust. | X EUR/Monat für Nachreinigungen (Hypothese), 5-10% der Reinigungszeit für Qualitätskontrollen (Hypothese). | hoch | https://robo-planet.de/roboter/reinigungsroboter/ (gleichbleibend hohe Sauberkeit, autonome Bodenreinigung) |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Der hohe Zeitaufwand für manuelle Routenplanung und die Überwachung der Reinigungsarbeiten binden wertvolle Kapazitäten, die für andere Aufgaben fehlen. | Zeit | Weniger Zeit für Personalentwicklung, Budgetkontrolle oder Sonderaufgaben. | 5-10 Stunden/Woche für manuelle Planung und Überwachung (Hypothese). | mittel | https://robo-planet.de/roboter/reinigungsroboter/ (einfache Programmierung, automatische Zyklen), https://robo-planet.de/service#service-3 (Mapping von Routen) |
|
||||
| F&B Manager / Restaurantleiter | Servicepersonal verbringt zu viel Zeit mit wiederkehrenden Routineaufgaben wie dem Abräumen oder dem Transport von Speisen, anstatt sich auf die Gästebetreuung zu konzentrieren. | Zeit, Qualitaet, Mitarbeiterbindung | Reduzierte Gästeinteraktion, potenzielle Wartezeiten, Frustration beim Personal. | 20-30% der Servicezeit für Routineaufgaben (Hypothese), X EUR/Monat durch entgangene Upselling-Möglichkeiten (Hypothese). | hoch | https://robo-planet.de/roboter/serviceroboter/ (Teams Zeit für die persönliche Betreuung gewinnen, übernehmen Auslieferung, Abräumen und Wegeführung) |
|
||||
| F&B Manager / Restaurantleiter | Mangelnde Personalverfügbarkeit, insbesondere zu Spitzenzeiten, führt zu Engpässen im Service, längeren Wartezeiten für Gäste und potenziellen Umsatzeinbußen. | Kosten, Risiko | Negative Gästebewertungen, Verlust von Gästen, geringere Tischrotation. | 10-15% Umsatzeinbußen in Spitzenzeiten (Hypothese), 5-10% höhere Personalkosten durch Überstunden (Hypothese). | hoch | https://robo-planet.de/roboter/serviceroboter/ (entlasten Teams spürbar, federn personelle Ausfälle ab), https://robo-planet.de/roboter/lieferroboter/ (Reduzierung von Engpässen) |
|
||||
| F&B Manager / Restaurantleiter | Schwierigkeiten, die Effizienz des Serviceablaufs transparent zu messen und Engpässe präzise zu identifizieren, erschweren eine datenbasierte Optimierung. | Zeit, Kosten | Suboptimale Personalplanung, verpasste Möglichkeiten zur Prozessverbesserung. | 5-10% Ineffizienz in der Serviceplanung (Hypothese), X h/Monat für manuelle Analyse (Hypothese). | mittel | https://robo-planet.de/service#service-1 (Bedarfsanalyse, Prozessanalyse), https://robo-planet.de/service#service-4 (Umfassendes Monitoring) |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Die Integration neuer autonomer Systeme in die bestehende Gebäudeinfrastruktur (z.B. Aufzüge, Türsysteme, WLAN) ist technisch komplex und birgt das Risiko von Kompatibilitätsproblemen. | Risiko, Zeit | Verzögerungen bei der Implementierung, zusätzliche Kosten für Anpassungen, potenzielle Systemausfälle. | 20-30% längerere Implementierungszeit ohne externe Unterstützung (Hypothese), X EUR für unerwartete Anpassungen (Hypothese). | hoch | https://robo-planet.de/service#service-3 (Fachgerechte Installation, Integration in bestehende Abläufe), https://robo-planet.de/roboter/lieferroboter/ (Aufzugintegration, IoT-Kompatibilität) |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Die Gewährleistung der dauerhaften Betriebssicherheit und die schnelle Behebung von Störungen bei Robotern ohne eigenes Spezialpersonal stellen eine Herausforderung dar und können zu Ausfallzeiten führen. | Risiko, Zeit | Unterbrechung der Reinigungs- oder Serviceabläufe, Kundenunzufriedenheit, Notwendigkeit manueller Ersatzlösungen. | 5-10% Ausfallzeit bei fehlendem Support (Hypothese), X EUR/Tag durch Ausfall der automatisierten Dienste (Hypothese). | hoch | https://robo-planet.de/service#service-4 (Umfassendes Monitoring, schnelle Reparaturservices, feste SLAs, bundesweites Servicenetzwerk), https://robo-planet.de/service#service-3 (Systemüberwachung, Feinjustierung, Fehleranalyse) |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Unklare Wartungsintervalle, fehlende Ersatzteilverfügbarkeit oder intransparente Servicekosten erschweren die Budgetplanung und die Einhaltung der Lebensdauer der Anlagen. | Kosten, Risiko | Unerwartete Kosten, kürzere Lebensdauer der Geräte, schwer kalkulierbare Total Cost of Ownership (TCO). | 10-20% höhere unplanmäßige Wartungskosten (Hypothese), X EUR durch vorzeitigen Ersatz von Geräten (Hypothese). | mittel | https://robo-planet.de/service#service-4 (Regelmäßige Wartungspläne, Ersatzteile, feste SLAs, transparente Kosten, Garantieverlängerungsoptionen) |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 5: Gains & Nutzen je Rolle (WARUM wechseln)
|
||||
|
||||
| Rolle (präzise) | Gain (konkreter Nutzen) | Quantifizierung (Hypothese in EUR, h, %) | Quelle/Indiz (URL) |
|
||||
| --- | --- | --- | --- |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Deutliche Reduktion der operativen Personalkosten und Abfederung von Personalengpässen. | 10-25% Reduktion der Personalkosten im betroffenen Bereich; bis zu 50% Abnahme der Überstunden. | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/, https://robo-planet.de/service#service-1 |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Sicherstellung eines konstant hohen und gleichbleibenden Qualitätsstandards bei Sauberkeit und Service. | 15-30% Steigerung der Gästezufriedenheit; Reduktion von Beschwerden um 20-40% (Hypothese). | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| Direktor / Geschäftsführer (Hotel/Restaurantkette) | Optimierung der Betriebsabläufe und Erzielung von Wirtschaftlichkeit durch transparente Daten und präzise Analysen. | 5-10% Effizienzsteigerung in operativen Abläufen; Einsparung von 2-4 Managementstunden pro Woche für manuelle Prozessüberwachung (Hypothese). | https://robo-planet.de/service#service-1, https://robo-planet.de/service#service-4 |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Signifikante Entlastung des Reinigungspersonals und Kompensation von Personalengpässen. | 20-40% Reduktion der Arbeitsbelastung für manuelle Reinigungsarbeiten; 10-20% Rückgang der Überstunden (Hypothese). | https://robo-planet.de/roboter/reinigungsroboter/ |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Garantierte, gleichbleibend hohe Reinigungsqualität rund um die Uhr, unabhängig von Personalverfügbarkeit. | 100% Abdeckung definierter Reinigungszyklen; Reduktion von Nachreinigungen um 30-50% (Hypothese). | https://robo-planet.de/roboter/reinigungsroboter/ |
|
||||
| Leiter Housekeeping / Hauswirtschaftsleitung | Effizienzgewinn durch automatisierte Reinigungsroutinen und reduzierte manuelle Planungs- und Überwachungszeit. | Einsparung von 5-10 Stunden/Woche für manuelle Planung und Überwachung (Hypothese). | https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/service#service-3 |
|
||||
| F&B Manager / Restaurantleiter | Freisetzung des Servicepersonals für wertschöpfende Aufgaben wie persönliche Gästebetreuung und Upselling. | 20-40% der Servicezeit für Gästebetreuung statt Routineaufgaben; Steigerung der Upselling-Möglichkeiten um 5-10% (Hypothese). | https://robo-planet.de/roboter/serviceroboter/ |
|
||||
| F&B Manager / Restaurantleiter | Abfederung von Personalengpässen und Steigerung der Servicekapazität ohne zusätzlichen Personalaufbau. | 10-20% höhere Servicekapazität in Spitzenzeiten; Vermeidung von Umsatzeinbußen durch Wartezeiten (Hypothese). | https://robo-planet.de/roboter/serviceroboter/, https://robo-planet.de/roboter/lieferroboter/ |
|
||||
| F&B Manager / Restaurantleiter | Transparenz über Serviceabläufe und datenbasierte Identifikation von Optimierungspotenzialen. | 5-15% Effizienzsteigerung in der Serviceplanung; Einsparung von 2-3 Stunden/Monat für manuelle Analyse (Hypothese). | https://robo-planet.de/service#service-1, https://robo-planet.de/service#service-4 |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Reibungslose und fachgerechte Integration in bestehende Infrastruktur durch Experten-Support. | 20-30% schnellere Implementierung; Reduktion technischer Anpassungskosten um 10-20% (Hypothese). | https://robo-planet.de/service#service-3, https://robo-planet.de/roboter/lieferroboter/ |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Minimierung von Ausfallzeiten durch proaktives Monitoring und schnellen, kompetenten Reparaturservice. | Reduktion der Ausfallzeiten um 80-90% (Hypothese). | https://robo-planet.de/service#service-4, https://robo-planet.de/service#service-3 |
|
||||
| Technischer Leiter / Facility Manager (im Hotelkontext) | Planbare Wartung, garantierte Ersatzteilverfügbarkeit und transparente Kosten durch feste SLAs und umfassende Servicepakete. | 10-20% Reduktion unerwarteter Wartungskosten; Verlängerung der Lebensdauer der Geräte um 1-3 Jahre (Hypothese). | https://robo-planet.de/service#service-4 |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 6: Marketingbotschaften je Segment & Rolle (WIE sprechen)
|
||||
|
||||
**Kurzresümee:**
|
||||
- Vollständige Analyse über alle identifizierten Branchen.
|
||||
|
||||
| Fokus-Branche | Rolle | Kernbotschaft (2-3 sentences) | LinkedIn | Kaltmail | Landingpage |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Hotellerie & Gastronomie | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Steigende Personalkosten und der Anspruch an exzellenten Service sind Herausforderungen in der Hotellerie & Gastronomie. Unsere autonomen Reinigungs- und Serviceroboter entlasten Ihre Teams, senken operative Kosten um 10-25% und steigern die Gästezufriedenheit messbar um 15-30%. | Hohe Personalkosten und Fachkräftemangel belasten Hotellerie und Gastronomie. Entdecken Sie, wie autonome Reinigungs- und Serviceroboter Ihre Teams entlasten, operative Kosten um 10-25% senken und gleichzeitig die Gästezufriedenheit um 15-30% steigern. Mehr dazu in unserem Leitfaden. #Hotelmanagement #Gastronomie #Robotik | Betreff: Effizienz & Gästezufriedenheit: Wie Roboter Ihre Betriebsabläufe optimieren. Sehr geehrte/r [Anrede Nachname], steigende Personalkosten und der Anspruch an exzellenten Service sind tägliche Herausforderungen. Wir zeigen Ihnen, wie Sie mit autonomen Roboterlösungen Ihre operativen Kosten um 10-25% reduzieren und die Gästezufriedenheit um 15-30% steigern können. Gerne besprechen wir dies in einem kurzen Gespräch. | Zukunftssichere Hotellerie & Gastronomie: Profitabilität durch intelligente Robotik steigern. Steigende Betriebskosten und Personalengpässe stellen Ihre Branche vor enorme Herausforderungen. Unsere autonomen Reinigungs- und Serviceroboter entlasten Ihre Mitarbeiter spürbar, senken operative Kosten um 10-25% und garantieren eine konstant hohe Service- und Sauberkeitsqualität, die Ihre Gäste begeistert – für eine messbare Steigerung der Gästezufriedenheit um 15-30%. |
|
||||
| Hotellerie & Gastronomie | Leiter Housekeeping / Hauswirtschaftsleitung | Personalengpässe erschweren oft eine lückenlose, qualitativ hochwertige Reinigung. Mit Reinigungsrobotern entlasten Sie Ihr Team um 20-40% bei Routinearbeiten, sichern 100%ige Abdeckung der Reinigungszyklen und reduzieren Nachreinigungen um 30-50%. | Kennen Sie den Druck, bei Personalengpässen eine makellose Reinigungsqualität zu garantieren? Unsere autonomen Reinigungsroboter entlasten Ihr Housekeeping-Team um 20-40% bei Routineaufgaben und sichern 100%ige Abdeckung der Reinigungszyklen, während Nachreinigungen um bis zu 50% reduziert werden. Erfahren Sie mehr über effizientes Housekeeping. #Housekeeping #Hotelreinigung #Effizienz | Betreff: Ihr Housekeeping: Qualität sichern, Team entlasten. Sehr geehrte/r [Anrede Nachname], Personalengpässe machen die Aufrechterhaltung höchster Hygienestandards schwierig. Mit Reinigungsrobotern entlasten Sie Ihr Team um 20-40% und garantieren eine 100%ige Abdeckung der Reinigungszyklen. Nachreinigungen können so um 30-50% sinken. Wollen Sie wissen, wie das für Ihr Haus funktioniert? | Makellose Sauberkeit, entlastetes Team: Intelligente Reinigung für Ihr Housekeeping. Überstunden, Fluktuation und der Druck, höchste Hygienestandards zu halten – Ihr Housekeeping-Team leistet Enormes. Unsere Reinigungsroboter nehmen Routineaufgaben ab, entlasten Ihr Personal um 20-40% und gewährleisten eine gleichbleibend hohe Reinigungsqualität. Erzielen Sie 100% Abdeckung Ihrer Zyklen und reduzieren Sie Nachreinigungen um 30-50%. |
|
||||
| Hotellerie & Gastronomie | F&B Manager / Restaurantleiter | Servicepersonal verbringt zu viel Zeit mit wiederkehrenden Routineaufgaben statt mit dem Gast. Serviceroboter entlasten Ihre Teams signifikant, geben ihnen 20-40% der Servicezeit für persönliche Gästebetreuung zurück und erhöhen die Servicekapazität um 10-20%. | Engpässe im Service und zu wenig Zeit für den Gast? Serviceroboter revolutionieren Ihren F&B-Bereich! Freuen Sie sich auf bis zu 40% mehr Zeit für Ihre Servicekräfte zur Gästebetreuung und eine 10-20% höhere Servicekapazität. Entdecken Sie, wie Sie das Gästeerlebnis und Ihre Effizienz steigern. #F&BManagement #Restaurantleiter #Serviceinnovation | Betreff: Mehr Zeit für den Gast: Serviceroboter im Fokus. Sehr geehrte/r [Anrede Nachname], möchten Sie Ihr Servicepersonal entlasten und das Gästeerlebnis nachhaltig verbessern? Serviceroboter übernehmen Routineaufgaben und geben Ihren Teams 20-40% der Zeit zurück, die sie für persönliche Gästebetreuung nutzen können, und steigern die Kapazität um 10-20%. Gerne zeigen wir Ihnen ein Beispiel. | Exzellenter Service, entlastetes Team: Serviceroboter für Hotellerie & Gastronomie. Routineaufgaben binden wertvolle Ressourcen und nehmen Ihrem Personal die Zeit für das Wichtigste: den Gast. Unsere Serviceroboter übernehmen zuverlässig Auslieferung und Abräumen. Sie gewinnen bis zu 40% der Servicezeit für persönliche Gästebetreuung zurück und steigern Ihre Servicekapazität um 10-20%, für ein herausragendes Gästeerlebnis und mehr Effizienz. |
|
||||
| Hotellerie & Gastronomie | Technischer Leiter / Facility Manager (im Hotelkontext) | Die nahtlose Integration und der störungsfreie Betrieb neuer Robotik sind entscheidend für Ihr Hotel. Wir garantieren 20-30% schnellere Integration, minimieren Ausfallzeiten um 80-90% durch proaktives Monitoring und reduzieren unerwartete Wartungskosten um 10-20% mit transparenten SLAs. | Als Technischer Leiter wissen Sie: Neue Systeme müssen nahtlos funktionieren. Wir garantieren 20-30% schnellere Integration von Robotern in Ihre Hotelinfrastruktur, minimieren Ausfallzeiten um 80-90% durch unser Monitoring und sparen Ihnen 10-20% unerwartete Wartungskosten. Verlassen Sie sich auf unser bundesweites Servicenetzwerk. #FacilityManagement #Hoteltechnik #Automatisierung | Betreff: Roboter-Integration & Betriebssicherheit für Ihr Haus. Sehr geehrte/r [Anrede Nachname], die Implementierung neuer Technologien birgt technische Herausforderungen. Wir sichern Ihnen eine 20-30% schnellere Integration unserer Roboter zu, reduzieren Ausfallzeiten um 80-90% und unerwartete Wartungskosten um 10-20% durch unser umfassendes Servicepaket. Sprechen Sie mit unseren Experten. | Sorgenfreier Roboter-Betrieb: Technik und Service aus einer Hand. Die Einführung intelligenter Robotik soll Ihre Effizienz steigern, nicht Ihre technischen Herausforderungen. Wir garantieren eine 20-30% schnellere, reibungslose Integration in Ihre bestehende Hotelinfrastruktur. Mit proaktivem Monitoring, schnellem Support und transparenten SLAs minimieren Sie Ausfallzeiten um 80-90% und reduzieren unerwartete Wartungskosten um 10-20%. Maximale Betriebssicherheit und Kalkulierbarkeit sind garantiert. |
|
||||
| Gesundheitswesen | Direktor / Geschäftsführer (Krankenhaus/Pflegeheim) | Steigende Personalkosten und Personalengpässe gefährden die Wirtschaftlichkeit und konstant hohe Hygiene- & Servicestandards in Ihrem Haus. Überdenken Sie, wie autonome Robotik Ihre Teams entlasten und Abläufe optimieren kann. Mit spezialisierten Reinigungs-, Service- und Lieferrobotern von RoboPlanet senken Sie operative Personalkosten um 10-25% und sichern durchgängig hohe Standards, die die Patientenzufriedenheit signifikant steigern. | Titelidee: Effizienz im Gesundheitswesen: Wie Robotik Ihre Betriebskosten senkt und Standards sichert.<br>Text: Steigende Personalkosten und die Herausforderung, hohe Hygiene- & Servicestandards zu halten, belasten Gesundheitseinrichtungen. Mit RoboPlanet automatisieren Sie Routineaufgaben und entlasten Ihr Team. Senken Sie operative Personalkosten um 10-25% und steigern Sie die Patientenzufriedenheit durch konstant hohe Qualität. #Gesundheitswesen #Robotik #Effizienz #Krankenhausmanagement | Subject: Ihre Lösung für steigende Kosten & Personalengpässe im Gesundheitswesen<br>Body: Sehr geehrte/r [Name],<br>Die Wirtschaftlichkeit und die Einhaltung hoher Hygiene- und Servicestandards stellen in Gesundheitseinrichtungen eine wachsende Herausforderung dar, bedingt durch steigende Personalkosten und Engpässe.<br>RoboPlanet bietet Ihnen eine strategische Antwort: unsere autonomen Reinigungs-, Service- und Lieferroboter entlasten Ihr Personal spürbar. Wir helfen Ihnen, operative Personalkosten um 10-25% zu senken und gleichzeitig die Patientenzufriedenheit durch durchgängig hohe Qualität zu steigern.<br>Möchten Sie erfahren, wie wir dies konkret für Ihr Haus umsetzen können?<br>[CTA: Jetzt kostenlose Erstberatung anfordern] | Headline: Zukunftsweisende Effizienz für Ihr Krankenhaus: Robotik, die entlastet und Kosten senkt.<br>Body: In der heutigen Gesundheitslandschaft sind steigende Personalkosten und die Notwendigkeit, höchste Hygiene- und Servicestandards zu gewährleisten, entscheidende Faktoren. RoboPlanet bietet strategische Automatisierungslösungen, die exakt auf die Anforderungen Ihres Hauses zugeschnitten sind.<br>Unsere Reinigungs-, Service- und Lieferroboter entlasten Ihre Teams von Routineaufgaben, kompensieren Personalengpässe und sichern eine gleichbleibend hohe Qualität. Profitieren Sie von einer Reduktion operativer Personalkosten um 10-25% und einer messbaren Steigerung der Patientenzufriedenheit.<br>[CTA: Jetzt Wirtschaftlichkeitsanalyse anfordern] |
|
||||
| Gesundheitswesen | Leiter Hygiene & Reinigung / Hauswirtschaftsleitung (Krankenhaus/Pflegeheim) | Personelle Unterbesetzung und hoher Aufwand für manuelle Planung erschweren die Sicherstellung durchgängig hoher Reinigungs- und Hygienestandards. Entdecken Sie, wie intelligente Automatisierung Ihr Reinigungsteam gezielt unterstützt und Abläufe vereinfacht. Unsere Reinigungsroboter ermöglichen eine effiziente und planbare Bodenreinigung, entlasten Ihr Personal um 20-40% und garantieren 100% Abdeckung Ihrer Hygienevorschriften mit minimalem Planungsaufwand. | Titelidee: Hygienestandards sichern: Reinigungsrobotik für das Gesundheitswesen.<br>Text: Ist die Sicherstellung durchgängiger Hygiene im Klinikalltag eine Herausforderung? Unsere Reinigungsroboter entlasten Ihr Team und übernehmen planbar die Bodenreinigung. Reduzieren Sie die manuelle Arbeitsbelastung um 20-40% und garantieren Sie 100% Abdeckung Ihrer Reinigungszyklen, um höchste Hygienestandards zu gewährleisten. #Hygiene #Krankenhausreinigung #Robotik #Personalentlastung | Subject: Entlastung für Ihr Reinigungsteam & garantierte Hygiene<br>Body: Sehr geehrte/r [Name],<br>Die Herausforderung, in Gesundheitseinrichtungen jederzeit höchste Reinigungs- und Hygienestandards zu gewährleisten, ist durch Personalengpässe und den Planungsaufwand immens. Unsere autonomen Reinigungsroboter sind die Lösung.<br>Sie entlasten Ihr Reinigungsteam spürbar von Routineaufgaben, ermöglichen eine 20-40%ige Reduktion manueller Arbeitsbelastung und sichern 100% Abdeckung Ihrer Reinigungszyklen. So haben Sie mehr Zeit für Qualitätskontrolle und Ihr Team für komplexere Aufgaben.<br>Lassen Sie uns in einem kurzen Gespräch die Möglichkeiten für Ihr Haus beleuchten.<br>[CTA: Demo anfordern] | Headline: Exzellente Hygiene, mühelos erreicht: Intelligente Reinigungsrobotik für Ihr Gesundheitswesen.<br>Body: In Bereichen, wo Hygiene entscheidend ist, können Personalengpässe und der manuelle Aufwand für Reinigung die Qualität beeinträchtigen. Unsere speziell für das Gesundheitswesen entwickelten Reinigungsroboter sichern eine konstant hohe Sauberkeit und entlasten Ihr Personal. <br>Erleben Sie eine 20-40%ige Reduktion der manuellen Arbeitsbelastung und eine 100%ige Abdeckung aller Reinigungszyklen. So erreichen Sie höchste Hygienestandards und optimieren gleichzeitig Ihre Personalplanung.<br>[CTA: Mehr erfahren] |
|
||||
| Gesundheitswesen | Leiter Speisenversorgung / Stationsleitung (Krankenhaus/Pflegeheim) | Ihr Stationspersonal verbringt wertvolle Zeit mit wiederkehrenden Transport- und Abräumarbeiten, statt sich voll auf die Patientenbetreuung zu konzentrieren. Erwägen Sie autonome Unterstützung, um Routineaufgaben effizient zu delegieren. Mit Servicerobotern von RoboPlanet für Auslieferung und Abräumen ermöglichen Sie Ihrem Team, 20-40% mehr Zeit direkt am Patienten zu verbringen und steigern Ihre Servicekapazität um 10-20% in Stoßzeiten. | Titelidee: Mehr Zeit für Patienten: Servicerobotik im Gesundheitswesen.<br>Text: Stationspersonal widmet sich oft zeitaufwendigen Routineaufgaben wie Essenslieferungen oder Abräumen, statt direkt am Patienten zu sein. Unsere Serviceroboter entlasten Ihr Team effektiv. Gewinnen Sie 20-40% mehr Zeit für die Patientenbetreuung und steigern Sie die Servicekapazität in Stoßzeiten um 10-20%. #Patientenversorgung #Serviceroboter #Krankenhausmanagement #Personalentlastung | Subject: Entlasten Sie Ihr Personal: Effizienter Patientenservice durch Robotik<br>Body: Sehr geehrte/r [Name],<br>Der Fokus auf die Patientenbetreuung ist essenziell, doch Routineaufgaben wie Essenslieferungen binden oft zu viel Personalzeit. Serviceroboter von RoboPlanet bieten eine effektive Lösung.<br>Durch die Automatisierung von Transport- und Abräumarbeiten können Sie Ihrem Team ermöglichen, 20-40% mehr Zeit direkt am Patienten zu verbringen. Zugleich steigern Sie Ihre Servicekapazität in Spitzenzeiten um 10-20%.<br>Lassen Sie uns besprechen, wie Ihre Station davon profitieren kann.<br>[CTA: Jetzt unverbindlich informieren] | Headline: Konzentrieren Sie sich auf das Wichtigste: Servicerobotik für eine effiziente Patientenversorgung.<br>Body: Zeit ist ein wertvolles Gut, besonders in der Patientenversorgung. Wenn Ihr Stationspersonal zu viel Zeit mit wiederkehrenden Transport- und Abräumarbeiten verbringt, fehlt diese für die direkte Interaktion mit den Patienten.<br>RoboPlanet Serviceroboter übernehmen diese Routineaufgaben zuverlässig. So können Ihre Teams 20-40% mehr Zeit für die persönliche Patientenbetreuung nutzen und Sie steigern die Servicekapazität Ihrer Station um 10-20%, besonders in Stoßzeiten. <br>[CTA: Service optimieren] |
|
||||
| Gesundheitswesen | Technischer Leiter / Facility Manager (Krankenhaus/Pflegeheim) | Die komplexe Integration neuer Automatisierungssysteme und die Gewährleistung dauerhafter Betriebssicherheit stellen eine große technische Herausforderung dar und bergen hohe Ausfallrisiken. Setzen Sie auf einen Partner, der technische Expertise und umfassenden Service bietet. RoboPlanet liefert fachgerechte Implementierung und ein bundesweites Wartungsnetzwerk, das eine 20-30% schnellere Implementierung ermöglicht und potenzielle Ausfallzeiten um 80-90% reduziert. | Titelidee: Technische Sicherheit & reibungslose Integration von Robotik im Krankenhaus.<br>Text: Die Integration autonomer Systeme im komplexen Krankenhausumfeld erfordert Expertise, um Ausfallrisiken zu minimieren. RoboPlanet bietet fachgerechte Implementierung und ein bundesweites Wartungsnetzwerk. Profitieren Sie von einer 20-30% schnelleren Implementierung und reduzieren Sie potenzielle Ausfallzeiten um 80-90% durch unseren Experten-Support. #FacilityManagement #Krankenhaustechnik #RobotikIntegration #Betriebssicherheit | Subject: Effiziente Integration und Wartung Ihrer Robotiklösungen im Gesundheitswesen<br>Body: Sehr geehrte/r [Name],<br>Die Einführung neuer Automatisierungssysteme in eine bestehende Krankenhausinfrastruktur ist technisch anspruchsvoll. Die Minimierung von Ausfallzeiten ist dabei entscheidend für einen reibungslosen Betrieb.<br>RoboPlanet ist Ihr Partner für eine fachgerechte Implementierung und umfassenden technischen Support. Wir gewährleisten eine 20-30% schnellere Integration Ihrer Robotiklösungen und reduzieren potenzielle Ausfallzeiten um 80-90% durch proaktives Monitoring und schnelle Reparaturservices. So sichern Sie die langfristige Verfügbarkeit und Planbarkeit Ihrer Anlagen.<br>[CTA: Kontakt für technische Beratung] | Headline: Zuverlässige Robotik-Integration: Maximale Betriebssicherheit für Ihr Gesundheitswesen.<br>Body: Als Technischer Leiter wissen Sie, wie kritisch die reibungslose Integration neuer Systeme und die Minimierung von Ausfallzeiten in einem Krankenhaus sind. Die Komplexität autonomer Robotik erfordert einen erfahrenen Partner.<br>RoboPlanet bietet Ihnen nicht nur die passenden Robotiklösungen, sondern auch eine fachgerechte Implementierung, nahtlose Integration in Ihre bestehende Infrastruktur und einen umfassenden 360°-Service mit bundesweitem Wartungsnetzwerk. Erreichen Sie eine 20-30% schnellere Implementierung und reduzieren Sie potenzielle Ausfallzeiten um 80-90% – für maximale Betriebssicherheit und Kalkulierbarkeit.<br>[CTA: Jetzt technische Details anfragen] |
|
||||
| Industrie & Logistik | Werksleiter / Produktionsleiter | Steigende Betriebskosten und ineffiziente Abläufe sind Herausforderungen in der Fertigung. Automatisieren Sie monotone Aufgaben mit Liefer- und Reinigungsrobotern, entlasten Ihr Team und senken Ihre Betriebskosten messbar um bis zu 15% (Hypothese). | Hohe Betriebskosten und manuelle Transportwege sind in der Produktion oft ein Engpass. Entdecken Sie, wie RoboPlanet mit autonomen Liefer- und Reinigungsrobotern Ihre Prozesse optimiert, Ihr Team entlastet und die Betriebskosten messbar senkt. Neugierig, wie Sie bis zu 15% (Hypothese) einsparen können? #Industrie40 #Automatisierung #RoboPlanet | Sehr geehrte/r [Anrede Nachname], als Werksleiter wissen Sie, wie kritisch ein reibungsloser Materialfluss und konstante Sauberkeit für die Produktion sind. Aktuell binden manuelle Tätigkeiten oft wertvolle Personalressourcen und treiben Kosten in die Höhe. RoboPlanet bietet intelligente Roboterlösungen, die nicht nur Ihr Team entlasten, sondern auch Ihre Betriebsabläufe optimieren. Wir zeigen Ihnen, wie Sie mit Reinigungs- und Lieferrobotern Ihre Effizienz steigern und bis zu 15% (Hypothese) Ihrer Betriebskosten einsparen können. Lassen Sie uns in einem kurzen Gespräch erörtern, wie dies in Ihrem Werk umsetzbar ist. | Produktion 4.0: Maximale Effizienz & Sauberkeit durch Robotik. Ihr Werk steht vor der Herausforderung, Betriebskosten zu senken und gleichzeitig die Effizienz sowie Sicherheitsstandards zu erhöhen? RoboPlanet unterstützt Sie dabei: Unsere Reinigungs- und Lieferroboter automatisieren monotone Aufgaben, optimieren Ihren Materialfluss und sorgen für konstant hohe Sauberkeit. Erzielen Sie eine messbare Reduktion Ihrer Betriebskosten um bis zu 15% (Hypothese) und steigern Sie die Produktivität. Entlasten Sie Ihr Team und sichern Sie Ihren Wettbewerbsvorteil. Erfahren Sie mehr über unsere maßgeschneiderten Lösungen für die Industrie. [Call to Action Button: Jetzt Beratung anfragen] |
|
||||
| Industrie & Logistik | Lagerleiter / Logistikleiter | Manuelle Transportwege und Engpässe bremsen die Effizienz in Lagern. Mit autonomen Lieferrobotern optimieren Sie Ihren Materialfluss, entlasten Ihr Team und reduzieren Transportkosten um bis zu 30% (Hypothese). | Als Logistikleiter suchen Sie nach Wegen, den Materialfluss zu optimieren und Kosten zu senken? Unsere Lieferroboter sind die Antwort. Automatisieren Sie Standardfahrten, entlasten Sie Ihr Team und erreichen Sie eine Effizienzsteigerung von 20-30% (Hypothese) in Ihrem Lager. Mehr dazu auf unserer Website! #Logistik #Intralogistik #RoboPlanet | Sehr geehrte/r [Anrede Nachname], der manuelle Materialtransport ist in vielen Lagern ein großer Zeit- und Kostenfaktor, der wertvolle Ressourcen bindet und Engpässe verursachen kann. RoboPlanet bietet fortschrittliche Lieferroboter, die Ihre Intralogistik revolutionieren. Durch die Automatisierung von Standardfahrten entlasten Sie Ihr Team spürbar, erhöhen die Versorgungssicherheit und erzielen eine Effizienzsteigerung von 20-30% (Hypothese). Gerne besprechen wir, wie eine maßgeschneiderte Lösung für Ihr Lager aussehen könnte. | Effiziente Intralogistik: Lieferroboter für Ihr Lager. Steigende Personalkosten und manuelle Transportwege bremsen die Effizienz in Ihrem Lager? Mit den Lieferrobotern von RoboPlanet automatisieren Sie zuverlässig Material- und Warentransporte. Entlasten Sie Ihr Logistikteam, reduzieren Sie Engpässe und erhöhen Sie die Versorgungssicherheit. Wir helfen Ihnen, Ihre Intralogistik zu optimieren und eine Effizienzsteigerung von bis zu 30% (Hypothese) zu erzielen. Entdecken Sie die Potenziale für Ihr Logistikzentrum. [Call to Action Button: Prozessanalyse anfordern] |
|
||||
| Industrie & Logistik | Leiter Facility Management / Instandhaltung | Die Sicherstellung konstanter Sauberkeit in großen Industriehallen ist ressourcenintensiv. Unsere autonomen Reinigungsroboter automatisieren diese Aufgaben, senken Reinigungskosten um bis zu 25% (Hypothese) und garantieren hohe Qualität. | Als Leiter Facility Management kennen Sie die Herausforderung großer Flächen. Unsere Reinigungsroboter garantieren effiziente Sauberkeit und entlasten Ihr Team. Senken Sie Ihre Reinigungskosten um bis zu 25% (Hypothese) und sichern Sie die Verfügbarkeit Ihrer Anlagen mit dem 360°-Service von RoboPlanet. Erfahren Sie mehr! #FacilityManagement #Industriereinigung #RoboPlanet | Sehr geehrte/r [Anrede Nachname], die Reinigung großer Industrie- und Logistikflächen bindet oft erhebliche Personal- und Budgetressourcen, während die Qualität variieren kann. RoboPlanet bietet Ihnen eine Lösung: Unsere autonomen Reinigungsroboter sorgen für gleichbleibend hohe Sauberkeit und entlasten Ihr Team spürbar. Mit unserem umfassenden Servicepaket von der Beratung bis zur Wartung senken Sie Ihre manuellen Reinigungskosten um bis zu 25% (Hypothese) und profitieren von maximaler Betriebssicherheit. Lassen Sie uns in einem kurzen Gespräch die Potenziale für Ihr Objekt beleuchten. | Automatisierte Reinigung für Industrie & Logistik: Effizienz im Facility Management. Steigender Druck auf das Reinigungsbudget und die Sicherstellung einer konstanten Sauberkeit in großen Industrie- und Logistikhallen? RoboPlanet löst diese Herausforderungen mit intelligenten Reinigungsrobotern. Wir bieten Ihnen nicht nur die Technologie, sondern einen durchdachten 360°-Service, der die Implementierung und den laufenden Betrieb absichert. Reduzieren Sie Ihre manuellen Reinigungskosten um bis zu 25% (Hypothese) und garantieren Sie eine hohe Sauberkeit und Betriebssicherheit. [Call to Action Button: Kostenfreie Bedarfsanalyse] |
|
||||
| Industrie & Logistik | Einkaufsleiter / Strategischer Einkäufer | Sie suchen nach innovativen Technologien mit klarem ROI und transparenten Folgekosten? Unsere Robotiklösungen für Industrie & Logistik senken die Gesamtbetriebskosten (TCO) um 10-20% (Hypothese) und bieten eine planbare Investition mit schneller Amortisation. | Hohe Investitionen erfordern eine klare Kosten-Nutzen-Rechnung. Entdecken Sie, wie unsere Robotik-Lösungen für Industrie & Logistik nicht nur die Effizienz steigern, sondern auch Ihre Gesamtbetriebskosten (TCO) um 10-20% (Hypothese) senken. RoboPlanet bietet Ihnen eine transparente und kalkulierbare Investition. #Einkauf #ROI #TCO #Automatisierung | Sehr geehrte/r [Anrede Nachname], die Beschaffung von Automatisierungstechnologien erfordert eine sorgfältige Abwägung von Investition, ROI und langfristigen Kosten. RoboPlanet ist Ihr Partner für intelligente Reinigungs- und Lieferroboter in der Industrie und Logistik, der Ihnen volle Transparenz bietet. Mit unserem 360°-Service garantieren wir nicht nur eine schnelle Implementierung, sondern auch eine Senkung Ihrer Gesamtbetriebskosten (TCO) um 10-20% (Hypothese) und einen nachweislich schnellen ROI. Lassen Sie uns über eine wirtschaftliche Partnerschaft sprechen. | Intelligente Beschaffung: Maximieren Sie den ROI Ihrer Robotik-Investition. Als strategischer Einkäufer benötigen Sie Partner, die nicht nur innovative Produkte, sondern auch maximale Wirtschaftlichkeit bieten. RoboPlanet liefert Reinigungs- und Lieferroboter für Industrie & Logistik, gepaart mit einem transparenten 360°-Service. Wir helfen Ihnen, die Gesamtbetriebskosten (TCO) um 10-20% (Hypothese) zu senken und einen schnellen Return on Investment zu erzielen. Überzeugen Sie sich von unserer umfassenden Bedarfsanalyse und den klaren Service Level Agreements. [Call to Action Button: Wirtschaftlichkeitsberechnung anfordern] |
|
||||
| Einzelhandel & Einkaufszentren | Center Manager / Filialleiter (Großmarkt) (Hypothese) | In Ihrem Einkaufszentrum oder Großmarkt stehen Sie täglich vor der Herausforderung, konstante Sauberkeit und ein exzellentes Kundenerlebnis bei gleichzeitig steigendem Kostendruck und Personalengpässen zu gewährleisten. Innovative Robotik kann hier einen entscheidenden Unterschied machen. RoboPlanet bietet Ihnen mit autonomen Reinigungs- und Servicerobotern nicht nur die Möglichkeit, diese operativen Hürden zu meistern, sondern auch Ihre Betriebskosten um bis zu 20% zu senken und die Kundenzufriedenheit signifikant zu steigern. | Steigende Betriebskosten und Personalengpässe gefährden das Kundenerlebnis in Ihrem Einzelhandel? Mit autonomen Reinigungs- und Servicerobotern von RoboPlanet senken Sie operative Kosten um bis zu 20% und sichern konstant hohe Sauberkeit sowie innovative Kundenservices. Sprechen Sie uns an, um Ihren Standort zukunftssicher zu machen. #Einzelhandel #RoboPlanet #Automatisierung | Sehr geehrte/r Herr/Frau [Nachname], in Anbetracht der Herausforderungen durch steigende Betriebskosten und Personalengpässe, die täglich in Ihrem Einkaufszentrum oder Großmarkt spürbar sind: Haben Sie bereits über den strategischen Einsatz von Robotik nachgedacht? RoboPlanet unterstützt Sie dabei, operative Kosten um bis zu 20% zu senken und gleichzeitig die Kundenzufriedenheit durch konstant hohe Sauberkeit und innovative Services signifikant zu steigern. Gerne zeigen wir Ihnen in einem kurzen Gespräch, wie sich dies konkret für Ihren Standort umsetzen lässt. | Ihr Weg zu geringeren Kosten und begeisterten Kunden im Einzelhandel. Als Center Manager oder Filialleiter stehen Sie vor der Aufgabe, Effizienz und Kundenerlebnis in Balance zu halten. Entdecken Sie, wie Reinigungs- und Serviceroboter von RoboPlanet Ihre Betriebskosten um bis zu 20% senken und gleichzeitig für eine herausragende Sauberkeit und innovative Kundeninteraktion sorgen. Profitieren Sie von einer messbaren Steigerung der Kundenzufriedenheit. Erfahren Sie mehr über unsere maßgeschneiderten Robotiklösungen. |
|
||||
| Einzelhandel & Einkaufszentren | Facility Manager (Einkaufszentrum / Großer Einzelhandel) (Hypothese) | Die nahtlose Integration und der reibungslose Betrieb autonomer Robotik in Ihrem Einkaufszentrum stellen Sie als Facility Manager vor technische und organisatorische Herausforderungen, die Ausfallzeiten und unvorhergesehene Kosten verursachen können. Mit einem erfahrenen Partner an Ihrer Seite lassen sich diese Risiken minimieren. RoboPlanet bietet Ihnen nicht nur leistungsstarke Reinigungs- und Lieferroboter, sondern auch einen durchdachten 360°-Service von der Integration bis zur Wartung, der Ausfallzeiten um 80% reduziert (Hypothese) und Ihre Betriebskosten planbar macht. | Als Facility Manager im Einzelhandel wissen Sie: Technische Komplexität und ungeplante Ausfälle bei Automatisierungslösungen sind kostspielig. RoboPlanet bietet Ihnen eine 360°-Lösung für Reinigungs- und Lieferroboter – von der fachgerechten Integration bis zur vorausschauenden Wartung. Minimieren Sie Ausfallzeiten um 80% (Hypothese) und sichern Sie planbare Betriebskosten. #FacilityManagement #RoboPlanet #Automatisierung | Sehr geehrte/r Herr/Frau [Nachname], die Implementierung und der zuverlässige Betrieb autonomer Systeme in großen Einzelhandelsflächen kann technisch anspruchsvoll sein und birgt Risiken für unplanmäßige Kosten und Ausfallzeiten. RoboPlanet ist Ihr erfahrener Partner für Reinigungs- und Lieferroboter. Unser 360°-Service – von der Analyse über die Integration bis zur Wartung – reduziert Ausfallzeiten um 80% (Hypothese) und sorgt für absolute Kostenklarheit. Erfahren Sie in einem persönlichen Gespräch, wie wir Ihre technischen Herausforderungen meistern können. | Maximale Verfügbarkeit, minimale Sorgen: Robotik für Ihr Facility Management. Die Integration und der zuverlässige Betrieb von Robotern erfordern Expertise. Als Facility Manager sind Sie für die reibungslose Funktion verantwortlich. RoboPlanet liefert Ihnen nicht nur Reinigungs- und Lieferroboter, sondern einen vollständigen 360°-Service, der Ausfallzeiten um 80% (Hypothese) reduziert und Ihnen volle Kostenkontrolle ermöglicht. Entdecken Sie unsere Lösungen für eine effiziente und planbare Gebäudetechnik. |
|
||||
| Einzelhandel & Einkaufszentren | Leiter Reinigung / Reinigungsdienstleister (im Auftrag des Einzelhandels) (Hypothese) | Als Leiter Reinigung in einem Einzelhandelsunternehmen oder als Dienstleister kämpfen Sie täglich mit Personalengpässen und dem Anspruch, auf stark frequentierten Flächen eine konstant hohe Reinigungsqualität zu sichern, ohne dabei die Kosten aus den Augen zu verlieren. Autonome Reinigungsroboter bieten hier eine leistungsstarke und planbare Lösung. RoboPlanet unterstützt Sie mit intelligenten Reinigungsrobotern und einem umfassenden Service, der Ihr Team entlastet und die Effizienz steigert, wodurch Sie die Personalarbeitslast um bis zu 30% senken (Hypothese) und die Reinigungsqualität nachweislich verbessern. | Personalengpässe und hohe Qualitätsansprüche in der Flächenreinigung im Einzelhandel? RoboPlanet bietet Ihnen die Lösung: Intelligente Reinigungsroboter, die Ihr Team entlasten und die Qualität konstant hochhalten. Reduzieren Sie die Personalarbeitslast um bis zu 30% (Hypothese) und optimieren Sie Ihre Reinigungsprozesse. Lassen Sie uns über Ihre Herausforderungen sprechen! #Reinigungsmanagement #RoboPlanet #Gebäudereinigung | Sehr geehrte/r Herr/Frau [Nachname], die Sicherstellung einer makellosen Sauberkeit in stark frequentierten Einzelhandelsflächen ist bei Personalengpässen eine echte Herausforderung, die die Qualität beeinträchtigen und Kosten in die Höhe treiben kann. RoboPlanet bietet Ihnen bewährte Reinigungsroboter und einen umfassenden Service, der Ihre Personalarbeitslast um bis zu 30% senkt (Hypothese) und die Reinigungsqualität messbar verbessert. Erfahren Sie in einem unverbindlichen Gespräch, wie wir Ihre Reinigungsstrategie optimieren können. | Ihre Lösung gegen Personalengpässe und für makellose Sauberkeit. Als Leiter Reinigung oder Dienstleister im Einzelhandel wissen Sie, wie wichtig eine effiziente und qualitativ hochwertige Flächenreinigung ist. Unsere autonomen Reinigungsroboter entlasten Ihr Team spürbar, reduzieren die Personalarbeitslast um bis zu 30% (Hypothese) und gewährleisten eine konstant hohe Reinigungsqualität – auch in Stoßzeiten. Entdecken Sie die Zukunft der Reinigung und optimieren Sie Ihre Betriebsabläufe mit RoboPlanet. |
|
||||
| Einzelhandel & Einkaufszentren | Marketingleiter / Vertriebsleiter (Einkaufszentrum / Großmarkt) (Hypothese) | In der heutigen Wettbewerbslandschaft suchen Sie als Marketingleiter im Einzelhandel nach innovativen Wegen, um Besucher zu begeistern, die Markenwahrnehmung zu stärken und das Einkaufserlebnis zu einem echten Highlight zu machen, während statische Informationspunkte oft ungenutzt bleiben. Interaktive Serviceroboter können Ihre Marketingstrategie revolutionieren. RoboPlanet bietet Ihnen Serviceroboter als smarte, mobile Werbe- und Informationsflächen, die Besucher nicht nur faszinieren, sondern auch die Interaktion um 20-30% steigern (Hypothese) und Ihr Einkaufszentrum als modernen, kundenorientierten Hotspot positionieren. | Möchten Sie Ihr Einkaufszentrum als Innovationsführer positionieren und Besucher aktiv begeistern? Statische Werbung war gestern. Mit den mobilen Servicerobotern von RoboPlanet steigern Sie die Kundeninteraktion um 20-30% (Hypothese) und schaffen ein einzigartiges Markenerlebnis. Lassen Sie uns über Ihre Marketingstrategie der Zukunft sprechen! #Marketing #Einzelhandel #Innovation #RoboPlanet | Sehr geehrte/r Herr/Frau [Nachname], um Ihr Einkaufszentrum im Wettbewerb hervorzuheben und Besucher nachhaltig zu begeistern, sind innovative Marketingansätze unerlässlich. Haben Sie schon einmal über den Einsatz von Servicerobotern als interaktive Werbe- und Informationsflächen nachgedacht? RoboPlanet bietet Ihnen eine Lösung, die die Besucherinteraktion um 20-30% (Hypothese) steigert und Ihr Zentrum als modernen Hotspot für Kunden positioniert. Gerne zeige ich Ihnen in einem kurzen Termin, wie dies Ihre Marketingziele unterstützen kann. | Begeistern Sie Ihre Besucher neu: Interaktives Marketing mit Servicerobotern. Als Marketingleiter sind Sie ständig auf der Suche nach dem nächsten Wow-Faktor. Entdecken Sie, wie Serviceroboter von RoboPlanet Ihr Einkaufszentrum in ein interaktives Erlebnis verwandeln. Steigern Sie die Besucherinteraktion um 20-30% (Hypothese), bieten Sie dynamische Informationen und positionieren Sie Ihre Marke als innovativ und kundenorientiert. Revolutionieren Sie Ihr digitales Marketing am Point-of-Sale. |
|
||||
| Gebäudemanagement & Dienstleistungen | Geschäftsführer / Bereichsleiter (FM-Dienstleister) | Steigende Personalkosten und der Druck, die Reinigungsqualität objektspezifisch zu garantieren, fordern Ihre Margen und Kundenbindung heraus. Stellen Sie sich vor, Ihre Dienstleistungen könnten mit planbarer Effizienz und konsistenter Qualität erbracht werden. Mit den autonomen Reinigungsrobotern und dem 360°-Service von RoboPlanet senken Sie Ihre operativen Personalkosten um 10-25% und steigern die Kundenzufriedenheit nachhaltig. | Als Geschäftsführer im Gebäudemanagement stehen Sie vor der Herausforderung, steigende Personalkosten zu kontrollieren und gleichzeitig eine exzellente, objektspezifische Reinigungsqualität zu gewährleisten. RoboPlanet bietet mit autonomen Reinigungsrobotern und einem umfassenden 360°-Service die Lösung. Optimieren Sie Ihre Betriebsabläufe, senken Sie operative Personalkosten um 10-25% und steigern Sie die Kundenzufriedenheit nachhaltig. | Betreff: Ihre Margen im Gebäudemanagement stärken – 10-25% Personalkosten senken? <br><br>Sehr geehrte/r [Ansprechpartner/in], <br><br>Steigende Personalkosten und die Sicherstellung konsistenter Reinigungsqualität in Ihren Objekten belasten Ihre Profitabilität. Mit autonomen Reinigungsrobotern und dem 360°-Service von RoboPlanet können Sie diese Herausforderungen gezielt angehen. Erfahren Sie, wie Sie Ihre operativen Personalkosten um 10-25% senken und die Kundenzufriedenheit objektiv steigern können. Sind Sie bereit, Ihre Effizienz neu zu definieren? | Ihre Profitabilität im Gebäudemanagement neu definieren: Konsistente Qualität, reduzierte Kosten. <br>Steigende Personalkosten und der Anspruch an objektspezifische Reinigungsqualität stellen Ihr Gebäudemanagement vor enorme Herausforderungen. Mit den fortschrittlichen Reinigungsrobotern und dem durchdachten 360°-Service von RoboPlanet transformieren Sie Ihre Dienstleistungen. Erreichen Sie eine planbare Effizienz und sichern Sie konstant hohe Qualitätsstandards. Senken Sie Ihre operativen Personalkosten signifikant um 10-25% und begeistern Sie Ihre Kunden nachhaltig durch exzellente Sauberkeit. |
|
||||
| Gebäudemanagement & Dienstleistungen | Leiter Objektmanagement / Operativer Leiter (FM-Dienstleister) | Personelle Engpässe und der hohe Aufwand für die manuelle Sicherstellung der Reinigungsqualität über Ihre Objekte hinweg binden wertvolle Ressourcen. Entlasten Sie Ihre Teams spürbar und sichern Sie konstant hohe Reinigungsstandards. RoboPlanet bietet Ihnen autonome Reinigungsroboter und einen umfassenden Integrations- und Betreuungsservice, um Ihre Mitarbeiter zu entlasten und Nachreinigungen um 30-50% in Ihren Objekten zu reduzieren. | Als operativer Leiter im Gebäudemanagement sind Sie mit Personalengpässen und der Notwendigkeit konfrontiert, eine gleichbleibend hohe Reinigungsqualität über mehrere Objekte hinweg zu gewährleisten. Unsere autonomen Reinigungsroboter, kombiniert mit unserem umfassenden Service, entlasten Ihre Teams signifikant. Erzielen Sie eine Reduktion der Arbeitsbelastung um 20-40% und senken Sie Nachreinigungen um 30-50%, um Ihre betriebliche Effizienz zu maximieren. | Betreff: Reinigungsteams entlasten & Qualität steigern – 30-50% weniger Nachreinigungen? <br><br>Sehr geehrte/r [Ansprechpartner/in], <br><br>Mangel an Personal und die Herausforderung, die Reinigungsqualität objektiv zu sichern, belasten Ihre Objektteams. RoboPlanet bietet autonome Reinigungsroboter und einen umfassenden Service, der Ihre Mitarbeiter entlastet. Reduzieren Sie Nachreinigungen um 30-50% und sichern Sie konstant hohe Standards. Möchten Sie erfahren, wie wir Ihre operativen Herausforderungen lösen? | Exzellente Sauberkeit, entlastete Teams: Revolutionieren Sie Ihr Objektmanagement. <br>Personalengpässe und der hohe Anspruch an eine gleichbleibende Reinigungsqualität in all Ihren Objekten fordern Ihr operatives Management. Mit den intelligenten Reinigungsrobotern von RoboPlanet entlasten Sie Ihre Teams spürbar und sichern rund um die Uhr eine makellose Umgebung. Gewinnen Sie 20-40% der Arbeitszeit für höherwertige Aufgaben zurück und reduzieren Sie Nachreinigungen um 30-50%. Für eine neue Ära der Effizienz in Ihrem Gebäudemanagement. |
|
||||
| Gebäudemanagement & Dienstleistungen | Technischer Leiter / Leiter Instandhaltung (FM-Dienstleister) | Die technische Integration und die Gewährleistung der dauerhaften Betriebssicherheit autonomer Systeme über diverse Kundenobjekte hinweg stellen eine komplexe Herausforderung dar. Sichern Sie eine reibungslose Implementierung und maximale Verfügbarkeit Ihrer Robotik. RoboPlanet bietet fachgerechte Integration und ein bundesweites Servicenetzwerk, um die Implementierungszeit um 20-30% zu verkürzen und Ausfallzeiten um 80-90% zu minimieren. | Als Technischer Leiter im Gebäudemanagement ist die reibungslose Integration und der störungsfreie Betrieb neuer Robotik-Systeme entscheidend für den Erfolg Ihrer Projekte. RoboPlanet unterstützt Sie mit fachgerechter Installation und einem bundesweiten Servicenetzwerk. Minimieren Sie Implementierungsrisiken, verkürzen Sie die Integrationszeit um 20-30% und reduzieren Sie Ausfallzeiten um 80-90% durch unseren proaktiven Support und feste SLAs. | Betreff: Roboter-Integration & Verfügbarkeit – 80-90% weniger Ausfallzeit? <br><br>Sehr geehrte/r [Ansprechpartner/in], <br><br>Die technische Integration autonomer Systeme und die Sicherstellung ihrer konstanten Verfügbarkeit in Ihren Kundenobjekten sind komplex. RoboPlanet bietet Ihnen Expertenunterstützung für Integration und Wartung. Verkürzen Sie Ihre Implementierungszeit um 20-30% und reduzieren Sie Ausfallzeiten um 80-90%. Lassen Sie uns über Ihre technischen Herausforderungen sprechen. | Maximale Systemverfügbarkeit: Professionelle Integration & Instandhaltung für Ihre Robotik. <br>Als Technischer Leiter wissen Sie: Die nahtlose Integration und der zuverlässige Betrieb autonomer Systeme in unterschiedlichsten Gebäudestrukturen sind eine immense technische Herausforderung. RoboPlanet steht Ihnen als erfahrener Partner zur Seite. Wir garantieren fachgerechte Implementierung und minimieren dank unseres bundesweiten Servicenetzwerks Ausfallzeiten um bis zu 80-90%. Planbare Wartung und transparente SLAs sichern Ihre Betriebsbereitschaft und reduzieren unerwartete Kosten um 10-20%. |
|
||||
| Gebäudemanagement & Dienstleistungen | Einkaufsleiter / Strategischer Beschaffungsmanager (FM-Dienstleister) | Die Evaluierung und strategische Beschaffung neuer Automatisierungslösungen für Ihr Dienstleistungsportfolio erfordert eine belastbare Entscheidungsgrundlage und transparente Kostenstrukturen. Treffen Sie fundierte Entscheidungen für skalierbare Robotik, die Ihre Wettbewerbsfähigkeit stärkt. RoboPlanet liefert Ihnen nicht nur passgenaue Roboterlösungen, sondern auch eine umfassende Bedarfsanalyse und Wirtschaftlichkeitsbelegung, um eine transparente TCO-Betrachtung und 10-20% Reduktion unerwarteter Wartungskosten zu sichern. | Als Einkaufsleiter sind Sie für die strategische Beschaffung von Technologien verantwortlich, die die Effizienz und Wettbewerbsfähigkeit Ihres Gebäudemanagement-Unternehmens steigern. RoboPlanet bietet Ihnen eine umfassende Bedarfsanalyse und Wirtschaftlichkeitsbelegung für Robotik-Lösungen. Treffen Sie datenbasierte Entscheidungen, sichern Sie eine transparente TCO und reduzieren Sie unerwartete Wartungskosten um 10-20% durch unsere festen Service Level Agreements. | Betreff: Strategischer Einkauf: Transparente TCO für Ihre Robotik-Investition <br><br>Sehr geehrte/r [Ansprechpartner/in], <br><br>Sie suchen nach skalierbaren Automatisierungslösungen, die Ihr Dienstleistungsportfolio stärken und die Kostenstruktur optimieren? RoboPlanet bietet Ihnen eine belastbare Entscheidungsgrundlage inklusive Bedarfsanalyse und Wirtschaftlichkeitsbelegung. Sichern Sie sich eine transparente TCO-Betrachtung und reduzieren Sie unerwartete Wartungskosten um 10-20%. Lassen Sie uns über eine fundierte Investition sprechen. | Strategische Beschaffung im Gebäudemanagement: Smarte Robotik, transparente Kosten, nachhaltiger ROI. <br>Als Einkaufsleiter wissen Sie: Jede Investition in neue Technologien muss sich rechnen und strategisch passen. RoboPlanet unterstützt Sie bei der Evaluierung und Beschaffung von Robotik-Lösungen mit einer umfassenden Bedarfsanalyse und detaillierten Wirtschaftlichkeitsbelegung. Treffen Sie fundierte Entscheidungen für skalierbare Automatisierung, die Ihre Dienstleistungen revolutioniert. Wir garantieren eine transparente TCO-Betrachtung und helfen Ihnen, unerwartete Wartungskosten um 10-20% zu senken – für eine zukunftssichere Investition. |
|
||||
|
||||
---
|
||||
|
||||
## Schritt 7: Customer Journey & Buying Center
|
||||
|
||||
| Phase | Rolle | Funktion (Buying Center) | Zentrale Frage / Beduerfnis | Moeglicher Deal-Breaker | Benoetigtes Asset / Format |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 1. Bewusstsein / Problemfindung | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Champion, Decider (initiator) | Wie können wir steigende Personalkosten und Personalengpässe abfedern, ohne Servicequalität einzubüßen und unsere Wettbewerbsfähigkeit zu erhalten? | Annahme, dass traditionelle Methoden ausreichen; keine strategische Priorität für Innovation; fehlende Budgetverfügbarkeit (Hypothese). | Branchenstudie zu Personalkosten & Fachkräftemangel in der Hotellerie (Hypothese), Management-Whitepaper zu Automatisierungstrends. (URL: https://robo-planet.de/service#service-1) |
|
||||
| 1. Bewusstsein / Problemfindung | Leiter Housekeeping / Hauswirtschaftsleitung | User, Influencer | Wie kann ich mein Team entlasten und trotzdem eine gleichbleibend hohe Reinigungs- und Hygienestandard in allen Bereichen sicherstellen? | Skepsis gegenüber der Praxistauglichkeit von Robotern in der täglichen Routine; Angst vor Jobverlust des Teams (Hypothese). | Kurzvideo über den Einsatz von Reinigungsrobotern im Hotelalltag, Artikel über Personalentlastung durch Robotik. (URL: https://robo-planet.de/roboter/reinigungsroboter/) |
|
||||
| 1. Bewusstsein / Problemfindung | F&B Manager / Restaurantleiter | User, Influencer | Wie können wir unser Servicepersonal effektiver einsetzen, Wartezeiten für Gäste reduzieren und die Servicequalität in Spitzenzeiten aufrechterhalten? | Bedenken hinsichtlich der Interaktion von Robotern mit Gästen; Komplexität der Integration in bestehende Abläufe (Hypothese). | Use Case Beschreibung "Serviceroboter im Restaurantbetrieb", Kurzbericht über positive Gästeresonanz auf Serviceroboter (Hypothese). (URL: https://robo-planet.de/roboter/serviceroboter/) |
|
||||
| 1. Bewusstsein / Problemfindung | Technischer Leiter / Facility Manager (im Hotelkontext) | Evaluator | Welche technischen Lösungen sind auf dem Markt, die unsere operativen Probleme adressieren könnten, und welche sind potenziell integrierbar? | Mangelnde Kenntnis über verfügbare Robotik-Technologien; fehlende interne technische Ressourcen zur Evaluierung (Hypothese). | Überblick über aktuelle Robotik-Technologien für Hotellerie, Whitepaper zu grundlegenden Integrationsanforderungen (Hypothese). (URL: https://robo-planet.de/service#service-3) |
|
||||
| 2. Informationssuche / Recherche | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Influencer, Decider | Welche Robotiklösungen bieten konkrete Vorteile für Kostenreduktion, Effizienz und Qualitätssteigerung in unserem Geschäftsmodell? | Mangelnde Übersicht über verschiedene Robotertypen und deren Anwendungsbereiche; unklare Wirtschaftlichkeitsaussichten ohne konkrete Zahlen. | Übersichts-Broschüre "Robotik in der Hotellerie: Chancen und Potenziale", generische ROI-Schätzungen für ähnliche Betriebe. (URL: https://robo-planet.de/roboter/reinigungsroboter/, https://robo-planet.de/roboter/serviceroboter/) |
|
||||
| 2. Informationssuche / Recherche | Technischer Leiter / Facility Manager (im Hotelkontext) | Gatekeeper, Evaluator | Welche technischen Anforderungen stellen Robotiklösungen an unsere bestehende Infrastruktur (WLAN, Aufzüge, Türsysteme, Not-Aus) und welche Anbieter bieten umfassenden technischen Support und Service? | Keine klaren Aussagen zur Systemkompatibilität; mangelnde Informationen zu Installationsaufwand, Netzwerkbedarf und Wartung. | Infoblatt "Technische Voraussetzungen für autonome Robotik", Überblick über Serviceleistungen & bundesweites Supportnetzwerk. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4) |
|
||||
| 2. Informationssuche / Recherche | Leiter Housekeeping / Hauswirtschaftsleitung | Evaluator, User | Welche spezifischen Reinigungsroboter sind für unsere Flächen geeignet, wie funktionieren sie im Detail und sind sie einfach zu bedienen und zu warten? | Bedenken hinsichtlich der Einarbeitung des Personals; Komplexität der Routenplanung und Anpassung an spezifische Reinigungsbereiche. | Detailliertes Produktblatt Reinigungsroboter mit Kernfunktionen & intuitiver Bedienung, Referenzbericht von einem Hotel mit ähnlichen Reinigungsherausforderungen. (URL: https://robo-planet.de/roboter/reinigungsroboter/) |
|
||||
| 2. Informationssuche / Recherche | F&B Manager / Restaurantleiter | Evaluator, User | Wie integrieren sich Serviceroboter in unsere bestehenden Serviceabläufe, welchen direkten Mehrwert bieten sie dem Team und den Gästen, und wie sicher ist der Betrieb im Publikumsbereich? | Zweifel an der Akzeptanz durch Gäste und Personal; Sorge vor Störungen im Serviceablauf oder Kollisionen mit Gästen/Mitarbeitern. | Produktblatt Serviceroboter mit Anwendungsbeispielen und Sicherheitsfeatures (z.B. 3D-Hindernisvermeidung), FAQ zu "Roboter im Gästebereich". (URL: https://robo-planet.de/roboter/serviceroboter/) |
|
||||
| 3. Evaluierung / Anbieterprüfung | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Decider, Influencer | Welcher Anbieter bietet das beste Gesamtpaket aus Technologie, Service und Wirtschaftlichkeit, das langfristig zu unseren strategischen Zielen passt und eine nachhaltige Investition darstellt? | Hohe Total Cost of Ownership (TCO); unklare Amortisationszeiten; fehlende Skalierbarkeit für zukünftige Expansion; mangelndes Vertrauen in den Partner. | Individueller Wirtschaftlichkeitsnachweis / TCO-Berechnung mit detailliertem ROI, Präsentation "Langfristige Partnerschaft & Innovationspotential". (URL: https://robo-planet.de/service#service-1, https://robo-planet.de/service#service-4) |
|
||||
| 3. Evaluierung / Anbieterprüfung | Technischer Leiter / Facility Manager (im Hotelkontext) | Gatekeeper, Evaluator | Sind die Roboterlösungen technisch kompatibel mit unserer komplexen Infrastruktur (Aufzugsintegration, WLAN, Brandschutz- und Zutrittssysteme), welche Schnittstellen gibt es und welche Daten- und IT-Sicherheitsstandards werden erfüllt? | Mangelnde Schnittstellen zu bestehender Gebäudetechnik; unzureichende Antworten zu IT-Sicherheit & Datenschutz; komplexe Implementierung; hohe Anforderungen an die interne IT (Hypothese). | Detaillierte technische Spezifikationen (z.B. API-Dokumentation für Aufzugintegration), Sicherheitsdatenblatt, Referenzen zu ähnlichen komplexen Integrationen. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/roboter/lieferroboter/) |
|
||||
| 3. Evaluierung / Anbieterprüfung | Leiter Housekeeping / Hauswirtschaftsleitung | Evaluator, User | Wie flexibel können die Reinigungsroboter auf spezielle Reinigungsbedarfe (z.B. unerwartete Verschmutzungen, kurzfristige Flächenänderungen) reagieren und wie einfach ist die Anpassung von Routen und Zeitplänen? | Eingeschränkte Flexibilität; komplizierte und zeitaufwändige Programmierbarkeit; keine Echtzeit-Anpassungsmöglichkeiten (Hypothese); hoher Wartungsaufwand (Hypothese). | Live-Demonstration des Roboters in einer Testumgebung, detaillierter Trainingsplan für die Roboterbedienung und Routenprogrammierung, Wartungs- und Reinigungsplan. (URL: https://robo-planet.de/service#service-1, https://robo-planet.de/service#service-3) |
|
||||
| 3. Evaluierung / Anbieterprüfung | F&B Manager / Restaurantleiter | Evaluator, User | Wie wirken Serviceroboter konkret auf unsere Gäste, welche Interaktionsmöglichkeiten bieten sie, und ist ihre Navigation in belebten Restaurant- und Barbereichen sicher, flüssig und diskret? | Negative Gästeerfahrungen in Referenzobjekten (Hypothese); schlechte Navigationsleistung in realer, dynamischer Umgebung; Störung der Atmosphäre. | Vor-Ort-Testphase mit Servicerobotern, Testimonial-Videos von Gästen und Mitarbeitern, Studie zur Gästebindung durch innovative Services (Hypothese). (URL: https://robo-planet.de/service#service-1, https://robo-planet.de/roboter/serviceroboter/) |
|
||||
| 4. Entscheidung / Verhandlung | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Decider | Passt das Gesamtangebot strategisch, finanziell und operativ am besten zu unseren Zielen und ist die Investition nachhaltig, risikoarm und zukunftssicher? | Unzureichende ROI-Prognosen; ungünstige Vertragsbedingungen; mangelndes Vertrauen in den Partner; interne Widerstände. | Finales, maßgeschneidertes Angebot, vollständiger Vertragsentwurf mit klar definierten SLAs und Garantien, Referenzanrufe. (URL: https://robo-planet.de/service#service-4) |
|
||||
| 4. Entscheidung / Verhandlung | Technischer Leiter / Facility Manager (im Hotelkontext) | Influencer, Gatekeeper | Sind alle technischen und supportbezogenen Aspekte (Integration, Wartung, Ersatzteile, Remote-Support) im Vertrag klar geregelt und bieten die SLAs ausreichende Sicherheit und Reaktionszeiten? | Unklare Verantwortlichkeiten bei Störungen; unzureichende Garantien oder Ersatzteilverfügbarkeit; hohe Folgekosten für Wartung und Upgrades (Hypothese). | Detaillierte Service Level Agreements (SLA)-Übersicht, Ersatzteilkatalog & Lieferzeiten, Support-Matrix und Eskalationspfade. (URL: https://robo-planet.de/service#service-4) |
|
||||
| 4. Entscheidung / Verhandlung | Leiter Housekeeping / Hauswirtschaftsleitung | Influencer, User | Werden meine Bedenken (z.B. Personalschulung, Flexibilität im Betrieb, Reinigungschemie) im Vertrag und im Implementierungsplan ausreichend berücksichtigt, und gibt es eine Begleitung in der Startphase? | Fehlende oder unzureichende Zusagen zur Schulung und operativen Begleitung; Bedenken bzgl. Sicherheit des Personals im Umgang mit Robotern. | Detaillierter Implementierungsplan mit umfassender Schulungskomponente, Begleitkonzept für die 2-wöchige Startphase. (URL: https://robo-planet.de/service#service-3) |
|
||||
| 4. Entscheidung / Verhandlung | F&B Manager / Restaurantleiter | Influencer, User | Ist die Integration der Serviceroboter so geplant, dass unser Serviceablauf optimiert und nicht gestört wird, und gibt es genug Unterstützung und Überwachung in der Anfangsphase, um Akzeptanz sicherzustellen? | Sorge vor Störungen des Gästebetriebs während der Einführung; mangelnde Unterstützung bei der Einarbeitung des Personals und der Fehlerbehebung. | Detaillierter Rollout-Plan für F&B-Bereich, Plan für die 2-wöchige Startphase mit Systemüberwachung und Feinjustierung. (URL: https://robo-planet.de/service#service-3) |
|
||||
| 5. Implementierung / Onboarding | Technischer Leiter / Facility Manager (im Hotelkontext) | Project Manager, Gatekeeper | Erfolgt die Installation reibungslos, die Integration in unsere Systeme (z.B. Aufzugssteuerung) fehlerfrei und funktioniert das Monitoring und Remote-Management wie versprochen? | Technische Probleme bei der Installation; Kompatibilitätsprobleme; mangelnde Kommunikation und Transparenz bei der Projektumsetzung; Verzögerungen im Zeitplan. | Projektmanagement-Dashboard mit Statusberichten, Integrationsprotokolle, Zugang zum Monitoring- und Remote-Support-System. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4) |
|
||||
| 5. Implementierung / Onboarding | Leiter Housekeeping / Hauswirtschaftsleitung | User, Influencer | Ist mein Team ausreichend geschult und fühlt es sich sicher und kompetent im Umgang mit den Robotern? Werden die versprochenen Entlastungen und Qualitätsverbesserungen im Alltag spürbar? | Unzureichende Schulung; Akzeptanzprobleme beim Personal; Roboter nicht so hilfreich oder zuverlässig wie erwartet (Hypothese). | Nachweis der Team-Schulungen (Zertifikate), Feedback-Runden mit dem Reinigungsteam, Reports zur Reinigungsleistung und Effizienzsteigerung. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4) |
|
||||
| 5. Implementierung / Onboarding | F&B Manager / Restaurantleiter | User, Influencer | Verbessert sich unser Serviceablauf durch die Roboter tatsächlich und wird unser Personal für höherwertige Aufgaben freigesetzt, um die Gästezufriedenheit zu steigern? | Gäste-/Personalbeschwerden; Roboter stören den Ablauf; kein spürbarer Mehrwert oder sogar negative Auswirkungen auf den Service. | Feedback-Analyse der Gäste- und Personalzufriedenheit, Zeitstudien zur Personalentlastung und Effizienzsteigerung (Hypothese), Reports zur Serviceleistung. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4) |
|
||||
| 5. Implementierung / Onboarding | Direktor / Geschäftsführer (Hotel/Restaurantkette) | Decider (for renewal/expansion) | Werden die versprochenen Effizienzgewinne und die Qualitätssteigerung realisiert und ist die Investition ein Erfolg, der unsere strategischen Ziele unterstützt? | Keine messbaren Erfolge; hohe unvorhergesehene Betriebskosten; negative Auswirkungen auf Image oder Mitarbeiterzufriedenheit. | Regelmäßige Performance-Reports (ROI, Kostenersparnis, Effizienz), Kundenzufriedenheitsberichte, Impact-Analyse auf Mitarbeiterbindung und Gäste-Feedback. (URL: https://robo-planet.de/service#service-3, https://robo-planet.de/service#service-4) |
|
||||
|
||||
---
|
||||
|
||||
375
docs/b2b_marketing_assistant_plan.md
Normal file
375
docs/b2b_marketing_assistant_plan.md
Normal file
@@ -0,0 +1,375 @@
|
||||
# Plan: Umsetzung des "B2B Marketing Assistant" Backends
|
||||
|
||||
Dieses Dokument beschreibt den Plan zur Umsetzung der Backend-Logik für die React-Anwendung unter `/b2b-marketing-assistant` als robusten, faktenbasierten Python-Service. Das primäre Ziel ist es, die Konsistenz und Zuverlässigkeit der Analyseergebnisse durch "Grounding" (Verankerung in realen Daten) signifikant zu erhöhen.
|
||||
|
||||
## 1. Zielsetzung & Architektur
|
||||
|
||||
- **Ziel:** Transformation der reinen Frontend-Anwendung in einen Service mit einem Python-Backend, das vor jeder KI-Analyse eine solide Faktenbasis durch Web-Scraping schafft. Dadurch werden die Ergebnisse reproduzierbar und basieren auf den tatsächlichen Inhalten der Unternehmens-Website.
|
||||
- **Architektur:** Wir replizieren den bewährten Aufbau des "Market Intelligence" Tools:
|
||||
1. **React-Frontend:** Die Benutzeroberfläche in `/b2b-marketing-assistant` bleibt bestehen, wird aber von direkten KI-Aufrufen befreit.
|
||||
2. **Node.js API-Brücke (`server.cjs`):** Ein minimaler Express.js-Server, der Anfragen vom Frontend annimmt und an das Python-Backend weiterleitet.
|
||||
3. **Python-Orchestrator (`b2b_marketing_orchestrator.py`):** Das neue Herzstück, das die gesamte Logik kapselt.
|
||||
|
||||
## 2. Kernprozess mit "Grounding"
|
||||
|
||||
Der 6-stufige Prozess der App wird im Backend abgebildet, wobei die ersten Schritte fundamental geändert werden:
|
||||
|
||||
1. **Schritt 1 (Angebot) & 2 (Zielgruppen):**
|
||||
* **Intelligentes Scraping:** Das Python-Skript crawlt die gegebene URL und sucht aktiv nach Unterseiten wie "Produkte", "Lösungen", "Branchen" etc.
|
||||
* **Text-Extraktion:** Der relevante Inhalt dieser Seiten wird extrahiert und zu einem "Grounding-Dokument" zusammengefasst.
|
||||
* **KI als Extraktions-Engine:** Die KI wird angewiesen, **ausschließlich auf Basis dieses extrahierten Textes** das Angebot und die Zielgruppen zu identifizieren und zu strukturieren. Halluzinationen werden so unterbunden.
|
||||
|
||||
2. **Schritt 3-6 (Personas, Pains, Gains, Messages):**
|
||||
* Diese Schritte bauen auf den validierten, faktenbasierten Ergebnissen aus Schritt 1 & 2 auf. Die gesamte Logikkette wird dadurch stabiler und konsistenter.
|
||||
|
||||
3. **Schritt 7 (Customer Journey & Buying Center):**
|
||||
* **NEU:** Als finaler Schritt wird die hypothetische Kaufentscheidung simuliert.
|
||||
* **Fokus:** Analyse der "Journey" vom ersten Touchpoint bis zum Vertragsabschluss.
|
||||
* **Kernfragen:**
|
||||
* Wie sieht der Entscheidungsprozess aus? (Spontan vs. Gremium)
|
||||
* Welche Stationen durchläuft der Käufer?
|
||||
* Wie sehen typische Verträge aus (Laufzeit, Lock-in)?
|
||||
* Welche spezifischen Fragen stellen sich die unterschiedlichen Entscheider (Buying Center) in den verschiedenen Phasen?
|
||||
* **Ziel:** Tiefe Einblicke in das Käuferverhalten, spezifisch getrimmt auf das ermittelte Produkt (SaaS vs. Hardware), unter Einbeziehung der Pains & Gains.
|
||||
|
||||
## 3. Strategische Vision: Integration der Tools
|
||||
|
||||
Dieses Projekt ist der erste Schritt zur Schaffung eines einheitlichen "Strategy & Audit"-Workflows.
|
||||
|
||||
- **Phase 1 (Aktuelles Projekt):** Wir bauen den "B2B Marketing Assistant" als eigenständigen Service mit einem modularen Python-Backend.
|
||||
- **Phase 2 (Zukünftig):** Die wiederverwendbaren Python-Module (Scraping, API-Handler etc.) werden mit dem `market_intel_orchestrator.py` zu einem einzigen, leistungsfähigen Backend verschmolzen. Der Workflow wäre dann nahtlos:
|
||||
1. **Strategie definieren:** Mit dem B2B Marketing Assistant eine Tiefenanalyse eines Referenzkunden durchführen.
|
||||
2. **Markt auditieren:** Die erstellte Strategie direkt nutzen, um Lookalikes zu finden und zu bewerten.
|
||||
|
||||
## 4. Fortschritts-Log
|
||||
|
||||
### Phase 1: Initialisierung & Planung
|
||||
|
||||
- [x] Anforderungsanalyse und Zieldefinition (Grounding, Konsistenz).
|
||||
|
||||
- [x] Architektur nach Vorbild `market-intel-backend` festgelegt.
|
||||
|
||||
- [x] Diesen Schlachtplan in `b2b_marketing_assistant_plan.md` erstellt.
|
||||
|
||||
- [x] Aufbau der Grundstruktur: Erstellen der `b2b_marketing_orchestrator.py`, der `server.cjs` in `/b2b-marketing-assistant` und des `Dockerfile`.
|
||||
|
||||
- [x] Erstellung von `package.json` und `requirements.txt`.
|
||||
|
||||
- [x] Anpassung des Frontends (`App.tsx`) für die Kommunikation mit dem neuen Backend.
|
||||
|
||||
- [x] Entfernen von Frontend-Dateien und -Inhalten, die nicht mehr benötigt werden (`parser.ts`, Prompts aus `constants.ts`).
|
||||
|
||||
- [x] Implementierung der `start_generation`-Logik im Python-Backend (Scraping, Grounding, initialer Gemini-Aufruf für Schritt 1).
|
||||
|
||||
- [x] Implementierung der `next_step`-Logik im Python-Backend (mehrstufige Gemini-Aufrufe für Schritte 2-6, Kontext-Management).
|
||||
|
||||
- [x] Fehlerbehebung: Alle Python-Syntaxfehler (Encoding, Strings) behoben.
|
||||
|
||||
- [x] Validierung: Das Tool lädt das Frontend und führt das Web-Scraping erfolgreich durch.
|
||||
|
||||
- [x] **API-Fix:** Umstellung auf Gemini v1 API und Modell `gemini-2.5-flash` (1M Token Context).
|
||||
|
||||
|
||||
|
||||
### Phase 2: Validierung & Optimierung (Abgeschlossen)
|
||||
|
||||
- [x] Docker-Container gebaut und gestartet.
|
||||
|
||||
- [x] Zugriff auf die UI über Port 3004 erfolgreich.
|
||||
|
||||
- [x] **Grounding Upgrade:** Umstellung von Plain-Text auf "Sanitized HTML" (H1-H6, Links erhalten) für präzise Produkterkennung.
|
||||
|
||||
- [x] **Kontext-Erweiterung:** Entfernung des 30.000 Zeichen Limits für vollständige Website-Analyse.
|
||||
|
||||
- [x] **Robustheit:** Implementierung von Retry-Logik (Exponential Backoff) und Timeout-Erhöhung (600s) für komplexe Analysen.
|
||||
|
||||
- [x] **Frontend Fixes:**
|
||||
|
||||
- [x] Robuster "Copy Table" Button (Fallback für Non-HTTPS).
|
||||
|
||||
- [x] PDF-Export optimiert (Landscape, keine Scrollbalken).
|
||||
|
||||
- [x] "Schritt 6 Wiederholen"-Funktion eingebaut.
|
||||
|
||||
- [x] **Prozess-Optimierung:** Schritt 6 fokussiert nun automatisch auf die Top-Branche, um Token-Limits und Lesezeit zu optimieren.
|
||||
|
||||
- [x] **Logging:** Detailliertes File-Logging (`Log_from_docker`) für Prompts und Antworten implementiert.
|
||||
|
||||
|
||||
|
||||
## 5. Deployment & Betrieb (Konsolidierte Architektur)
|
||||
|
||||
Die Anwendung ist nun vollständig in die zentrale Docker-Compose-Architektur des Projekts integriert. Das separate Bauen und Starten einzelner Container ist nicht mehr notwendig.
|
||||
|
||||
### Zentraler Start via Docker Compose
|
||||
|
||||
Der gesamte Anwendungs-Stack (Proxy, Dashboard, B2B Assistant, Market Intelligence) wird über die `docker-compose.yml`-Datei im Hauptverzeichnis des Projekts verwaltet und gestartet.
|
||||
|
||||
1. **Navigieren Sie in das Projekt-Hauptverzeichnis.**
|
||||
2. **Starten Sie alle Dienste:**
|
||||
```bash
|
||||
docker-compose up -d --build
|
||||
```
|
||||
Der `--build`-Parameter sorgt dafür, dass alle Docker-Images neu erstellt werden. Dies ist bei Änderungen am Frontend (`App.tsx`), an den `Dockerfile`n oder den `requirements.txt`/`package.json` notwendig.
|
||||
|
||||
### Zugriff
|
||||
|
||||
- Das zentrale Dashboard ist unter `http://<Server-IP>:8090` erreichbar.
|
||||
- Der **B2B Marketing Assistant** ist direkt über das Unterverzeichnis `http://<Server-IP>:8090/b2b/` zugänglich.
|
||||
- Der Zugang ist durch Basic Authentication geschützt (Benutzer: `admin`, Passwort: `gemini`).
|
||||
|
||||
### Entwicklung (Sideloading)
|
||||
|
||||
Für eine schnelle Entwicklung ist "Sideloading" für die Python-Logik aktiviert. Das bedeutet, die `b2b_marketing_orchestrator.py` wird als Volume in den Container gemountet.
|
||||
|
||||
- **Nach Änderungen am Python-Skript:** Ein einfacher Neustart des Containers genügt, um die Änderungen zu übernehmen. Ein kompletter Rebuild ist nicht erforderlich.
|
||||
```bash
|
||||
docker-compose restart b2b-app
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 6. Roadmap: Nächste Erweiterungen
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Priorität 1: Integration der SQLite-Datenbank (Portierung) [ABGESCHLOSSEN]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* **Status:** Erfolgreich implementiert. Der B2B Assistant nutzt nun die gleiche robuste Persistenzschicht wie das Market Intelligence Tool.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* **Backend:** Die Datenbankintegration erfolgt über das Modul `market_db_manager.py`, das für die Verwaltung der SQLite-Datenbank `b2b_projects.db` zuständig ist. Der Datenbankpfad wird über `DB_PATH` isoliert.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* **API:** Die entsprechenden Datenbank-Routen sind in `server.cjs` aktiviert, um die Kommunikation zwischen Frontend und Backend zu ermöglichen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* **Frontend:** Auto-Save-Funktionen und ein History-Modal wurden in `App.tsx` integriert, um die Persistenz der Projektdaten zu gewährleisten und den Zugriff auf frühere Versionen zu ermöglichen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Priorität 2: Customer Journey (Schritt 7) [ABGESCHLOSSEN]
|
||||
|
||||
* **Status:** Erfolgreich implementiert.
|
||||
* **Funktion:** Tiefe Analyse der Kaufentscheidung mit Fokus auf Buying Center Dynamik.
|
||||
* **Mehrwert:** Liefert konkrete "Deal-Breaker" und definiert benötigte Assets (Munition) für jede Phase.
|
||||
* **UI:** Tabellarische Darstellung mit neuer "Schritt neu starten"-Funktion für iterative Optimierung.
|
||||
|
||||
### Priorität 3: Asset Factory (Schritt 8)
|
||||
|
||||
* **UI:** Neuer Bereich "Assets generieren" nach Abschluss von Schritt 7.
|
||||
* **Funktion:** Auswahl einer Persona und eines Formats (z.B. "LinkedIn Vernetzungsanfrage", "Cold Mail Sequenz").
|
||||
* **Input:** Nutzt die in Schritt 7 definierten "Benötigten Assets" als Blaupause.
|
||||
* **Output:** Generierung von Copy-Paste-fertigen Texten basierend auf den Painpoints/Gains der Analyse.
|
||||
* **Export:** Als separater "Marketing Kit" Download oder Anhang im Markdown.
|
||||
|
||||
### Priorität 4: Erweiterung des Finalen Reports [ABGESCHLOSSEN]
|
||||
|
||||
* **Status:** Vollständig in den Workflow integriert.
|
||||
* **Search Strategy Beschreibung ICP:** Detaillierte Profile werden generiert.
|
||||
* **Digital Signals:** Konkrete Signale (Technographic, Growth, Strategy) identifiziert.
|
||||
* **Target Pages:** Relevante URLs für die Akquise im Report gelistet.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Status: Produktionsbereit (Version 2.2)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Das System ist nun hochgradig robust und bietet volle Transparenz sowie Persistenz.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- [x] Grounding (HTML-Parsing) & Gemini 2.5 Flash / Pro
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- [x] Robustheit (Nginx Timeouts 600s, Scraping Fallback "Digital Footprint Mode")
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- [x] Persistenz (SQLite DB für alle Projekte)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- [x] UI-Optimierung (History Modal, On-Demand Outreach Generation)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- [x] Logging (Detailliertes Trace-Logging im Container)
|
||||
|
||||
|
||||
|
||||
|
||||
82
docs/duckdns_setup.md
Normal file
82
docs/duckdns_setup.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# DuckDNS & DNS Monitor Setup
|
||||
|
||||
**Erstellt am:** 05.01.2026
|
||||
**Zuletzt aktualisiert:** 06.01.2026
|
||||
**Status:** Aktiv
|
||||
**Architektur:** Sidecar-Pattern
|
||||
|
||||
Dieses Dokument beschreibt die Docker-basierte Lösung zur DynDNS-Aktualisierung und Überwachung sowie die kritischen Netzwerkeinstellungen auf der Synology Diskstation und der FritzBox.
|
||||
|
||||
## Problembeschreibung
|
||||
Das System litt unter massiven DNS-Problemen:
|
||||
1. **"IP Flapping":** Die IP sprang ständig zwischen der aktuellen (`.252`) und der gestrigen (`.49`). Ursache war **aggressives Caching** der alten IP durch Google DNS (`8.8.8.8`) und falsche DNS-Einstellungen in der Synology, die diesen Cache abfragten.
|
||||
2. **Interne Unerreichbarkeit:** Dienste waren im LAN nicht erreichbar (NAT Loopback Problem).
|
||||
3. **Synology DNS-Chaos:** Die Synology nutzte veraltete DNS-Server (`8.8.8.8`) fest in der Netzwerkschnittstelle.
|
||||
|
||||
## Lösung
|
||||
Wir haben eine robuste **Zwei-Container-Lösung** implementiert und das gesamte Netzwerk-Environment gehärtet.
|
||||
|
||||
### 1. Docker Services (`docker-compose.yml`)
|
||||
|
||||
* **Updater (`duckdns`):** Aktualisiert zuverlässig die IP bei DuckDNS. Wir nutzen einen **neuen Token**, um alle alten Updater auszusperren.
|
||||
* **Monitor (`dns-monitor`):** Überwacht alle 5 Minuten die DNS-Auflösung via Cloudflare (`1.1.1.1`).
|
||||
|
||||
## Kritische Peripherie-Konfiguration (MUSS GEPRÜFT WERDEN!)
|
||||
|
||||
### 1. Synology DSM Netzwerkeinstellungen (Die "versteckte Falle")
|
||||
Die Synology kann DNS-Server an zwei Orten haben. Die Schnittstellen-Einstellung überschreibt die allgemeine Einstellung!
|
||||
|
||||
* **Ort 1 (Allgemein):** Systemsteuerung -> Netzwerk -> Allgemein -> "DNS-Server manuell konfigurieren".
|
||||
* **Ort 2 (Schnittstelle - WICHTIG):** Systemsteuerung -> Netzwerk -> Netzwerk-Schnittstelle -> LAN 1 -> Bearbeiten -> IPv4.
|
||||
* **Fehler:** Hier war manuell `8.8.8.8` eingetragen.
|
||||
* **Korrektur:** Auf "Automatisch abrufen" oder manuell auf `1.1.1.1` (Cloudflare) stellen.
|
||||
|
||||
### 2. FritzBox (Router)
|
||||
* **DNS-Server:** Internet -> Zugangsdaten -> DNS-Server auf Cloudflare (`1.1.1.1`, `1.0.0.1`) stellen.
|
||||
* **DNS-Rebind-Schutz:** Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> "DNS-Rebind-Schutz". Alle Subdomains eintragen (`floke.duckdns.org` etc.).
|
||||
|
||||
### 3. Hardware / DSL-Leitung (Physische Ursache für Timeouts)
|
||||
Die FritzBox-Logs zeigen wiederkehrende DSL-Sync-Probleme und den Fehler:
|
||||
> *"An der DSL-Leitung wurde eine Beeinträchtigung des Signals durch eine unzulässige Verkabelung erkannt. [...] Die Abzweigung ist 17 Meter lang."*
|
||||
|
||||
Dies deutet auf eine **Stichleitung/Parallelschaltung** in der Hausverkabelung hin. Dies verursacht Signalreflexionen, Paketverluste und Timeouts (`NETWORK_WAIT` im Monitor).
|
||||
**Empfehlung:** Hausverkabelung prüfen (lassen) und ungenutzte Telefondosen abklemmen.
|
||||
|
||||
## Logs & Monitoring
|
||||
|
||||
### DNS-Konsistenz prüfen
|
||||
```bash
|
||||
docker logs dns-monitor
|
||||
```
|
||||
|
||||
**Szenario OK:**
|
||||
```text
|
||||
[TIMESTAMP] [OK] Pub: 87.x.x.x | CF: 87.x.x.x | Loc: 87.x.x.x
|
||||
```
|
||||
|
||||
**Szenario NETWORK_WAIT (Leitungsfehler):**
|
||||
```text
|
||||
[TIMESTAMP] [NETWORK_WAIT] Pub: 87.x.x.x | CF: Unresolved | ...
|
||||
```
|
||||
Häufig verursacht durch DSL-Resyncs oder Paketverlust wegen der Stichleitung.
|
||||
|
||||
## Aktueller Status (06.01.2026)
|
||||
|
||||
Basierend auf den Logs des `dns-monitor` (Stand 20:34 Uhr) ergibt sich folgendes Bild:
|
||||
|
||||
### 1. Analyse der Log-Phasen
|
||||
* **Vormittag/Nachmittag:** Sporadische `[ALERT]`-Meldungen. Die IP bei DuckDNS sprang kurzzeitig auf die veraltete Endung `.49` zurück, stabilisierte sich aber meist nach 5-10 Minuten wieder auf `.252`.
|
||||
* **Kritische Phase (19:38 - 19:54 Uhr):** Ein 20-minütiger anhaltender Alert. Cloudflare (`CF`) lieferte hartnäckig die alte IP `.49`, obwohl die öffentliche IP (`Pub`) bereits `.252` war. Dies deutet auf eine verzögerte TTL-Aktualisierung oder einen "Zombie-Updater" im Netzwerk hin, der kurzzeitig erfolgreich war.
|
||||
* **Stabilisierung (seit 19:59 Uhr):** Das System ist seit über 30 Minuten durchgehend im Status `[OK]`. Sowohl Cloudflare als auch die lokale Auflösung zeigen stabil auf die `.252`.
|
||||
|
||||
### 2. Erkenntnisse
|
||||
* **Netzwerk-Instabilität:** Die `[NETWORK_WAIT]` Einträge korrelieren mit den DSL-Sync-Problemen der FritzBox. In diesen Momenten ist keine DNS-Abfrage möglich (Paketverlust).
|
||||
* **Local Cache Lag:** Die Spalte `Loc` (Lokale Auflösung) zeigt oft noch `Unresolved` oder die alte IP, wenn Cloudflare bereits korrekt ist. Dies bestätigt, dass der interne DNS-Cache der Synology/Docker-Umgebung deutlich träger reagiert als externe Server.
|
||||
|
||||
### 3. Empfehlung
|
||||
* **Beobachtung:** Da die Stabilisierung seit 19:59 Uhr anhält, scheint der neue DuckDNS-Token nun die Oberhand gewonnen zu haben.
|
||||
* **Hardware:** Die physische DSL-Beeinträchtigung (Stichleitung 17m) bleibt das primäre Risiko für die `NETWORK_WAIT` Timeouts.
|
||||
|
||||
## Dateien
|
||||
- `/app/docker-compose.yml`: Definition der Services.
|
||||
- `/app/dns-monitor/monitor.sh`: Das Shell-Skript für den Monitor-Container.
|
||||
176
docs/gtm_architect_documentation.md
Normal file
176
docs/gtm_architect_documentation.md
Normal file
@@ -0,0 +1,176 @@
|
||||
# Dokumentation: GTM Architect Engine (v3.1)
|
||||
|
||||
## 1. Projektübersicht
|
||||
|
||||
Der **GTM Architect** ("Go-to-Market Architect") ist ein KI-gestütztes System zur Entwicklung umfassender Marktstrategien für neue technische Produkte (Schwerpunkt: Robotik & Facility Management).
|
||||
|
||||
Das System führt den Nutzer durch einen **9-stufigen Prozess** – von der technischen Analyse über Business-Case-Modellierung bis hin zu fertigen Vertriebsunterlagen und Landingpages.
|
||||
|
||||
**Aktuelle Version:** v3.1 ("Closing-Ready Edition") - Stand: 20.01.2026
|
||||
|
||||
## 2. Architektur & Tech-Stack
|
||||
|
||||
Das System ist als Microservice in die bestehende Docker-Umgebung integriert (`gtm-app`).
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
User[Browser] -- HTTP/JSON --> Proxy[Nginx :8090]
|
||||
Proxy -- /gtm/ --> NodeJS[Node.js Server :3005]
|
||||
NodeJS -- Spawn Process --> Python[Python Orchestrator]
|
||||
Python -- import --> Helpers[Core Engine (helpers.py)]
|
||||
Helpers -- Dual SDK --> Gemini[Google Gemini 2.0 Flash (Text)]
|
||||
Helpers -- Dual SDK --> Imagen[Google Imagen 4.0 (Text-to-Image)]
|
||||
Helpers -- Dual SDK --> GeminiImg[Google Gemini 2.5 Flash (Image-to-Image)]
|
||||
Python -- SQL --> DB[(SQLite: gtm_projects.db)]
|
||||
```
|
||||
|
||||
### Komponenten
|
||||
|
||||
1. **Frontend (`/gtm-architect`):**
|
||||
* Framework: **React** (Vite + TypeScript).
|
||||
* Features: **Session History**, **Hard Fact Extraction UI** und **Markdown Upload**.
|
||||
|
||||
2. **Backend Bridge (`server.cjs`):**
|
||||
* Runtime: **Node.js** (Express).
|
||||
* Funktion: Nimmt HTTP-Requests entgegen und startet Python-Prozesse (`gtm_architect_orchestrator.py`).
|
||||
|
||||
3. **Logic Core (`gtm_architect_orchestrator.py`):**
|
||||
* Runtime: **Python 3.11+**.
|
||||
* Verantwortlichkeit: Steuert den 9-Phasen-Prozess, verwaltet Payloads und interagiert mit der Datenbank. Nutzt `helpers.py` für alle KI-Interaktionen.
|
||||
|
||||
4. **Core Engine (`helpers.py`):**
|
||||
* Laufzeit: **Python 3.11+**.
|
||||
* Verantwortlichkeit: Abstrahiert die Komplexität der KI-API-Aufrufe. Stellt robuste, wiederverwendbare Funktionen für Text- und Bildgenerierung bereit.
|
||||
|
||||
5. **Persistenz (`gtm_projects.db`):**
|
||||
* Typ: **SQLite**. Speichert alle Phasen-Ergebnisse als JSON-Blobs in einer einzigen Tabelle.
|
||||
|
||||
## 3. Kernfunktionalität: Die AI Engine (`helpers.py`)
|
||||
|
||||
Das Herzstück des Systems ist die `helpers.py`-Bibliothek, die für Stabilität und Zukunftssicherheit konzipiert wurde.
|
||||
|
||||
### 3.1 Dual SDK Support
|
||||
|
||||
Um maximale Stabilität zu gewährleisten und gleichzeitig Zugriff auf die neuesten KI-Modelle zu haben, wird ein dualer Ansatz für die Google AI SDKs verfolgt:
|
||||
* **`google-generativeai` (Legacy):** Wird bevorzugt für Text-Generierungs-Aufgaben (`gemini-2.0-flash`) verwendet, da es sich in diesem Setup als robuster erwiesen hat.
|
||||
* **`google-genai` (Modern):** Wird für alle Bild-Generierungs-Aufgaben und als Fallback für die Text-Generierung genutzt.
|
||||
|
||||
### 3.2 Hybride Bildgenerierung
|
||||
|
||||
Die `call_gemini_image`-Funktion wählt automatisch die beste Methode basierend auf dem Input:
|
||||
* **Szenario A: Text-to-Image (Kein Referenzbild)**
|
||||
* **Modell:** `imagen-4.0-generate-001`.
|
||||
* **Anwendung:** Generiert ein komplett neues Bild basierend auf einem textuellen Prompt (z.B. für Landingpage-Banner).
|
||||
* **Szenario B: Image-to-Image (Mit Referenzbild)**
|
||||
* **Modell:** `gemini-2.5-flash-image`.
|
||||
* **Anwendung:** Platziert ein existierendes Produkt (via Upload) in eine neue, per Text beschriebene Szene. Der Prompt ist darauf optimiert, das Produktdesign nicht zu verändern.
|
||||
|
||||
## 4. Der 9-Phasen Prozess (v3.1 Logik)
|
||||
|
||||
| Phase | Modus | Input | Output | V3.1 Update |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **1** | `phase1` | Rohtext / URL | Features, Constraints, **Category** | Autonome Erkennung der Wackler-Kategorie (z.B. Cleaning Indoor Carpet). |
|
||||
| **2** | `phase2` | Phase 1 Result | ICPs, Data Proxies | Identifiziert ideale Kundenprofile basierend auf Kategorie. |
|
||||
| **3** | `phase3` | Phase 2 Result | Whales, **Archetypes** | Identifiziert 4 strategische Archetypen (Operativ, Infrastruktur, Eco, Innovation). |
|
||||
| **4** | `phase4` | Phase 1 & 3 | Strategy Matrix | Wendet "Service Gap" Logik an (Machine vs. Human Service). |
|
||||
| **5** | `phase5` | Alle Daten | **Senior Report** | Erstellt "Closing-Ready" Report mit Datasheet-Specs & ROI-Range. |
|
||||
| **6** | `phase6` | Phase 1, 3, 4 | Battlecards, Prompts | **Legal/Liability** Fokus für Infrastruktur-Persona. |
|
||||
| **7** | `phase7` | Phase 2, 4 | Landing Page Copy | Erstellt Landingpage-Texte mit Wackler-Symbiose. |
|
||||
| **8** | `phase8` | Phase 1, 2 | **ROI Framework** | Generiert ROI-Formel mit **Example Ranges** (kein "undefined"). |
|
||||
| **9** | `phase9` | Phase 1, 4 | Feature-to-Value | Übersetzung technischer Features in Nutzen. |
|
||||
|
||||
## 5. Changelog & Version History
|
||||
|
||||
* **[MAJOR] v3.1: "Closing-Ready" Edition (Jan 20, 2026)**
|
||||
* **ROI-Fix:** Phase 8 generiert nun plausible **Wertebereiche** (z.B. "20-30% Reduktion") statt abstrakter Formeln, die zu `undefined` führten.
|
||||
* **Legal-Härtung:** Phase 6 Battlecards adressieren gezielt **Haftung, DSGVO & DGUV V3** für die "Infrastruktur"-Persona.
|
||||
* **Technical Depth:** Phase 5 Report fordert nun explizit **alle** technischen Specs (auch Layer-Daten) für eine "Datasheet"-Qualität.
|
||||
* **Stabilität:** Implementierung von `isinstance(list)` Checks in Phasen 6, 7, 8, um "White Screen of Death" durch Listen-Antworten zu verhindern.
|
||||
|
||||
* **[MAJOR] v3.0: "Dynamic Service Logic" (Jan 20, 2026)**
|
||||
* Einführung der **7 Wackler-Kategorien** (Cleaning Indoor/Outdoor, POS, Security, Service, Transport).
|
||||
* Implementierung der universellen "Machine Layer vs. Human Service Layer" Logik im System-Prompt.
|
||||
* Konsolidierung auf **4 Buying Center Archetypen**.
|
||||
|
||||
* **[UPGRADE] v2.6.2:** Editierbare Hard Facts & Report Completeness.
|
||||
* **[UPGRADE] v2.6:** Rich Session Browser & Metadaten-Persistenz.
|
||||
|
||||
## 6. GTM Architect V3.1 Prompts (Reference)
|
||||
|
||||
Dies ist die Referenz der kritischen Prompts, die die "Senior Grade" Qualität der Engine steuern.
|
||||
|
||||
### 6.1. System Prompt (Universal Service Logic)
|
||||
Definiert die "Denkweise" der KI. Erkennt autonom die Kategorie und wendet die passende Hybrid-Logik an.
|
||||
|
||||
```python
|
||||
def get_system_instruction(lang):
|
||||
return """
|
||||
# RULE 5: THE "DYNAMIC SERVICE" LOGIC (UNIVERSAL)
|
||||
First analyze the **category** of the robot and then apply the appropriate hybrid logic:
|
||||
|
||||
1. CLEANING INDOOR (CARPET) - Vacuums for carpets
|
||||
* Robot: Does the area (80%).
|
||||
* Human (Wackler Cleaning): Does edges, corners, spot removal (20%).
|
||||
|
||||
2. CLEANING INDOOR (WET SURFACE) - Scrubber dryers (Hard floor)
|
||||
* Robot: Cleans halls/corridors continuously.
|
||||
* Human (Wackler Cleaning): Safety check (slip hazard), water change, hygiene audit.
|
||||
|
||||
5. SECURITY ROBOT - Mobile Surveillance (Quadruped/Drone)
|
||||
* Robot: "Detection & Presence". 24/7 patrol, thermal imaging, no fatigue.
|
||||
* Human (Wackler Security): "Evaluation & Intervention". NSL evaluates alarm, intervention force drives out.
|
||||
* Pitch: "The robot sees the danger, Wackler eliminates it."
|
||||
|
||||
[...weitere Kategorien...]
|
||||
Mandatory application of this logic in PHASE 4 (Strategy) and PHASE 6 (Sales Enablement).
|
||||
"""
|
||||
```
|
||||
|
||||
### 6.2. Phase 5 Prompt (Senior Report Generation)
|
||||
Erzwingt ausführliche, gut formatierte Reports und verhindert "dünnen" Content.
|
||||
|
||||
```python
|
||||
report_sys_instr = """
|
||||
You are a Senior Business Consultant at a top-tier firm (like McKinsey or BCG).
|
||||
Your task is to write a strategically deep, detailed "Go-to-Market Strategy Report".
|
||||
|
||||
RULES:
|
||||
1. **No JSON:** Your output is pure, cleanly formatted Markdown.
|
||||
2. **Senior Grade:** Do not write "thin" bullet points. Write full sentences...
|
||||
3. **Completeness:** Never stop in the middle of a table or sentence.
|
||||
"""
|
||||
|
||||
prompt = """
|
||||
TASK: Write the "GTM STRATEGY REPORT v3.1" in Markdown.
|
||||
REQUIRED STRUCTURE:
|
||||
...
|
||||
3. Product Reality Check (Technical Deep Dive)
|
||||
* Include ALL available specs... Make it as comprehensive as a technical datasheet.
|
||||
...
|
||||
7. Commercial Logic (ROI Framework)
|
||||
* Example Calculation: Provide a hypothetical example calculation with plausible ranges...
|
||||
"""
|
||||
```
|
||||
|
||||
### 6.3. Phase 6 Prompt (Legal Hardening)
|
||||
Sorgt für rechtssichere Verkaufsargumente.
|
||||
|
||||
```python
|
||||
prompt = """
|
||||
1. **Anticipate Objections:** ...
|
||||
* *Special Focus for 'Infrastructure Responsible' (Gatekeeper):* Address **Legal, Liability & Compliance** issues (e.g. GDPR, DGUV V3, accident liability) specifically.
|
||||
2. **Formulate Battlecards:** ...
|
||||
* *Requirement:* Use specific **proof points** (e.g., "Certified according to...", "Data hosted in Germany") instead of generic promises.
|
||||
"""
|
||||
```
|
||||
|
||||
### 6.4. Phase 8 Prompt (ROI Ranges)
|
||||
Verhindert "undefined" Fehler durch Forderung von Schätzbereichen.
|
||||
|
||||
```python
|
||||
prompt = """
|
||||
2. **ROI Formula & Example:** Create a formula: `Net Value = (Savings + Risk Mitigation) - (TCO)`.
|
||||
* *CRITICAL:* Provide **PLAUSIBLE EXAMPLE RANGES** for efficiency gains (e.g., "Estimate: 20-30% reduction in manual patrol time") instead of just listing the variable.
|
||||
* **Do NOT output "undefined".** Give a realistic estimation based on the industry context.
|
||||
"""
|
||||
```
|
||||
159
docs/market_intel_backend_plan.md
Normal file
159
docs/market_intel_backend_plan.md
Normal file
@@ -0,0 +1,159 @@
|
||||
# Plan: Umsetzung des "General Market Intelligence" Backends als Python-Service
|
||||
|
||||
Dieses Dokument beschreibt den Plan zur Umsetzung der Backend-Logik für die React-Anwendung unter `/general-market-intelligence` als robusten, faktenbasierten Python-Service. Dieser Ansatz ersetzt die ursprüngliche Idee einer n8n-Migration.
|
||||
|
||||
## 1. Zielsetzung & Architektur-Entscheidung
|
||||
|
||||
Das primäre Ziel ist die Schaffung eines **transparenten, kontrollierbaren und faktenbasierten Backend-Prozesses**. Die ursprüngliche Implementierung der React-App zeigte Schwankungen in der Ergebnisqualität und mangelnde Nachvollziehbarkeit, da die KI-Aufrufe nicht auf verifizierbaren Daten basierten ("Grounding").
|
||||
|
||||
Nach einer Analyse wurde entschieden, von einer n8n-basierten Lösung Abstand zu nehmen und stattdessen einen **dedizierten Python-Service** zu entwickeln.
|
||||
|
||||
**Gründe für Python statt n8n:**
|
||||
- **Maximale Kontrolle & Transparenz:** Ein Python-Skript ermöglicht detailliertes Logging, schrittweises Debugging und die volle Kontrolle über jeden Aspekt der Logik – von Web-Scraping bis zu den API-Aufrufen. Dies ist entscheidend, um die Ergebnisqualität sicherzustellen.
|
||||
- **Nahtlose Projekt-Integration:** Das Python-Skript fügt sich perfekt in die bestehende, Python-basierte Projektstruktur ein und kann auf geteilte Module (`config.py`, `helpers.py`) zugreifen.
|
||||
- **Robuste Fehlerbehandlung:** Komplexe Fehler- und Wiederholungslogiken lassen sich in Python präziser und robuster implementieren als in einer visuellen Workflow-Engine.
|
||||
- **Vermeidung von Plattform-Limitierungen:** Wir umgehen technische Hürden wie die eingeschränkte REST-API der selbstgehosteten n8n-Version.
|
||||
|
||||
## 2. Architektur: React-Frontend mit Python-Backend
|
||||
|
||||
Die Architektur besteht aus drei Kernkomponenten, die in einem Docker-Container gekapselt werden:
|
||||
|
||||
1. **React-Frontend (unverändert):** Die bestehende Anwendung in `/general-market-intelligence` bleibt die interaktive Benutzeroberfläche.
|
||||
2. **Node.js API-Brücke (`server.js`):** Ein minimaler Express.js-Server, der im selben Verzeichnis wie die React-App läuft. Seine einzige Aufgabe ist es, HTTP-Anfragen vom Frontend entgegenzunehmen und sie sicher an das Python-Skript weiterzuleiten.
|
||||
3. **Python-Orchestrator (`market_intel_orchestrator.py`):** Das Herzstück der Logik. Dieses Kommandozeilen-Skript ist zuständig für:
|
||||
- Web-Scraping zur Gewinnung von Rohdaten ("Ground Truth").
|
||||
- Text-Extraktion und -Bereinigung.
|
||||
- Gezielte und "geerdete" Aufrufe an die Gemini-API.
|
||||
- Rückgabe der strukturierten Ergebnisse als JSON über die Konsole (stdout).
|
||||
|
||||
**Deployment:** Der gesamte Backend-Service (Node.js-Brücke und Python-Skript) wird in einem **Docker-Container** verpackt, um eine konsistente, "immer online" verfügbare Umgebung zu schaffen.
|
||||
|
||||
## 3. Kernfunktionen als Python-Module
|
||||
|
||||
Die Logik aus `geminiService.ts` wird in Python-Funktionen innerhalb von `market_intel_orchestrator.py` nachgebildet, wobei der Fokus auf Faktenbasiertheit liegt.
|
||||
|
||||
---
|
||||
|
||||
### Funktion 1: `generate_search_strategy`
|
||||
|
||||
- **Trigger:** Aufruf durch die Node.js-Brücke mit `--mode generate_strategy`.
|
||||
- **Input:** `reference_url` und `context_content` (Strategie-Dokument).
|
||||
- **Prozess:**
|
||||
1. **Scraping (Grounding):** Lädt den HTML-Inhalt der `reference_url`.
|
||||
2. **Text-Extraktion:** Bereinigt das HTML zu sauberem Text.
|
||||
3. **KI-Analyse:** Ruft die Gemini-API mit einem Prompt auf, der explizit anweist, die digitalen Signale aus dem **bereitgestellten Website-Text** und dem Strategie-Kontext abzuleiten.
|
||||
- **Output:** Gibt das `SearchStrategy`-JSON auf der Konsole aus.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### Funktion 2: `identify_competitors`
|
||||
|
||||
- **Trigger:** Aufruf mit `--mode identify_competitors`.
|
||||
- **Input:** `reference_url` und `target_market`.
|
||||
- **Prozess:**
|
||||
1. Ruft die Gemini-API mit einem Google-Search-Tool auf, um ähnliche Unternehmen zu finden.
|
||||
- **Output:** Gibt eine JSON-Liste der gefundenen Unternehmen aus.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### Funktion 3: `run_full_analysis`
|
||||
|
||||
- **Trigger:** Aufruf mit `--mode run_analysis`.
|
||||
- **Input:** Eine Liste von Unternehmensnamen und die zuvor generierte Suchstrategie.
|
||||
- **Prozess:**
|
||||
1. Iteriert über die Unternehmensliste.
|
||||
2. **Für jedes Unternehmen:**
|
||||
- Sucht die offizielle Website (z.B. über SerpAPI).
|
||||
- Scrapt die relevanten Seiten basierend auf den `targetPageKeywords` der digitalen Signale.
|
||||
- Ruft die Gemini-API auf, um die Signale basierend auf dem **gescrapten Inhalt** zu bewerten.
|
||||
- **Output:** Gibt eine Liste von `AnalysisResult`-Objekten aus.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### Funktion 4: `generate_outreach_campaign`
|
||||
|
||||
- **Trigger:** Aufruf mit `--mode generate_outreach`.
|
||||
- **Input:** `company_data` (ein `AnalysisResult`-Objekt), `knowledge_base` (Strategie-Dokument) und `reference_url`.
|
||||
- **Prozess:**
|
||||
1. Baut den Prompt für die Erstellung der E-Mail-Kampagne, wobei die **faktenbasierten `dynamicAnalysis`-Ergebnisse** als Kern der Personalisierung dienen.
|
||||
2. Ruft die Gemini-API auf.
|
||||
- **Output:** Gibt die `EmailDraft`-Objekte als JSON-Array aus.
|
||||
|
||||
## 4. Deployment & Betrieb in der Konsolidierten Architektur
|
||||
|
||||
Das Market Intelligence Tool ist nun vollständig in die zentrale Docker-Compose-Architektur des Projekts integriert. Das separate Bauen und Starten einzelner Container, wie in den alten Abschnitten beschrieben, ist nicht mehr der richtige Weg.
|
||||
|
||||
### Zentraler Start via Docker Compose
|
||||
|
||||
Der gesamte Anwendungs-Stack (Proxy, Dashboard, B2B Assistant, Market Intelligence) wird über die `docker-compose.yml`-Datei im Hauptverzeichnis des Projekts verwaltet und gestartet.
|
||||
|
||||
1. **Navigieren Sie in das Projekt-Hauptverzeichnis.**
|
||||
2. **Starten Sie alle Dienste:**
|
||||
```bash
|
||||
docker-compose up -d --build
|
||||
```
|
||||
Der `--build`-Parameter sorgt dafür, dass alle Docker-Images neu erstellt werden. Dies ist bei Änderungen am Frontend (`App.tsx`), an den `Dockerfile`n oder den `requirements.txt`/`package.json` notwendig.
|
||||
|
||||
### Zugriff
|
||||
|
||||
- Das zentrale Dashboard ist unter `http://<Server-IP>:8090` erreichbar.
|
||||
- Das **Market Intelligence Tool** ist direkt über das Unterverzeichnis `http://<Server-IP>:8090/market/` zugänglich.
|
||||
- Der Zugang ist durch Basic Authentication geschützt (Benutzer: `admin`, Passwort: `gemini`).
|
||||
|
||||
### Entwicklung (Sideloading)
|
||||
|
||||
Für eine schnelle Entwicklung ist "Sideloading" für die Python-Logik aktiviert. Das bedeutet, die `market_intel_orchestrator.py` wird als Volume in den Container gemountet.
|
||||
|
||||
- **Nach Änderungen am Python-Skript:** Ein einfacher Neustart des Containers genügt, um die Änderungen zu übernehmen. Ein kompletter Rebuild ist nicht erforderlich.
|
||||
```bash
|
||||
docker-compose restart market-backend
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Status Update (2026-01-14) - Quality & Stability Refinements
|
||||
|
||||
|
||||
|
||||
**Erreichte Meilensteine:**
|
||||
|
||||
|
||||
|
||||
1. **Anti-Halluzinations-Fix (Technographic Audit):**
|
||||
|
||||
* **Problem:** Die KI hat aufgrund von Suggestiv-Prompts ("Look for SAP Ariba") oft Technologien halluziniert oder irrelevante Systeme als Wettbewerber eingestuft.
|
||||
|
||||
* **Lösung:** Entfernung aller festcodierten "Suggestiv-Listen" aus dem Code. Der Audit sucht nun rein faktenbasiert oder basierend auf der expliziten Strategie-Eingabe.
|
||||
|
||||
* **Ergebnis:** Keine "falschen Feinde" mehr. Wenn keine Konkurrenz-Hardware gefunden wird, wird korrekt "Greenfield" (Status Quo: Manuell) erkannt.
|
||||
|
||||
|
||||
|
||||
2. **Outreach-Optimierung ("Strategic Observer"):**
|
||||
|
||||
* **Prompting:** Radikale Überarbeitung des Outreach-Prompts.
|
||||
|
||||
* **Stil:** Weg vom "Verkäufer", hin zum "Scharfsinnigen Branchenbeobachter".
|
||||
|
||||
* **Opportunity Bridge:** Die E-Mails schlagen in der ersten Nachricht sofort die Brücke von der Beobachtung (z.B. "Expansion") zur Lösungskategorie (z.B. "Autonome Reinigungsrobotik"), ohne plump Features zu verkaufen.
|
||||
|
||||
* **Kontext-Sensitivität:** Technologische Signale (wie ERP-Systeme) werden nur noch bei Rollen erwähnt, für die sie relevant sind (CIO, CFO), aber bei operativen Rollen (Facility Management) ausgeblendet, um Verwirrung zu vermeiden.
|
||||
|
||||
|
||||
|
||||
3. **Produktionsreife:**
|
||||
|
||||
* Der Prozess liefert nun konsistent hochwertige, C-Level-taugliche Ansprachen, die strategische Schmerzpunkte mit operativen Lösungen verbinden.
|
||||
|
||||
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
* **Regelbetrieb & Monitoring:** Überwachung der Qualität bei neuen Branchen.
|
||||
|
||||
--- End of content ---
|
||||
|
||||
|
||||
2332
docs/moltbot_chatgpt.md
Normal file
2332
docs/moltbot_chatgpt.md
Normal file
File diff suppressed because it is too large
Load Diff
65
docs/notion_integration.md
Normal file
65
docs/notion_integration.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Notion Integration Dokumentation
|
||||
|
||||
**Stand:** 06. Januar 2026
|
||||
**Status:** Proof of Concept (PoC) erfolgreich
|
||||
|
||||
Diese Dokumentation beschreibt die erfolgreiche Anbindung der GTM Architect Engine an Notion. Es wurden Skripte erstellt, um eine Verbindung herzustellen, Seiten und Datenbanken anzulegen und strukturierte Produktdaten (Hard Facts) automatisch einzutragen.
|
||||
|
||||
## 1. Konfiguration
|
||||
|
||||
* **API Token:** Das Notion-Token wird aus der Datei `notion_api_key.txt` (im Root-Verzeichnis) gelesen. Diese Datei ist im `.gitignore` und wird nicht versioniert.
|
||||
* **Bot Identity:** "RoboPlanet GTM Engine"
|
||||
|
||||
## 2. Ressourcen IDs
|
||||
|
||||
Wichtige IDs für die weitere Entwicklung und Integration:
|
||||
|
||||
* **Root Page (Roboplanet):** `2e088f42-8544-8024-8289-deb383da3818`
|
||||
* **Product Master Database:** `2e088f42-8544-815e-a3f9-e226f817bded`
|
||||
|
||||
## 3. Skripte (PoC)
|
||||
|
||||
Folgende Python-Skripte wurden entwickelt und getestet:
|
||||
|
||||
### 3.1. `hello_notion.py`
|
||||
* **Zweck:** Testet die Authentifizierung und erstellt eine einfache "Hello World"-Seite.
|
||||
* **Funktion:**
|
||||
1. Liest Token.
|
||||
2. Authentifiziert sich als Bot.
|
||||
3. Erstellt eine Page "Hello World" unterhalb der Root Page.
|
||||
|
||||
### 3.2. `create_notion_db.py`
|
||||
* **Zweck:** Erstellt die zentrale Produktdatenbank ("📦 RoboPlanet Product Master").
|
||||
* **Struktur:** Legt Properties für alle relevanten "Hard Facts" an, die in Phase 1 des GTM Architect extrahiert werden:
|
||||
* **Core Specs:** Battery Runtime, Charge Time, Weight, Max Slope.
|
||||
* **Layers:** Fresh Water, Area Performance.
|
||||
* **Metadata:** Brand, Category, Manufacturer URL, GTM Status.
|
||||
|
||||
### 3.3. `add_product_to_notion.py`
|
||||
* **Zweck:** Schreibt ein analysiertes Produkt in die Datenbank.
|
||||
* **Input:** Erwartet ein JSON-Objekt im Format der `specs` aus Phase 1 (siehe `templates/json_struktur_roboplanet.txt`).
|
||||
* **Mapping:** Mapped die JSON-Felder (z.B. `core_specs.battery_runtime_min`) auf die entsprechenden Notion-Datenbank-Spalten.
|
||||
|
||||
## 4. Datenmodell (Product Master)
|
||||
|
||||
Die Datenbank "📦 RoboPlanet Product Master" hat folgendes Schema:
|
||||
|
||||
| Notion Property | Typ | Source JSON Field |
|
||||
| :--- | :--- | :--- |
|
||||
| **Model Name** | Title | `metadata.model_name` |
|
||||
| **Brand** | Select | `metadata.brand` |
|
||||
| **Category** | Select | `metadata.category` |
|
||||
| **Battery Runtime (min)** | Number | `core_specs.battery_runtime_min` |
|
||||
| **Charge Time (min)** | Number | `core_specs.charge_time_min` |
|
||||
| **Weight (kg)** | Number | `core_specs.weight_kg` |
|
||||
| **Max Slope (deg)** | Number | `core_specs.max_slope_deg` |
|
||||
| **Fresh Water (l)** | Number | `layers.cleaning.fresh_water_l` |
|
||||
| **Area Performance (m2/h)** | Number | `layers.cleaning.area_performance_sqm_h` |
|
||||
| **Manufacturer URL** | URL | `metadata.manufacturer_url` |
|
||||
| **GTM Status** | Status | *(Initial: Not Started)* |
|
||||
|
||||
## 5. Nächste Schritte
|
||||
|
||||
1. Integration der Logik aus `add_product_to_notion.py` direkt in `gtm_architect_orchestrator.py` (Phase 1).
|
||||
2. Erweiterung um "Content"-Blöcke (z.B. generierte Zusammenfassung als Page Content).
|
||||
3. Status-Updates (GTM Status) je nach Fortschritt der Phasen (z.B. "Phase 3 Complete").
|
||||
21
docs/planning.md
Normal file
21
docs/planning.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Projektplanung & Roadmap
|
||||
|
||||
## Phase 1: Stabilisierung & Daten-Import (Q3 2025) - ABGESCHLOSSEN
|
||||
- **Ziel:** Ein stabiles System schaffen, das zuverlässig Daten aus D365 aufnehmen und verarbeiten kann.
|
||||
- **Ergebnis:** Das System ist lauffähig. Der `sync`-Prozess ermöglicht es, das Google Sheet auf dem aktuellen Stand der D365-Stammdaten zu halten und gleichzeitig bereits angereicherte Daten zu schützen.
|
||||
|
||||
## Phase 2: Schließen des Datenkreislaufs (Q3 2025) - NÄCHSTER SCHRITT
|
||||
- **Ziel:** Die im Google Sheet generierten und verbesserten Daten zurück ins D365-System zu spielen.
|
||||
- **Vorgehen:** Implementierung einer Export-Funktion, die eine saubere Import-Datei für den D365 Import Assistenten generiert. Dies schließt den manuellen, aber kontrollierten Datenkreislauf.
|
||||
|
||||
## Phase 3: Technische Modernisierung (Q4 2025)
|
||||
- **Ziel:** Das System auf den neuesten technischen Stand heben, um von modernen Features zu profitieren.
|
||||
- **Vorgehen:**
|
||||
- Geplantes Refactoring aller OpenAI-Aufrufe auf die `openai v1.x` Bibliothek. Dies ermöglicht stabilere JSON-Antworten und den Zugang zu neuen Modellen.
|
||||
- Überprüfung und ggf. Update weiterer Bibliotheken.
|
||||
|
||||
## Phase 4: Automatisierung & Erweiterung (Langfristig)
|
||||
- **Ziel:** Manuelle Schritte eliminieren und neue Anreicherungs-Features hinzufügen.
|
||||
- **Vorgehen:**
|
||||
- Evaluation von Möglichkeiten, den D365-Export/Import zu automatisieren (z.B. über Power Automate).
|
||||
- Hinzufügen weiterer Datenquellen oder KI-basierter Analysen (z.B. Social-Media-Analyse, News-Monitoring).
|
||||
87
docs/tasks.md
Normal file
87
docs/tasks.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Aufgaben & Meilensteine
|
||||
|
||||
## Phase 1: Stabilisierung & Daten-Import (Abgeschlossen)
|
||||
- [x] **Stabilität:** `ModuleNotFoundError` durch Downgrade der `openai`-Bibliothek beheben.
|
||||
- [x] **Stabilität:** `json.JSONDecodeError` durch robuste Parser in `helpers.py` beheben.
|
||||
- [x] **Sync-Design:** Prozess für den Datenabgleich D365 -> GSheet ohne API definieren.
|
||||
- [x] **Implementierung:** `sync_manager.py` für den "Full-Sync mit intelligentem Merge" erstellen.
|
||||
- [x] **Debugging:** Fehler im `SyncManager` (Attribut-, Typ- und Index-Fehler) iterativ beheben.
|
||||
- [x] **Kernproblem-Analyse:** "Header-Mismatch" als Ursache für Datenverlust identifizieren.
|
||||
- [x] **Implementierung:** Header-Normalisierung in der `_load_data`-Methode implementieren.
|
||||
- [x] **Fachlogik:** Spezifische Vergleichsregeln für Länder, Techniker, Umsatz, Mitarbeiter und Branchen definieren und implementieren.
|
||||
- [x] **Tooling:** Einen `simulate_sync`-Modus und einen finalen Statistik-Report implementieren.
|
||||
|
||||
## Phase 2: Schließen des Datenkreislaufs (In Arbeit)
|
||||
|
||||
- [ ] **Design:** Spalten und Format für die D365-Re-Import-Datei definieren.
|
||||
|
||||
- [ ] **Implementierung:** Eine neue Funktion/einen neuen Modus (`generate_import_file`) erstellen, der die `d365_import.xlsx` erzeugt.
|
||||
|
||||
- [ ] **Logik:** Die Funktion soll nur Datensätze exportieren, die im letzten Lauf geändert wurden (`ReEval Flag` oder neu erstellt).
|
||||
|
||||
- [ ] **Logik:** Die Branchennamen müssen vor dem Export mithilfe des Mappings in der `config.py` in das D365-Format übersetzt werden.
|
||||
|
||||
- [ ] **Testing:** Den vollständigen Round-Trip testen: `sync` -> `reeval` -> `generate_import_file` -> Manueller Import in D365.
|
||||
|
||||
|
||||
|
||||
## Phase 3: Optimierung der Potenzialanalyse (Abgeschlossen)
|
||||
|
||||
- [x] **Bugfix:** "Concatenated Year Bug" (z.B. Wolfra 802020) im `MetricParser` behoben.
|
||||
|
||||
- [x] **Logik:** Smart-Year-Skipping implementiert (Zahlen zwischen 1900-2100 werden als Jahre ignoriert, wenn Alternativen existieren).
|
||||
|
||||
- [x] **Präzision:** Entity-Confusion (z.B. Therme Erding vs. Hallenbad Erding) durch Standort-Validierung im Such-Prompt minimiert.
|
||||
|
||||
- [x] **Transparenz:** Confidence Scores (0.0-1.0) und "Proof Snippets" (Original-Textfragmente) in die Datenbank integriert.
|
||||
|
||||
- [x] **UI:** Confidence-Ampel und Tooltip für Quellen-Beweise im Frontend implementiert.
|
||||
|
||||
- [x] **Integrität:** Fehlende API-Endpunkte für Firmen-Erstellung, Bulk-Import und Wiki-Overrides wiederhergestellt.
|
||||
|
||||
## Persona Segmentierung & Rollen-Matching (v0.9.0 - Abgeschlossen)
|
||||
|
||||
- [x] **Database Portability:** Up- & Download der SQLite-Datenbank direkt im UI implementiert (inkl. automatischem Backup).
|
||||
- [x] **Pattern Optimizer:** Asynchrones KI-System zur automatischen Generierung von Regex-Mustern aus Einzelregeln.
|
||||
- [x] **Konflikt-Management:** KI-gestützte Prüfung von Regex-Regeln gegen andere Rollen (Negative Examples) zur Vermeidung von Fehlzuordnungen.
|
||||
- [x] **Regex Sandbox:** Interaktives Test-Tool im Frontend zur Validierung von Mustern gegen echte Jobtitel.
|
||||
- [x] **Smart Suggestions:** Live-Analyse der Datenbank zur Anzeige häufiger Schlüsselwörter als Klick-Vorschläge.
|
||||
- [x] **Robustheit:** Implementierung eines AST-basierten Parsers für komplexe Regex-Escaping-Szenarien.
|
||||
|
||||
## Lead Engine: Tradingtwins Automation (In Arbeit)
|
||||
|
||||
- [x] **E-Mail Ingest:** Automatisierter Import von Leads aus dem Postfach `info@robo-planet.de` via Microsoft Graph API.
|
||||
- [x] **Parsing:** Strukturierte Extraktion von Bedarfsdaten (Fläche, Zweck, Funktionen) aus Tradingtwins-HTML.
|
||||
- [x] **Contact Research:** KI-gestützte Rollen-Identifizierung via SerpAPI und Gemini 2.0 Flash.
|
||||
- [x] **CE-Sync:** Automatisches Anlegen von Firmen und Kontakten im Company Explorer inkl. Role-Mapping.
|
||||
- [x] **Drafting:** E-Mail-Generator auf "Human Expert Level" mit Branchen-Fokus und ROI-Argumentation.
|
||||
- [x] **UI: Visuelle Unterscheidung:** Leads nach Herkunft (TradingTwins vs. Website-Formular) optisch differenziert.
|
||||
- [x] **UI: Status-Indikatoren:** Synchronisationsstatus (CE) und Low-Quality-Warnungen direkt im Lead-Header sichtbar.
|
||||
- [x] **Drafts: Persistente Speicherung:** Generierte E-Mail-Entwürfe werden dauerhaft in der Datenbank gespeichert.
|
||||
- [ ] **IT-Klärung:** Microsoft Bookings Berechtigungen (`Bookings.Read.All`, `BookingsAppointment.ReadWrite.All`) für die Entra App anfragen und "Admin Consent" einholen.
|
||||
- [ ] **Infrastruktur:** Korrekten Buchungslink (persönliches Konto) ermitteln und in der `.env` (Variable `BOOKING_LINK`) hinterlegen.
|
||||
- [ ] **CRM-Integration:** Modul "Push to SuperOffice" entwickeln, um Personen und E-Mail-Entwürfe (als Aufgabe/Aktivität) direkt im CRM anzulegen.
|
||||
- [ ] **Daten-Synchronisation:** Notion-Produktdatenbank in die lokale DB spiegeln, um Produktauswahl und ROI-Berechnung zu dynamisieren.
|
||||
- [ ] **Logik:** ROI-Kalkulation im E-Mail-Entwurf auf Basis von echten Leistungsdaten (m²/h) und Preisen schärfen.
|
||||
- [ ] **UI:** "Copy to Clipboard" Funktion für den fertigen Entwurf in der Web-App finalisieren.
|
||||
- [ ] **Phase 2: Intelligente Antworten für Kontaktformulare:** Entwicklung einer kontextbezogenen Antwortlogik für Website-Formular-Leads (zunächst allgemeine Bestätigung, später KI-gestützt auf Nachrichtsinhalt basierend).
|
||||
|
||||
## Heatmap Tool (Standalone)
|
||||
|
||||
### Status: Beta (Funktionsfähig mit Basisfunktionen)
|
||||
|
||||
- [x] **Setup:** Projektstruktur mit FastAPI (Backend) und React/Vite (Frontend) aufgesetzt.
|
||||
- [x] **Daten:** Upload von XLSX-Dateien und automatische PLZ-Erkennung implementiert.
|
||||
- [x] **Visualisierung:** Leaflet-Karte mit "Points"-Ansicht (CircleMarker) und "Heatmap"-Ansicht (Density) erstellt.
|
||||
- [x] **Interaktivität:** Dynamische Filterung nach Spaltenwerten implementiert.
|
||||
- [x] **UI/UX:** Filter-Panel redesignet (Checkboxen, Collapsible) und Tooltip-Manager integriert (Drag & Drop, Sichtbarkeit).
|
||||
- [x] **Clustering:** Marker Clustering für die Punkte-Ansicht implementiert.
|
||||
- [x] **Fix:** Docker-Networking Probleme (Vite Proxy) gelöst.
|
||||
- [x] **Fix:** Infinite-Loop bei zoom-adaptiver Legende durch Revert behoben (Feature als instabil markiert).
|
||||
|
||||
### Offene Punkte & Erweiterungen
|
||||
|
||||
- [ ] **Export:** Funktion "Karte als PNG speichern" implementieren.
|
||||
- [ ] **Geo-Aggregation:** Aggregation nach Bundesland und Landkreis hinzufügen.
|
||||
- [ ] **Multi-Layer:** Vergleichsansicht (z.B. Kunden vs. Techniker) durch zweiten Datei-Upload ermöglichen.
|
||||
|
||||
695
docs/transkript_verticals1.txt
Normal file
695
docs/transkript_verticals1.txt
Normal file
@@ -0,0 +1,695 @@
|
||||
Hier ist das Transkript des Meetings.
|
||||
|
||||
Teilnehmer:
|
||||
|
||||
Christian: (Führt durch das Meeting, tiefere Stimme)
|
||||
|
||||
Alex: (Antwortet und diskutiert, etwas höhere Stimme)
|
||||
|
||||
00:00 Christian: So. Also. Die Grundlage für alles, was in Zukunft kommt Richtung Marketing Automation und Richtung Kommunikation zum Kunden, basiert bei mir auf den Verticals. Die Verticals, ähm, ist das, was wir im Prinzip aktuell als Industries haben. Wo ich sag, dass die Industries das Bild nicht das ab[bilden], wie wir die Welt eigentlich sehen. Das ist ein Branchenschema, was sich irgendjemand ausgedacht hat, was aber nicht Robo-Planet-Sicht der Welt entspricht. Sondern das ist halt ein Branchenschema, keine Ahnung, Standard, aber das passt nicht zu dem, wie wir die Welt eigentlich sehen. Sondern wir sehen die Welt sehr viel differenzierter. Und zwar größtenteils daran angelehnt: Welchen Roboter können wir bei dem Kunden einsetzen? Das ist für uns im Prinzip so ein bisschen die Sicht der Welt, aus der wir denken. Also welchen Roboter können wir einsetzen und dann müssen wir überlegen, wie können wir die Kunden sauber clustern, nach dem, was wir dort platzieren wollen.
|
||||
|
||||
01:00 Christian: Ähm, ich bin mit meiner Marketing Automation der Meinung, dass wir einen Schuss haben, den Kunden abzuholen. Wenn ich dem komme mit: „Pass auf, wir haben Reinigungsroboter und wir haben Security-Roboter und wir haben noch einen Butler, der rumfährt und Tabletts zum Platz bringt“, dann komme ich mit dem mit einem Bauchladen an Lösungen, dann habe ich ihn komplett verloren, weil er denkt: „Äh, was willst du jetzt eigentlich von mir?“ Ja? Das heißt, ich habe einen Schuss, um ihn zu treffen, und der muss sitzen.
|
||||
|
||||
01:34 Alex: Natürlich kommt [es] drauf an, in welchem Unternehmen du halt wen wo ansprichst, ja. Also...
|
||||
|
||||
01:40 Christian: Ja, das ist auch... das ist jetzt die zweite Thematik. Es kann sein, dass wir bei einem Seniorenstift oder bei so einem Altenheim, dass wir einen Ansprechpartner fürs Facility Management haben, dem wird das komplett Latte sein, wenn ich da mit irgendwelchen Tablett-Robotern komme. Genauso wird der Pflegedienstleitung das egal sein, wenn ich sage, wir haben Reinigungsroboter, dann sagt die: „Pff, ist mir doch egal.“
|
||||
|
||||
01:59 Alex: Klar.
|
||||
|
||||
02:01 Christian: „Weil ich bin die Pflegedienstleitung, mir ist das wichtig, dass die Tabletts auf die Zimmer kommen.“ Ähm, das ist ein valider Punkt, den ich auch versucht habe zu berücksichtigen. Wenn wir uns jetzt das hier anschauen... ein bisschen Delay hier, aber ich hoffe, ich komme damit klar. Ähm, ich habe jetzt für jedes Vertical habe ich ein... Gott, das macht einen echt... echt ein bisschen schwummrig hier mit dem Delay, aber das kriegen wir hin. Ich habe für jeden... für jedes Vertical habe ich ein Primary Product festgelegt und ein Secondary Product. Also das heißt, jetzt hier die Automotive Dealer, also das sind die Autohändler, hab ich gesagt, für die ist die Sicherheit, dass da nachts keine Katalysatoren geklaut werden, ist für die wichtiger, als dass der... dass der Außenhof sauber ist, dass da das Laub weggefegt ist, ja? Das ist für den der größere Schmerz.
|
||||
|
||||
02:53 Alex: Definitiv.
|
||||
|
||||
02:55 Christian: Wenn ich natürlich jemanden habe im Bereich Facility Management oder der für die Reinigung der Standorte zuständig ist, dann kann ich ihn definitiv auch hier drüber ansprechen. Aber der größte Schmerz, wenn ich jetzt an den Geschäftsführer rangehe und ich habe einen Schuss, dann verkaufe ich ihm den Security Roboter, weil das für mich aus... aus jetzt gefühlt, aus meiner Wahrnehmung, ist das der größte Schmerz, den er erstmal hat.
|
||||
|
||||
03:16 Alex: Teile ich. Teile ich definitiv, ja.
|
||||
|
||||
03:19 Christian: Ähm. Dieses Sheet hatte ich euch mal geteilt. Es ist jetzt ein bisschen noch gewachsen, indem ich hier hinten noch eine Spalte für die Pains und die Gains hinzugedichtet habe für jede Branche. Das heißt, hier sind dann so Sachen wie, ähm, ja Teile-Diebstahl, dass Katalysatoren oder die Räder nachts geklaut werden, Vandalismus, Imageverlust und so weiter, Personalkosten. Das sind die Themen, die für die Autohäuser im Herz sind. Wahrscheinlich sind das Themen, die für alle Branchen gelten, wenn's mit Personalkosten und so weiter [zu tun hat]. Ähm. Und genauso eben die Gains. Was sind die Vorteile, die sie von unseren Robotern eben haben? Prävention natürlich. Ähm. Doppelnutzen ist natürlich, muss man jetzt dann in Frage stellen, wenn sie beide Lösungen im Einsatz haben. Ähm, das sind jetzt erstmal nur Hypothesen, die ich aufgestellt habe, die wir möglichst zügig freigeben müssen oder freikriegen müssen, weil das im Prinzip die Basis für alles weitere ist. Dass wir einmal eine solide Basis haben: Welche Branchen haben wir? Wie zeichnen sich die aus? Was fehlt uns vielleicht noch an Branchen, was wir jetzt noch hier nicht haben? Was klammern wir bewusst aus? Weil wir sagen: Keine Ahnung, alle Hersteller der Welt, ob sie jetzt Apfelsaft produzieren oder ob sie irgendwelche Maschinen und Anlagen bauen, ist für uns im Prinzip das Gleiche, weil das ist alles entweder das Thema Transportroboter oder Security Roboter. Also aus dieser, ähm, durch diese Brille müssen wir im Prinzip die Verticals betrachten.
|
||||
|
||||
04:55 Alex: Ja.
|
||||
|
||||
04:56 Christian: Und dann festlegen: Trifft's das jetzt? Haben wir schon alles oder fehlt da noch was, ja?
|
||||
|
||||
05:01 Alex: Also müssen wir da quasi, wenn du... wir müssten letzten Endes durch alle durchgehen und dann checken wir noch einmal die Pains and Gains durch und sagen: Okay.
|
||||
|
||||
05:10 Christian: Das wäre mein Ziel. Das wird für eine Stunde jetzt nicht klappen.
|
||||
|
||||
05:13 Alex: Ja, ja. Ich muss mal durchlesen, das können wir ja machen noch.
|
||||
|
||||
05:16 Christian: Genau, wir können ja mal anfangen, dass wir... Und was eben auch noch dabei ist: Mein Tool versucht ja am Ende dann die Berechnungsgrundlage zu finden, welche Fläche dieses Unternehmen hat. Das ist dann diese Abstraktionslogik, indem ich sag, wenn ich jetzt zwei oder drei Krankenhäuser nebeneinander lege, ähm, welches will ich als Erstes angehen, weil das die größte Fläche hat, ja? Ähm, das hat er ja schon öfters mal kommuniziert. Wir haben die Anzahl der Betten, die auf der Webseite kommuniziert oder teilweise aus Wikipedia auslesbar ist. Das können wir eins zu eins durch den Faktor 100 auf die Fläche umrechnen. Also je Bett 100 Quadratmeter Fläche und dann habe ich meine Reinigungsfläche anhand einer öffentlich kommunizierten Zahl sehr nah berechnet. Also ich bin sehr nah an der Realität dran.
|
||||
|
||||
06:09 Alex: Das ist ja schon super. Ist perfekt. Reicht doch.
|
||||
|
||||
06:11 Christian: Und das ist für mich so ein bisschen der Hebel, womit ich arbeiten möchte. Ähm. Ich weiß jetzt nicht, ob wir jetzt von oben nach unten durchgehen. Ähm. Ob wir sagen... also ich habe das schon mal für mich jetzt so ein bisschen gesagt, welche sind wichtiger, welche sind nicht wichtiger. Mag sein, dass das völlig daneben ist.
|
||||
|
||||
06:31 Alex: Ja, es kommt immer drauf an. Wahrscheinlich mit, weißt du, mit Security ist es natürlich was anderes wie... Also P2 ist jetzt für dich...
|
||||
|
||||
06:41 Christian: Das wäre jetzt Prio 2.
|
||||
|
||||
06:42 Alex: Prio 2, genau. Ähm. Also wir müssen ja, glaube ich, erst... die erste Prio ist natürlich jetzt aktuell wahrscheinlich erstmal das Brot-und-Butter-Geschäft abzusichern. Ähm, somit ist mit Sicherheit jetzt Security für uns gerade jetzt unter aktuellen Prämissen mit Sicherheit nicht die... sehe ich auch so, ja.
|
||||
|
||||
06:58 Christian: Es ist ganz klar... nee... Sagen wir einfach, mit welchem Vertical wir starten. Oder sagst du, das ist für...
|
||||
|
||||
07:07 Alex: Also ich bin da völlig frei. Wir können ja mal mit Healthcare anfangen, oder? Oder... Die Krankenhäuser? Ja, oder Homecare, oder willst du alle von oben nach unten durchgehen? Wie viele hast du denn jetzt eigentlich? Jetzt hast du Hospitality, Freizeiteinrichtungen, Retail seh ich...
|
||||
|
||||
07:22 Christian: Das sind ungefähr 20 oder sowas, oder ein bisschen mehr. Ich habe es jetzt nicht genau gezählt, aber es ist... es ist einigermaßen...
|
||||
|
||||
07:28 Alex: Also wir haben Healthcare, Hospitality...
|
||||
|
||||
07:31 Christian: Mhm.
|
||||
|
||||
07:32 Alex: Ähm. Und was hast du noch?
|
||||
|
||||
07:35 Christian: Also wir haben, ähm, wir haben Automotive, ist jetzt nicht so relevant. Corporate Campus...
|
||||
|
||||
07:39 Alex: Und Retail hast du, also quasi drei. Drei. Und Indi... und, und, und, sag ich jetzt mal, das Thema Logistik und Produktionsindustrie, diese Themen, da sind dann wo mit drin?
|
||||
|
||||
07:49 Christian: Das ist hier Industry Manufacturing, haben wir.
|
||||
|
||||
07:51 Alex: Ja, okay.
|
||||
|
||||
07:52 Christian: Also wir können mal einmal ganz kurz durchreiten. Wir haben Automotive Dealer. Wir haben Corporate Campus, das sind die Firmenzentralen.
|
||||
|
||||
07:59 Alex: Ja.
|
||||
|
||||
08:00 Christian: Wir haben Energie, da haben wir die Energieversorger lokal. Wir haben die Solar- und Windparks, ist noch mal ein anderes Thema. Wir haben die Altenheime, ähm, Krankenhäuser. Wir haben die Gastronomie, hier die Franchises und so weiter. Wir haben Hotels. Wir haben alles, was Industrie ist.
|
||||
|
||||
08:21 Alex: Ja.
|
||||
|
||||
08:22 Christian: Wir haben, ähm...
|
||||
|
||||
08:24 Alex: Ja.
|
||||
|
||||
08:25 Christian: Ja, Messehallen und so weiter, Infrastruktur.
|
||||
|
||||
08:27 Alex: Ja. Freizeiteinrichtungen und so, ja, ja.
|
||||
|
||||
08:29 Christian: Transport, äh, Flughäfen, Bahnhöfe und so weiter. Wir haben die Freizeitparks. Äh, nee, Moment, das sind... das sind erstmal... das sind nicht Freizeitparks, das sind die Casinos, Theater und so weiter. Wir haben Fitnessstudios.
|
||||
|
||||
08:44 Alex: Ja.
|
||||
|
||||
08:45 Christian: Wir haben die Indoor-Aktivitätsparks. Wir haben die Außen-Freizeitparks.
|
||||
|
||||
08:49 Alex: Ja.
|
||||
|
||||
08:50 Christian: Schwimmbäder.
|
||||
|
||||
08:51 Alex: Ja.
|
||||
|
||||
08:52 Christian: Logistik.
|
||||
|
||||
08:53 Alex: Mhm.
|
||||
|
||||
08:54 Christian: Wir haben Retail Food Bereich. Wir haben Retail Non-Food. Ähm, Shopping Center im Retail Bereich und Data Center.
|
||||
|
||||
09:07 Alex: Ja, ist super. Ist alles drin. Ist mega.
|
||||
|
||||
09:09 Christian: Fehlt noch was?
|
||||
|
||||
09:10 Alex: Fehlt... Nee. Schulen zum Beispiel?
|
||||
|
||||
09:12 Christian: Ja.
|
||||
|
||||
09:13 Alex: Ja, schon Schulen. Schulen ist auch ein wichtiges Thema. Also Turnhallen, aber das hätte ich jetzt ja mal eher bei dem Thema Freizeiteinrichtung. Ich weiß nicht, wo du das... also Schulen und Kitas ist schon...
|
||||
|
||||
09:23 Christian: Das ist bei uns Public. Indoor... äh, das ist...
|
||||
|
||||
09:26 Alex: Ja, aber Schulen und also generell so öffentliche Hand, ne? Also, ähm...
|
||||
|
||||
09:31 Christian: Also diese...
|
||||
|
||||
09:35 Alex: Gemeinden, Kommunen halt, ne? Also die haben ja... da fällt natürlich viel von dem rein, was da schon irgendwo mit drin ist, aber die [Ansprache] ist ja wahrscheinlich noch mal eine gesonderte Ansprache, ja. Aber das würde mir noch einfallen.
|
||||
|
||||
09:47 Christian: Mhm.
|
||||
|
||||
09:48 Alex: Naja und eigentlich, eigentlich ja mit größter Markt, der ja für uns am schwierigsten ist, ist das Thema Dienstleister, ne? Also andere Gebäudereinigungsdienstleister.
|
||||
|
||||
09:59 Christian: Inwiefern? Also das ist ja jetzt kein Zielkunde.
|
||||
|
||||
10:02 Alex: Also eigentlich ja. Also die Großen arbeiten mit uns nicht zusammen. Aber der größte Markt im Bereich Reinigungsrobotik, was das Volumen betrifft im Markt, sind die Dienstleister.
|
||||
|
||||
10:13 Christian: Mhm.
|
||||
|
||||
10:15 Alex: Also, ähm, mit den... mit den, sage ich jetzt mal, mit den, ähm, mit den Großen wie so ein Wisag und Dussmann, das haben wir ja schon mal versucht, ne? Die wollen halt mit uns nicht zusammenarbeiten, weil wir halt die... also die würden ja im Wettbewerb stehen, ne? Aber das ist schon ein Riesenmarkt. Also das ist eigentlich der größte Markt mit, ne? Und so die anderen, die dann vielleicht uns jetzt nicht so kritisch sehen, ähm, wäre da schon ein Potenzial.
|
||||
|
||||
10:48 Christian: Wobei wir von denen auch immer wieder mal eine Anfrage kriegen, ne? Also apropos Strabag, wo ich gerade sehe... muss ich unbedingt weiterleiten. Das habe ich gar nicht weitergeleitet.
|
||||
|
||||
11:00 Christian: (Tippt) So.
|
||||
|
||||
11:09 Christian: Okay. Ähm, wo wollen wir anfangen?
|
||||
|
||||
11:13 Alex: Wie du willst. Wir können da gerne einfach irgendwo einsteigen. Gerne bei... wo wir oben waren, bei Gesundheitswesen.
|
||||
|
||||
11:18 Christian: Fangen wir hier an, bei Alten- und Pflegeheime, Residenzen. Essen auf... Essen und Boden. Also da ist... Service... Jetzt die Frage...
|
||||
|
||||
11:32 Christian: Ja, wir haben potenziell das Thema, dass wir den Facility Management Mensch in der Einrichtung erreichen können und bei dem werden wir dann das Thema Reinigung platzieren. Ich bin ein bisschen entleert. (Hustet/Räuspert sich). Ähm. Oder wir haben den Pflegedienstleister, für den natürlich nur die Teller relevant sind, was wir vorhin schon gesagt hatten. Ähm, wenn wir jetzt die Leitung von dem Heim direkt anschreiben: Was ist für die das größte Thema? Sind das die Serviceroboter oder ist es der...
|
||||
|
||||
12:08 Alex: Ich würde sagen, im ersten Schritt erstmal die Reinigungsrobotik, ja. Definitiv.
|
||||
|
||||
12:12 Christian: Ich hab's jetzt hier mal umgedreht vor dem Hintergrund, ähm, weil ich sag, es ist eh meistens die Reinigung ist das Thema. Und das ist einer der wenigen Fälle, wo tatsächlich das Teller-Thema vielleicht ein größeres ist und wo auch sein Schmerz größer ist. Weil Reinigungskräfte kriegt man immer, aber mit dem Pflegenotstand, das ist glaube ich ein echtes Thema.
|
||||
|
||||
12:35 Alex: Ja. Teile ich den Gedanken. Ich glaube halt, das Problem ist, dass du... also dass da die Akzeptanz und auch das, sage ich jetzt mal, es sich trauen zu tun, noch ein bisschen am Anfang ist. Also, ähm...
|
||||
|
||||
12:49 Christian: Dann tauschen wir es wieder.
|
||||
|
||||
12:50 Alex: Ich würde es fast tauschen. Ich würde es fast tauschen.
|
||||
|
||||
12:52 Christian: Oh.
|
||||
|
||||
13:14 Christian: Irgendwie zeigt er es hier nicht gut an. Kriegen wir hin. So. Ähm. Das sind die... die haben auch eine Bettenzahl. Ach Gott, jetzt springt das wieder alles hier.
|
||||
|
||||
13:37 Christian: So, hier sind wir. Wie groß muss es mindestens sein? 60 Betten? Größer? Also wie groß muss der mindestens sein, damit sich so ein Einsatz von einem Roboter lohnt?
|
||||
|
||||
13:51 Alex: Also nach Betten, weiß ich nicht, wie viel... ich gehe halt immer so nach den... nach den Quadratmetern. Also Grundreinigungsfläche brauchen wir mindestens 1000 Quadratmeter.
|
||||
|
||||
14:01 Christian: Wie hast du es dann gerechnet, wenn wir sagen... Wir haben hier den... die Anzahl der Betten mal 30 Quadratmeter. Also müssten wir...
|
||||
|
||||
14:12 Christian: 60. Das sind dann, äh, 1800 Quadratmeter.
|
||||
|
||||
14:16 Alex: Ja, da lohnt sich das schon, ja.
|
||||
|
||||
14:18 Christian: Also wir können den Wert auch niedriger ansetzen, wenn du meinst.
|
||||
|
||||
14:20 Alex: Ja, also 1500 würde ich schon sagen, dass... also...
|
||||
|
||||
14:24 Christian: Dann machen wir 50 Betten, ne?
|
||||
|
||||
14:30 Alex: Ja, würde ich schon sagen, ja. Muss ich schon sagen, ja. In der Regel ja. Die haben ja immer hohe Reinigungskosten.
|
||||
|
||||
14:38 Christian: So. Ähm. Die Themen sind, denke ich, easy. Pflegenotstand, Fachkräfte. 30 Prozent der Arbeitszeit mit Hol- und Bringdienst. Wobei das jetzt eher auf das Hol- und Bringdienst-Thema abzielt. Ähm, Hygienerisiko.
|
||||
|
||||
14:51 Alex: Ich find's... also ich find's ja prinzipiell geil. Ich hab bloß jetzt noch keinen gehabt, der darauf angesprungen ist. Also wir haben es immer vorgestellt, aber da ist jetzt keiner, der uns... also, ähm...
|
||||
|
||||
15:00 Christian: ...der auf uns proaktiv zugekommen ist und hat gesagt: "Hey, wir brauchen hier Unterstützung im Essensauslieferung."
|
||||
|
||||
15:09 Alex: Also ich find's geil, aber ich... ich... Ist noch nicht so der Praxisalltag.
|
||||
|
||||
15:15 Christian: Dann Hygienerisiko, Kreuzkontamination.
|
||||
|
||||
15:20 Alex: Ja, Laufwege. Körperliche Belastung. Ja klar, schweres Heben.
|
||||
|
||||
15:26 Christian: Das ist, muss ich komplett auf... Muss man dann nochmal anpassen.
|
||||
|
||||
15:30 Christian: Ich mach mir mal eine kurze Notizenspalte mit dazu, damit ich das hier nochmal umdrehe. Gott.
|
||||
|
||||
15:47 Alex: Daraus bau... was ist das für ein Tool jetzt? Sieht aus wie so Spreadsheets.
|
||||
|
||||
15:51 Christian: Das ist so ähnlich, ja.
|
||||
|
||||
15:56 Alex: Notion?
|
||||
|
||||
16:03 Christian: Das ist Notion heißt das, das ist...
|
||||
|
||||
16:04 Alex: Okay, ist so was ähnliches.
|
||||
|
||||
16:10 Christian: Ich zauber hier mal. So. Ähm. Das dreh ich noch um. Dann haben wir die... Ach Freund. Irgendwie mag er nicht so ganz so wie ich will hier.
|
||||
|
||||
16:30 Christian: Ah. So. Dann haben wir die Krankenhäuser. Ähm. Private und öffentliche Hand.
|
||||
|
||||
16:39 Christian: Da auch die... umdrehen, oder?
|
||||
|
||||
16:44 Alex: Würde ich fast sagen, ja. Also das, wo die halt immer am ehesten kommen... die großen... wenn du auf Logistik gehst, dann glaube ich, brauchen wir halt schon die wirklich... also da sehe ich auch viel Potenzial, ne? Also, ähm, definitiv.
|
||||
|
||||
17:04 Alex: Aber ich glaube, das ist ein Thema, das entwickelt sich so erst.
|
||||
|
||||
17:07 Christian: Gut, da haben wir wahrscheinlich das Ähnliche. Dann mache ich das einmal neu. (Tippt/Klickt)
|
||||
|
||||
17:31 Christian: So, was haben wir noch? Wir haben die Gastronomie. Große Restaurants, Systemgastronomie.
|
||||
|
||||
17:39 Alex: Mhm.
|
||||
|
||||
17:42 Christian: Ist das der Tellerbringer oder ist das wieder die Reinigung?
|
||||
|
||||
17:46 Alex: Schwierig. Also ich hab zum Beispiel jetzt, weil da steht L'Osteria, ich hab mit denen gesprochen jetzt, ne? Hab auch geschrieben, ja Service Robotik und so weiter. Nee, wir haben zu große Läden, aber die setzen wohl auch eigentlich das Thema Reinigung drin haben. Ähm...
|
||||
|
||||
18:06 Christian: Also ich noch mal: Das sind die einzigen drei Fälle, wo ich die Serviceroboter überhaupt sehe. Ansonsten können wir das Thema komplett canceln. Ich weiß nicht.
|
||||
|
||||
18:14 Alex: Naja, also zum Beispiel wenn du mal überlegst, bei... diese ganzen Themen der Freizeiteinrichtungen oder so. Oder, also Freizeitpark, also überall wo Kinder mit im Spiel sind, ja, wo dieses Thema Entertainment, da finden die das eigentlich ziemlich geil. Also da ist zum Beispiel, ich weiß nicht, wie diese großen Freizeitparks heißen, die haben 150 von den Service Robotern da drin stehen.
|
||||
|
||||
18:38 Christian: Ist das so? Für was machen... für was?
|
||||
|
||||
18:39 Alex: Ja, so große Themenparks oder so weiter, ne? Also, jetzt überleg mal, so ein großer Themenpark, wenn da so eine BellaBot rumfährt, da gibt's ja auch schon ein paar, die haben das. Da ist Service Robotik halt schon ein Thema. Oder ich seh's halt auch so, was wie ein Bowling Center oder so, da waren wir ja. Ähm, da hast du dieses Thema, da bestellst du am Tisch, erwartest dir auch keinen Service. Also überall eigentlich, wo du keinen wirklichen Service erwartest. Da passt halt diese, diese Service Robotik ganz gut. Was wir halt immer wieder spüren, dass... oder hörst du aus dem Markt, dass... sag ich: "Ja, das habe ich mal beim Chinesen gesehen." Da ist wieder die Akzeptanz hoch in dem Bereich der Gastronomie. Ich glaube schon, dass das ein Thema auch ist. Ich habe zum Beispiel... Welches Hotel war das? Also bei Hotels ist es mit auch ein Thema, ja? Aber wenn du halt sagst, wir haben halt einen Schuss, dann ist es halt schon schwer zu sagen, okay, ist es dann immer die Service Robotik, ja? Ich kann mir gut vorstellen, dass wir im Bereich Freizeiteinrichtungen mit der Service Robotik vielleicht besser schießen können als mit der Reinigungsrobotik.
|
||||
|
||||
19:49 Christian: Ja.
|
||||
|
||||
19:50 Alex: Wenn wir auf die normale Gastronomie gehen, größere Restaurants, weiß ich nicht, ob wir da mit den richtigen Treffer immer haben. Ja das, das ist... Das ist halt schwer abzuschätzen. Also wir haben halt auch, muss man sagen, wir haben leider viel zu wenig Erfahrung im Bereich dem Thema, weil wir finde ich nach außen hin viel zu wie... also nicht visibel genug sind. Also man sieht uns immer...
|
||||
|
||||
20:15 Christian: Ja gut, das ist so ein Henne-Ei-Problem. Ich meine, wir kommen aus der Reinigung, deswegen verkaufen wir Reinigung, ähm...
|
||||
|
||||
20:19 Alex: Ja, wir haben uns, also man hat sich halt von Anfang an auch nur so aufgestellt, aber ist halt so. Ähm.
|
||||
|
||||
20:29 Christian: Aber dann, dann drehen wir es auch um.
|
||||
|
||||
20:30 Alex: Das ist... das ist jetzt die...
|
||||
|
||||
20:33 Alex: Ich glaube, wir tun uns leichter. Ich glaube, wir tun uns leichter.
|
||||
|
||||
20:36 Christian: Ja.
|
||||
|
||||
20:37 Alex: Ja.
|
||||
|
||||
20:38 Christian: Das ist jetzt die... der... die Geburtsstunde der Thematik, ne?
|
||||
|
||||
20:41 Alex: Ja. Ich meine, du kannst ja auch mal ein A/B-Testing machen, ne?
|
||||
|
||||
20:46 Christian: Definitiv, ja. Also deswegen haben wir auch Primary und Secondary Product. Wir können das immer noch, ähm, umdrehen. Drehen wir hier auch um.
|
||||
|
||||
21:00 Christian: So, wir mal den Status auf. Klärungsbedarf. So.
|
||||
|
||||
21:19 Christian: Dann haben wir als nächstes...
|
||||
|
||||
21:24 Christian: Die Hotels.
|
||||
|
||||
21:27 Alex: Ja.
|
||||
|
||||
21:31 Christian: Ja, wobei ich jetzt hier, du hast ja schon die Serviceroboter hier auch erwähnt, jetzt hätte ich hier die Teppichreinigung als Erstes und die Nassflächenreinigung als Zweites gesehen.
|
||||
|
||||
21:46 Alex: Ja, es ist schon, ist schon... macht schon Sinn. Also wenn wir jetzt mal gucken, die beiden Key Accounts Motel One und Premier Inn, da ist Service Robotik nachgelagert.
|
||||
|
||||
21:54 Christian: Mhm. Ab 80 Betten, hätte ich jetzt gesagt?
|
||||
|
||||
21:56 Alex: Ja.
|
||||
|
||||
22:01 Christian: Personalnot, Housekeeping, Fachkräftemangel.
|
||||
|
||||
22:04 Alex: Mhm.
|
||||
|
||||
22:05 Christian: Gefährdete Bettenbereitstellung. Lobby-Optik.
|
||||
|
||||
22:08 Alex: Mhm. Mhm.
|
||||
|
||||
22:11 Christian: Nachtschichtlücke. Ja gut, reinigen, wenn sie eh nicht nachts, ne?
|
||||
|
||||
22:14 Alex: Kostendruck, ja.
|
||||
|
||||
22:17 Christian: Und, ähm... Ja, der Roboter übernimmt die Gänge, die langen Gänge. Manchmal auch die Zimmer. Zimmer können wir auch überlegen, hatten wir ja schon mal besprochen.
|
||||
|
||||
22:28 Alex: Das können wir so...
|
||||
|
||||
22:31 Alex: Und Grundqualität und so hast du es auch so, so allgemeine Sauberkeit, ja. 24 Stunden Sauberkeit, leise Reinigung der Lobby in der Nacht. Ja.
|
||||
|
||||
22:41 Christian: Dann haben wir da schon mal einen grünen Haken, das ist schon mal gut.
|
||||
|
||||
22:48 Christian: Dann haben wir als Nächstes Manufacturing. Ist jetzt nicht so der... Soll ich es mal auf P2 setzen? Die... alles was mit Produktion, mit diesen Transportrobotern...
|
||||
|
||||
22:58 Alex: Also ist jetzt hier nur... wir machen halt schon viel dort, ne?
|
||||
|
||||
23:03 Christian: Dann lassen wir es.
|
||||
|
||||
23:04 Alex: Das wird schon, also wir machen da doch echt einiges.
|
||||
|
||||
23:09 Christian: Sind da Transport oder ist Reinigung das Wichtigere?
|
||||
|
||||
23:12 Alex: Auch Reinigung.
|
||||
|
||||
23:13 Christian: Mhm.
|
||||
|
||||
23:14 Alex: Auch Reinigung. Also, ähm, wobei, also ich meine klar, wenn du eine... wenn du eine extra Kampagne machst. Also ich habe das wieder gesehen letzte Woche, war ich beim Kunden. Transportrobotik ist auch ein klassischer KMU gewesen. Sagt: "Hey, könnten Sie mir da das lösen, das Thema?" Kaufen sofort Lieferrobotik. Die haben ein Riesen Thema halt damit.
|
||||
|
||||
23:33 Christian: Mhm. Also...
|
||||
|
||||
23:35 Alex: Ich glaube, da können wir halt, da können wir, können wir, wenn wir eine Kampagne rein, also wenn wir sagen, wir wollen mal wirklich jetzt eine Kampagne nur auf Transportrobotik absetzen, da reingehen in KMUs, wir werden mit Sicherheit viele Nachfragen kriegen.
|
||||
|
||||
23:48 Christian: Das ist sicherlich auch tatsächlich eine Frage, wen wir anschreiben, ne? Also dass wir das da noch mal aussteuern können, dass eben der Lagerverantwortliche oder sowas oder für die ganzen Supply Chain Thematik, dass wir den mit dem Transportroboter anschreiben und den...
|
||||
|
||||
24:02 Alex: Ja, ja.
|
||||
|
||||
24:04 Christian: Ich glaube, das wird eh so ein Thema, aber das können wir erreichen. Also das, ähm, das ist das Ziel der Thematik.
|
||||
|
||||
24:12 Alex: Ja.
|
||||
|
||||
24:13 Christian: Ähm. Area hab ich jetzt ab 3000 Quadratmeter Innenfläche angenommen.
|
||||
|
||||
24:20 Alex: Genau. Mhm. Mhm.
|
||||
|
||||
24:23 Alex: Ja, weil du halt meistens halt auch nicht die Nettofläche dann da... Also wir brauchen da schon 3000 Quadratmeter, ja.
|
||||
|
||||
24:32 Christian: Die kann... die muss ich... also ich habe da auch schon Überlegungen. Es gibt so, so eine Art Map-API, wo man im Prinzip dann die Flächen aus dem All, also aus Satellitendaten auslesen kann.
|
||||
|
||||
24:45 Alex: Ja.
|
||||
|
||||
24:46 Christian: Ähm, damit wir da nicht raten müssen. Das muss man natürlich schauen, wie das mit verschiedenen Standorten dann geht, aber wir arbeiten ja immer mit einem konkreten Standort. Ähm, deswegen ist hier die Fläche, wenn wir sie irgendwo kriegen, ähm, der Hebel.
|
||||
|
||||
25:02 Alex: Ja, definitiv.
|
||||
|
||||
25:05 Christian: Wir haben hier natürlich verschmutzte Fahrwege, Arbeitssicherheit.
|
||||
|
||||
25:08 Alex: Aber mit Staplerverkehr würde ich aufpassen. Würde ich nicht reinnehmen, würde ist immer ein schwieriges Thema für uns. Deshalb würde ich, ähm...
|
||||
|
||||
25:21 Christian: Mach mal.
|
||||
|
||||
25:30 Alex: Es können die Roboter nicht.
|
||||
|
||||
25:32 Christian: Cleaning, also...
|
||||
|
||||
25:34 Alex: Also kann man schon, aber es würde zu Problemen führen.
|
||||
|
||||
25:37 Christian: Muss er dann drumherum fahren oder kann er die...
|
||||
|
||||
25:39 Alex: Ja, man würde solche Bereiche so ein bisschen versuchen auszugrenzen. Also es gibt in vielen Produktionsanlagen hast du dann zum Beispiel, wo so Hydraulikschläuche sind oder so, die können mal platzen. Und wenn der Roboter dort reinfährt, dann, das kriegt er gar nicht weg. Und dann schmiert er halt durch den ganzen Raum.
|
||||
|
||||
25:54 Christian: Das ist wie Hundescheiße, die durch den ganzen Raum fährt, ne?
|
||||
|
||||
25:56 Alex: Genau wie Hundescheiße und du brauchst richtig Chemie dafür und das ist halt so eine aggressive Chemie, die will ich für die Roboter schwierig, ja, ne.
|
||||
|
||||
26:02 Christian: Okay, passt.
|
||||
|
||||
26:04 Christian: Personalmangel, Reinigung ungern. Reinigungskräfte fehlen. Ähm, ich finde halt auch Produkt... also was halt auch in manchen Betrieben ist es halt auch so, das hören wir auch immer wieder, dass du, ähm, die Mitarbeiter machen das mit, ne? Das heißt, Mitarbeiter gehen dann von Produktivitäten.
|
||||
|
||||
26:20 Alex: Also dass du halt die Produktivität dadurch der Mitarbeiter halt einfach steigerst. Ähm. Und natürlich auch das Thema der Dienstleister, die dann da auch mit drin sind, ne? Also...
|
||||
|
||||
26:29 Christian: Das wollte ich gerade sagen.
|
||||
|
||||
26:30 Alex: Ähm, dass du halt durch die Dienst... also Unzuverlässigkeiten der Dienstleister, da sind sie nicht mit zufrieden, das ist ein sehr hoher Kostenblock und so weiter. Ähm.
|
||||
|
||||
26:41 Christian: Mhm.
|
||||
|
||||
26:43 Alex: Das ist auch schon immer ein großes Thema bei den... bei den großen Unternehmen. Ja?
|
||||
|
||||
26:50 Christian: Okay.
|
||||
|
||||
26:54 Christian: Ach Gott, jetzt springt er wieder. Wo waren wir?
|
||||
|
||||
27:08 Christian: Hier waren wir. CO2-Wert zu hoch?
|
||||
|
||||
27:14 Alex: Ja?
|
||||
|
||||
27:16 Christian: Sollen wir gleich lüften, ne? Egal. Wurscht. Das haben wir jetzt gemuted.
|
||||
|
||||
27:21 Alex: Ja, ich habe auf Mute gedrückt.
|
||||
|
||||
27:22 Christian: Gut. So, guck dir das Ding noch an.
|
||||
|
||||
27:24 Christian: Äh, es kommt aus Corona, direkt hier. Direkt nach 2025.
|
||||
|
||||
27:31 Christian: 26. Also, ähm, ja, Abnahmegarantie, permanente Reinigung verhindert Reifenpannen und Stopps.
|
||||
|
||||
27:38 Alex: Was meinst du mit Reifenpannen?
|
||||
|
||||
27:40 Christian: Ich glaube, das war eher auf Richtung Staplerverkehr. Also dass der irgendwo über was drüber fährt.
|
||||
|
||||
27:46 Alex: Er ist auch auf Transportrobotik dann gemünzt?
|
||||
|
||||
27:49 Christian: Können wir mal ganz kurz schauen. Ich glaube...
|
||||
|
||||
27:52 Alex: Weil Stapler haben keine... haben keine Gummireifen. Die haben Vollreifen, Vollgummireifen. Also die haben... können nicht einen Platten haben.
|
||||
|
||||
28:03 Christian: Das ist ein valides Argument. Dann werfen wir das direkt raus.
|
||||
|
||||
28:07 Alex: Und wir treten eigentlich auch nie gegen Stapler an. Weil wir das in der Art der Lieferrobotik nicht können.
|
||||
|
||||
28:15 Christian: Mhm.
|
||||
|
||||
28:16 Alex: Weil wir keine Paletten, also die... du musst vorstellen, die können keine Paletten heben, die Dinger, noch nicht.
|
||||
|
||||
28:20 Christian: Mhm.
|
||||
|
||||
28:22 Alex: Also wir sind mehr eigentlich innerhalb des Produktionsprozesses. Ware von A nach B.
|
||||
|
||||
28:27 Christian: Mhm.
|
||||
|
||||
28:38 Christian: Sicherheits-Upgrade, trockene, saubere Böden reduzieren Unfallrisiken.
|
||||
|
||||
28:43 Alex: Wobei Entlastung Facharbeiter konzentrieren sich auf Produktion nicht aufs Kehren. Das war dieses Thema, was wir...
|
||||
|
||||
28:49 Christian: Ja, genau.
|
||||
|
||||
28:50 Christian: Hatten. Audit ready, lückenlose Dokumentation der Reinigung. Weiß nicht, ob das ein Thema ist.
|
||||
|
||||
28:54 Alex: Ja. Das wäre was fürs Gesundheitswesen.
|
||||
|
||||
28:59 Christian: Das ist nicht gesund... fürs Gesundheitswesen?
|
||||
|
||||
29:05 Alex: Das war hier oben, ne?
|
||||
|
||||
29:10 Christian: Ich nehme das mal mit auf.
|
||||
|
||||
29:11 Alex: Oder ist es... Nee, bist du bei Event Location ist gerade. Ich glaube, du musst noch... Guck mal bitte weiter runter. Also hier sehe ich Event... müsstest du... müsstest du [?].
|
||||
|
||||
29:19 Christian: Ich nehm's mal hier unten auf. Die anderen werden dann neu generiert werden.
|
||||
|
||||
29:35 Christian: Okay. Dann haben wir die Fertigung.
|
||||
|
||||
29:43 Alex: Aber warte mal ganz kurz mal...
|
||||
|
||||
29:46 Christian: Es ist...
|
||||
|
||||
29:48 Alex: Also ich würde in der Produktion, finde ich eigentlich, ist der... ist der... also den den Schmerzpunkt, den ich eigentlich immer drücke bei denen, ist halt das Thema der Kosten, ne? Also durch den Einsatz von Robotik gerade bei den Produktionsunternehmen reduzierst du halt natürlich signifikant deine Betriebskosten. Und steigerst natürlich dadurch wieder die Wettbewerbsfähigkeit, ne? Und schaffst natürlich auch, wenn du im Bereich Automatisierung einsteigst, einen Wettbewerbsvorteil zu der Konkurrenz. Also ich spreche da immer so ganz gerne zum großen Thema dann immer vom Wohlstandserhalt in Deutschland, ne? Das ist halt dann schon sehr großgegriffen, das brauchen wir hier nicht. Aber dieses Thema der Betriebskosten senken ist schon ein großes Thema, ja, und auch Steigerung der Produktivität. Finde ich so ein bisschen...
|
||||
|
||||
30:42 Christian: Dann kann ich gerne noch mal ein bisschen in die Richtung schärfen, dass auch... das ist jetzt ein bisschen zu staplerlastig, dass wir die Stapler da komplett rausnehmen. Weil gegen die werden wir nicht fahren.
|
||||
|
||||
30:52 Alex: Also wir sind... wir sind... ja, das können wir noch nicht. Also wir können auch nicht die... wir können auch nicht die hochkomplexen... die hochkomplexen Logistikprozesse abbilden, das können wir auch nicht. Aber so einfache Sachen können wir eigentlich super gut machen damit.
|
||||
|
||||
31:09 Christian: Mhm. Dann mache ich hier auch noch mal den orangen hin.
|
||||
|
||||
31:17 Christian: Dann haben wir als Nächstes: Infrastructure Public. Also alles was Messehallen, Eventreinigung, Arenen...
|
||||
|
||||
31:28 Alex: Ja. Nicht zu... also wenn... ja.
|
||||
|
||||
31:31 Christian: Die haben auch Teppich, oder? Oder ist es nur...
|
||||
|
||||
31:35 Alex: Teils. Teils ja. Teils ja. Ähm, aber in der Regel eigentlich...
|
||||
|
||||
31:43 Christian: Können wir Teppich rausnehmen, oder?
|
||||
|
||||
31:44 Alex: Würde ich fast rausnehmen. Wir haben eher das Thema Kehr...
|
||||
|
||||
31:46 Christian: Ah nee, Entschuldigung, Entschuldigung. Das war... Kehren hab ich drin. Also das ist die Outdoor... Outdoorreinigung, ne?
|
||||
|
||||
31:52 Alex: Ja. Genau. Kann auch genauso Indoor sein, ne? Also, ähm...
|
||||
|
||||
31:56 Christian: Ja, so Messehallen, das ist ja... ist ja meistens so dieser schwarze...
|
||||
|
||||
32:01 Alex: Genau. Keine Ahnung. Ja.
|
||||
|
||||
32:03 Alex: Also da auf jeden Fall, ne? Also Kehren ist da halt auch schon ein wichtiges Thema, ja. Wobei, gibt leider noch nicht so große Roboter, die den ganzen Müll wirklich halt von so einem ganzen Stadion und Spiel wegräumen, ne? Also das kriegen wir auch nicht hin mit den Dingern, die wir haben.
|
||||
|
||||
32:21 Christian: Genau. Was haben wir hier? Turnaround-Zeit. Messehallen müssen über Nacht wieder sauber sein. Wie gesagt, das ist das Thema, ich weiß tatsächlich nicht, wie es aktuell ist, ob die Stände auch mit gereinigt werden oder ob nur die Gangflächen. Also ob die Messe... wenn es eine Messe ist, ob während der Messe...
|
||||
|
||||
32:42 Alex: Nee. Nee, das machen die glaube ich... nee, da kommst du nicht rein.
|
||||
|
||||
32:45 Christian: Weil die sind ja teilweise auch erhöht und so weiter.
|
||||
|
||||
32:47 Alex: Du... das Thema ist halt, ähm, wenn du so einen Roboter reinbringst in die Messe. Also du könntest theoretisch sagen... ähm... ist jetzt halt sehr speziell bei einer Messe. Ähm, da ist ja der Aufbau immer anders. Und du kannst jetzt nicht dann die ganze Halle, sage ich jetzt mal, wenn du ein Mapping machst, ähm, alle Hindernisse rausnehmen und da lässt ihn da durchfahren, weil es halt immer irgendwie ein bisschen anders ist in der Punkt der Wegeführung. Ähm, du müsstest dich eigentlich fokussieren auf die Wegeführung dort, dann könntest du das im Großen und Ganzen auch übernehmen. Oder halt natürlich am Ende nach dem Abbau, dann kommst du und lässt halt reinfahren. Aber wer macht es? Das macht nicht die Messe selber, sondern das macht immer ein Dienstleister.
|
||||
|
||||
33:35 Christian: Mhm.
|
||||
|
||||
33:36 Alex: Das heißt, du hast bei diesen ganzen großen Messedingern immer halt irgendwie keine Ahnung, sowas wie Wisag oder Dussmann, die danach dann einmal da durchfegen oder halt dann auch während... sagen wir mal am letzten Aufbautag dann über Nacht diese Reinigung übernehmen. Was du halt natürlich auch machen könntest... ist jetzt schon sehr detailliert... dass die Messe das Know-how hat, diese Roboter auch kurz zu mappen und dann einfach durchschickt über den Zeitraum der Messe.
|
||||
|
||||
34:03 Christian: Das hab ich auch letztens beim TÜV Nord auch mitbekommen, dass in München glaube ich genauso was besprochen, dass sie einmal dann das Mapping durchführen.
|
||||
|
||||
34:11 Alex: Ja, genau. Da war... da waren die Menschen... [unverständlich].
|
||||
|
||||
34:15 Christian: Aber natürlich, das sind halt riesen Flächen. Ähm. Ja.
|
||||
|
||||
34:20 Alex: Übrigens, was mir einfällt: Du kannst jetzt gerne auch bei uns sitzen. Weil ich... die Ellie ist viel im Homeoffice, die Selina ist die nächsten zwei Wochen eh nicht da, krank. Und da kannst du auch mal schnell zum Axel oder wenn ich da bin...
|
||||
|
||||
34:36 Christian: Ja klar, gerne.
|
||||
|
||||
34:37 Alex: Also ist auch ruhiger, ne? Also das...
|
||||
|
||||
34:39 Christian: Das Ruhiger ist so ein Stichpunkt, weil...
|
||||
|
||||
34:41 Alex: Biet ich dir gerne an.
|
||||
|
||||
34:42 Christian: Sind ja schon viel am Telefonieren gegenüber.
|
||||
|
||||
34:43 Alex: Ja, ja, weil ich weiß... da sitzt du deutlich besser, glaube ich, aktuell.
|
||||
|
||||
34:47 Christian: Aber auf der anderen Seite krieg ich auch viel mit. Das ist natürlich auch nicht...
|
||||
|
||||
34:51 Alex: Ja. Wie du magst. Also...
|
||||
|
||||
34:52 Christian: Ich bleib erstmal mal da.
|
||||
|
||||
34:54 Alex: Okay.
|
||||
|
||||
34:55 Christian: Ähm, ja Müllmengen, das ist natürlich gerade so ein Thema, was du gesagt hast, ob die das überhaupt...
|
||||
|
||||
34:59 Alex: Kriegst du nicht weg. Also also mit unseren... mit unseren Dingern kriegst du das nicht weg. Also ich würde da eher dieses Thema der Flexibilität und und, ähm, ja ist halt immer das Thema auch der Kosten, ne? Also im ganzen Event-Gastronomiebereich, die haben halt, ähm, die haben halt sehr geringe Margen, ja, ähm, und dadurch müssen die halt auf solche Kosten, solche Blöcke, so große Blöcke wie die Reinigung natürlich drauf achten, ne? Also...
|
||||
|
||||
35:30 Christian: Mhm.
|
||||
|
||||
35:31 Alex: Ist schon ein Thema.
|
||||
|
||||
35:33 Christian: Ich nehme das mal so auf. Also nur als Hintergrund, warum wir das machen. Ähm, das hier wird dann die Grundlage für diese Matrixmultiplikation, wo es dann die Rollen und die, also die Painpoints der Rolle mit dem Painpoints der Branche multipliziert wird. Das ist die Grundlage dafür.
|
||||
|
||||
35:52 Alex: Mhm.
|
||||
|
||||
35:53 Christian: Aber das passiert alles dann durch ein KI-Modell, deswegen kann ich auch reinschreiben, das ist es nicht. Und das checkt das dann schon, ja.
|
||||
|
||||
36:03 Christian: So, ähm. Gains... Einsatz von Roboterschaft, die Fläche über Nachts, Verfügbarkeit, Roboter stehen bereit. Messehallen zu großen... Ja. Ja. Passt soweit, ne?
|
||||
|
||||
36:21 Alex: Warte mal. Und, äh... Ja. Ja.
|
||||
|
||||
36:31 Christian: Gut. Dann haben wir als Nächstes die Flughäfen, Bahnhöfe und so weiter. Hab ich jetzt Wet Surface und Sweeper gesehen, also die...
|
||||
|
||||
36:47 Alex: Mhm. Mhm. Kannst du auch umdrehen, ne? Aber ich glaube...
|
||||
|
||||
36:56 Christian: Da ist halt auch wieder das Thema... ich ich überlege jetzt gerade nur von der Ansprache halt. Der Hintergrund ist, dass kein Flughafen oder kein kein kein Bahnhof macht es in Eigenregie. Das heißt, die haben immer einen Dienstleister mit drin. Ähm.
|
||||
|
||||
37:18 Christian: Naja, die Frage ist, ähm, der Bahnhof beschafft ja den Dienstleister, ja? Wenn der Bahnhof jetzt sagt: "Ja, Freunde, wir haben zwar noch einen Vertrag bis 2026, aber ab dann haben wir einen Reinigungsroboter, wir brauchen zwei Leute weniger." Dann kann der Dienstleister da nichts gegen sagen.
|
||||
|
||||
37:34 Alex: Ja genau, die Dienstleister, die Großen stehen ja auch dann aber auch schon mit Robotik an und bieten halt dann mit Robotik an, so. Ähm, deshalb sagt dann der Dienstleister: "Warum soll ich mir die Roboter anschaffen? Ich mach's einfach Grundlage meiner Ausschreibung." Das passiert schon. Warum ich jetzt gerade so ein bisschen zucke ist, ähm, ich sehe im Bereich Flughäfen zum Beispiel durchaus ein sehr interessantes Potenzial für Service Robotik. Also diese Greeting Robots beispielsweise durch OrionStar. Und da kam auch beispielsweise vom Flughafen München eine Anfrage von denen.
|
||||
|
||||
38:12 Christian: Die Frage ist, ist das wirklich was, womit wir Geld machen können? Oder ist das eher so ein Prestige-Ding und...
|
||||
|
||||
38:17 Alex: Perspektivisch sehe ich da schon Potenzial, ne? Also, ähm, aber... lass es jetzt mal so.
|
||||
|
||||
38:29 Christian: Ich meine, was ja auch geil ist, sind diese Transportroboter, wo du dich dann draufsetzen kannst. Also diese fahrenden Rollstühle, so so...
|
||||
|
||||
38:36 Alex: Ja, also in in in Shenzhen am Flughafen, da konntest du den T300 für deine Koffer nehmen. Wird jetzt ein Flughafen sagen, ich stelle mir jetzt da 20 Dinger von hin? Glaube ich würden sie nicht machen. Ja, also da ist der Wagen halt das günstigere Mittel. Aber lass es mal so drin, also vielleicht macht's mehr Sinn jetzt im ersten Schritt.
|
||||
|
||||
38:59 Christian: Genau so. Dann haben wir alle Freizeitparks, Zoos. Da hätte ich jetzt den Sweeper gesehen. Du sagst auch den den Serviceroboter.
|
||||
|
||||
39:09 Alex: Also einen Tierpark stelle ich mir schwer vor.
|
||||
|
||||
39:13 Christian: Wieso? Da fährt so eine Kehrmaschine umeinander und...
|
||||
|
||||
39:16 Alex: Ja, und dann fährt die durch die Hundeschei... durch die Pferdekacke und so durch.
|
||||
|
||||
39:19 Christian: Naja, dann halt die Wege, nicht die Gehege.
|
||||
|
||||
39:23 Alex: Ja, ja. Ja.
|
||||
|
||||
39:28 Christian: Ich hol das, mach mal jetzt mal den den Serviceroboter da noch rein. Aber da brauchen wir größere Maschinen. Also ich glaube nicht, dass wir... Aber ist egal.
|
||||
|
||||
39:41 Christian: Ich weiß, was du meinst. Ist dann eher so ein...
|
||||
|
||||
39:45 Alex: Aber muss man... wäre auch ein Learning, das muss man sich mal angucken, also...
|
||||
|
||||
39:48 Christian: Machen wir den Serviceroboter da rein.
|
||||
|
||||
39:56 Christian: So, Outdoor Park, da haben wir sie. Ähm. Das sind die kilometerlangen Wege, die zu reinigen sind. Ähm. Also wie gesagt, große Kehrmaschinen. Das könnte sich der der MC MT X1 sein.
|
||||
|
||||
40:37 Alex: Ja, deshalb würde ich da eigentlich das Thema... diesen diesen VIGGO 100 oder wie er heißt, diese größere Kehrmaschine, die halt wirklich... die zieht da für die Arbeit. Genau, Autonomix, den wir da...
|
||||
|
||||
40:50 Christian: Ich weiß nicht, was es gibt... also den...
|
||||
|
||||
40:53 Alex: Ja. Also wir haben jetzt... hätten jetzt glaube ich kein Gerät aktuell...
|
||||
|
||||
40:56 Christian: ...aktuell noch nicht, das kommt aber glaube ich das...
|
||||
|
||||
41:00 Alex: Ja, ähm. Kann ich auch auf Prio 2 runtersetzen.
|
||||
|
||||
41:06 Christian: Ne, ich sehe in den Freizeit... also ich würde halt in den Freizeiteinrichtungen, also da, wo du überall diese... dort eigentlich in der Gastronomie, in den Innenbereichen. Für einen Außenbereich...
|
||||
|
||||
41:19 Christian: Das ist exklusiv jetzt Außenbereich. Das ist... exklusiv die großen Parks, ne?
|
||||
|
||||
41:21 Alex: Ja, okay. Area Outdoor. Ja, okay, dann passt es ja. Ja, ja.
|
||||
|
||||
41:26 Christian: Aber dann würde ich's Prio 2 sehen, weil wir da eher noch nichts haben.
|
||||
|
||||
41:30 Christian: Mhm. Ähm, notier ich mir direkt. Oder Service eben. Wenn du sagst, dass das da halt ein Thema ist. Dass da ein Roboter rumläuft und dir Wasser an Platz bringt.
|
||||
|
||||
41:59 Alex: Was ich... Achso, warte mal. P2. Nee, passt.
|
||||
|
||||
42:09 Christian: Dann haben wir noch hier, ähm, Schwimmbäder, Thermen und so weiter. Mhm. Das ist Wet Surface.
|
||||
|
||||
42:15 Alex: Ja.
|
||||
|
||||
42:18 Christian: Ähm. Ja, wir haben Rutschgefahr, Wasserpfützen, Unfallgefahr. Hygiene-Audit, Keimbelastung auf Barfußwegen.
|
||||
|
||||
42:29 Alex: Mhm.
|
||||
|
||||
42:30 Christian: Dauereinsatz manuelles Wischen im laufenden Betrieb. Stört Gäste. Also das sehe ich oft bei uns im Schwimmbad, die laufen ständig mit dem Ding da umeinander. Ähm.
|
||||
|
||||
42:39 Alex: Ja, aber da kannst du, das glaube ich... wenn... ich glaube, die werden sich nicht trauen, Roboter fahren zu lassen.
|
||||
|
||||
42:43 Christian: Nee?
|
||||
|
||||
42:45 Alex: Weiß ich nicht, aber... ja. Warum? Ist ein Argument.
|
||||
|
||||
42:49 Christian: Der Bademeister hat dort eine andere Aufgabe, nämlich Retten, nicht Putzen.
|
||||
|
||||
42:52 Alex: Ja.
|
||||
|
||||
42:53 Christian: Aber die haben ja, die haben ja dafür, ähm, ja, Putzpersonal, aber das kannst du halt sparen. Und ist natürlich, äh, Gains: Sicherheit. Desinfektion ist ein Thema. Hygienestandards.
|
||||
|
||||
33:05 Christian: Dann haben wir das auch auf grün. Was haben wir hier unten noch? Die... jetzt haben wir die die Warehouses, Logistics. Hätte jetzt tatsächlich auch die die Wet Surfaces gesehen und die Sweeper und nicht die Transport. Die T300 hätte ich jetzt hier nicht gesehen.
|
||||
|
||||
43:34 Alex: Im Warehouse?
|
||||
|
||||
43:35 Christian: Mhm.
|
||||
|
||||
43:36 Alex: Im Warehouse sehe ich eher die Kehrmaschine als Erstes. Warum? Weil du in den... du hast da, die Verschmutzung ist eine andere. Und du hast erstmal das Thema der Paletten. Dinger. Und der, das, der Anspruch an Nassreinigung ist im ersten Schritt nicht so hoch. Die wollen das zwar, aber, ähm...
|
||||
|
||||
44:00 Christian: Naja, warte mal, aber wenn wir jetzt den ansprechen. Die checken das meistens ja auch gar nicht, dass sie erst vorkehren müssen. Das ist ja das Thema. Also wie spreche ich den an? Also...
|
||||
|
||||
44:17 Alex: Nee, ich würd mal, ich würd mal die... ich würd mal Kehr... ich würd mal Kehrrobotik, weil der... der Anspruch an Rand... die die fahren da schon durch mit ihren Maschinen, aber die kennen dann auch die Probleme, von denen wir dann sprechen. Aber, ähm... lass mal die Kehrmaschine drin.
|
||||
|
||||
44:33 Christian: Mhm. FOD-Risiko, keine Ahnung, was das heißt. Äh, sie Reifenpannen verursachen bei LKWs oder Staplern. Staplern wie gesagt... ich weiß, die haben Vollgummireifen. Nehm ich hier raus.
|
||||
|
||||
44:48 Alex: Aber beim LKW, also...
|
||||
|
||||
44:49 Christian: Ja, da geht's teilweise auch um die Logistikparks, weißt du, irgendwelche, äh, großen Außenflächen, die da als Fahrwege oder... das ist weiter hinten, ne?
|
||||
|
||||
44:56 Alex: Mhm.
|
||||
|
||||
44:57 Christian: Äh, Staubbelastung, dass die Sensoren verschmutzt werden.
|
||||
|
||||
45:03 Alex: Mhm.
|
||||
|
||||
45:05 Christian: Ja, Außenwirkung. Ja. Und Nachtschicht halt, ne? Das ist...
|
||||
|
||||
45:09 Alex: Ja.
|
||||
|
||||
45:12 Christian: Dann haben wir hier die die die Dauerreinigung, dass die Pannen reduziert. Staubschutz, Staubschutz. Sauberkeit, reinigt nachts, wenn der Betrieb ruht.
|
||||
|
||||
45:26 Christian: Ich hab mal Klärungsbedarf, weil wir hier den Fokus geändert haben.
|
||||
|
||||
45:37 Christian: Oder haben wir da zwei... Ach so, das habe ich mal neu eingebaut. Die... also wir haben noch Others, wenn's wenn's jetzt gar nichts zuweilen kann, das ist eher Notlösung. Die Schulen haben wir neu hinzugefügt. Die Reinigungsdienstleister haben wir zugefügt, deswegen hab ich da noch keine Punkte. Dann haben wir Retail Food, also die Lebensmittelmärkte.
|
||||
|
||||
46:01 Christian: Lebensmittel-Einzelhandel und so weiter. Ich hab jetzt mal nur zur Einordnung, dass bei uns der der Kaufland hat sechseinhalbtausend Quadratmeter, der Aldi 1800 Quadratmeter, hab ich mal ausgemessen, damit man das ungefähr einschätzen kann.
|
||||
|
||||
46:13 Alex: Aber die wirst du nicht im Einzelnen an... erreichen.
|
||||
|
||||
46:17 Christian: Das ist klar. Ja. Dass der das nicht selbst entscheidet. Ähm, das mit der Ansprache müssen wir generell dann schauen. Wir hatten jetzt hier auch mal die die Parkplatzthematik, ähm...
|
||||
|
||||
46:31 Alex: Warte mal, was hast du Primary... ich... auf Kehren gesetzt?
|
||||
|
||||
46:35 Christian: Nee, nee. Wet Surface.
|
||||
|
||||
46:36 Alex: Okay.
|
||||
|
||||
46:40 Christian: Und Serviceroboter. Ja gut. Ist jetzt dann die Frage, ob die Parkplätze wichtiger sind oder die die POS... also POS Roboter hab ich jetzt gar nicht... noch gar nicht drin.
|
||||
|
||||
46:49 Alex: Welche?
|
||||
|
||||
46:50 Christian: POS, also die Point of Sales Roboter, die irgendwie so Marketing Displays rumfahren.
|
||||
|
||||
46:54 Alex: Ach so. Ja.
|
||||
|
||||
46:57 Christian: Ist halt auch die Frage, wie gesagt, was was ist jetzt der Fokus.
|
||||
|
||||
47:01 Alex: Fokus, ne? Ja.
|
||||
|
||||
47:04 Christian: Hast du jetzt Meeting, meintest du?
|
||||
|
||||
47:05 Alex: Ja, ich hab's ein bisschen kohle mäßig.
|
||||
|
||||
47:08 Christian: Dann müssen wir jetzt, äh, einen zweiten noch mal machen, ne?
|
||||
|
||||
47:11 Alex: Wann machen wir das?
|
||||
|
||||
47:12 Christian: Ähm...
|
||||
|
||||
47:13 Alex: Ich schau mal ganz kurz rein, ich geh dann mal schon... Ähm, ich würde auch gerne nämlich das Thema, was wir auch angesprochen haben wegen den KIs... KI-Tools noch mal. Ist echt wichtig, finde ich. Ich bin morgen eigentlich und eigentlich auch am Donnerstag im Urlaub. Da nehm ich die Kinder ab. Ähm. Freitag.
|
||||
|
||||
47:45 Christian: Dann machen wir das Freitag.
|
||||
|
||||
47:46 Alex: Ja, stell ich... schieb den Termin von heute nochmal um auf Freitag.
|
||||
|
||||
47:49 Christian: Ja, passt.
|
||||
|
||||
47:51 Alex: Okay.
|
||||
|
||||
47:55 Alex: Gehen wir schon mal rüber.
|
||||
|
||||
47:56 Christian: Alles klar.
|
||||
|
||||
47:58 Alex: Passt schon.
|
||||
|
||||
48:00 Christian: Aber wir sind ja, sind ein bisschen vorangekommen.
|
||||
|
||||
48:02 Alex: Du sind gut vorangekommen.
|
||||
248
docs/transkript_verticals2.txt
Normal file
248
docs/transkript_verticals2.txt
Normal file
@@ -0,0 +1,248 @@
|
||||
[00:00:01] Speaker A: Was äh brauche ich auf jeden Fall, damit wir hier dann ähm eine gute Basis haben?
|
||||
[00:00:07] Speaker B: Ja.
|
||||
[00:00:10] Speaker A: Gut, ähm sollen wir uns die Sachen anschauen, die wir letztens auf ähm Klärungsbedarf gelegt hatten oder sollen wir mit den Sachen starten, die noch offen sind?
|
||||
[00:00:22] Speaker B: Flexibel, kannst können erst die Klärungsbedarf vielleicht noch mal angucken, dann sind wir da vielleicht schneller durch.
|
||||
[00:00:28] Speaker A: Denke ich auch, ja.
|
||||
[00:00:32] Speaker A: Also, hier hatten wir die Reinigung als Primary Produkt, das haben wir hier klebrige Böden bei bei bei Gastronomie sind wir jetzt.
|
||||
[00:00:41] Speaker A: Klebrige Böden, verschüttete Getränke und Speisereste und so weiter stören das Ambiente.
|
||||
[00:00:47] Speaker A: Ähm Randzeitenproblem nach Schließung ist es schwer Personal für die Grundreinigung zu finden, bzw. Nachtzuschläge ist das Thema.
|
||||
[00:00:56] Speaker B: Mhm.
|
||||
[00:00:57] Speaker A: Und das äh die Service Roboter haben wir hier als Secondary Produkt.
|
||||
[00:01:04] Speaker A: Teller Taxi Servicekräfte verbringen 80 % der Zeit mit Laufen Küche Gast statt mit Verkaufen und Beratung, weiß ich nicht, ob das mit mit Verkaufen Betreuung so ein so ein Thema ist, aber am meistens so die einfachen Tätigkeiten so ähm die Getränke oder sowas zu bringen, das machen die wahrscheinlich auch in den in den Restaurants gerne durch sowas ähm ohne sich dann das das Trinkgeld jetzt zu gefährden durch Roboter, ne?
|
||||
[00:01:31] Speaker B: Ja.
|
||||
[00:01:31] Speaker A: Ist ja auch immer ein Thema.
|
||||
[00:01:33] Speaker B: Ja.
|
||||
[00:01:34] Speaker B: Ähm Ja, also ja, ja, ein, also äh kassieren ja nicht ab, ne?
|
||||
[00:01:43] Speaker B: Also, aber ich glaube Nee, doch das das nicht, das das nicht, aber ähm dass dass äh die Leute dann halt denken, ja, ich habe ja du hast mir mein Trink nicht gebracht, wieso soll ich dann Trinkgeld geben so so ungefähr.
|
||||
[00:01:56] Speaker B: Ja, also musst also glaube ich nur in Einzelfällen, weil normalerweise der der Roboter, also dort, wo ähm wo du die ähm äh Roboter quasi direkt wie so ein Self Service einsetzt, da wäre eher so ähm dass du irgendwo am Counter bestellst und dann setzt du dich hin.
|
||||
[00:02:20] Speaker B: Ja, und ähm da wo den Roboter unterstützend einsetzt in der Gastronomie, fährt quasi der Roboter hin und der und und und die die Bedienung stellt trotzdem noch den Teller drauf.
|
||||
[00:02:30] Speaker A: Na klar.
|
||||
[00:02:30] Speaker B: Nicht, dass du selber den.
|
||||
[00:02:32] Speaker B: Insofern glaube ich ein bisschen unkritisch.
|
||||
[00:02:34] Speaker A: Ja, ich weiß, was du meinst.
|
||||
[00:02:35] Speaker A: Passt.
|
||||
[00:02:36] Speaker B: Ja.
|
||||
[00:02:37] Speaker A: Ähm dann Personalmangel, zu wenig Kellner führen zu langen Wartezeiten, ähm kalten Speisen und genervten Gästen, das ist voll das Thema.
|
||||
[00:02:47] Speaker B: Ja.
|
||||
[00:02:47] Speaker A: Und die Gains hast du sonst noch was, wo du sagst ähm an Paint für die Restaurants, was jetzt hier nicht genannt wurde oder was was ganz wichtig ist?
|
||||
[00:03:02] Speaker B: Der Service ähm für beides, also für Reinigung äh hatten wir gesagt Nachtzuschläge und so weiter ist das Thema ähm Ja, Nacht Nachtzuschläge, ja.
|
||||
[00:03:18] Speaker B: Ähm Kannst du mir noch mal vorlesen, die du jetzt drin hast, weil ich bin gar ich bin im Auto, ne?
|
||||
[00:03:23] Speaker B: Ich kann sie nicht.
|
||||
[00:03:24] Speaker B: Kannst du die noch mal das.
|
||||
[00:03:25] Speaker A: Also wir hatten bei bei Cleaning Indoor hatten wir klebrige Böden, verschüttete Getränke und Speise solche Bildschirmsharing dann ausmachen, das siehst du jetzt wahrscheinlich eh nicht, oder?
|
||||
[00:03:35] Speaker B: Ja, ich gucke so so ein bisschen mal drauf rein, aber ich kann so ein bisschen reinzoomen, aber Nee, dann dann dann dann mache ich es komplett auf der Tonspur, weil das lenkt dich sonst nur ab.
|
||||
[00:03:45] Speaker A: Ja, ich habe jetzt mal Bildschirm weggemacht.
|
||||
[00:03:48] Speaker A: Also, wir hatten ähm bei bei Cleaning hatten wir klebrige Böden, verschüttete Getränke und Speisereste wirken unhygienisch und stören das Ambiente.
|
||||
[00:03:56] Speaker A: Ähm Randzeitenproblem nach Schließung ist es schwer Personal für die Grundreinigung zu finden, Nachtzuschläge, das ist das Thema für für die Reinigung in der Gastronomie und im Bereich Teller Taxi ähm Servicekräfte verbringen 80 % der Zeit zum mit Laufen Küche zu Gast.
|
||||
[00:04:20] Speaker B: Ja, ja, ja, ja.
|
||||
[00:04:21] Speaker A: Statt mit statt mit Verkaufen bzw. Betreuung, Personalmangel, zu wenig Kellner führen zu lange Wartezeiten, kalten Speisen und genervten Gästen.
|
||||
[00:04:31] Speaker B: Ja, ist sehr gut.
|
||||
[00:04:32] Speaker A: Genau.
|
||||
[00:04:32] Speaker A: Sollen wir die Games auch noch durchgehen, das ist dann sowas wie also ist dann im Prinzip die die die Negierung des Ganzen eben makelloses Ambiente, saubere Böden als Visitenkarte des Restaurants, Zuverlässigkeit, die Grundreinigung findet jede Nacht garantiert statt.
|
||||
[00:04:50] Speaker A: Und im Bereich Service mehr Umsatz am Gast Servicekraft hat mehr Zeit für Empfehlungen, Wein, Dessert und Abselling, Entlastung Roboter übernimmt das schwere Tragen Tablett Personal bleibt in im Gastraum präsent.
|
||||
[00:05:05] Speaker B: Ja, perfekt, perfekt.
|
||||
[00:05:08] Speaker B: Hätte ich nicht anders gesagt.
|
||||
[00:05:10] Speaker A: Super, dann haben wir das da weg.
|
||||
[00:05:13] Speaker A: Dann haben wir Industry Manufacturing, also alles was in dem Bereich Maschinenbau, Produktion, Automotive 247 Betrieb geht.
|
||||
[00:05:23] Speaker A: Da haben wir ähm das Wet Surface Cleaning auch als Primary und Secondary hatten wir Transportroboter.
|
||||
[00:05:31] Speaker B: Ja.
|
||||
[00:05:32] Speaker A: Wir haben ähm beim Primary Produkt, die Paint ist ähm Prozesssicherheit, Staub und Abrieb Abrieb auf Fahrwegen gefährdet empfindliche Sensorik z.B. von FTS und die Produktqualität.
|
||||
[00:05:50] Speaker A: Arbeitssicherheit Rutschgefahr durch feine Staubschichten oder ausgelaufene nichtchemische Flüssigkeiten erhöhen das Unfallrisiko und Ressourcenverschwendung hochbezahlte Fachkräfte müssen Maschinen stoppen, um ihr Umfeld zu reinigen.
|
||||
[00:06:07] Speaker B: Ja, ja, ja, ja, ja.
|
||||
[00:06:09] Speaker A: Dann ähm für den gehen wir gleich die Games durch.
|
||||
[00:06:14] Speaker A: Konstante Boden Bodenqualität, definierte Sauberkeitsstandards Audit ready rund um die Uhr, Unfallschutz, Reduktion von Arbeitsunfällen durch rutschfreie Verkehrswege.
|
||||
[00:06:27] Speaker B: Ja.
|
||||
[00:06:29] Speaker A: Dann haben wir ja.
|
||||
[00:06:31] Speaker B: Ähm äh ne, Kosten hast du ja immer mit dabei, hast du gesagt.
|
||||
[00:06:34] Speaker A: Kosten das ist je nachdem welche Rolle wir anschreiben, ne?
|
||||
[00:06:36] Speaker B: Ja, ja, okay.
|
||||
[00:06:38] Speaker A: Ja.
|
||||
[00:06:38] Speaker A: Dann ähm haben wir die das Secondary Produkt Transport, da geht's um Intransparenz und Suchzeiten, Facharbeiter unterbrechen die Wertschaffende Wertschöpfung für unproduktive Material Beschaffung C Teile C Teile holen oder Mikrostillstände fehlendes Material in der Linie stoppt die stoppt den Takt.
|
||||
[00:07:05] Speaker B: Mhm.
|
||||
[00:07:06] Speaker A: Und als äh Gains entsprechend dann Just in Time Logistik, automatisierter Nachschub hält die Fachkraft Wertschaffen an der Maschine und Flussoptimierung Stabilisierung der Taktzeit durch OEE durch und OEE durch zuverlässige verlässliche Materialfluss.
|
||||
[00:07:30] Speaker B: Mhm.
|
||||
[00:07:31] Speaker B: Passt für mich.
|
||||
[00:07:32] Speaker B: Ja auch gut, sehr gut.
|
||||
[00:07:34] Speaker A: Dann haben wir die Communities, also Schulen, Gemeindeinrichtungen, Turnhallen.
|
||||
[00:07:40] Speaker A: Wir haben hier ähm das nur den den Wet Surface Roboter mit der Großflächenreinigung, Sporthallen, Aulen und Flure binden enorm viel Personalstunden.
|
||||
[00:07:52] Speaker A: Ähm Kommunen müssen sparen, Reinigungskosten sind größer ist ein großer Posten und Nutzungskonflikte Reinigung muss in engen Zeitfenstern zwischen Schulvereins Vereinssitzung Vereinsnutzung gefolgen.
|
||||
[00:08:11] Speaker B: Ja, ja, ja.
|
||||
[00:08:14] Speaker B: Äh Zeitfenster weiß ich jetzt nicht.
|
||||
[00:08:16] Speaker A: Mhm.
|
||||
[00:08:17] Speaker B: Weil du meist, weil die meisten sagen ich habe 22 Uhr bis nächsten Tag Mhm. äh 7 Uhr oder da genug Zeit habe in der Regel das zu machen, also dann nehme ich den letzten Punkt komplett raus mit dem Nutzungskonflikt, weil hast recht, wenn die wenn die nachts fahren, dann stört das keinen.
|
||||
[00:08:36] Speaker B: Ja normal.
|
||||
[00:08:37] Speaker B: Ja, normalerweise ist eigentlich der Game, ne?
|
||||
[00:08:41] Speaker B: Der Stelle.
|
||||
[00:08:42] Speaker B: Das sie das halt nicht machen müssen, weil die ähm das Personal zu den Zeiten schwer bekommen, ja und halt viele äh Aufschläge zahlen.
|
||||
[00:08:53] Speaker B: der Pain.
|
||||
[00:08:54] Speaker A: Ich ich nehme das gerne noch mal auf.
|
||||
[00:08:56] Speaker B: Bei der Turnhalle bei der Turnhalle oder Genau.
|
||||
[00:09:00] Speaker A: Ähm Hallo.
|
||||
[00:09:19] Speaker A: So, als Gain haben wir dann an dieser Stelle ähm Kosteneffizienz Reduktion der Reinigungskosten pro Quadratmeter.
|
||||
[00:09:30] Speaker A: Ähm Flexibilität Reinigung kann nachts oder an in Randzeiten erfolgen und Werterhalt schon regelmäßige Wartung Reinigung verlängert die Lebensdauer von Sportböden.
|
||||
[00:09:48] Speaker B: Boah, ähm Das kann ich jetzt nicht 100 % bestätigen.
|
||||
[00:09:56] Speaker A: Können wir rausnehmen, wenn es zu viel ist, ne?
|
||||
[00:09:59] Speaker B: Ja, aber das könnte man vielleicht noch mal Sicherheitshalber über den validieren.
|
||||
[00:10:07] Speaker B: Den letzten Punkt.
|
||||
[00:10:09] Speaker B: Ähm könnte sein, dass es stimmt, kann ich jetzt aber nicht versprechen.
|
||||
[00:10:13] Speaker A: Mhm.
|
||||
[00:10:18] Speaker A: Habe ich mir notiert, das müssen wir mal gegen.
|
||||
[00:10:20] Speaker B: Also da bin ich mir nicht so sicher wegen wegen wegen wegen dieser Versiegelung und so weiter.
|
||||
[00:10:25] Speaker A: Mhm.
|
||||
[00:10:26] Speaker B: Da könnte sein, dass es äh nicht so ist.
|
||||
[00:10:34] Speaker A: Gut, dann haben wir noch die Infrastructure Parking.
|
||||
[00:10:41] Speaker A: Also, da haben wir nur den Sweeper, also den die Kehrmaschine.
|
||||
[00:10:46] Speaker B: Äh Mhm.
|
||||
[00:10:47] Speaker A: Die Gains sind äh verschmutzte Parkflächen, Müll schaden dem Image, erster Eindruck.
|
||||
[00:10:54] Speaker A: Dann manuelle Arbeiten fegen von großen Außenflächen ist Personalintensiv und unbeliebt und Umwelt Müll gelangt in die Umgebung bzw. Kanalisation.
|
||||
[00:11:04] Speaker B: Ja, ja.
|
||||
[00:11:05] Speaker A: Als Gains haben wir dann gepflegtes Erscheinungsbild, tägliche äh saubere Außenanlagen, ähm Roboter Autonomie Roboter reinigt selbstständig auch bei schlechtem Wetter, Entlastung Hausmeister kann sich um Wartung kümmern stattfegen.
|
||||
[00:11:24] Speaker B: Ja.
|
||||
[00:11:26] Speaker B: Definitiv.
|
||||
[00:11:27] Speaker A: Super.
|
||||
[00:11:28] Speaker A: Dann haben wir noch den den Reinigungsdienstleister, den haben wir neu aufgenommen, das war hast du gesagt, dass der größte Markt ist.
|
||||
[00:11:36] Speaker A: Ähm hat ja nicht direkte große Konkurrenten, aber eben die kleineren.
|
||||
[00:11:43] Speaker A: Da haben wir am Primary Produkt bei äh haben wir auch Cleaning Wet Surface.
|
||||
[00:11:49] Speaker A: Als Paint haben wir Personalmangel und Fluktuation, hohe No Show Quote und ständig ständig Neurekrutierung binden Objektleiter massiv und gefährden die Vertrags äh Vertragserfüllung.
|
||||
[00:12:04] Speaker A: Margenverfall steigende Tariflöhne bei gleichbleibenden Preisdruck der Auftraggeber lassen kaum noch Gewinn zu und Qualitätsschwankungen wechselndes ungelerntes Personal liefert oft unzureichende Ergebnisse, was zu Reklamationen und Kürzungen führt.
|
||||
[00:12:30] Speaker A: Hallo?
|
||||
[00:12:37] Speaker A: Alex?
|
||||
[00:12:42] Speaker B: Bist du wieder da?
|
||||
[00:12:44] Speaker B: Warte mal.
|
||||
[00:12:47] Speaker B: Ja, ich bin im Funkloch.
|
||||
[00:12:50] Speaker B: Hörst du mich?
|
||||
[00:12:51] Speaker A: Ja, jetzt höre ich dich wieder.
|
||||
[00:12:53] Speaker B: Hallo, hallo, hallo.
|
||||
[00:12:55] Speaker B: Ja, okay, da bin ich.
|
||||
[00:12:57] Speaker B: Ja, jetzt habe ich wieder Netz, ja.
|
||||
[00:12:58] Speaker A: Hast leider nicht gehört, musst.
|
||||
[00:13:00] Speaker A: Dann dann mache ich die Reinigungsdienstleister noch mal, also das sind unsere Konkurrenten, also bzw. die kleineren Reinigungsleister, nicht unsere großen Konkurrenten wie Staback und Wisack.
|
||||
[00:13:09] Speaker A: Ähm ich habe als Paint habe ich Personalmangel und Fluktuation, hohe No Show Quote und ständigen neue Rekrutierung binden Objektleiter massiv und gefährden die Vertragserfüllung.
|
||||
[00:13:22] Speaker A: Margenverfall, steigende Tariflöhne bei gleichbleibend gleichzeitig gleichzeitigen Preisdruck der Auftraggeber lassen kaum noch Gewinn zu und Qualitätsschwankung wechselndes Personal wechselndes ungelernte Personal liefert oft unzureichende Ergebnisse, was zu Reklamationen und Kürzungen führt.
|
||||
[00:13:42] Speaker B: Ja, sehr gut.
|
||||
[00:13:43] Speaker B: Sehr gut.
|
||||
[00:13:44] Speaker A: Die Gains sind entsprechend Kalkulation.
|
||||
[00:13:46] Speaker B: Ja, sehr richtig vom Fach.
|
||||
[00:13:48] Speaker B: Bitte?
|
||||
[00:13:52] Speaker B: Ist ja richtig vom Fach.
|
||||
[00:13:57] Speaker A: Dann ähm die die Gains haben wir Kalkulationssicherheit, Roboter bieten fixe Kosten statt unkalkulierer Krankheits- und Ausfallrisiken.
|
||||
[00:14:07] Speaker A: Wettbewerbsvorteil mit Roboter mit Robotik Konzepten punkten Dienstleister bei Ausschreibung als Innovativ Innovationsführer und Entlastungs Entlastung Objektleiter, weniger Personalmanagement bedeutet mehr Zeit für Kundenpflege und Qualitätskontrolle.
|
||||
[00:14:27] Speaker B: Ja.
|
||||
[00:14:28] Speaker B: Sehr gut.
|
||||
[00:14:30] Speaker A: Dann haben wir noch die Data Center.
|
||||
[00:14:36] Speaker A: Da haben wir den Security Roboter als Primary Produkt.
|
||||
[00:14:42] Speaker A: Wir haben hier die Gains Sicherheitsrisiko unbefugter Zutritt in Sicherheitsbereiche muss lückenlos dokumentiert werden 247.
|
||||
[00:14:53] Speaker A: Personalbindung, Wachpersonal ist teuer und kann nicht überall gleichzeitig sein.
|
||||
[00:15:01] Speaker B: Ja.
|
||||
[00:15:02] Speaker A: Und ähm ich weiß nicht, ob wir den den den Cleaning noch als Secondary Produkt platzieren oder ob wir das rauslassen bei Data Center.
|
||||
[00:15:13] Speaker B: Was meinst du genau mit Data Center?
|
||||
[00:15:15] Speaker A: Ja, halt so so Rechenzentrum, Serverfarm sowas in der Richtung.
|
||||
[00:15:20] Speaker B: Die nur die nur die auf Security oder würdest du das auch noch erweitern?
|
||||
[00:15:24] Speaker B: Also zum Anfang oder?
|
||||
[00:15:25] Speaker A: Ob wir da noch den Ja, ob wir da noch den Also so so so Energie äh Energie ist ein eigenes Thema, das das geht jetzt um um Rechenzentrum.
|
||||
[00:15:35] Speaker B: Ah, okay.
|
||||
[00:15:36] Speaker B: Ja, okay.
|
||||
[00:15:37] Speaker B: Na, dann passt.
|
||||
[00:15:39] Speaker A: Passt das.
|
||||
[00:15:41] Speaker A: Sehr gut und als Gains haben wir lückenlose Überwachung, permanente Patrouille und sofortige Alarmierung ohne Personalbindung, Dokumentation Video und Sensorprotokolle alle Ereignisse.
|
||||
[00:15:56] Speaker B: Ja.
|
||||
[00:15:57] Speaker B: Sehr gut.
|
||||
[00:15:59] Speaker A: So, dann haben wir noch an offenen Branchen.
|
||||
[00:16:10] Speaker A: Haben wir noch Oh, das sind einige.
|
||||
[00:16:13] Speaker A: Legen wir oben los.
|
||||
[00:16:15] Speaker A: Die Automotive Dealer, also die Autohändler ums Eck.
|
||||
[00:16:19] Speaker A: Wir haben den Security Roboter als Primary Product und den die Kehrmaschine als Secondary Product platziert.
|
||||
[00:16:28] Speaker B: Ja, ja, sehr gut.
|
||||
[00:16:31] Speaker A: Wir haben die Paint Primary Product, also jetzt für den Security Roboter, Teildiebstahl, organisierte Banden demontieren nachts Katalysatoren, Räder enormen Schaden und Versicherungsstress.
|
||||
[00:16:44] Speaker A: Vandalismus zerkratzte Neuwagen auf dem Außenhof mindern den Verkaufswert drastisch und Personalkosten lückenlose menschlichen Nachtbewachung ist für viele Standorte wirtschaftlich kaum darstellbar.
|
||||
[00:16:59] Speaker B: Mhm.
|
||||
[00:17:01] Speaker A: Ähm den gegenüber haben wir die Gains äh Abschreckung und Intervention, permanente Roboterpräsenz wirkt präventiv bei Alarm schaltet sich sofort eine Leitstelle auf.
|
||||
[00:17:15] Speaker A: Asset Schutz, Reduktion von Versicherungsschäden und selbst äh behaltenen Selbstbehalten durch lückenlose Dokumentation.
|
||||
[00:17:27] Speaker A: Und für das Secondary Product, also den die Kehrmaschine haben wir hier Imageverlust, also als Pain Imageverlust ein verschmutzter Außenbereich, Laubmüll passt nicht zum Premium Anspruch der äh ausgestellten ausgestellten Fahrzeuge.
|
||||
[00:17:44] Speaker A: Manuelle Aufwand Verkaufspersonal oder teure Hausmeisterdienste binden Zeit mit unproduktiven Fegen.
|
||||
[00:17:52] Speaker A: Und als Gains entsprechend ähm äh Premium Präsentation, der Hof ist bereits morgens bei Kundenöffnung makellos sauber und Automatisierung nächtliche äh täglich gereinigte Flächen ohne manuellen Eingriff.
|
||||
[00:18:08] Speaker B: Ja.
|
||||
[00:18:10] Speaker B: Sehr gut.
|
||||
[00:18:12] Speaker A: Dann haben wir Corporate Campus, also das das geht jetzt um Firmen Firmenzentralen Business Parks, Unis Privatgelände, ähm da haben wir den Wet Surface als Primary Product und den die Kehrmaschine als Secondary Product.
|
||||
[00:18:31] Speaker A: Die Paint sind die Paint zunächst.
|
||||
[00:18:35] Speaker B: Mhm.
|
||||
[00:18:36] Speaker A: Ähm für das äh Indoor Cleaning haben wir ähm repräsentative Repräsentativität, Empfangshallen und Atrien sind das Aushängeschild, sichtbarer Staub oder Schlieren wirken unprofessionell.
|
||||
[00:18:55] Speaker A: Kostendruck Kostendruck Facility enorme Flächen, Flure, Verbindungsgänge und so weiter erzeugen hohe laufende Reinigungskosten.
|
||||
[00:19:06] Speaker A: Die Gains entsprechend sind Innovation Statement, Einsatz von Robotik unterstreicht den technologische Führer Führungsanspruch des Unternehmens gegenüber Besuchern und Bewerbern.
|
||||
[00:19:20] Speaker A: Konstante Qualität, einheitliches Sauberkeitsniveau in allen Gebäudeteilen unabhängig von Tagesform oder Krankenstand.
|
||||
[00:19:29] Speaker B: Ja.
|
||||
[00:19:30] Speaker A: Für den äh für die Kehrmaschine haben wir als ähm Paint äh Campuspflege weitläufige Außenanlagen manuell sauber zu halten, bindet unverhältnismäßig viele Ressourcen.
|
||||
[00:19:44] Speaker A: Und als Gains dementsprechend gepflegtes Erscheinungsbild, automatisierte Kehrleistung sorgt für repräsentative Wege und Plätze.
|
||||
[00:19:56] Speaker B: Ja.
|
||||
[00:19:57] Speaker B: Auch gut, ja.
|
||||
[00:20:00] Speaker A: Dann haben wir die Netzbetreiber, also Energy Grid and Utilities, also die die die Netzbetreiber Umspannwerke, Wasser, Strom und so weiter kritische Infrastruktur.
|
||||
[00:20:16] Speaker A: Haben wir nur den Security Roboter.
|
||||
[00:20:20] Speaker B: Aha.
|
||||
[00:20:21] Speaker A: Ich habe hier als Paint Sabotage und Diebstahl, Kupferdiebstahl in Umspannwerken verursacht Millionenschäden und Versorgungsausfälle.
|
||||
[00:20:30] Speaker A: Reaktionszeit entlegene Standorte sind für Interventionskräfte oft zu spät erreichbar und Sicherheitsrisiko Mensch, Alleinarbeit bei Kontrollgängen in Hochspannungsbereichen ist gefährlich.
|
||||
[00:20:45] Speaker B: Ja.
|
||||
[00:20:46] Speaker B: Und warum bist du da kein Secondary Product reinnehmen, weil die haben ja auch riesige Flächen, ne?
|
||||
[00:20:53] Speaker B: Auch in dem Bereich.
|
||||
[00:20:56] Speaker A: Du meinst jetzt äh Wet Surface Reinigung?
|
||||
[00:20:59] Speaker B: Ja, ja, ja.
|
||||
[00:21:01] Speaker A: Kann kann ich gerne noch mal mit aufnehmen.
|
||||
[00:21:04] Speaker B: Ja, ich glaube ich glaube nicht schlecht.
|
||||
[00:21:07] Speaker B: Weil wir haben einige, die da ähm das Thema äh also die auch schon mal auf uns zu kamen diesbezüglich.
|
||||
[00:21:15] Speaker A: Das ist ein guter Punkt, habe ich mit aufgenommen, werde ich ja noch ergänzen, dann noch mal die Gains First Responder Maschine Roboter ist bereits vor Ort, verifiziert Alarm und schreckt Täter ab.
|
||||
[00:21:28] Speaker A: Kriti Kriti Compliance lückenlose Manipulationssicherheit Manipulationssichere Dokumentation aller Vorfälle für Behörden.
|
||||
[00:21:40] Speaker A: Arbeitsschutz ähm Roboter übernimmt gefährliche Routine Kontrolle z.B. Thermografie an Trafus.
|
||||
[00:21:48] Speaker B: Mhm.
|
||||
[00:21:52] Speaker A: Gut, dann setze ich das noch mal auf Klärungsbedarf.
|
||||
[00:21:56] Speaker A: Dann haben wir die Solarparks, Windparks, abgelegene abgelegene ähm Anlagen.
|
||||
[00:22:03] Speaker A: Ist sehr ähnlich zu den zu den ähm Utilities ähm hier ist auch der der Kupferdiebstahl im professionelle Banden plündern abgelegene Parks in Minuten.
|
||||
[00:22:15] Speaker A: Der Schaden durch Betriebsunterbrechung übersteigt den Materialwert oft weit.
|
||||
[00:22:21] Speaker A: Interventionszeit.
|
||||
[00:22:23] Speaker B: Hast du da aber aber Solarparks, ne?
|
||||
[00:22:27] Speaker B: Also jetzt nicht auf Kupfer.
|
||||
[00:22:29] Speaker B: Ja, okay.
|
||||
[00:22:30] Speaker A: Ja, gut, da liegen auch liegen auch Kabel rum.
|
||||
[00:22:32] Speaker B: Wechselrichter, die Wechselrichter klauen die auch viel, habe ich gelesen.
|
||||
[00:22:36] Speaker A: Ja.
|
||||
[00:22:36] Speaker A: Genau.
|
||||
[00:22:38] Speaker A: Ähm kommt glaube ich noch.
|
||||
[00:22:41] Speaker A: Ähm wenn ich notiere ich noch mal Wechselrichter.
|
||||
[00:22:52] Speaker A: Genau.
|
||||
[00:22:53] Speaker A: Ähm Interventionszeit bis bis der Wachdienst eintritt Blaulichtfahrt sind die Täter längst verschwunden und Kostenfalle Fehlalarm, Wildtiere oder Wetterbedingte Störungen lösen teure unnötige Polizeieinsätze aus.
|
||||
[00:23:10] Speaker B: Ja.
|
||||
[00:23:16] Speaker A: Dann haben wir die ähm Gains sofortige Verifikation KI gestützt Erkennung unterschiedlicher unterscheidet zuverlässig zwischen Tier und Mensch und liefert Livebilder in Sekunden.
|
||||
[00:23:30] Speaker A: Ähm präventive Abschreckung, autonome Patrouille signalisiert, hier wird bewacht und verhindert den Versuch und lückenlose Beweissicherung, kriegsfeste Dokumentation von Vorfällen für Versicherung und Strafverfolgung.
|
||||
[00:23:46] Speaker B: Ja.
|
||||
[00:23:48] Speaker B: Ziemlich gut, ja.
|
||||
[00:23:50] Speaker A: Dann haben wir noch Retail Food, also der der klassische Supermarkt.
|
||||
[00:23:56] Speaker A: Wir haben hier den Wet Surface als Primary Product und den Service Roboter als Secondary Product.
|
||||
[00:24:04] Speaker B: Ja.
|
||||
[00:24:06] Speaker A: Die Paint ähm sind Maleur Management, also zerbrochene Gläser oder ausgelaufene Flüssigkeiten, Haverien ähm bilden sofortige Rutsch Rutschfallen und binden Personal, optischer Eindruck ähm Geräusch Grauschlieren und verschmutzte Böden senken das frische Empfinden der Kunden massiv und Personalengpass Marktpersonal soll Regale füllen und kassieren, nicht mit der Scheuermaschine fahren.
|
||||
[00:24:40] Speaker A: Die Gains entsprechend sind sofortige Sicherheit, Roboter beseitigt Rutschgefahren autonom und schnell.
|
||||
[00:24:48] Speaker A: Frische Optik permanent glänzende Böden Lobby Effekt unterstreichen die Qualität der Lebensmittel.
|
||||
[00:24:56] Speaker B: Ja.
|
||||
[00:24:57] Speaker B: Bitte?
|
||||
[00:24:59] Speaker B: Ja, sehr gut, sehr gut.
|
||||
[00:25:01] Speaker A: Für den Sweeper ist es Parkplatzpflege Müll und Müll auf Parkplätzen und Parkhäusern ist in der erste ist der erste negative Touchpoint für die Besucher und das entsprechend Willkommenskultur saubere Außenbereiche lädt zum Betreten ein.
|
||||
[00:25:21] Speaker B: Ja.
|
||||
[00:25:22] Speaker B: Sehr gut.
|
||||
[00:25:23] Speaker A: Dann haben wir nur noch die die Retail Nonfood, wir haben hier riesige Gangflächen verstauben schnell, Personal ist knapp und soll beraten, nicht nicht kehren.
|
||||
[00:25:36] Speaker A: Verschmutzte Böden wirken im Premium Segment Möbelwertmindernd.
|
||||
[00:25:42] Speaker A: Und die Gains entsprechend dann Staubfreie Umgebung für angenehmes Einkaufen.
|
||||
[00:25:48] Speaker A: Roboter reinigt autonom große Flächen während Mitarbeiter für Kundenberatung verfügbar sind.
|
||||
[00:25:55] Speaker B: Mhm, sehr gut, ja.
|
||||
[00:25:58] Speaker A: Dann haben wir das alles auf grün.
|
||||
[00:26:01] Speaker B: Cool.
|
||||
[00:26:02] Speaker A: Soll ich dir noch mal schicken oder sagst du ja, mach jetzt?
|
||||
[00:26:06] Speaker B: Ich fand es, ich fand es alles wirklich sehr gut, muss ich sagen, also ähm fand es wirklich gut.
|
||||
[00:26:12] Speaker B: Hatte ich jetzt keine mehr keinen großen.
|
||||
[00:26:15] Speaker A: Keine Redflex.
|
||||
[00:26:17] Speaker A: Okay, gut, dann gehe ich damit jetzt in die Multiplikation und dann haben dann haben wir jetzt eine solide Grundlage für die für die Marketing Texte dann.
|
||||
[00:26:28] Speaker B: Schau, mega.
|
||||
[00:26:31] Speaker A: Alles klar.
|
||||
[00:26:32] Speaker A: Super.
|
||||
[00:26:32] Speaker A: Dann dann rufe ich dich über den nächsten Call.
|
||||
[00:26:35] Speaker B: Danke dir.
|
||||
[00:26:35] Speaker A: Alles klar, dann.
|
||||
[00:26:36] Speaker A: Ciao.
|
||||
[00:26:37] Speaker B: Ciao.
|
||||
[00:26:37] Speaker B: Ciao.
|
||||
87
docs/umzug.md
Normal file
87
docs/umzug.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Migration Report: Setup on docker1 (Ubuntu 24.04)
|
||||
|
||||
**Datum:** 10.02.2026
|
||||
**Ziel:** Einrichtung einer sauberen Entwicklungsumgebung ("Greenfield") auf der neuen VM `docker1` (10.10.81.2).
|
||||
|
||||
## 1. System- & Docker-Konfiguration
|
||||
|
||||
Vor der Installation der Anwendungen mussten grundlegende Systemanpassungen vorgenommen werden, um Docker auf Ubuntu 24.04 lauffähig zu machen.
|
||||
|
||||
* **Docker-Rechte:** Der Benutzer wurde der Gruppe `docker` hinzugefügt (`sudo usermod -aG docker $USER`), um `sudo` für Docker-Befehle zu vermeiden.
|
||||
* **DNS-Fix:** Es gab massive Probleme mit der DNS-Auflösung innerhalb von Docker-Containern (Konflikt mit `systemd-resolved` und Stub-Resolver auf `127.0.0.53`).
|
||||
* *Lösung:* `systemd-resolved` wurde deaktiviert und `/etc/resolv.conf` wurde manuell auf Google DNS (`8.8.8.8`) gesetzt.
|
||||
* *Befehle:*
|
||||
```bash
|
||||
sudo systemctl stop systemd-resolved
|
||||
sudo systemctl disable systemd-resolved
|
||||
sudo rm /etc/resolv.conf
|
||||
echo -e 'nameserver 8.8.8.8\nnameserver 8.8.4.4' | sudo tee /etc/resolv.conf
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
## 2. Gitea Installation (Docker Compose)
|
||||
|
||||
Gitea wurde als zentrale Versionsverwaltung eingerichtet.
|
||||
|
||||
* **Methode:** Docker Compose mit PostgreSQL.
|
||||
* **Herausforderung:** Die automatische Admin-Erstellung über Umgebungsvariablen (`GITEA__admin__...`) schlug fehl (Race Condition oder Image-Bug).
|
||||
* **Lösung:** Manuelle Installation über das Web-Interface.
|
||||
* **Konfiguration (`docker-compose.yml`):**
|
||||
```yaml
|
||||
version: "3"
|
||||
services:
|
||||
db:
|
||||
image: postgres:16
|
||||
restart: always
|
||||
environment:
|
||||
POSTGRES_USER: gitea
|
||||
POSTGRES_PASSWORD: 'secure_password'
|
||||
POSTGRES_DB: gitea
|
||||
volumes:
|
||||
- ./postgres:/var/lib/postgresql/data
|
||||
networks:
|
||||
- gitea-network
|
||||
healthcheck:
|
||||
test: ["CMD-SHELL", "pg_isready -U gitea -d gitea"]
|
||||
interval: 5s
|
||||
timeout: 5s
|
||||
retries: 5
|
||||
|
||||
gitea:
|
||||
image: gitea/gitea:1.21
|
||||
restart: always
|
||||
networks:
|
||||
- gitea-network
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:22"
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
depends_on:
|
||||
db:
|
||||
condition: service_healthy
|
||||
|
||||
networks:
|
||||
gitea-network:
|
||||
external: false
|
||||
```
|
||||
* **Zugriff:** `http://10.10.81.2:3000`
|
||||
|
||||
## 3. Gemini CLI Umgebung
|
||||
|
||||
Die Gemini CLI wurde nicht nativ installiert, sondern als isolierte Docker-Umgebung eingerichtet, um Konsistenz zu gewährleisten.
|
||||
|
||||
* **Ansatz:** Custom Docker Image (`gemini-dev-env`) gesteuert durch ein Shell-Skript (`startgemini.sh`).
|
||||
* **Dateien:*
|
||||
* `gemini.Dockerfile`: Basiert auf `node:20-slim`, installiert Python, Git und `@google/gemini-cli`.
|
||||
* `startgemini.sh`: Baut das Image (falls nötig) und startet den Container mit gemountetem Projektverzeichnis.
|
||||
* `.env`: Enthält den `GEMINI_API_KEY`.
|
||||
* **Workflow:*
|
||||
1. Dateien manuell erstellt.
|
||||
2. `chmod +x startgemini.sh`
|
||||
3. Start via `./startgemini.sh` -> Startet interaktive Session im Container.
|
||||
|
||||
## Status
|
||||
✅ System ist bereit. Gitea läuft, Gemini CLI ist einsatzbereit.
|
||||
305
docs/verticals_analysis.md
Normal file
305
docs/verticals_analysis.md
Normal file
@@ -0,0 +1,305 @@
|
||||
--- 1. Fetching Product Categories ---
|
||||
Loaded 7 products.
|
||||
|
||||
--- 2. Fetching Verticals ---
|
||||
|
||||
--- 3. Analysis ---
|
||||
|
||||
### Logistics - Warehouse
|
||||
**Primary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Secondary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Pains:**
|
||||
Verschmutzte Fahrwege durch Palettenabrieb und Staub gefährden die Sensorik von FTS (Fahrerlosen Transportsystemen) und erhöhen das Unfallrisiko für Flurförderzeuge. Manuelle Reinigung stört den 24/7-Betrieb und bindet Fachpersonal.
|
||||
**Gains:**
|
||||
Permanente Staubreduktion im laufenden Betrieb schützt empfindliche Anlagentechnik (Lichtschranken). Saubere Hallen als Visitenkarte und Sicherheitsfaktor (Rutschgefahr), ohne operative Unterbrechungen.
|
||||
----------------------------------------
|
||||
|
||||
### Healthcare - Hospital
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
Fachpflegekräfte sind bis zu 30% der Schichtzeit mit logistischen Routinetätigkeiten (Wäsche, Essen, Laborproben) gebunden ('Hände weg vom Bett'). Steigende Hygienerisiken bei gleichzeitigem Personalmangel im Reinigungsteam führen zu lückenhafter Dokumentation und Gefährdung der RKI-Konformität.
|
||||
**Gains:**
|
||||
Rückgewinnung von ca. 2,5h Fachkraft-Kapazität pro Schicht durch automatisierte Stationslogistik. Validierbare, RKI-konforme Reinigungsqualität rund um die Uhr, unabhängig vom Krankenstand des Reinigungsteams.
|
||||
----------------------------------------
|
||||
|
||||
### Infrastructure - Transport
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Pains:**
|
||||
Sicherheitsbereiche erfordern personalintensives Screening von externen Reinigungskräften. Verschmutzte Böden (Winter/Salz) erhöhen das Rutschrisiko für Passagiere und Klagerisiken.
|
||||
**Gains:**
|
||||
Autonome Reinigung innerhalb der Sicherheitszonen ohne externe Personalwechsel. Permanente Trocknung von Nässe (Schneematsch) in Eingangsbereichen.
|
||||
----------------------------------------
|
||||
|
||||
### Leisure - Indoor Active
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
Personal ist rar und teuer, Gäste erwarten aber Service am Platz. Reinigung im laufenden Betrieb stört den Erlebnischarakter.
|
||||
**Gains:**
|
||||
Service-Roboter als Event-Faktor und Entlastung: Getränke kommen zum Gast, Personal bleibt an der Bar/Theke. Konstante Sauberkeit auch bei hoher Frequenz.
|
||||
----------------------------------------
|
||||
|
||||
### Retail - Food
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
Reinigungskosten steigen linear zur Fläche, während Kundenfrequenz schwankt. Sichtbare Reinigungsmaschinen blockieren tagsüber Kundenwege ('Störfaktor'). Abends/Nachts schwer Personal zu finden.
|
||||
**Gains:**
|
||||
Unsichtbare Reinigung: Roboter fahren in Randzeiten oder weichen Kunden dynamisch aus. Konstantes Sauberkeits-Level ('Lobby-Effekt') steigert Verweildauer.
|
||||
----------------------------------------
|
||||
|
||||
### Retail - Shopping Center
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Pains:**
|
||||
Food-Court ist der Schmutz-Hotspot: Verschüttete Getränke und Essensreste wirken unhygienisch und binden Personal dauerhaft. Dreckige Böden senken die Verweildauer.
|
||||
**Gains:**
|
||||
Sofortige Beseitigung von Malheuren im Food-Court. Steigerung der Aufenthaltsqualität und Verweildauer der Kunden durch sichtbare Sauberkeit.
|
||||
----------------------------------------
|
||||
|
||||
### Hospitality - Gastronomy
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
Servicepersonal verbringt Zeit auf Laufwegen statt am Gast ('Teller-Taxi'). Personalmangel führt zu langen Wartezeiten und Umsatzverlust.
|
||||
**Gains:**
|
||||
Servicekräfte werden von Laufwegen befreit und haben Zeit für aktive Beratung und Verkauf (Upselling). Steigerung der Tischumschlagshäufigkeit.
|
||||
----------------------------------------
|
||||
|
||||
### Leisure - Outdoor Park
|
||||
**Primary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
Enorme Flächenleistung (Wege) erfordert viele Arbeitskräfte für die Grobschmutzbeseitigung (Laub, Müll). Sichtbare Reinigungstrupps stören die Immersion der Gäste.
|
||||
**Gains:**
|
||||
Autonome Großflächenreinigung (Kehren) in den frühen Morgenstunden vor Parköffnung. Erhalt der 'heilen Welt' (Immersion) für Besucher.
|
||||
----------------------------------------
|
||||
|
||||
### Leisure - Wet & Spa
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
Hohes Unfallrisiko durch Nässe auf Fliesen (Rutschgefahr). Hoher Aufwand für permanente Desinfektion und Trocknung im laufenden Betrieb bindet Aufsichtspersonal.
|
||||
**Gains:**
|
||||
Permanente Trocknung und Desinfektion kritischer Barfußbereiche. Reduktion der Rutschgefahr und Haftungsrisiken. Entlastung der Bademeister (Fokus auf Aufsicht).
|
||||
----------------------------------------
|
||||
|
||||
### Infrastructure - Public
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Pains:**
|
||||
Extrem kurze Turnaround-Zeiten zwischen Messetagen oder Events. Hohe Nachtzuschläge für die Endreinigung der Hallengänge oder Klassenzimmer.
|
||||
**Gains:**
|
||||
Automatisierte Nachtreinigung der Gänge/Flure stellt die Optik für den nächsten Morgen sicher. Kalkulierbare Kosten ohne Nachtzuschlag.
|
||||
----------------------------------------
|
||||
|
||||
### Retail - Non-Food
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
Riesige Gangflächen verstauben schnell, Personal ist knapp und soll beraten, nicht kehren. Verschmutzte Böden wirken im Premium-Segment (Möbel) wertmindernd.
|
||||
**Gains:**
|
||||
Staubfreie Umgebung für angenehmes Einkaufsklima. Roboter reinigen autonom große Flächen, während Mitarbeiter für Kundenberatung verfügbar sind.
|
||||
----------------------------------------
|
||||
|
||||
### Hospitality - Hotel
|
||||
**Primary Product:** Cleaning Indoor Roboter (Carpet)
|
||||
**Secondary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Pains:**
|
||||
Enorme Fluktuation im Housekeeping gefährdet die pünktliche Zimmer-Freigabe (Check-in 15:00 Uhr). Hohe Nachtzuschläge oder fehlendes Personal verhindern, dass die Lobby und Konferenzbereiche morgens um 06:00 Uhr perfekt glänzen.
|
||||
**Gains:**
|
||||
Lautlose Nachtreinigung der Lobby und Flure ohne Personalzuschläge. Servicekräfte im Restaurant werden von Laufwegen ('Teller-Taxi') befreit und haben Zeit für aktives Upselling am Gast.
|
||||
----------------------------------------
|
||||
|
||||
### Leisure - Entertainment
|
||||
**Primary Product:** Service Roboter
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
[Primary Product: Service]
|
||||
- Service-Engpass: Umsatzverlust zu Stoßzeiten, da Personal nicht schnell genug Getränke/Snacks nachliefert.
|
||||
- Personalmangel: Schwierige Besetzung von Spätschichten führt zu geschlossenen Stationen/Bahnen.
|
||||
- Wartezeiten: Gäste sind unzufrieden, wenn Bestellungen zu lange dauern.
|
||||
|
||||
[Secondary Product: Cleaning]
|
||||
- Bodenverschmutzung: Klebrige Böden (Getränke/Popcorn) im Foyer stören das Gästeerlebnis.
|
||||
**Gains:**
|
||||
[Primary Product: Service]
|
||||
- Umsatzsteigerung: Permanente Verfügbarkeit von Snacks/Getränken direkt am Platz (Cross-Selling).
|
||||
- Erlebnis-Faktor: Innovative Roboter begeistern Gäste und fördern Social-Media-Sichtbarkeit.
|
||||
- Entlastung: Servicepersonal hat mehr Zeit für Gästebetreuung statt Laufwege.
|
||||
----------------------------------------
|
||||
|
||||
### Healthcare - Care Home
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Service Roboter
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning]
|
||||
- Infektionsrisiko: Mangelnde Bodenhygiene und Keimverschleppung in sensiblen Bereichen gefährden Bewohner.
|
||||
- Dokumentationspflicht: Lückenlose Nachweise für Hygiene-Audits binden wertvolle Pflegezeit.
|
||||
- Personalmangel: Reinigungskräfte fehlen, Standards können manuell kaum gehalten werden.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Pflegeressourcen: Fachkräfte binden bis zu 30% ihrer Zeit mit nicht-pflegerischen Transportwegen (Essen/Wäsche).
|
||||
- Körperliche Belastung: Schweres Heben und weite Wege führen zu krankheitsbedingten Ausfällen im Pflegeteam.
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning]
|
||||
- Audit-Sicherheit: Automatisierte, protokollierte Reinigung sichert Compliance ohne Mehraufwand.
|
||||
- Entlastung Housekeeping: Personal konzentriert sich auf Sichtreinigung und Desinfektion statt Bodenfläche.
|
||||
|
||||
[Secondary Product: Service]
|
||||
- Mehr Zeit am Patienten: Reduktion der Laufwege gibt Pflegekräften 2-3 Std./Schicht zurück.
|
||||
- Mitarbeiterzufriedenheit: Reduktion körperlicher Belastung senkt Krankenstand.
|
||||
----------------------------------------
|
||||
|
||||
### Industry - Manufacturing
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Transport Roboter
|
||||
**Pains:**
|
||||
Hochbezahlte Facharbeiter unterbrechen die Wertschöpfung für unproduktive Such- und Holzeiten von Material (C-Teile). Intransparente Materialflüsse an der Linie führen zu Mikrostillständen und gefährden die Taktzeit.
|
||||
**Gains:**
|
||||
Just-in-Time Materialversorgung direkt an die Linie. Fachkräfte bleiben an der Maschine. Stabilisierung der Taktzeiten und OEE durch automatisierten Nachschub.
|
||||
----------------------------------------
|
||||
|
||||
### Energy - Grid & Utilities
|
||||
**Primary Product:** Security Roboter
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
- Sabotagegefahr: Bedrohungslage für unbemannte Umspannwerke.
|
||||
- Reaktionszeit: Zu lange Dauer zwischen Alarm und Eintreffen der Intervention.
|
||||
- Inspektionsaufwand: Manuelle Kontrollgänge binden hochqualifiziertes Personal.
|
||||
- Sicherheitsrisiko Mensch: Gefahren bei Alleinarbeit in Hochspannungsbereichen.
|
||||
**Gains:**
|
||||
- Sofortige Verifikation: Roboter liefert Live-Bild vor Eintreffen der Intervention.
|
||||
- Inspektions-Support: Thermografie-Checks an Trafos entlasten Techniker.
|
||||
- Sicherheit: Gefahrenlose Voraufklärung bei Alarmen (First Responder Maschine).
|
||||
- Wackler-Netzwerk: Flächendeckende Interventionspartner sichern kurze Eintreffzeiten.
|
||||
----------------------------------------
|
||||
|
||||
### Leisure - Fitness
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
- Schweiß & Staub: Hohe Frequenz erfordert ständiges Nachreinigen.
|
||||
- 24/7 Betrieb: Wann soll gereinigt werden, wenn immer offen ist?
|
||||
- Mitglieder-Beschwerden: Dreckige Umkleiden sind Kündigungsgrund #1.
|
||||
- Personal-Fokus: Trainer sollen Mitglieder betreuen, nicht saugen.
|
||||
**Gains:**
|
||||
- Permanente Sauberkeit: Roboter fährt Zyklen während des Trainingsbetriebs.
|
||||
- Mitglieder-Bindung: Top-Hygiene rechtfertigt den Beitrag.
|
||||
- Nacht-Modus: Autonome Reinigung in den schwachen Randzeiten (24/7).
|
||||
- Trainer-Entlastung: Fokus auf Sport, Technik macht den Boden.
|
||||
----------------------------------------
|
||||
|
||||
### Corporate - Campus
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Pains:**
|
||||
- Flächen-Management: Weitläufige Areale sind manuell kaum sauber zu halten.
|
||||
- Sicherheitsgefühl: Mitarbeiter fühlen sich auf großen Parkplätzen abends unsicher.
|
||||
- Reinigungs-Qualität: Unregelmäßige manuelle Reinigung wirkt ungepflegt.
|
||||
- ESG-Ziele: Einsatz von Dieselfahrzeugen passt nicht zur Nachhaltigkeit.
|
||||
**Gains:**
|
||||
- Sichtbare Innovation: Roboter unterstreichen High-Tech-Anspruch.
|
||||
- Kosteneffizienz: Automatisierung großer Flächen senkt Nebenkosten.
|
||||
- Sicherheit & Service: Roboter als Concierge erhöht subjektives Sicherheitsgefühl.
|
||||
- Green FM: Vollelektrische Reinigung zahlt auf CO2-Ziele ein.
|
||||
----------------------------------------
|
||||
|
||||
### Energy - Solar/Wind
|
||||
**Primary Product:** Security Roboter
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
- Hoher Schaden durch Kupfer-/Moduldiebstahl & Ertragsausfall.
|
||||
- Teure Falschfahrten von Wachdiensten durch Wildtier-Fehlalarme.
|
||||
- Steigende Versicherungsauflagen fordern lückenlose Überwachung.
|
||||
- Personal an abgelegenen Standorten schwer verfügbar.
|
||||
**Gains:**
|
||||
- Autonome Bestreifung schließt tote Winkel & schreckt ab.
|
||||
- Roboter verifiziert Alarm, Mensch rückt nur im Ernstfall aus.
|
||||
- Lückenlose Protokollierung für KRITIS-Audits & Versicherer.
|
||||
- 24/7 Betrieb ohne permanente menschliche Präsenz.
|
||||
----------------------------------------
|
||||
|
||||
### Others
|
||||
**Primary Product:**
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
|
||||
**Gains:**
|
||||
|
||||
----------------------------------------
|
||||
|
||||
### Tech - Data Center
|
||||
**Primary Product:** Security Roboter
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
[Primary Product: Security]
|
||||
- Sicherheitsrisiko: Unbefugter Zutritt in Sicherheitsbereiche muss lückenlos detektiert werden (24/7).
|
||||
- Personalbindung: Wachpersonal ist teuer und kann nicht überall gleichzeitig sein.
|
||||
|
||||
[Secondary Product: Cleaning]
|
||||
- Feinstaub: Staubpartikel in Serverräumen gefährden Hardware und Kühlung.
|
||||
**Gains:**
|
||||
[Primary Product: Security]
|
||||
- Lückenlose Überwachung: Permanente Patrouille und sofortige Alarmierung ohne Personalbindung.
|
||||
- Dokumentation: Video- und Sensorprotokolle aller Ereignisse.
|
||||
|
||||
[Secondary Product: Cleaning]
|
||||
- Ausfallsicherheit: Staubfreie Umgebung verlängert Hardware-Lebensdauer.
|
||||
----------------------------------------
|
||||
|
||||
### Automotive - Dealer
|
||||
**Primary Product:** Security Roboter
|
||||
**Secondary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Pains:**
|
||||
- Teile-Diebstahl: Nächtlicher Abbau von Katalysatoren/Rädern auf Außenflächen.
|
||||
- Vandalismus: Schäden an Neuwagen durch unbefugten Zutritt.
|
||||
- Image-Verlust: Verschmutzte Außenbereiche entwerten das Premium-Erlebnis.
|
||||
- Personalkosten: Nachtwache ist für Händler oft unwirtschaftlich.
|
||||
**Gains:**
|
||||
- Prävention: Sichtbare Roboter-Präsenz schreckt Diebe effektiver ab als Kameras.
|
||||
- Doppel-Nutzen: Tagsüber Reinigung für sauberen Hof, nachts Bestreifung.
|
||||
- Asset-Schutz: Reduktion von Versicherungsschäden und Selbstbehalten.
|
||||
- Kunden-Erlebnis: Innovatives Image und stets gepflegtes Areal.
|
||||
----------------------------------------
|
||||
|
||||
### Reinigungsdienstleister
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
Margendruck durch steigende Tariflöhne bei gleichzeitigem Preisdiktat der Auftraggeber. Hohe Fluktuation (>30%) führt zu ständiger Rekrutierung ('No-Show'-Quote), was Objektleiter bindet und die Qualitätskontrolle vernachlässigt.
|
||||
**Gains:**
|
||||
Kalkulationssicherheit durch Fixkosten statt variabler Personalkosten. Garantierte Reinigungsleistung in Objekten unabhängig vom Personalstand. Innovationsträger für Ausschreibungen.
|
||||
----------------------------------------
|
||||
|
||||
### Infrastructure Parking
|
||||
**Primary Product:** Cleaning Outdoor Roboter (Sweeper)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
[Primary Product: Sweeper]
|
||||
- Außenwirkung: Verschmutzte Parkflächen/Müll schaden dem Image (erster Eindruck).
|
||||
- Manuelle Arbeit: Fegen von großen Außenflächen ist personalintensiv und unbeliebt.
|
||||
- Umwelt: Müll gelangt in die Umgebung/Kanalisation.
|
||||
**Gains:**
|
||||
[Primary Product: Sweeper]
|
||||
- Gepflegtes Erscheinungsbild: Täglich saubere Außenanlagen.
|
||||
- Autonomie: Roboter reinigt selbstständig, auch bei schlechtem Wetter.
|
||||
- Entlastung: Hausmeister kann sich um Wartung kümmern statt Fegen.
|
||||
----------------------------------------
|
||||
|
||||
### Infrastructure - Communities
|
||||
**Primary Product:** Cleaning Indoor Roboter (Wet Surface)
|
||||
**Secondary Product:**
|
||||
**Pains:**
|
||||
[Primary Product: Cleaning]
|
||||
- Großflächen-Reinigung: Sporthallen, Aulen und Flure binden enorm viele Personalstunden.
|
||||
- Budget-Druck: Kommunen müssen sparen, Reinigungskosten sind großer Posten.
|
||||
- Nutzungs-Konflikte: Reinigung muss in engen Zeitfenstern zwischen Schul/Vereinsnutzung erfolgen.
|
||||
**Gains:**
|
||||
[Primary Product: Cleaning]
|
||||
- Kosteneffizienz: Reduktion der Reinigungskosten pro Quadratmeter.
|
||||
- Flexibilität: Reinigung kann nachts oder in Randzeiten erfolgen.
|
||||
- Werterhalt: Schonende, regelmäßige Reinigung verlängert Lebensdauer von Sportböden.
|
||||
----------------------------------------
|
||||
Reference in New Issue
Block a user