Von Excel zur Club Plattform auf Salesforce

Kapitel 1 Wie alles anfing

Das Erbe

Unsere Geschichte beginnt genau da, wo viele enden: Mit einer Sammlung Excel Tabellen, die eigentlich längst außer Kontrolle geraten ist.

Das Herzstück war eine mächtige Exceltabelle mit jeder Menge Tabs, Formeln und Abhängigkeiten. Dazu muss ich tatsächlich ein wenig ausholen, denn so eine Club-Abrechnung ist natürlich durchaus komplex. Da gibt es mehrere Bars, die einen Warenbestand haben. Es gibt ein Kühlhaus mit noch mehr Ware. Es gibt eine Garderobe mit Kapazität und natürlich eine Kasse für den Eintritt. Und am Ende muss man natürlich herausfinden, wie viele Getränke verkauft wurden, wie viele Gäste Eintritt bezahlt haben und wie viele davon ihre Jacke an der Garderobe gelassen haben. Außerdem wird Personal entlohnt, Belege ausgezahlt und Kartenzahlungen zugeordnet.

Das alles wurde nun aufwändig in Excel erfasst, um dann eine Abrechnung zu erstellen. Die Wahrheit über alles was relevant ist:

• Welcher Bestand an Bargeld muss im Safe sein?

• Wieviel Geld muss von den Mitarbeitern abgeschöpft werden?

• Welcher Umsatz wurde über die Kartenterminals gebucht?

• Wie hoch ist der Warenbestand zum Veranstaltungsende?

• Muss Ware nachbestellt werden?

• Welche Löhne wurden vor Ort ausgezahlt?

• Wurden Rechnungen und/oder Belege ausgezahlt?

Man stelle sich vor, jemand überschreibt eine Formel, oder trägt Informationen ein, die nicht valide sind. Schon stimmen die Zahlen nicht und niemand merkt es und das hatten wir wirklich immer wieder - vor allem wenn die Tabelle mit den ganzen Fehlern dann noch dupliziert wurde, um sie am nächsten Tag gleich wieder zu verwenden.

Und selbst wenn alles gepasst hat, dann lagen die ganzen Zahlen einsam auf einem Rechner im Club, auf den man eben nur Zugriff hat, wenn man vor Ort ist, also immer am Wochenende. Doch wann will man sich die Zahlen anschauen? Wann trifft man Entscheidungen auf Basis dieser Zahlen? Genau: Dann, wenn gerade kein Betrieb ist, wenn man vor der Warenbestellung sitzt, wenn man die Personaleinteilung macht, wenn man sich durch die Buchhaltung kämpft.

Natürlich lag die Lösung längst auf der Hand und unter uns: Schon weit vor der Unterschrift beim Notar war mir klar:

“Das bauen wir in Salesforce”.

Alles andere hätte sich wie ein Rückschritt angefühlt. Seit 2009 bin ich der Überzeugung, dass Salesforce sehrwohl auch für kleine Unternehmen geeignet ist und weder zu komplex noch zu teuer ist.

Das Fundament

Nachdem wir zuvor die Tastatur gegen den Werkzeugkasten getauscht hatten und viele Wochen Umbau hinter uns lagen, haben wir uns im Juni 2025 entschieden, unser eigenes Salesforce Projekt zu starten.

3 Lizenzen und eine “nackte” Salesforce-Org. Von dem Moment an, wenn man das erste Mal das Setup öffnet, schlugen zwei Herzen in meiner Brust. Das eine rief laut “Du kannst alles so machen, wie Du willst” und das andere mahnte “Bleib nah am Standard”.

Doch wie definiert man Standard? Wie kann man einen “Standard” auf das eigene Unternehmen münzen? Unsere ersten Aufgaben waren deshalb ganz klar:

Welche Rollen werden wir für unsere Mitarbeiter, oder uns selbst benötigen?

Bei 3 Lizenzen ist da wenig Spielraum. Dennoch haben wir das genau durchdacht. Denn alles was wir später umsetzen würden, ist eng mit dem Berechtigungskonzept verknüpft. 3 Lizenzen, 3 Profile:

• Accounting - ist für die komplette Abrechnung der Veranstaltung verantwortlich

