Nextcloud und Nutshell CRM: Wenn Datensouveränität auf Vertriebslogik trifft
Wer sich heute ernsthaft mit selbst gehosteter Collaboration-Software auseinandersetzt, kommt an Nextcloud kaum vorbei. Was vor gut einem Jahrzehnt als Fork von ownCloud begann, ist heute eine Plattform, die von einem deutschen Unternehmen mit Sitz in Kaiserslautern federführend entwickelt wird – und die inzwischen weit mehr kann als Dateien synchronisieren. Nextcloud ist Dateiablage, Groupware, Kalender, Chat, Office-Anbindung, Workflow-Engine und Zugriffsbroker in einem. Wer will, kann daraus eine komplette Arbeitsumgebung für ein mittelständisches Unternehmen bauen, ohne dass auch nur ein Byte auf den Servern eines US-Hyperscalers landet.
Genau an dieser Stelle wird es interessant, wenn man das Vertriebsmanagement hinzunimmt. Denn während Nextcloud im Backend zunehmend als souveräne Datendrehscheibe funktioniert, tummeln sich auf der CRM-Seite viele SaaS-Anbieter, deren Geschäftsmodell auf Cloud-Abos und externer Datenhaltung basiert. Nutshell CRM ist einer davon. Und obwohl auf den ersten Blick Welten zwischen einem selbst gehosteten Open-Source-Stack und einem US-amerikanischen Vertriebstool liegen, gibt es durchaus Schnittmengen, mit denen sich ein erstaunlich schlanker Workflow bauen lässt. Genau darum soll es hier gehen: um Nextcloud als Rückgrat, um Nutshell als Vertriebsgedächtnis, und um die Frage, wie man beides pragmatisch zusammenbringt.
Nextcloud: mehr als eine Dropbox-Alternative
Die Grundidee von Nextcloud ist schnell erzählt: Man installiert den Server auf eigener Hardware, in einer virtuellen Maschine, in einem Container oder bei einem deutschen Hosting-Anbieter, verbindet ihn mit einem Speicher seiner Wahl und bekommt anschließend eine Web-Oberfläche, über die Nutzer Dateien ablegen, teilen und gemeinsam bearbeiten. Das ist die Kurzfassung. Die Langfassung ist deutlich komplexer, und wer die Plattform produktiv betreibt, sollte sich mit ihrer Architektur auseinandersetzen.
Technisch basiert Nextcloud auf PHP, einer relationalen Datenbank – üblicherweise MariaDB, MySQL oder PostgreSQL – und einem Webserver wie Apache oder nginx. Der Speicher kann lokal liegen, auf einem NAS, auf einem S3-kompatiblen Object Store oder in einem verteilten Cluster. Für kleinere Installationen genügt eine einzelne VM mit einer Datenbank und einem Volume; für größere Umgebungen wird es schnell anspruchsvoll, weil Dateisperren, Caching, Vorschaugenerierung und Synchronisationslast verteilt werden müssen. Wer mehr als ein paar hundert Nutzer versorgen will, landet fast zwangsläufig bei einer getunten Umgebung mit Redis als Cache, APCu als lokalem Cache, PHP-FPM mit angepassten Prozesspools und einem vorgelagerten Reverse Proxy. Das ist kein Hexenwerk, aber es ist Arbeit, und es ist der Punkt, an dem viele Selbstbau-Projekte scheitern: Nicht an Nextcloud selbst, sondern an den Betriebsdetails drumherum.
Interessant ist, dass Nextcloud in den vergangenen Jahren erheblich an Funktionsumfang gewonnen hat, ohne die Komplexität proportional wachsen zu lassen. Der Groupware-Teil mit Kalender, Kontakten und Aufgaben ist heute ausgereift genug, um Thunderbird, Outlook oder mobile Clients sauber anzubinden – wobei Outlook-Anwender traditionell mit etwas mehr Reibung zu kämpfen haben als die Thunderbird-Fraktion. Der Talk-Teil, also Chat und Video, ist brauchbar, wenn auch nicht mit kommerziellen Lösungen wie Teams oder Zoom auf Augenhöhe. Für interne Kommunikation, die nicht ständig in großen Konferenzen stattfindet, reicht er mehr als aus.
Was Nextcloud als Plattform so attraktiv macht
Zwei Dinge heben Nextcloud aus der Masse vergleichbarer Produkte heraus. Das eine ist die strikte Offenheit: Der Quellcode ist unter einer freien Lizenz verfügbar, die APIs sind dokumentiert, und es gibt eine ausgeprägte App-Landschaft, die von der Community gepflegt wird. Das andere ist die Philosophie der Datensouveränität. Nextcloud ist kein Produkt, das darauf optimiert ist, möglichst viel Telemetrie zum Hersteller zu schicken, und es gibt keine versteckte Kopplung an proprietäre Backend-Dienste. Das ist in Zeiten zunehmender regulatorischer Anforderungen an Datenhaltung ein Argument, das schwerer wiegt als es auf den ersten Blick scheint.
Für Unternehmen, die unter die DSGVO fallen und ihre Verarbeitung dokumentieren müssen, bedeutet das konkret: Man weiß, wo die Daten liegen, kann die Zugriffsrechte selbst regeln, und man muss gegenüber Aufsichtsbehörden nicht erklären, dass Daten in einer Rechtsordnung verarbeitet werden, die möglicherweise nicht mit europäischem Datenschutz harmoniert. Das ist kein Selbstläufer, aber es ist ein struktureller Vorteil, den SaaS-Lösungen nur mit Mühe kompensieren können.
Dazu kommt die Flexibilität bei der Speicheranbindung. Wer eine bestehende NAS-Infrastruktur hat, kann diese anbinden. Wer einen Sekundärspeicher für kalte Daten braucht, kann einen Object Store hinter Nextcloud hängen. Wer Filesystem-Verschlüsselung auf Serverseite betreiben will, kann das tun. Diese Freiheit hat ihren Preis: Man muss wissen, was man tut. Aber sie erlaubt Architekturen, die mit einer reinen SaaS-Lösung schlicht nicht abbildbar sind.
Das Ökosystem: Apps, externe Speicher, WebDAV
Der wahrscheinlich wichtigste technische Hebel, wenn man Nextcloud mit anderen Systemen verbindet, ist die Kombination aus REST-APIs, WebDAV und dem sogenannten External Storage. Über WebDAV lässt sich Nextcloud wie ein entferntes Dateisystem behandeln – viele Programme können das ohne spezielle Anpassung. Das ist unspektakulär, aber genau diese Eigenschaft macht Nextcloud zu einer brauchbaren Integrationsplattform für Werkzeuge, die ansonsten lieber mit ihrer eigenen Datenhaltung arbeiten würden.
Zusätzlich bietet Nextcloud mit der Flow-Engine eine einfache Automatisierungsschicht. Man kann Regeln definieren wie „Wenn eine Datei in einen bestimmten Ordner hochgeladen wird, tagge sie und schicke eine Benachrichtigung“. Das ist kein vollwertiger Workflow-Builder im Sinne von n8n oder Zapier, aber für einfache Fälle durchaus ausreichend. Wer mehr braucht, greift auf die ausgereiften APIs zurück und baut die Logik in einem eigenen Dienst – oder in einem SaaS-Tool, das Webhooks versteht.
Und hier kommen wir zu Nutshell.
Nutshell CRM: Vertriebssoftware mit Blick auf den Mittelstand
Nutshell ist ein CRM-Anbieter mit Sitz in Ann Arbor, Michigan. Das Produkt richtet sich primär an kleine und mittlere Vertriebsteams und an Unternehmen, die ihre Vertriebsprozesse ohne große IT-Abteilung organisieren möchten. Funktional deckt Nutshell die üblichen Disziplinen ab: Kontakte, Firmen, Deals, Aktivitäten, Pipelines, E-Mail-Integration, Telefonie-Anbindung und Reporting. Dazu kommen Marketing-Automation-Funktionen, die in den vergangenen Jahren deutlich ausgebaut wurden, sowie ein API-Zugang, der sich sauber dokumentiert zeigt.
Was Nutshell von anderen CRM-Systemen unterscheidet, ist seine pragmatische Haltung. Die Oberfläche ist modern, aber nicht überladen. Standardprozesse sind vorkonfiguriert, Anpassungen sind möglich, aber nicht ins Unendliche skalierbar. Das ist für viele kleinere Vertriebsorganisationen genau richtig: Sie wollen ein System, das sofort funktioniert, nicht eine Plattform, in der sie erst sechs Wochen konfigurieren, bevor der erste Deal eingetragen wird.
Dass Nutshell als SaaS betrieben wird, ist Fluch und Segen zugleich. Der Segen: Man muss sich nicht um Updates, Skalierung, Backups und Verfügbarkeit kümmern. Der Fluch: Die Daten liegen bei einem Anbieter, dessen Server in den USA stehen und der als US-Unternehmen dem Cloud Act unterliegt. Für Unternehmen mit hohen Compliance-Anforderungen ist das ein Kriterium, das man nicht wegdiskutieren kann. Für viele andere hingegen ist es eine akzeptable Abwägung, weil die Vertriebsdaten selten so sensibel sind wie etwa Konstruktionsdaten oder personenbezogene Informationen aus dem HR-Bereich.
Wo Nextcloud und Nutshell sich treffen
Richtig spannend wird es, wenn man sich die Berührungspunkte genauer ansieht. Es gibt nämlich keinen offiziellen, vom Hersteller gepflegten Connector zwischen Nextcloud und Nutshell. Wer beides nutzen will, muss ein wenig selbst Hand anlegen. Das ist ein Umstand, der in der Praxis häufiger vorkommt als reine SaaS-Ökosysteme vermuten lassen – und der die Frage aufwirft, ob man ihn als Mangel oder als Chance begreift.
Zunächst: Nutshell verwaltet Kontakte, Deals und Aktivitäten. An Deals hängen typischerweise Dateien – Angebote, Verträge, Präsentationen. Diese Dateien liegen, wenn man der Standardlogik von SaaS-CRM-Tools folgt, in Nutshells eigener Cloud. Alternativ kann man sie in Nextcloud ablegen und aus Nutshell heraus verlinken. Damit hat man die Dateihoheit beim eigenen Speicher, während Nutshell nur noch die Metadaten und die Verknüpfung hält. Das ist ein pragmatischer Ansatz, der in vielen kleineren Umgebungen funktioniert und der die Datenhoheit zumindest für die Dokumente wahrt.
Der zweite Berührungspunkt ist die Automatisierung. Nextcloud kann per WebDAV oder über die öffentlichen APIs Dateiereignisse nach außen signalisieren, sofern man das entsprechend einrichtet. Nutshell wiederum bietet Webhooks und eine API, über die sich Datensätze anlegen und aktualisieren lassen. Wer bereit ist, eine kleine Middleware dazwischenzusetzen – ein Python-Skript, ein Node-Dienst oder auch eine Low-Code-Lösung wie n8n –, kann Abläufe bauen, die in der Praxis echt etwas bringen. Beispiel: Ein Kunde legt einen Angebotsentwurf in einem Nextcloud-Ordner ab, ein Watcher erkennt die Datei, zieht Metadaten aus dem Dateinamen oder einer Begleitdatei und legt automatisch eine Aktivität im zugehörigen Nutshell-Deal an.
Solche Konstrukte klingen gebastelt, und sie sind es auch. Aber sie sind extrem leistungsfähig, wenn man ihre Grenzen kennt. Die größte Einschränkung: Fehlerbehandlung. Wer ein Skript schreibt, das zwei Systeme synchronisiert, muss damit rechnen, dass die API des einen Systems mal langsam antwortet, dass ein Zugriffstoken abläuft, dass ein Datensatz in einem System geändert wurde, während das andere gerade schreibt. Wer diese Fälle nicht explizit behandelt, baut sich eine Dateninkonsistenz, die im Zweifel mehr Arbeit macht als das ursprüngliche Problem.
Ein realistisches Beispielszenario
Nehmen wir ein mittelständisches Maschinenbauunternehmen mit fünf Vertriebsmitarbeitern, einer kaufmännischen Leitung und einem kleinen IT-Team von zwei Personen. Das Unternehmen nutzt Nextcloud bereits für die Ablage von Zeichnungen, Angeboten und Verträgen. Der Wunsch: ein CRM, das die Vertriebspipeline abbildet, ohne dass man auf einen weiteren Cloud-Dienst angewiesen ist – wobei man Kompromisse bei den Vertriebsdaten akzeptiert, solange die Dokumente im eigenen Haus bleiben.
Der pragmatische Aufbau sieht so aus: Nextcloud bleibt die Datenquelle für alles, was als Datei existiert. Innerhalb der Nextcloud-Struktur gibt es pro Kunde einen Ordner, in dem Angebote, Auftragsbestätigungen und Verträge liegen. Nutshell dient als Pipeline-Tool, hält Kontaktdaten, Deal-Stadien und Aktivitäten. In jedem Deal wird ein Link auf den entsprechenden Nextcloud-Ordner hinterlegt – entweder als Freitextfeld-Notiz oder als angehängte URL, je nachdem was die Konfiguration hergibt.
Die Middleware dazwischen übernimmt zwei Aufgaben. Erstens: Sie legt für jeden neuen Kontakt in Nutshell automatisch einen Ordner in Nextcloud an, mit den üblichen Unterordnern für Angebote, Verträge und Kommunikation. Zweitens: Sie erzeugt eine Notiz im Deal, sobald in dem Ordner eine neue Datei landet – mit Namen, Datum und einem Direktlink. Damit weiß der Vertrieb immer, wo der letzte Stand liegt, ohne sich durch Dateisysteme klicken zu müssen.
Wer diese Integration sauber haben will, sollte mit einem Identitätskonzept arbeiten. Nextcloud unterstützt LDAP und SAML, Nutshell bietet SSO über gängige Provider. Wenn man eine zentrale Identitätsquelle – etwa Keycloak, Authentik oder einen Active Directory – dazwischenhängt, lassen sich Benutzerkonten konsistent halten. Das ist mehr Aufwand als eine reine Passwortverwaltung in beiden Systemen, aber es reduziert die Zahl der Onboarding- und Offboarding-Fehler erheblich.
Was gegen eine enge Kopplung spricht
So reizvoll eine tiefe Integration auch klingt, es gibt gute Gründe, sie nicht zu übertreiben. Erstens: Jede Kopplung erhöht die Abhängigkeit. Wer sein CRM fest mit einem selbst betriebenen Filesystem verklebt, bekommt Probleme, wenn eines der Systeme ersetzt wird. Zweitens: Nutshell ist SaaS. Der Anbieter kann seine API ändern, Endpunkte deprecaten oder Preise anpassen. Wer dann auf eine tiefe Integration angewiesen ist, hat schlechte Karten.
Drittens – und das ist vielleicht der wichtigste Punkt – die Komplexität. Middleware will betrieben, überwacht und aktualisiert werden. Wer sie baut, muss sie auch pflegen. In kleinen IT-Teams ist das oft die Sorte Aufgabe, die zuerst liegen bleibt und dann irgendwann ausfällt, ohne dass es jemand merkt. Eine bewusst flache Integration – per Link und gemeinsamer Namenskonvention – ist weniger elegant, aber robuster gegenüber Personalwechseln und Aufmerksamkeitslücken.
In diesem Sinne lohnt es sich, genau zu überlegen, welche Abläufe wirklich automatisiert werden müssen. Ein CRM, das einen Link in die eigene File-Sharing-Plattform setzt, ist oft schon ausreichend. Erst wenn Kundenstammdaten an mehreren Stellen gepflegt werden, oder wenn Prozesse mit hoher Frequenz laufen, rechtfertigt sich der Integrationsaufwand.
Alternativen zur Kombination
Natürlich ist die Kombination Nextcloud plus Nutshell nicht die einzige Option. Wer eine vollständig souveräne Lösung sucht, kann auf ein CRM setzen, das sich selbst hosten lässt – SuiteCRM zum Beispiel, oder EspoCRM, oder Odoo in der Community-Edition. Diese Systeme bieten den Vorteil, dass alle Daten im eigenen Haus liegen und sich über die bestehenden Nextcloud-Mechanismen anbinden lassen. Sie kommen aber mit anderen Kompromissen: Reifegrad der Oberfläche, Community-Support, fehlende Marketing-Funktionen.
Wer den umgekehrten Weg gehen will, ersetzt Nextcloud durch eine SaaS-Plattform wie Microsoft 365 oder Google Workspace und integriert den Vertrieb dort. Der Vorteil: bessere Interoperabilität mit kommerziellen CRM-Systemen, weniger Betriebsaufwand. Der Nachteil: Man gibt die Datenhoheit auf, und die Abhängigkeit vom Anbieter wächst.
Zwischen diesen Extremen gibt es eine Reihe von Zwischenwegen. Man kann Nextcloud als reine Dateiablage betreiben und parallel ein CRM eines europäischen Anbieters nutzen, der DSGVO-konforme Datenhaltung garantiert. Man kann auch eine hybride Lösung bauen, in der Nextcloud die Dokumente und Teile der Kommunikation hält, während Nutshell (oder ein anderer Vertriebsdienst) nur die Pipeline verwaltet. Welcher Weg passt, hängt weniger von technischen Fragen ab als von den organisatorischen Rahmenbedingungen: Wie groß ist die IT-Mannschaft? Wie wichtig ist Datenhoheit? Wie viel Änderungswille ist im Vertrieb vorhanden?
Betriebliche Realitäten
Ein Punkt, der in vielen Artikeln zu kurz kommt, ist der laufende Betrieb. Nextcloud ist kein Set-and-forget-System. Updates müssen zeitnah eingespielt werden – nicht nur, weil neue Funktionen dazukommen, sondern weil Sicherheitslücken geschlossen werden. Größere Versionssprünge sollten auf einer Testinstanz vorbereitet werden, weil gelegentlich Apps brechen oder Datenbankschemata angepasst werden müssen. Wer das ignoriert, riskiert, dass ein Update zur Unzeit die Arbeit lahmlegt.
Auf der Nutshell-Seite ist der Betrieb einfacher, weil der Anbieter die Verantwortung trägt. Dafür muss man sich dort um Ausfälle nicht selbst kümmern, hat aber auch keine Kontrolle, wenn Wartungsfenster ungelegen kommen. Wichtiger ist die Frage, wie man Daten aus Nutshell herausbekommt, wenn man den Anbieter wechseln will. Der Export ist möglich, aber man sollte vor Vertragsabschluss klären, in welchen Formaten und mit welcher Vollständigkeit die Daten migrierbar sind. Erfahrungsgemäß ist der Teufel hier im Detail: Ein CSV-Export enthält keine Beziehungen, und Verlaufshistorien sind oft nicht vollständig rekonstruierbar.
Für beide Systeme gilt: Backups sind nicht optional. Bei Nextcloud sollte man regelmäßig Datenbank und Datenverzeichnis sichern, am besten auf separaten Medien und mit getesteten Restore-Prozessen. Bei Nutshell verlässt man sich auf den Anbieter – was in der Regel funktioniert, aber nicht davor schützt, dass man versehentlich Datensätze löscht. Ein periodischer Export auf ein eigenes Speichermedium, das im eigenen Haus bleibt, ist ein sinnvoller Riegel gegen die schlimmsten Fälle.
Sicherheit: Wo die eigentlichen Fragen liegen
Auf der Sicherheitsseite ist die Antwort nicht pauschal. Nextcloud bietet eine Reihe von Schutzmechanismen: Zwei-Faktor-Authentifizierung, Verschlüsselung im Ruhezustand mit serverseitigem Krypto-Modul oder Ende-zu-Ende-Verschlüsselung, feingranulare Freigabeoptionen, Wasserzeichen, Zugriffsbeschränkungen nach IP-Bereichen und so weiter. Ob man sie nutzt, ist eine andere Frage. In der Praxis sehen wir häufig, dass die Zwei-Faktor-Authentifizierung aus Bequemlichkeit aus ist, dass Freigaben großzügig gesetzt werden und dass Audit-Logs nicht ausgewertet werden. Das sind vermeidbare Risiken, die schwerer wiegen als die Wahl des Filesystems.
Bei Nutshell ist das Sicherheitsmodell von der Cloud-Architektur geprägt. Der Anbieter sichert Übertragung und Speicherung zu, bietet Rollenkonzepte und Audit-Funktionen, und für Unternehmen mit höheren Anforderungen gibt es die üblichen Compliance-Zusagen. Der kritische Punkt bleibt: Die Daten liegen in einer US-Cloud. Wer damit leben kann, bekommt ein robust betriebenes System. Wer nicht, muss die Vertriebsdaten entweder ganz aus dem SaaS-Tool heraushalten – was in der Praxis kaum möglich ist – oder auf eine andere Plattform setzen.
Interessant ist in diesem Kontext, dass einige Unternehmen asymmetrische Wege gehen. Sie verlegen die unkritischen Vertriebsaktivitäten in ein SaaS-CRM, während vertrauliche Angebote, Konstruktionsdaten und Verträge in Nextcloud bleiben, mit Zugriff nur für einen kleinen Kreis. Damit trennt man die Datenströme nach Sensitivitätsgrad, was datenschutzrechtlich und sicherheitstechnisch oft die bessere Lösung ist als eine einzige Lösung für alles zu erzwingen.
Nutzung in der Praxis: Was wirklich funktioniert
Erfahrungen aus laufenden Umgebungen zeigen, dass drei Dinge besonders wichtig sind. Erstens: einheitliche Namenskonventionen. Wer Ordner nach Kundenname anlegt und Angebote nach Schema „Kundennummer-Datum-Version“ benennt, hat verloren, sobald zwei Personen dasselbe tun. Eine schriftlich festgehaltene Konvention spart erstaunlich viel Reibung – und macht spätere Automatisierung überhaupt erst möglich.
Zweitens: klare Verantwortlichkeiten. Wer darf einen Kunden in Nutshell anlegen? Wer löscht einen Deal? Wer entscheidet über die Anlage eines Ordners in Nextcloud? In kleinen Teams werden solche Fragen gern mündlich geklärt, was funktioniert, solange alle langjährig im Unternehmen sind. Sobald eine neue Person dazukommt, brechen die informellen Regeln auseinander.
Drittens: Sichtbarkeit. Was in Nutshell passiert, sollte im Vertrieb sichtbar sein. Was in Nextcloud passiert, sollte in der Projekt- und Auftragsabwicklung sichtbar sein. Man muss nicht alles überall sehen, aber es hilft, wenn klar ist, wer welches System als „führend“ betrachtet. Ein häufiger Fehler ist, beide Systeme als gleichberechtigt zu behandeln und dann in Meetings zu erleben, dass zwei Personen unterschiedliche Zahlen aus unterschiedlichen Quellen präsentieren.
Was kommt als Nächstes?
Für Nextcloud ist zu erwarten, dass der Plattformgedanke weiter gestärkt wird. Die Entwicklung der letzten Jahre zeigt deutlich, dass man sich zunehmend als Grundlage für andere Anwendungen positioniert – mit Files, Groupware, Talk, Office und vor allem einer wachsenden Anzahl von Apps, die auf der Plattform aufsetzen. Die Frage, ob man Nextcloud als zentrale Schaltstelle für Kollaboration und Datenhaltung einsetzt, wird damit zunehmend zu einer Frage der Architektur – nicht mehr nur der Werkzeugwahl.
Nutshell bewegt sich in einem Markt, der von Konsolidierung geprägt ist. Die Großen der Branche kaufen kleinere Anbieter auf, integrieren Funktionen und verschieben den Fokus in Richtung umfassender Sales-Plattformen. Wie lange ein Anbieter dieser Größenordnung eigenständig bleibt, ist offen. Unternehmen, die auf Nutshell setzen, sollten deshalb ihre Exit-Strategien kennen – unabhängig davon, wie zufrieden sie mit dem Produkt sind.
Die eigentlich spannende Entwicklung liegt aber in der Mitte: in Werkzeugen, die beides verbinden. Middleware-Lösungen wie n8n, Make oder die Integration-Frameworks von Nextcloud (Flow) und Nutshell (Webhooks, API) werden zunehmend mächtiger. Was vor fünf Jahren noch Eigenentwicklung erforderte, lässt sich heute mit überschaubarem Aufwand abbilden. Das bedeutet aber auch: Die Entscheidung, zwei getrennte Systeme zu betreiben, wird zunehmend zu einer bewussten Architekturentscheidung – nicht mehr zu einem Kompromiss aus Mangel an Alternativen.
Ein Fazit, das kein Rezept ist
Nextcloud und Nutshell sind kein Traumpaar, das von Natur aus zueinander strebt. Das eine ist eine offene, selbst gehostete Plattform mit Fokus auf Datenhoheit; das andere ein pragmatisches SaaS-CRM mit Fokus auf Bedienbarkeit und schnellem Einstieg. In vielerlei Hinsicht verkörpern sie gegensätzliche Philosophien. Und dennoch lassen sich beide sinnvoll verbinden, wenn man die Bruchstelle bewusst gestaltet.
Wer Datenhoheit als nicht verhandelbares Kriterium sieht, wird um eine selbst gehostete CRM-Lösung nicht herumkommen. Wer Bedienbarkeit und schnelle Einsatzbereitschaft priorisiert, findet in Nutshell ein gutes Werkzeug und akzeptiert im Gegenzug die Cloud-Abhängigkeit. Wer einen Mittelweg sucht, kann Nextcloud als Datendrehscheibe betreiben und Nutshell als Vertriebsgedächtnis – mit einer schlanken Middleware dazwischen, die genau die Abläufe automatisiert, die dies tatsächlich rechtfertigen.
Der entscheidende Punkt ist, dass es keine generelle Antwort gibt. Jede Kombination muss zu den eigenen Anforderungen passen. Nicht zuletzt deshalb lohnt es sich, vor der Entscheidung eine ehrliche Bestandsaufnahme zu machen: Welche Daten sind wirklich sensibel? Wie viel IT-Kapazität ist dauerhaft verfügbar? Wie viel Änderungswille ist im Vertrieb vorhanden? Wer diese Fragen beantwortet, kommt zu einer Lösung, die nicht trendy ist, sondern trägt – und das ist am Ende das, was im Betrieb zählt.