Leichtgewichtiges CRM‑Schema für kleine Teams, das einfach bleibt

Welches Problem dieses CRM-Schema lösen soll

Ein kleines Team braucht ein CRM, das alltägliche Fragen schnell beantwortet: Mit wem sprechen wir, was versuchen wir abzuschließen, was ist zuletzt passiert und was ist als Nächstes dran. Das ist die eigentliche Aufgabe eines leichtgewichtigen CRM-Schemas. Alles, was diese Fragen nicht unterstützt, ist meist nur Rauschen.

Kleine Teams brauchen selten tiefe Account-Hierarchien, Dutzende benutzerdefinierte Objekte oder komplizierte Scoring-Modelle. Sie brauchen klare Zuständigkeit, eine einfache Historie von Touchpoints und eine Pipeline, die alle gleich verstehen.

"Einfach" bricht zusammen, wenn es auf Freitext und Duplikate setzt. Wenn eine Person eine Deal-Phase als "Negotiation" schreibt und eine andere "negotiating", wird Reporting zur Ratespielerei. Wenn Aktivitäten in separaten Tabellen für Anrufe, Meetings und Notizen leben, hast du mehrere Datumsfelder und keinen verlässlichen Wert für „zuletzt berührt“.

Dieses Schema beschränkt sich auf vier Kernobjekte, die die meisten Small-Team-CRMs abdecken, ohne zum Monster zu werden:

• Contacts (und optional Organizations) als die Personen, mit denen du sprichst
• Deals als Opportunities, die du durch eine Pipeline verfolgst
• Activities als ein einheitliches Log für Aufgaben, Meetings, Anrufe und Notizen
• Permissions als praktische Regeln, wer was sehen und bearbeiten darf

Sauberes Reporting bedeutet, dass du zuverlässig sehen kannst: Deals nach Phase diese Woche, Konversionsraten von Phase zu Phase, durchschnittliche Verweildauer in einer Phase, letzte Aktivität pro Deal und die offenen Aufgaben jedes Reps für heute. Diese Berichte sollten weiterhin sinnvoll sein, wenn das Team von 3 auf 15 Personen wächst.

Wenn du ein internes CRM in einem No‑Code-Tool wie AppMaster (appmaster.io) baust, hält diese Herangehensweise die Datenbank klein und liefert gleichzeitig stabile Zahlen für Dashboards und Wochenreviews.

Prinzipien, um leichtgewichtig zu bleiben ohne sich einzuschränken

Ein leichtgewichtiges CRM-Schema funktioniert, wenn es eine Frage klar beantwortet: Wo lebt diese Information? Wenn dieselbe „Wahrheit“ an zwei Orten gespeichert werden kann, wird sie es sein, und deine Reports driftet.

Wähle eine kleine Menge an Source-of-Truth-Objekten und lasse alles andere auf sie verweisen. Für die meisten kleinen Teams heißt das: Contacts, Organizations (optional), Deals und Activities. Wenn du mehr Details brauchst, füge eine neue Tabelle hinzu, statt Bedeutungen in ein einzelnes Textfeld zu quetschen, das zur Müllschublade wird.

Ein paar Regeln halten das Modell einfach und flexibel:

• Eine Tatsache, ein Zuhause: eine Telefonnummer gehört zu Contact, ein Deal-Wert gehört zu Deal.
• Bevorzuge explizite Tabellen gegenüber überlasteten Feldern: Stage-Historie ist kein komma-getrennter String.
• IDs stabil halten und Namen editierbar machen: Leute benennen Firmen um, sie ändern keine Primärschlüssel.
• Trenne „Status“ von „Typ“: eine Aufgabe kann gleichzeitig „open“ und „call“ sein.
• Gehe davon aus, dass Importe chaotisch sind: leere Felder, Duplikate und seltsames Format sind normal.

Plane für chaotische Daten ab Tag eins, indem du ein paar langweilige, aber mächtige Felder hinzufügst: created_at, updated_at und ein einfaches external_id (oder import_source + import_key) in deinen Kern-Tabellen. Das gibt dir einen sicheren Weg, erneut zu importieren, ohne Duplikate zu erzeugen.