• Logistik - kümmert sich um die Warenbestellung, Annahme und Lagerung im Kühlhaus oder an den Bars

• Administrator - darf alles, also ich 😇

Nun hatten wir ein simples Berechtigungskonzept.

Welche Informationen brauchen wir auf unserer Plattform?

• Unser Sortiment - denn es ist die Basis für alles was wir an den Bars verkaufen

• Alle Lieferanten - von diesen beziehen wir unser Sortiment und oft gibt es Kommunikation, Bestellungen, Vereinbarungen, Verträge und Konditionen, die wir diesen Lieferanten zuordnen müssen

• Alle Mitarbeiter - inklusive Rollen, Informationen zur Bezahlung, Anstellungsverhältnis, Dienstplan, Zeiterfassung, Urlaub und ganz klassische Stammdaten

Unsere Events / Veranstaltungen mit

• allen Bars inklusive Zuordnung der einzelnen Artikel mit Bestand, Preis und Abrechnungsart (pro Einheit, Volumen, etc.)

• Eintritt strukturiert nach Preisstaffelungen, Vorverkauf, Abendkasse, etc.

• Garderobe inklusive Wechselgeld, Garderobenmarken, etc.

• Auszahlungen an Mitarbeiter

• Auszahlung von Rechnungen und Belegen

Was davon ist nun Standard?

Für die Abbildung von Lieferanten und deren Ansprechpartner haben wir die Standard Objekte Account und Contact genutzt und lediglich um ein paar Merkmale erweitert. Unsere eigenen Mitarbeiter haben wir ebenfalls als Contact abgebildet. Beide Objekte sollten im Laufe der Zeit noch viel relevanter werden, aber dazu komme ich bald noch.

Beim Rest haben wir dann doch schnell festgestellt, dass es keinen Standard gibt. Woher sollte Salesforce auch einen „Standard“ für Diskotheken oder Gastronomiebetriebe haben…

…also haben wir uns selbst einen Standard geschaffen und aufbauend, auf dem was Salesforce mitbringt, ein eigenes Datenmodell entwickelt. Erst auf einem Lucidchart Board, dann etwas Validierung mit ChatGPT und dann ging es los mit der Objektanlage im Setup. Objekt für Objekt, Feld für Feld. Eine gute Übung, wie ich finde, denn man zwingt sich, bei jedem Schritt mitzudenken.

Ist es der richtige Feldtyp? Es macht Sinn immer darüber nachzudenken, wie eine Information später verarbeitet wird. Zum Beispiel zur Kalkulation, Filterung, Prozess-Logik oder einfach nur informativ.

Wer darf die Information nutzen, genauer gesagt, welches Profil darf die Information sehen und/oder bearbeiten? Beispiel: Das Logistikprofil kann den Bestand eines Artikels ändern, aber nicht die Preise.

Soll es im Layout verwendet werden? Manchmal gibt es Felder, die zwar wichtig sind, aber nicht sichtbar sein müssen, wie z.B. eine externe Id.

Was ist der Zweck eines Feldes? Man kann zu jedem Objekt und Feld eine Beschreibung hinterlegen - extrem wertvoll falls man später zufällig mal mit einem KI Agenten arbeiten will, der Salesfore Metadaten nutzen will 😉

In 6 Stunden zum fertigen Datenmodell

3 Netflix Abende später war es soweit: 23 Objekte, unzählige Felder und ein Datenmodell, das plötzlich mehr konnte als jede Excel zuvor. Wenig Zeitaufwand für ein massives Ergebnis. Denn gleichzeitig hat Salesforce das Frontend in Detailansichten aufgebaut und dank Funktionen wie RollUp Summaries und Formelfelder ist auch gleich noch die grundlegende Logik entstanden, um Warenbestand inklusive Abgänge durch Verkauf/Verbrauch und Zugänge durch Wareneingang/Bestellungen abzubilden.

Die erste App

Auch wenn Salesforce viel vorwegnimmt, so bleiben dennoch ein paar weitere Schritte, um aus einem Datenmodell eine Anwendung zu machen.

