was wir gebaut haben.
wir verkaufen keinen plan — wir bauen ein system in dein unternehmen. hier ist die art von sache, die wir ausliefern: die situation, in die wir hineingingen, was wir installiert haben und was sich änderte. illustrativ, repräsentativ für unsere engagements mit regulierten, wissensintensiven unternehmen.
jedes kundenmeeting,
voll gebrieft.
jeder relationship-manager betreute 80+ haushalte. der kontext lebte im CRM, in e-mails, geteilten drives, KYC-akten und gesprächsnotizen — sechs systeme, keines sprach mit dem anderen. ein review vorzubereiten hiess 30–40 minuten graben, also liefen die meisten meetings aus dem gedächtnis.
- ein souveränes memory über crm, e-mail, dokumente und gesprächs-transkripte
- skills, die das beratungs-framework und den ton der bank kodieren
- ein relationship-manager-agent, der vor jedem meeting ein briefing entwirft
- schweiz-gehostet · audit-geloggt · nichts verlässt die bank
briefings, die 30–40 minuten brauchten, landen jetzt im posteingang des bankers, bevor der tag startet — letzter kontakt, offene punkte, portfolio-flags, die frage, die nie zu ende beantwortet wurde. rund 8 senior-stunden pro woche zurück, pro banker.
wissen, das
aufhört zu gehen.
jedes mal, wenn ein senior-associate ging, ging ein jahrzehnt mandats-wissen mit. neue mitarbeiter brauchten monate, um zu lernen, wo die dinge lagen und wie die kanzlei argumentierte. die präzedenz-bibliothek war riesig und faktisch nicht durchsuchbar.
- memory über frühere mandate, schriftsätze und internes know-how
- skills, kodifiziert aus präzedenz und dem house-style der kanzlei
- ein research-agent, der mit zitaten auf der eigenen bibliothek der kanzlei entwirft
- jeder output rückführbar auf eine quelle — keine halluzinierte autorität
eine frage, die früher einen halben tag im archiv bedeutete, liefert in minuten eine zitierte antwort. neue associates erreichen nützlichen output in wochen, nicht quartalen — und das wissen der kanzlei bleibt das der kanzlei, nachdem jemand geht.
das montags-review,
vorgeschrieben.
die operative realität lag verstreut über ein ERP, ein ticketing-system, lieferanten-e-mail-threads und ein dutzend tabellen. das wöchentliche ops-review brauchte zwei leute fast einen ganzen tag zum zusammenstellen — und war schon veraltet, als es gelesen wurde.
- memory über erp, tickets und lieferanten-korrespondenz
- tools mit governiertem lesen/schreiben in die systems of record
- eine routine, die das ops-review jeden montag vor 7 uhr zusammenstellt
- jede zahl zurückverlinkt auf ihre quelle für ein-klick-verifikation
das leadership kommt ins review bereits ausgerichtet darauf, was sich bewegt hat, was riskiert ist und was eine entscheidung braucht. der tag des zusammenstellens ist weg; das gespräch startet dort, wo es früher endete.
erst-triage,
auf jedem schadenfall.
schadenfälle kamen als mix aus formularen, e-mails und anhängen. die handler verbrachten die erste stunde jedes falls nur mit lesen, klassifizieren und routen — bevor irgendein urteil angewendet wurde. einfache und komplexe fälle bekamen denselben langsamen start.
- memory über policen, frühere schadenfälle und das handbuch
- skills, die die triage- und eskalations-regeln des versicherers kodieren
- ein agent, der jeden fall liest, eine triage entwirft und markiert, was ein mensch entscheiden muss
- ein menschlicher handler besitzt jede entscheidung — der agent bereitet vor, genehmigt nie
unkomplizierte fälle kommen vorsortiert mit einer entworfenen empfehlung an; komplexe landen auf dem richtigen tisch, mit dem kontext bereits gesammelt. handler setzen ihr urteil dort ein, wo es zählt, statt beim eingang.
noch ein tool.
was würden wir
für dich bauen?
erzähl uns von deinem unternehmen und der arbeit, die am meisten weh tut. wir kommen zurück mit dem, was wir bauen würden, wie es laufen würde und was es bräuchte — kein plan zu kaufen, keine verpflichtung.