Ein konkretes Beispiel: Du importierst eine Tabelle, in der „Acme Inc." in der Hälfte der Zeilen als „ACME" erscheint. Wenn Organization.name editierbar ist und Organization.id stabil bleibt, kannst du Datensätze später zusammenführen, ohne bestehende Deals und Activities zu zerstören.

Contacts und Organizations: die einfachste Struktur, die funktioniert

Ein leichtgewichtiges CRM-Schema beginnt mit einer Entscheidung: Trackst du nur Personen oder Personen plus Firmen? Wenn dein Team an Unternehmen verkauft, möchtest du fast immer sowohl Contact (Person) als auch Organization (Firma). Wenn du an Endkunden verkaufst, kannst du Organizations ganz weglassen und jeden Eintrag als Contact behandeln.

Für ein B2B-Setup halte die Beziehung einfach: jeder Contact gehört zu einer primären Organization (nullable) und eine Organization kann viele Contacts haben. Das deckt die meisten Workflows kleiner Teams ab, ohne dich in komplizierte Account-Hierarchien zu treiben.

Pflichtfelder minimal halten

Der schnellste Weg zu chaotischen Daten ist, zu viele Felder verpflichtend zu machen. Eine gute Basis ist:

• Contact: id, Name (oder first_name + last_name), created_at
• Organization: id, name, created_at

Alles andere (Jobtitel, Website, Adresse, Branche, Source) kann optional sein. Regeln kannst du später hinzufügen, aber eine Datenbank voller Platzhalter wie "N/A" zu säubern ist schwer.

E‑Mail und Telefon: Eindeutigkeit ohne Schmerz

Es ist verlockend, E‑Mail als eindeutig zu erzwingen. Das funktioniert gut für B2C oder für ein CRM, das zugleich dein Login-System ist. In kleinen B2B-Teams sind Shared Inboxes (sales@, info@) und wiederverwendete Telefonnummern üblich. Harte Unique-Regeln können gültige Datensätze blockieren.

Ein praktischer Kompromiss:

• Durchsetze Eindeutigkeit nur, wenn ein Wert vorhanden ist (und nur, wenn es zu deinem Use Case passt).
• Erlaube Duplikate, aber zeige im UI eine weiche Warnung, wenn ein Treffer gefunden wird.

Wenn du mehrere E‑Mails oder Telefonnummern brauchst, vermeide Spalten wie email_2 oder phone_3. Nutze stattdessen eine separate Tabelle (z. B. ContactMethod mit type, value, is_primary). Das Reporting bleibt sauber und das Modell skaliert natürlich.

Beispiel: Dein Team trifft Pat, der mitten im Quartal den Job wechselt. Mit Contact, der an eine Organization gebunden ist, kannst du Pat zur neuen Firma verschieben, alte Kontaktmethoden für die Historie behalten und deine Reports zählen Deals weiterhin korrekt nach Firma.

Deals und Pipelines: Struktur, die lesbar bleibt

Ein Deal ist deine Forecast-Einheit: ein potenzieller Kauf mit einem klaren nächsten Schritt. Halte die Deal‑Tabelle klein und verweise auf alles andere.

Beginne mit Feldern, die du jedem im Team erklären kannst:

• Deal-Name: ein kurzer Bezeichner, der in einer Liste Sinn macht
• Stage: Referenz auf eine Pipeline-Stage (nicht als Freitext)
• Value: erwarteter Betrag (wähle eine Währung für das ganze System)
• Owner: die Person, die verantwortlich ist
• Close Date: die beste aktuelle Schätzung für den Abschluss

Bei Beziehungen wähle einen primären Contact auf dem Deal. Das hält Reporting einfach (z. B. Umsatz nach Kontakt, Win‑Rate nach Segment). Falls gelegentlich mehr Personen beteiligt sind, füge eine deal_contacts-Tabelle hinzu, damit du zusätzliche Kontakte anhängen kannst, ohne jeden Deal in ein komplexes Many‑to‑Many zu verwandeln. Die meisten kleinen Teams kommen mit 1 primären Kontakt plus optionalen Teilnehmern zurecht.

Stages sind ein häufiger Stolperstein. Speichere Stage nicht als Freitext. Nutze Referenzdaten, damit du eine Stage später umbenennen kannst, ohne Reports zu brechen. Eine minimale Stage-Tabelle könnte enthalten:

• stage_id
• pipeline_id
• stage_name
• stage_order
• is_closed (oder separate Flags für won und lost)

Wenn dein Team klein ist, vermeide das Aufspalten in „Lead“ und „Deal“, es sei denn, du behandelst Leads tatsächlich anders. Eine einfache Regel funktioniert: wenn du eine echte Opportunity hast, ist es ein Deal. Davor behältst du es als Contact mit einem Status wie „new“ oder „nurture“. Das hält die Pipeline lesbar und verhindert, dass halbfertige Deals deine Zahlen verfälschen.

Beispiel: Ein zweiköpfiges Sales-Team trackt „Acme Renewal“ als Deal, der Sam gehört, Stage „Proposal Sent“, Value 12.000, Close Date nächsten Monat. Der primäre Contact ist der Käufer, ein zweiter Contact ist als Finanzfreigabe hinterlegt. Reports bleiben konsistent, weil Stage-Namen und Reihenfolge fixiert sind.

Activities: ein Modell für Aufgaben, Meetings und Notizen

Ein kleines Team braucht keine separaten Tabellen für Anrufe, E‑Mails, Meetings und Notizen. Ein Activity-Modell reicht meist aus und macht CRM und Reporting einfacher.

Eine einzige Activity-Tabelle

Verwende einen Datensatz pro Ereignis (oder Aufgabe). Gib ihm ein einfaches type-Feld mit einer kleinen, festen Auswahl wie: call, email, meeting, note, task. Halte die Liste kurz, damit alle dieselben Begriffe wählen.

Um Aktivitäten ohne Verwirrung zu verknüpfen, nutze klare Regeln:

• Wenn es um eine Person geht (Follow-up-Anruf, Intro-Mail), verknüpfe es mit einem Contact.
• Wenn es um Umsatz geht (Pricing-Call, Verhandlungsmeeting), verknüpfe es mit einem Deal.
• Wenn beides zutrifft, verknüpfe mit beiden, aber behandle den Deal als primär für Pipeline-Reporting.

In der Praxis hat Activity contact_id (nullable) und deal_id (nullable), plus optional ein owner_id (wer verantwortlich ist).

Reporting-freundliche Zeitstempel

Behalte sowohl due_at als auch completed_at. Sie beantworten unterschiedliche Fragen. due_at sagt dir, was hätte passieren sollen (Planung und Arbeitslast). completed_at sagt dir, was tatsächlich passiert ist (Ausführung und Zykluszeit).

Den Status kannst du ableiten, ohne ein zusätzliches Feld: ist completed_at gesetzt, ist die Aktivität erledigt. Falls nicht, ist sie offen. Das vermeidet zusätzliche Statuswerte, die aus dem Tritt geraten.

Für Aktivitätstext speichere ein durchsuchbares Feld wie summary oder body. Vermeide frühe Überstrukturierung von Notizen. Beispiel: „Anruf mit Maya: Budget bestätigt, Angebot Freitag senden.“ Spezielle Felder fügst du später hinzu, wenn du echten Bedarf spürst.

Ownership und Sichtbarkeit: praktisch bleiben

Ownership ist die Person, die für den nächsten Schritt verantwortlich ist. In einem leichtgewichtigen Schema bedeutet das meist ein Feld wie owner_user_id auf einem Deal (und oft auch auf Contacts).

Zwei Bedeutungen von “Owner” werden oft vermischt: Benutzerzuweisung (ein konkreter Mensch) und Teamzuweisung (eine Gruppe). Wenn du von Anfang an alles team-owned machst, verlierst du die Klarheit, wer heute handeln sollte.

Ein Default, der für die meisten kleinen Teams funktioniert: alles ist für alle sichtbar, aber jeder Deal hat genau einen Owner. So bleibt Zusammenarbeit einfach und du vermeidest Berechtigungs‑Edge-Cases, wenn jemand für eine Kolleg:in einspringen muss.

Wenn du strengere Sichtbarkeit brauchst, gestalte sie als einfachen Schalter, nicht als komplexe Matrix. Zum Beispiel ein visibility-Feld auf Deals und Activities mit Werten wie public und private, wobei private bedeutet: „nur der Owner (und Admins) sehen es.“