Also haben wir überlegt, für welche Daten wir einen direkten Zugriff benötigen und für welche nicht und entsprechend Tabs angelegt. Beispiel: Das Objekt Event beinhaltet alle Veranstaltungen, welche direkt aufgerufen werden müssen. Das Objekt Bar Position hingegen ordnet bestimmte Artikel einer Bar zu und definiert einen Bestand und Verkaufspreise. Dies würde man nie direkt bearbeiten, sondern über die zugehörige Bar.

Nachdem wir die Tabs definiert haben, war der nächste Schritt eine App zu erstellen. Also haben wir eine Accounting App erstellt und passenden Tabs hinzugefügt. Ich hab mich sehr bewusst für eine Konsolenansicht entschieden, weil gerade bei der Abrechnung mehrere Bars parallel bearbeitet werden und das ist damit sehr elegant lösbar.

In weniger als 15 Minuten war die App fertig und aufrufbar.

Man konnte also direkt starten, Daten zu befüllen. Genau das haben wir gemacht. Lieferanten angelegt, Artikel hinzugefügt, Mitarbeiter und auch die erste Veranstaltung. Da wurde es dann schon komplizierter, denn für die erste Veranstaltung musste zumindest einmal jede Bar und jeder Artikel pro Bar angelegt werden. Dazu die Anfangsbestände und Verkaufspreise je Bar. Notwendig, aber eine Arbeit, die man am liebsten nur einmal machen möchte. Für jede Veranstaltung von vorne anfangen? Auf keinen Fall! Schnell war ich mental wieder bei Excel Tabellen, die bis ins Nirvana Kopien von Kopien von Kopien auf einer Festplatte auf Erlösung warten.

Der erste Flow

Der imaginäre Astro Chor auf meiner Schulter (es war schon sehr spät am Abend) rief laut “Auto-ma-ti-sie-rung! Auto-ma-ti-sie-rung!”. Astro hatte recht und ich war müde. Also begann ich am nächsten Abend einen Flow zu bauen, der Veranstaltungen duplizieren sollte.

Klingt einfach, ist es aber gar nicht. Denn schließlich haben wir vorher ja bei der mühsamen Erstellung der Inhalte gemerkt, dass es viele Komplexitäten und Abhängigkeiten gibt. Statt zu theoretisieren, habe ich jedoch direkt den Flowbuilder geöffnet und losgelegt.

Stück für Stück habe ich den Flow aufgebaut und als Leitfaden für mich selbst bei jedem Schritt darüber nachgedacht, in welcher Reihenfolge ich es manuell durchführen müsste. Das hilft ungemein, gerade wenn es komplex wird und Abhängigkeiten entstehen:

1 Stunde und ein paar Tests hat es gebraucht, bis der Flow einsatzbereit war.

Nun habe ich ihn “nur” noch zugänglich machen müssen. Ich entschied mich dazu den Flow in die Utility Bar unserer “Accounting” App zu packen. Da stört er nicht und kann jeder Zeit aufgerufen werden.

Vibe Coding vs. Standard Pages und Components

Salesforce bringt schon wirklich viel mit, wenn es um die Gestaltung von Oberflächen geht. Es lässt sich echt viel durch Konfiguration aufbauen. Genau so haben wir auch angefangen.

Wir haben zunächst die wichtigsten Listenansichten optimiert, dann aber vor allem die Record Pages aufgebaut, mit besonderem Fokus auf Event, Bars, Cashflow, Artikel und Lieferanten.

Wer allerdings schon mal versucht hat, zum Beispiel Informationen in einer zugehörigen Liste schnell auf einmal zu bearbeiten (also so wie der Anwender es von Excel kennt), stößt schnell an die Grenzen des Standards. Unsere Anwender brauchen das aber, denn gerade am Anfang und am Ende müssen Daten wie Bestände, Gewichte und Differenzen schnell hinzugefügt und geändert werden.

Die Antwort: Vibe-Coding.

Früher hätte ich angefangen, meine notwendigen Components selbst zu bauen - heute macht das die KI - zumindest wenn man ihr auch genau sagt, was man will.

