Angebotssystem für einen Dachbinderhersteller — von 2 Stunden auf 5 Minuten pro Angebot

· 8 Min. Lesezeit · Case Study
BrancheHolzbau — Nagelplattenbinder (Dachbinder)
Größe30 Personen
LeistungIndividuelle Software
Time to Go-live3 Monate
StackASP.NET Core · React · PostgreSQL · QuestPDF · Azure

Ein Hersteller von Nagelplattenbindern — hölzernen Dachtragwerken, die für ein konkretes Dach, einen konkreten Sparrenabstand, eine konkrete Schneelast berechnet werden. Jedes Angebot maßgeschneidert, jedes einzeln vom Vertrieb in Excel kalkuliert. Nach drei Monaten Arbeit blieben statt zwei Stunden im Excel fünf Minuten im Browser — und null falsche Kalkulationen.

Kontext: ein Produkt, das in keine Preisliste passt

Der Kunde fertigt seit achtzehn Jahren Nagelplattenbinder. Dreißig Personen, zwei Produktionshallen, Lieferungen auf Baustellen im Umkreis von 300 km. Ein Dachbinder ist kein Regalprodukt — es ist ein Dachtragwerk, das für eine konkrete Baustelle ausgelegt wird, mit konkreter Dachgeometrie, Winkeln, Sparrenabstand, Schneelast der Klimazone, Spannweite und Holzklasse.

Jedes Angebot ist einzigartig. Der Kunde (Bauträger, Planungsbüro, Privatinvestor) kommt mit einer Dach-PDF oder einer Parameterliste. Der Vertrieb analysiert das Tragwerk, wählt Bindertypen, berechnet Mengen, prüft die aktuellen Holz- und Nagelplattenpreise aus den Lieferantenpreislisten, ergänzt die zum Kundentyp passende Marge und packt das Ganze in ein Angebot.

Wir haben 2025 angefangen zusammenzuarbeiten. Der Kunde kam zu uns, nachdem er versucht hatte, eine fertige Lösung von einem ausländischen Anbieter zu kaufen — und feststellte, dass es sich um Konstruktionssoftware (Tragwerksberechnung) handelte, nicht um Angebotssoftware. Das Kalkulieren sollte weiter im Excel passieren. Der Kunde sagte: „Ich will kein weiteres Excel. Ich will ein Tool, das Parameter aufnimmt und ein PDF-Angebot ausspuckt, das ich dem Kunden in 5 Minuten schicken kann."

Ausgangspunkt: 2 Stunden Excel, 5 Versionen der „aktuellen" Datei

Der Status quo sah so aus: Jeder der fünf Vertriebsmitarbeiter hatte seine eigene Kopie der „Haupt"-Excel, individuell angepasst. Die Holzpreisliste lag in einer anderen Excel, vom Einkaufsleiter manuell aktualisiert. Die Preisliste der Verbindungsbleche — in einer dritten Excel. Margen — aus dem Kopf, „weil Herr Janek weiß, welcher Kunde welche Marge bekommt".

Die Folgen waren schmerzhaft und messbar:

Was wir geprüft und verworfen haben

Der erste Reflex war „lasst uns das Excel verbessern". Man könnte ein komplexes Sheet mit VBA, Makros und Zellschutz bauen. Wir haben davon abgeraten: Solche Sheets sind nach einem Jahr nicht mehr wartbar, niemand weiß, wer was geändert hat, und kein neuer Vertriebsmitarbeiter lernt sie.

Die zweite Option war ein fertiges CPQ (Configure-Price-Quote) vom Markt. Wir haben drei evaluiert. Alle waren auf Distributionsfirmen mit Produktkatalog ausgerichtet — nicht auf einen Hersteller, der ein Tragwerk für ein konkretes Dach rechnet. Die Branchenlogik wäre als Customizing zu schreiben gewesen, die Kosten von Lizenz + Customizing überstiegen die einer dedizierten Lösung.

Wir entschieden uns für ein dediziertes Web-System. Drei Argumente: (1) die Branchenlogik benötigte ein präzises Domänenmodell (Bindertypen, Geometrie, Lasten) — leichter von Grund auf zu schreiben, als in ein CPQ-Schema zu pressen; (2) der Kunde wollte, dass das System wächst — B2B-Portal und Produktionsanbindung in einer zweiten Stufe; (3) die Entwicklungskosten lagen unter den 3-Jahres-TCO eines fertigen CPQ.

Lösung: Konfigurator + Preislisten + PDF-Generator

[ Vertrieb — Browser ] │ ▼ [ React-SPA — Binder-Konfigurator ] │ REST + JWT ▼ ┌──────────────────────────────────────┐ │ ASP.NET-Core-API │ │ • Kalkulations-Engine (DDD-Logik) │ │ • Preislisten-Import (Cron) │ │ • PDF-Generator (QuestPDF) │ │ • Auth, Audit-Log │ └──────┬──────────────┬───────────────┘ │ │ ▼ ▼ [ PostgreSQL ] [ Blob-Storage ] • Angebote • generierte PDFs • Preisliste • Anhänge • Kunden ▲ │ (Cron, einmal täglich) │ [ Lieferanten-Excels: Holz und Nagelplatten ]