Teams oder Territorien brauchst du nur, wenn eines dieser Dinge zutrifft:

• Du hast separate Gruppen, die sich gegenseitig nicht sehen sollen.
• Du reportest nach Team und People wechseln zwischen Teams.
• Manager brauchen Zugriff auf ihre Gruppe, aber nicht auf die ganze Firma.
• Du weist Leads einer gemeinsamen Queue zu, bevor ein Rep sie übernimmt.

Ownership wirkt sich aufs Reporting aus. Wenn du saubere Zahlen „pro Rep" willst, reportest du nach dem aktuellen owner_user_id auf dem Deal. Wenn du auch “nach Team” zusammenfassen willst, füge owner_team_id hinzu (oder leite es aus dem Profil des Owners ab), aber sei explizit, welches Feld die Quelle der Wahrheit ist.

Beispiel: Zwei Reps teilen ein Postfach. Ein neuer Deal startet unassigned mit owner_user_id = null und owner_team_id = Sales. Sobald Alex ihn übernimmt, setze owner_user_id = Alex (Team bleibt Sales). Deine Pipeline bleibt lesbar und Team‑Totals funktionieren weiterhin.

Permissions-Design: genug Kontrolle ohne Komplexität

Fang mit einfachem RBAC an

Berechtigungen funktionieren am besten, wenn du drei Dinge trennst: Rollen (wer), Ressourcen (was) und Aktionen (was sie tun dürfen). Das ist Role-Based Access Control (RBAC) und es bleibt verständlich, wenn dein Team wächst.

Halte Ressourcen nahe an deinen Kernobjekten: Contacts, Organizations, Deals, Activities und vielleicht Pipelines (wenn Stages editierbar sind). Definiere eine kleine, konsistente Aktionsliste über alle Ressourcen hinweg: view, create, edit, delete, export.

Export ist es wert, separat betrachtet zu werden. Viele Teams sind mit breitem Sichtrecht zufrieden, wollen aber Bulk-Exports einschränken.

Objekt‑Level-Berechtigungen sind der einfachste Einstieg: "Kann diese Rolle Deals bearbeiten?" Für die meisten kleinen Teams reicht das für Monate. Record‑Level-Regeln (pro Kontakt oder Deal) sind die Stelle, an der Komplexität auftaucht – füge sie nur hinzu, wenn es einen echten Bedarf gibt.

Ein praktischer erster Schritt ist eine einzige Ownership-Regel: jedes Record hat owner_user_id, und Nicht‑Admins können nur das bearbeiten, was sie besitzen. Wenn du eine zusätzliche Ebene brauchst, füge team_id hinzu und erlaube teamweites Sehen, während das Editieren owner‑only bleibt.

Record‑Level-Regeln nur bei echtem Bedarf

Führe Record‑Level-Berechtigungen für Fälle ein wie:

• Sales‑Reps dürfen die Deals der anderen nicht sehen
• Support darf Deals ansehen, aber nie bearbeiten
• Manager dürfen alles sehen und Owner neu zuweisen

Halte Audit‑Bedarf leichtgewichtig aber echt. Füge created_at, created_by, updated_at und updated_by in jede Haupttabelle. Wenn du später tiefere Historie brauchst, ergänze eine kleine audit_log-Tabelle mit: Objekt‑Typ, Record‑ID, Aktion, wer, wann und einem kurzen JSON der geänderten Felder.

Schritt für Schritt: Baue das Schema an einem Wochenende

Am einfachsten gelingt das, wenn du es wie ein kleines Produkt behandelst: definiere die Daten zuerst, prüfe sie mit echten Einträgen und baue dann die Bildschirme.

Tag 1: Datenmodell fixieren

Beginne mit einem schnellen ERD auf Papier oder Whiteboard. Halte die Anzahl der Tabellen klein, sei aber klar in den Verknüpfungen: Contact gehört optional zu einer Organization, Deal gehört zu einer Pipeline und hat einen Owner, Activity kann zu Contact und/oder Deal gehören.

Dann mache das Nötigste in dieser Reihenfolge:

• Definiere Objekte und Beziehungen: contacts, organizations, deals, activities, users/roles, plus kleine Lookup-Tabellen falls nötig.
• Definiere Pflichtfelder und Defaults: mache created_at, owner_id und Schlüssel­namen verpflichtend; setze Defaults für Stage und Währung, wenn du Beträge nutzt.
• Definiere Enums oder Lookup-Tabellen: Deal-Stages und Activity-Types, damit Reporting konsistent bleibt.
• Füge Indexe für häufige Filter hinzu: owner_id, Stage, due_at, created_at und Fremdschlüssel, nach denen du täglich filterst.
• Teste mit 20 echten Datensätzen: nutze reale Namen, Daten und chaotische Notizen, um zu sehen, was bricht.

Tag 2: Beweise, dass es sauber reportet

Bevor du Forms baust, schreibe 6–8 Fragen auf, die dein Team jede Woche stellt. Zum Beispiel: "Deals in Negotiation nach Owner", "Überfällige Activities", "Neue Contacts diesen Monat", "Gewonnener Umsatz pro Monat". Wenn eine Frage verwirrende Joins oder Sonderfälle braucht, behebe das Schema jetzt.

Ein simples Testszenario hilft: Füge 3 Contacts bei einer Firma hinzu, 2 Deals in unterschiedlichen Stages und 6 Activities (ein Anruf, ein Meeting, zwei Tasks und zwei Notizen). Prüfe dann, ob du ohne Raten beantworten kannst, wer dafür verantwortlich ist, was als Nächstes passiert und was sich letzte Woche geändert hat.

Wenn die Daten stabil sind, baue UI und Automatisierungen zuletzt. Du wirst schneller sein und musst später nicht die Historie umschreiben, damit Reports wieder passen.

Häufige Fehler, die Reporting chaotisch machen

Chaotisches Reporting beginnt meist mit "Quick Fixes", die heute schneller wirken, dich aber jede Woche kosten. Ein leichtgewichtiges CRM-Schema funktioniert am besten, wenn deine Daten klare Formen haben und ein paar Regeln, die das Team tatsächlich befolgt.

Eine Falle ist, alles in eine "customer"-Tabelle zu stopfen. Klingt einfach, bis du Fragen beantworten musst wie „Wie viele Deals sind an eine Firma gebunden?“ oder „Welche Person hat den Job gewechselt?“ Halte People (Contacts) und Companies (Organizations) getrennt und verbinde sie.

Ein weiterer Reporting-Killer ist, Stages als Freitext zuzulassen. Wenn jemand "Negotiation" und jemand anders "negotiating" tippt, ist dein Pipeline-Diagramm schon falsch. Nutze eine feste Stageliste (oder eine Stage-Tabelle), damit jeder Deal auf dasselbe Set zeigt.

Vermeide mehrere Werte in einem Feld zu packen. Komma-getrennte E‑Mails oder Telefonnummern machen Suche, Deduping und Exports schwer. Wenn du mehrere Werte brauchst, speichere sie als separate Zeilen (z. B. eine E‑Mail pro Record in einer Child‑Tabelle).

Activities werden chaotisch, wenn Daten unklar sind. Ein einzelnes "date"-Feld kann nicht sagen, ob eine Aufgabe letzten Freitag fällig war oder letzten Freitag abgeschlossen wurde. Trenne diese Konzepte, damit du überfällige Arbeit und erledigte Arbeit korrekt reporten kannst.

Hier eine kurze "rette zukünftiges Ich"-Checkliste:

• Trenne Contacts und Organizations und verknüpfe sie
• Nutze Stage-IDs, nicht getippte Stage-Namen
• Ein Wert pro Feld; für Mehrfachwerte eine Child-Tabelle verwenden
• Behalte due_at und completed_at als separate Felder
• Starte mit einfachen Rollen; füge Record‑Level-Regeln erst hinzu, wenn echte Workflows sie erfordern

Beispiel: Wenn dein Team Anrufe als Notizen loggt und später als "done" markiert, indem es dasselbe Feld bearbeitet, kannst du nicht mehr reporten, wie lange Follow‑ups gedauert haben. Mit getrennten Feldern ist der Report einfach.

Schnelle Checkliste bevor du dich auf das Schema festlegst

Bevor du Screens, Automatisierungen und Dashboards baust, mache einen kurzen Reporting‑ und Regel‑Durchlauf. Ein leichtgewichtiges CRM‑Schema bleibt leichtgewichtig nur, wenn du Standardfragen ohne Hacks oder Einzelfelder beantworten kannst.