Und genau da beginnt der spannende Teil. Ich schmunzle immer, wenn mir jemand sagt, „schau mal, hab ich eben mal mit Vibe Coding gebaut“. Auf den ersten Blick sehen die Ergebnisse meistens toll aus und liefern ein „passables“ Ergebnis. Doch was passiert, wenn man Funktionalität dynamisch erweitern will? Was passiert, wenn sich das Datenmodell ändert, oder das Ergebnis anderweitig wiederverwertet werden soll?

Dann wird der Unterschied zwischen „Rapid Prototyping“ und eines ausgereiften wiederverwendbaren Assets deutlich.

Was befähigt nun eine KI dazu, solche Assets zu bauen?

Zwei Dinge: Metadaten und klar definierte Anforderungen.

Bei unseren Anfängen im Sommer letzten Jahres war mein Tool der Wahl ChatGPT. Vermutlich entstanden aussenrum schon andere und bessere Modelle, aber ich war es gewohnt und kam damit klar. Ich merkte aber auch schnell, dass ohne detaillierte Beschreibung der Metadaten das Ergebnis oft Fehler hatte. Api Namen, Feldtypen, Validierungsregeln, oder gar alle LWC Standard Components und das Lightning Design System - das alles kannte das LLM nicht und alles musste aufwändig beschrieben werden. Bevor man überhaupt Anforderungen definierte. Inzwischen kann man dafür Skills definieren.

Dann kam Agentforce Vibes. Nach anfänglichen Kinderkrankheiten hab ich dann doch relativ schnell gewechselt und bin seitdem mit der Entwicklung neuer Components und bei Bedarf Apex Code doch recht zufrieden. Denn auf einmal war der Vorteil da, dass ich eben nicht mehr meine Metadaten „erklären“ musste, sondern mich voll auf die Anforderung konzentrieren konnte.

Das war auch notwendig, denn ich habe schnell gelernt, je sauberer und durchdachter die Instruktion ist, umso besser ist das Ergebnis.

Viele unserer Components sind für die Massenbearbeitung erstellt worden und da kann es einen signifikanten Unterschied machen, wie man eine Anforderung beschreibt. in unserem Fall war die Kernfunktion, dass man z.B. jeweils nur ein Feld eines Datensatzes, wie den Anfangsbestand eines Artikels an der Bar ändert und dann zum nächsten Datensatz springt. Die KI wird nicht automatisch daran denken, welche Keyboard Events berücksichtigt werden sollten. Also stand in unserer Anweisung zum Beispiel

    if the user starts to edit the field OpeningCount__c on all related Bar Position Records, set the focus to the input field of the first row. If the user does press „Enter“ set the focus to the input field on the next row. If the user does press enter on the last row update all changed records and close the editing mode.

Ohne diese Instruktion hatte das zunächst gefehlt. Für unsere Mitarbeiter wäre es aufwändig gewesen, zwischen Eingaben per Touch am iPad auf das gewünschte Feld zu springen. So kann man direkt von Eingabe zu Eingabe springen und spart extrem Zeit. Außerdem kommt niemand und meckert, dass das in Excel aber früher viel einfacher war 😉

Beispiel für Bearbeitung pro Position

Schnell hatten wir die ersten Komponenten am Start und waren so weit ab September 2025 unsere Mitarbeiter auf die Lösung zu lassen.

Fazit

Mit einem Customizing / Entwicklungsaufwand von ca. 30 Stunden hatten wir Version 1 im Live Betrieb und sofort spürbare Verbesserungen. Wir konnten endlich alle wesentlichen Daten rund um unsere Veranstaltungen prüfen, nachhalten und auswerten, und zwar immer und überall. Wir konnten den Zeitaufwand für die Abrechnung um ca. 30 bis 60 Minuten pro Veranstaltung reduzieren, was z.B. Personalkosten reduziert hat. Wir haben alle User früh mit eingebunden, damit sie Teil der Lösung sind.

In den kommenden Beiträgen werde ich mehr darauf eingehen, was sich seit dem ersten Go Live alles getan hat. Von der Anbindung von Slack, über erste wirkungsvolle Prompt Templates, bis hin zu neuen Components und unserem ersten Employee Agent mit Agentforce, warten noch viele spannende Kapitel.