Das wichtigste Element war die Kalkulations-Engine. Wir haben sie als eigenes Domänenmodul entworfen, mit Unit-Tests, die alle Bindertypen abdecken. Der Vertrieb gibt die Dachparameter ein (Geometrie, Sparrenabstand, Schneelastzone, Holzklasse), das System wählt selbst den passenden Bindertyp aus der Bibliothek und berechnet Bretteranzahl, Anzahl der Nagelplatten, Länge, Querschnitte, Gewicht und am Ende den Preis.

Holz- und Nagelplatten-Preislisten werden einmal täglich aus den Excels der Lieferanten gezogen (wir haben dieses Format gelassen, weil die Lieferanten es ohnehin nicht ändern — die Middleware liest und lädt es in die Datenbank). Margen und Rabattpolitik sind in Regeln hinterlegt: Kunde Typ A → Marge X %, Kunde Typ B → Marge Y %, Wintersaison → Bonus Z %.

Das Angebot generiert der Vertrieb mit einem Klick. Das PDF (QuestPDF) enthält: eine Übersichtszeichnung des Dachs (aus den Parametern gerendert), Bindertabellen mit Maßen und Gewicht, Kostenaufstellung, Lieferbedingungen, Lieferzeit, Firmenadresse, Kontaktdaten des Vertriebs. Firmen-Branding, sauberes Layout, mit einer Mail an den Kunden raus.

Drei Entscheidungen, die sich bewährt haben

Rollout: 3 Monate, 4 Sprints, ein Team

Wir haben in vier zweiwöchigen Sprints gearbeitet. Sprint 1 — Domänenmodell und Kalkulations-Engine (nur die Engine, ohne UI, mit Tests anhand echter Beispiele aus den Excels des Kunden). Sprint 2 — Konfigurator-UI und durchgängige End-to-End-Kalkulation. Sprint 3 — PDF-Generator, Preislisten-Import, Auth, Audit-Log. Sprint 4 — Produktionsexport, Migration historischer Angebote (300 aktuellste in die Datenbank), Vertriebsschulungen.

Jeder Sprint endete mit einem Demo für Vertrieb und Geschäftsführung. Mehrere wichtige Korrekturen (z. B. die Vereinfachung des Geometrie-Eingabeschirms) kamen genau aus diesen Demos — der Vertrieb hat das Werkzeug früh gesehen und konkrete Punkte gemeldet, die niemand am Tisch erfunden hätte.

Ergebnis nach 9 Monaten Live-Betrieb

5 Min.
pro Angebot statt 2 Stunden — die Durchschnittszeit fiel um den Faktor 24
0
in der Kontrolle erkannte Fehlkalkulationen — gegenüber ~6/Monat vor Go-live
3 Mon.
von der Idee bis zum Produktiv-Betrieb — ohne nennenswerte Verzögerungen

Der Kunde hat die Zahl der bearbeiteten Anfragen um etwa ein Drittel gesteigert, ohne den Vertrieb aufzustocken — weil der Vertrieb jetzt Zeit hat, mit Kunden zu reden, statt im Excel zu sitzen. Die Antwortzeit auf Anfragen sank von 2–3 Tagen auf denselben Tag, was die Conversion auf Aufträge spürbar verbessert hat (der Kunde fragt gar nicht mehr beim Wettbewerb an).

Der Wert entstand nicht in dem Moment, als der Code geschrieben wurde. Er entstand in dem Moment, als ein Vertriebsmitarbeiter zum ersten Mal 8 Minuten nach dem Anruf eines Kunden das Angebot verschickte und der Kunde antwortete: „Wow, das war wirklich schnell."

Wie es weitergeht

Das System läuft, der Kunde baut es weiter aus. Für 2026 ist die zweite Stufe geplant: ein Kundenportal, in dem Bauträger und Planungsbüros Anfragen selbst eingeben und sofort eine Vorabkalkulation bekommen (der Vertrieb bestätigt nur und schickt das PDF). Dazu eine Integration mit dem Produktionssystem des Kunden, sodass ein angenommenes Angebot direkt als Produktionsauftrag landet.

Das ist ein gutes Beispiel für ein Projekt, das bei einem konkreten Schmerzpunkt anfängt (Angebotserstellung) und nebenbei den gesamten Front-Office des Unternehmens ordnet. Wir schreiben das ERP nicht um. Wir ändern keine Prozesse. Wir nehmen den schmerzhaftesten Punkt und automatisieren ihn — und alles, was darum herum funktioniert, wächst in den nächsten Stufen mit.

Kalkuliert dein Unternehmen Produkte für konkrete Kunden, und macht es das von Hand? Reden wir 30 Minuten darüber, was sich automatisieren lässt — unverbindlich.

Kostenloses Gespräch buchen →

← Alle Case Studies