Teste die Checks mit realen Beispieldaten (20 Contacts und 10 Deals reichen). Wenn du stecken bleibst, ist meist ein Feld fehlend, eine Picklist inkonsistent oder eine Beziehung zu lose.

Die 5 Checks, die die meisten Probleme finden

• Reporting‑Basics: Kannst du Deals nach Stage, Owner und Abschlussmonat gruppieren, ohne zu raten, welches Datumsfeld zu nutzen ist?
• Work‑Management: Kannst du "überfällige Activities nach Owner" in einem Report ziehen, wobei Überfällig auf einem einzigen Due‑Datum und einem klaren Done‑Status basiert?
• Contact ↔ Organization: Kann ein Contact ohne Organization existieren und später verknüpft werden, ohne History (E‑Mails, Notizen, Deal‑Teilnahme) zu zerstören?
• Konsistenz: Kommen Stages und Activity‑Types aus einer festen Liste, sodass du nicht "Follow up", "Follow-up" und "Followup" als drei Werte hast?
• Sicherheit: Kannst du einschränken, wer Records löschen oder Listen exportieren darf, ohne normale Updates wie das Verschieben eines Deals in die nächste Stage zu blockieren?

Wenn du auf alle fünf Fragen „Ja" antworten kannst, bist du in einer guten Ausgangslage. Wenn nicht, behebe es jetzt, solange das Schema noch klein ist.

Ein praktischer Tipp: Definiere Stages und Activity‑Types einmal (als Tabelle oder Enum) und verwende sie überall, damit jede Oberfläche und jeder Prozess dieselben Werte nutzt.

Ein realistisches Small‑Team‑Beispiel und nächste Schritte

Eine 5‑Personen‑Agentur ist ein guter Test für ein leichtgewichtiges CRM‑Schema. Das Team ist beschäftigt, Leads kommen von überall und niemand will Daten pflegen. Stell dir vor: 1 Admin, 2 Sales, 1 Ops‑Lead und 1 Lesezugang (der Gründer, der nur Zahlen prüft).

Eine neue Anfrage kommt rein (Webformular oder E‑Mail): „Brauche Website‑Refresh, Budget 15k, Timeline 6 Wochen." Die Regel ist einfach: Erstelle eine Organization (wenn es eine Firma ist) und einen Contact (die Person). Dann erstelle einen Deal, der an die Organization gebunden ist und setze den Contact als primären Contact für diesen Deal.

Um schnell zu bleiben, nutzen sie eine kleine Intake‑Checkliste:

• Wenn Domain oder Firmenname zu einer bestehenden Organization passt, wiederverwenden.
• Wenn die E‑Mail der Person existiert, den Contact wiederverwenden.
• Für echte Kaufabsicht immer einen Deal anlegen.
• Die Originalnachricht in die Deal‑Beschreibung packen.
• Source (Referral, Form, Outbound) als ein einzelnes Feld speichern.

Activities verhindern verpasste Calls, weil jeder nächste Schritt zu einem datierten Item wird, das einer Person gehört. Beim Discovery‑Call loggt Sales eine Activity als Meeting und fügt sofort die nächste hinzu: einen Call in zwei Tagen. Wenn Ops Details zur Scope‑Erstellung braucht, erstellen sie eine Task‑Activity auf demselben Deal, damit alles an einem Ort sichtbar ist.

Rollen bleiben praktisch: Admin kann alles bearbeiten und Einstellungen verwalten, Sales kann Contacts, Deals und ihre Activities erstellen und aktualisieren, Ops kann delivery‑bezogene Felder und Activities pflegen und Read‑only kann Pipeline und Reports ansehen ohne Daten zu ändern.

Wenn du das schnell in ein funktionierendes internes Tool verwandeln willst, ist AppMaster (appmaster.io) eine unkomplizierte Option: Du kannst das Schema im Data Designer (PostgreSQL) modellieren, Workflow‑Regeln im Business Process Editor hinzufügen, eine einfache Lead‑Inbox und Deal‑Seite bauen und dann zu AppMaster Cloud oder deiner eigenen Cloud deployen, wenn du bereit bist, es mit dem Team zu teilen.