Für Softwarehäuser und Systemhäuser
Ihr betreibt Software beim Kunden – im Keller, in der Cloud, bei euch im Rack. Dafür gibt es Wartungsverträge mit Reaktionszeiten, die jemand unterschrieben hat. Und dann liegt der Vertrag in einem Ordner, das Ticket in einem Helpdesk, die Installation in einer Tabelle und die Überwachung in einem vierten Werkzeug. openbi Studio legt das in eine Datenbank: Vertrag → Installation → Ticket → Frist → Monitor. Ohne Schnittstelle, weil es keine braucht.
Der Freitagabend
Heute
Freitag, 17:40, eine Mail an support@: „Das System antwortet nicht mehr.“ Jemand sucht den Vertrag, um zu wissen, welche Reaktionszeit gilt. Findet die Version von 2023. Fragt den Kollegen, der im Urlaub ist. Am Montag um 9 stellt sich heraus: Bronze, vier Stunden Geschäftszeit, Frist war Montag 12:00 – und niemand hatte sie auf der Uhr.
Mit openbi Studio
Die Mail kommt ins Postfach, der Agent findet die Firma über die Absenderadresse, zieht die Reaktionszeit aus dem Wartungsvertrag, legt das Ticket an der richtigen Installation an – Frist Montag 12:00, gerechnet mit dem Zeitfenster aus dem Vertrag – und benachrichtigt das Team. Eine Wache prüft alle fünf Minuten, ob die Frist hält. Sechs von sieben Schritten ohne Menschen; den siebten, die Antwort, macht ihr.
Warum das für euch anders ist
01
Wartung ist bei euch ein Satz vom Lizenzpreis – 15, 18, 20 Prozent, je Kunde anders, seit Jahren. Hier zeigt der Wartungsvertrag auf den Lizenzvertrag und bekommt je Lizenzposition eine gerechnete Wartungszeile. Kauft der Kunde nach, entsteht die Zeile mit. Bemessungsgrundlage ist der Preis von damals, nicht der Listenpreis von heute.
02
On-premise beim Kunden, bei euch gehostet, bei einem Hyperscaler in der Region, die im Vertrag steht. Mit Land der Daten, Version und Adresse. Verträge und Tickets zeigen auf dieselbe Installation – als echter Verweis, nicht als Freitext, in dem „Prod-Server neu“ steht.
03
Macht der Kunde ein Ticket auf, sucht der Server den maßgeblichen Vertrag – Installation vor Landschaft vor Projekt vor Rahmenvertrag, im Zweifel die kürzere Frist – und schreibt Reaktions- und Lösungsfrist an das Ticket. Gespeichert, nicht jedes Mal neu gerechnet: Was zählt, ist die Zusage vom Tag der Meldung.
04
Ein täglicher Lauf sieht nach, welcher Wartungsvertrag ausläuft, und legt eine Aufgabe an – fällig am Kündigungstermin, nicht heute. Mit dem Hinweis, um wie viel er sich sonst verlängert. Die Verlängerung, die euch bisher durchgerutscht ist, war Umsatz. Die, die dem Kunden durchgerutscht ist, war ein Gespräch, das ihr nicht führen wolltet.
05
Im Hub, mit Bezug auf sein System, mit Anhang. Er sieht seine Verträge dort nach – ohne Preise – und liest die zugesagte Frist im Klartext. Interne Notizen bleiben intern. 19 € im Monat für alle eure Kunden zusammen. Den Hub ansehen
06
Alle fünf Minuten von außen: Status, Antwortzeit, Zertifikat, erwarteter Text. Auch für Systeme, die nicht bei uns laufen – der Server beim Kunden im Keller genauso wie der bei AWS. Vorfälle mit Grund, Verfügbarkeit über 24 Stunden, 7 und 30 Tage. Zum Monitoring
Aus dem laufenden System
Wir sind selbst ein Softwarehaus mit Wartungsverträgen. Das hier ist das Werkzeug, mit dem wir unsere eigenen Kunden betreuen – deshalb gibt es Bildschirmfotos und keine Mockups.
Was ihr heute dafür zusammenklebt
Wir vergleichen mit Kategorien, nicht mit Namen.
Helpdesk je Sitzplatz
Tickets ja. SLA nur als Regel, die jemand von Hand pflegt.
PSA-Suite aus den USA
Kann alles. Kostet entsprechend, und die Daten liegen dort.
CRM plus Tabelle plus Kalender
Der Vertrag liegt im Laufwerk, die Erinnerung bei jemandem, der gekündigt hat.
openbi Studio
Ein Datenbestand auf eurem Server. 99 € im Monat für die Organisation, nicht je Kopf.
Und das Studio dazu
Das CRM läuft auf einem openbi-Server, der auch euren Auftritt, euer Kundenportal und eure eigenen Werkzeuge trägt. Braucht ein Kunde eine Erweiterung, die es nicht gibt, schreibt ihr sie in C# – im selben Browserfenster, gegen die Serverversion eurer Instanz übersetzt. Wer bei euch entwickelt, findet hier keinen Umweg, sondern den Normalfall.
Ehrlich gesagt
Der Vertrag weiß, was er im Jahr wert ist und wann er abzurechnen ist. Rechnungen schreibt er nicht. Wer heute aus lexoffice oder DATEV fakturiert, macht das weiter dort – der Sales-Bericht liest die Rechnungen von dort zurück.
Das Monitoring fragt von außen über HTTP. Es läuft kein Agent auf dem Kundenrechner: keine CPU, kein Plattenplatz, keine Patches, keine Ports. Wer das braucht, behält sein RMM – und trägt die Adresse trotzdem hier ein, damit Vertrag und Ticket sie kennen.
Tickets haben Beiträge und Fristen, aber keine Stunden. Wer Support nach Aufwand abrechnet, erfasst die Zeit heute noch woanders.
Der Hub läuft unter openbi Studio, Mails an eure Kunden gehen von einer openbi-Studio-Absenderadresse, nicht von eurer Domain. Ein Werkzeug für euch, kein Produkt unter eurem Namen.
Erst der eigene Bestand
Eine Instanz, 30 Tage kostenlos. Fünf Verträge, ihre Installationen, ein Testticket. Dann seht ihr, ob die Fristen stimmen, die ihr bisher im Kopf hattet.