Domínio Visual ist kein Start-up. Es ist ein Betrieb für visuelle Beschilderung — Blockbuchstaben, Fassaden, Paneele, Innenbeschilderung — und arbeitet für Kunden, die den Auftrag an einem festen Datum montiert brauchen, nicht in einem hypothetischen Sprint.
Hier geht es darum, was passiert, wenn ein echtes Dienstleistungsgeschäft aufhört, Aufträge in Excel-Tabellen, Notizbüchern und WhatsApp-Verläufen zu verwalten, und stattdessen über eine maßgeschneiderte digitale Plattform arbeitet. Was man gewinnt, was man verliert und was beim ersten Anlauf fast immer schiefläuft.
Zusammenfassung
Ein Dienstleistungsbetrieb hat drei chronische operative Probleme: der echte Status jedes Auftrags verteilt sich auf mehrere Köpfe, die Kundenhistorie lebt in Gesprächen, und die Rechnungsstellung hängt davon ab, wer sich erinnert, was gemacht wurde. Generische Software löst nichts davon, weil das Vokabular falsch ist. Die Lösung ist eine Plattform, die um den tatsächlichen Ablauf des Betriebs herum gedacht ist, mit Zuständen, die den physischen Arbeitsphasen entsprechen, und einer Oberfläche, die jeder im Team ohne Schulung bedienen kann.
Bei Domínio Visual hieß das: zehn Zustände modellieren, von „Technischer Besuch" bis „Rechnungsstellung", eine MariaDB-Datenbank rund um Serviceaufträge entwerfen und ein Frontend, das davon ausgeht, dass der Nutzer gerade auf einer Baustelle steht und nicht auf ein Metrik-Dashboard schaut.
Das geschäftliche Problem
Ein Beschilderungsbetrieb arbeitet projektweise. Jeder Serviceauftrag durchläuft mehrere physische Etappen: jemand fährt zum Objekt und misst aus, jemand entwirft das Layout, das Layout geht zur Freigabe an den Kunden, Material wird gedruckt oder geschnitten, bei Außenanlagen entsteht die Metallkonstruktion, in der Werkstatt wird montiert, die Installation wird terminiert, geliefert — und erst dann wird abgerechnet.
An jeder dieser Etappen hängen andere Personen. Der Vertriebler, der vor Ort war, ist nicht der Designer, der das Layout baut. Der Designer bedient keine Schneidemaschine. Wer vor Ort montiert, war selten in der Werkstatt. Und der Kunde ruft bei jedem von ihnen an und fragt: „Und, wie weit ist mein Auftrag?"
Ohne Plattform hängt die Antwort davon ab, wer abnimmt. Jeder hat ein Teil des Puzzles. Die konsolidierte Sicht gibt es nirgends — sie ist verteilt.
Warum das wichtiger ist, als es scheint
Dieses Modell hat drei versteckte Kosten, und alle fressen Marge, ohne in der Gewinn- und Verlustrechnung aufzutauchen.
Erstens: Koordinationskosten. Jeder Auftrag erzeugt zehn bis zwanzig Mikro-WhatsApp-Chats zur Statusabfrage. Multipliziere das mit dreißig oder vierzig laufenden Baustellen und du hast täglich mehrere Stunden qualifizierter Leute, die die Arbeit eines Systems machen.
Zweitens: Nacharbeitskosten. Ohne zentrale Historie wird häufig Arbeit wiederholt, weil die freigegebene Layout-Version in einer drei Wochen alten E-Mail vergraben ist oder weil das Aufmaß mit Bleistift notiert wurde und niemand es entziffern kann.
Drittens — und das ist das Teuerste — ausgefallene Rechnungen. Aufträge, die montiert, aber nie fakturiert wurden, weil sie vom Radar verschwanden. Mündlich vereinbarte Nachträge, die nie in das endgültige Angebot flossen. Eine Studie der Aberdeen Group schätzte vor Jahren, dass Unternehmen ohne strukturierte digitale Prozesse jährlich zwischen 1 % und 3 % des Umsatzes an nicht gestellten oder nicht eingetriebenen Rechnungen verlieren. Diese Zahl steht nirgends — sie verschwindet lautlos.
Was „digitale Plattform" für so ein Geschäft bedeutet
Es ist kein CRM. Es ist kein ERP. Es ist kein Trello mit angepassten Zuständen. Es ist all das gleichzeitig, aber mit einem Vokabular, das exakt dem entspricht, was der Betrieb tut.
Der Unterschied ist fein, aber entscheidend. Wenn die Software einen Serviceauftrag „Deal", „Opportunity" oder „Task" nennt, wird das Team sie nie konsistent nutzen. Nennt sie ihn „OS" und hat die Zustände, die das Team im Kopf schon verwendet — Besuch, Layout, Freigabe, Druck, Schnitt, Metallbau, Produktion, Montage, Versand, Rechnung — kommt die Akzeptanz sofort.
Das ist das zentrale Argument für Individualsoftware im Dienstleistungsgeschäft: Es geht nicht um Features. Es geht um Sprache.
Die technischen Entscheidungen, die geschäftlich zählen
Jede technische Wahl hier wurde mit Blick auf die operative Wirkung getroffen, nicht darauf, was für den Entwickler interessant ist.
Die Datenbank ist relationales MariaDB, keine modische NoSQL-Basis. Weil ein Serviceauftrag feste Beziehungen zu Kunde, Positionen, Historie und Rechnung hat, und wenn ein Buchhalter zum Jahresende eine Abfrage laufen lassen muss, ist SQL eine Sprache, die viele Menschen lesen können.
Die Authentifizierung nutzt bcrypt für neue Nutzer, bleibt aber mit MD5-Altbeständen kompatibel. Das ist nicht elegant. Es ist pragmatisch: bestehende Nutzer müssen am Umzugstag kein Passwort zurücksetzen, und genau das ist der Unterschied zwischen „alle nutzen es" und „die halbe Belegschaft hat aufgegeben".
Das Frontend ist eine schnelle SPA, ausgeliefert über Nginx, mit einer Fastify-API in Node.js im Rücken. Es hätte eine klassische Rails-Anwendung mit serverseitigem Rendering sein können. Die SPA-Wahl kommt aus einer konkreten Anforderung: Monteure vor Ort müssen den Status vom Handy aktualisieren, oft mit schwachem Mobilfunk. Eine SPA mit lokalem Zustand und asynchroner Synchronisation funktioniert in diesem Kontext besser als ein System, das pro Klick einen vollständigen Roundtrip verlangt.
Nur deshalb ist die Entscheidung sinnvoll. Säßen alle im Büro am Glasfaseranschluss, wäre eine klassische Anwendung billiger zu bauen und zu warten gewesen.
Den echten Ablauf modellieren: das Zustandsproblem
Der häufigste Fehler bei der Digitalisierung solcher Betriebe ist, den echten Ablauf in ein vereinfachtes Modell mit drei oder vier Zuständen zu übersetzen: offen, in Arbeit, erledigt. Sauber im Diagramm, nutzlos im Feld.
Domínio Visual arbeitet mit zehn eigenständigen Zuständen. Jeder entspricht einer physischen Arbeitsphase und einem verantwortlichen Team oder einer verantwortlichen Person:
- Abgeschlossen (0) — Endzustand nach Rechnungsstellung
- Besuch (1) — Vertrieb fährt zum Objekt und misst aus
- Layout (2) — Designer erstellt den visuellen Entwurf
- Druck (3) — Vinyl oder bedrucktes Material
- Schnitt (4) — Zuschnitt von Buchstaben oder festem Material
- Metallbau (5) — Metallkonstruktion, falls erforderlich
- Produktion (6) — Montage in der Werkstatt
- Montage (7) — Installation beim Kunden
- Versand (8) — Lieferlogistik
- Rechnung (9) — Rechnungserstellung
- Layout-Freigabe (10) — Kunde bestätigt vor dem Druck
Diese Granularität ist kein Overengineering. Jeder Zustand entspricht einer konkreten Person, die wissen muss: „Welche Aufträge liegen jetzt bei mir?" Zwei Zustände zusammenzulegen heißt, dass diese Person plötzlich Aufträge sieht, die nicht zu ihr gehören. Die Akzeptanz bricht sofort ein.
Historie: das unsichtbare Feature, das mehr Probleme löst als jedes andere
Jeder Serviceauftrag hat eine zugeordnete Historie-Tabelle. Jeder Statuswechsel, jede Notiz, jeder Anhang wird mit Zeitstempel und ändernder Person festgehalten.
Dieses Feature verlangt niemand in der Anforderungsphase — und sechs Monate später ist es das meistgenutzte. Weil es drei operative Probleme löst, die keine technische Lösung zu haben schienen:
Wenn der Kunde reklamierend anruft, kann jeder die exakte Chronologie des Auftrags rekonstruieren, ohne auf das Gedächtnis der Beteiligten angewiesen zu sein.
Wenn intern diskutiert wird, „wer wem was gesagt hat", gibt es ein neutrales Protokoll, das die Diskussion in Sekunden beendet.
Wenn ein neues Teammitglied anfängt, kann es den Kontext alter Aufträge verstehen, ohne fünf Leute fragen zu müssen.
Die Faustregel lautet: Wenn etwas drei Monate später die Frage „Aber wann war denn…" oder „Wer war es, der…" auslösen kann, muss es in der Historie stehen. Immer.
Was beim ersten Anlauf fast immer schiefläuft
Es lohnt, über die Fehler konkret zu werden, die in fast jedem Projekt dieser Art auftauchen, damit wer darüber nachdenkt zu starten, weiß, was zu vermeiden ist.
Fehler eins: mit dem Rechnungsmodul beginnen. Das ist intuitiv — die Rechnung ist der Punkt, an dem das Geld reinkommt, also wirkt sie prioritär. Es ist falsch. Wenn der Rest des Systems nicht genutzt wird, wird weiter außerhalb des Systems abgerechnet wie bisher. Beginne mit dem operativen Status der Aufträge; die Rechnungsstellung folgt von selbst.
Fehler zwei: das ganze Team vor dem Bau nach seiner Meinung fragen. Jeder will die Software für seinen Teil des Ablaufs optimieren, was zu einem Frankenstein aus widersprüchlichen Features führt. Wähle ein bis zwei erfahrene Personen, die das Geschäft von Ende zu Ende sehen, und ignoriere den Rest, bis eine lauffähige Version zur Reaktion da ist.
Fehler drei: keine historischen Daten migrieren. Ein neues System ohne die letzten zwei Jahre an Aufträgen ist ein leeres System. Das Team geht weiter ins alte, um die Vergangenheit nachzuschauen. Datenmigration ist mühsam, technisch und unglamourös, aber ohne sie bleibt die Akzeptanz immer halb.
Fehler vier: Dashboards vor dem Ablauf. Diagramme sieht die Geschäftsführung einmal pro Woche. Den täglichen Ablauf nutzen alle. Eine Plattform ohne Dashboards, aber mit funktionierendem Ablauf, ist ab Tag eins nützlich. Umgekehrt nicht.
Gute Praktiken für jeden Dienstleistungsbetrieb
Domínio Visual ist Beschilderung, aber das Muster gilt für jedes Unternehmen, das Projekte verkauft: Kreativagenturen, Bau, Architektur, Werkstätten, Druckereien, AV-Integratoren, Event-Firmen.
- Modelliere die Zustände, die das Team im Kopf schon nutzt, nicht die, die im Diagramm sauber aussehen
- Die Historie jedes Auftrags ist Pflicht, nicht optional
- Hybride Authentifizierung während der Migration — zwinge am ersten Tag niemandem ein Passwort-Reset auf
- Relationale Datenbank für operative Daten; wenn später komplexe Analysen nötig sind, exportiere
- Oberfläche gedacht für Handy mit schwachem Empfang, nicht für Bürobildschirm
- Rechnungsstellung kommt nach dem operativen Ablauf, nie davor
- Ein interner Verantwortlicher mit Entscheidungsmacht, kein Komitee
Zur Wahl zwischen Standardsoftware und Maßanfertigung
Die richtige Frage ist nicht „kostet eine Maßanfertigung mehr?". Tut sie. Die Frage lautet: Wie viel ist es wert, dass das Team das System täglich nutzt und nicht nach drei Monaten wieder aufgibt?
Standardsoftware — ein Monday, ein Asana, ein mit Zusatzfeldern angepasstes HubSpot — ist in der Anschaffung günstiger. Sie ist aber systematisch teurer im Unterhalt, weil sie vom Team verlangt, das Softwarevokabular ins Betriebsvokabular zu übersetzen. Diese Übersetzung versagt genau in den Momenten, in denen das System am dringendsten gebraucht wird: wenn Druck herrscht, der Kunde gereizt ist, die Frist eng wird.
Individualsoftware mit eigenem Vokabular eliminiert diese Übersetzung. Die Anfangskosten sind höher. Die Gesamtkosten über fünf Jahre sind fast immer niedriger. Und der Wert, operative Daten strukturiert im eigenen Schema zu haben — abfragbar, exportierbar, analysierbar, ohne von eingeschränkten Drittexporten abhängig zu sein — ist schwer zu überschätzen.
Das ist keine universelle Regel. Ein kleines Team am Anfang soll Notion oder ein Spreadsheet nutzen, bis es wehtut. Wenn es anfängt wehzutun, ist das das Signal zum Bauen.
Sicherheit und Betriebsfähigkeit
Eine Plattform, die Serviceaufträge, Kundendaten und Rechnungshistorie verwaltet, wird schnell geschäftskritisch. Das zwingt zu drei Disziplinen, die Dienstleistungsbetriebe traditionell unterschätzen.
Backups. Nicht wöchentlich. Mindestens täglich, idealerweise stündlich inkrementell. Getestet. Ein nie getestetes Backup ist eine Hoffnung, keine Garantie. Führe mindestens zweimal im Jahr eine vollständige Wiederherstellung in einer separaten Umgebung durch.
Pflicht-HTTPS und automatisch erneuerte Zertifikate über Let's Encrypt. Das ist seit 2016 Standard, und noch heute tauchen Firmen mit gebrochenem Schloss im Browser auf. Es gibt 2026 keine technische Rechtfertigung, eine Verwaltungsanwendung über HTTP auszuliefern.
Rollenbasierte Zugriffskontrolle. Nicht jeder muss alles sehen. Wenn der Vertrieb keine Margen sehen muss, sieht er sie nicht. Wenn der Monteur nur Adresse und Uhrzeit braucht, erscheint nur das. Das Prinzip der minimalen Rechte, wie OWASP es seit Jahrzehnten beschreibt, ist keine Paranoia — es ist Grundhygiene.
DSGVO: was sich mit eigener Software ändert
Dienstleistungsbetriebe in Portugal arbeiten mit personenbezogenen Kundendaten: Namen, Adressen, Kontakte, oft Steuernummer. Die DSGVO fordert in Artikel 6 eine klare Rechtsgrundlage für die Verarbeitung und in Artikel 32 angemessene technische Maßnahmen.
Eigene Software bringt hier konkrete Vorteile: Du kannst passende Aufbewahrungsfristen umsetzen, Pseudonymisierung dort, wo es sinnvoll ist, Löschrecht ohne Support-Ticket beim externen Anbieter und auditierbare Logs über das Wer-tat-was. Generisches SaaS bietet das alles in der Theorie; in der Praxis hängt jede dieser Funktionen vom gebuchten Tarif und von der Reaktionszeit des Supports ab.
Echte Kosten: was in Angeboten niemand sagt
Ein gut gemachtes Projekt dieser Art hat vier Kostenblöcke, die die meisten Angebote unterschätzen.
Die initiale Entwicklung ist der sichtbare Teil — Aufbau der Anwendung, Design, Tests, Produktivsetzung. Typischerweise 40 % bis 60 % der Gesamtkosten im ersten Jahr.
Datenmigration wird immer unterschätzt. Daten aus Excel-Dateien, digitalisiertem Papier und Altsystemen zu ziehen und sie für den Import konsistent zu machen, kostet mehr Zeit, als jede vernünftige Schätzung nahelegt. Reserviere mindestens 15 % des Budgets.
Schulung und Begleitung in den ersten Wochen. Die ersten zwei Wochen nach dem Start entscheiden, ob die Akzeptanz greift. Jemanden verfügbar zu haben, der Fragen beantwortet, kleine Bugs schnell behebt und UX-Details nachjustiert, ist der Unterschied zwischen „das Team hat es übernommen" und „das Team ist zurück bei WhatsApp".
Laufende Wartung. Server, Backups, Sicherheitsupdates, kleine monatliche Verbesserungen. Ein planbarer monatlicher Betrag, den viele Unternehmen gerne verdrängen, bis das System ausfällt.
Signale, dass es Zeit ist, es zu tun
Einige konkrete Signale, vom milden zum ernsten, die zeigen, dass ein Dienstleistungsbetrieb an die Grenze der manuellen Verwaltung stößt:
- Kunden rufen an und fragen nach Aufträgen, und du musst drei Leute fragen, bevor du antworten kannst
- Die Person, die die zentrale Excel-Datei pflegt, ist im Urlaub, und das Geschäft stockt
- Du entdeckst Aufträge, die seit Wochen abgeschlossen, aber nie fakturiert sind
- Interne Diskussionen enden mit „Ich dachte, du kümmerst dich darum"
- Neue Mitarbeiter brauchen Wochen, um zu verstehen, wo was liegt
- Wenn du um 20 % wächst, verschlechtert sich die Koordination exponentiell statt linear zu skalieren
Erkennst du zwei oder drei dieser Signale, ist es wahrscheinlich Zeit. Erkennst du vier oder mehr, war es vor zwei Jahren Zeit.
Kernaussagen
Ein Dienstleistungsbetrieb braucht keine beeindruckende Technik. Er braucht ein System, das das richtige Vokabular verwendet, den tatsächlichen Status der Arbeit erfasst, eine auditierbare Historie führt und auf dem Handy derer funktioniert, die im Feld sind.
Die Wahl zwischen Standard und Maßanfertigung ist eine Entscheidung über Gesamtbetriebskosten und über die reale Wahrscheinlichkeit, dass das Team das System annimmt. Standard ist billiger zu starten; Maßanfertigung ist billiger im Unterhalt und im Gebrauch. Für kritische Abläufe gewinnt die Maßanfertigung in drei bis fünf Jahren fast immer.
Die Migration ist eher eine Frage des Veränderungsmanagements als der Technik. Dass die Software fertig ist, ist notwendig, aber nicht ausreichend. Ohne internen Verantwortlichen mit Autorität und ohne ernsthafte Migration der Altdaten bleibt selbst das beste System halb angenommen.
Der nächste redaktionelle Beitrag schaut auf das Gegenteil: wann es sinnvoll ist, alles in Tabellenblättern zu lassen und der Versuchung zu widerstehen, zu früh zu digitalisieren. Nicht jeder Betrieb ist bereit, und manchmal ist der Bau eines Systems nur eine Art, operative Entscheidungen aufzuschieben, die vorher getroffen werden müssen.