Zweite Schicht EN, English version Gespräch buchen

Zielgruppe

Stand

Beim Softwarehersteller wurde die Antwort schon dreimal geschrieben, nur findet sie keiner.

Ein Softwarehaus mit 220 Beschäftigten, einem Produkt für die Baubranche in drei Ausbaustufen und 1.400 Kunden mit Wartungsvertrag: Zendesk für den Support, Jira und Confluence für Entwicklung und Dokumentation, GitLab für den Code, HubSpot für Vertrieb und Verträge. Der Support bekommt 900 Tickets im Monat, und der Support-Leiter weiß bei jedem dritten, dass die Lösung bereits existiert, als Kommentar in einem alten Ticket, als Absatz in einem Hilfeartikel, als Workaround in einem Jira-Vorgang. Seine Leute suchen trotzdem von vorn, und die Entwickler bekommen Fehlerberichte, die in anderen Worten schon fünfmal im Backlog stehen. Am Freitag schreibt jemand aus den Commits der Woche die Release Notes zusammen. KI für Softwarehersteller fängt bei diesem Wissen an: Tickets lesen, die vorhandene Lösung finden, Dubletten erkennen, Texte entwerfen, und das Team gibt frei statt zu suchen.

Anfrage

Welcher Ablauf kostet Sie bei Softwareherstellern und SaaS-Anbietern am meisten Zeit?

Beschreiben Sie ihn in drei Sätzen. Wir melden uns am nächsten Werktag mit einer ersten Einschätzung, ob sich KI dort lohnt, und mit einem Terminvorschlag für ein Gespräch von 30 Minuten.

Lieber gleich einen festen Termin? Gespräch von 30 Minuten direkt buchen

Erst einmal selbst prüfen? Potenzial-Check in zehn Minuten

Direkt
+49 89 856 371 02
projekt@wdm.de

Danke, Ihre Anfrage ist angekommen. Sie bekommen in wenigen Minuten eine Bestätigung per E-Mail. Wir melden uns am nächsten Werktag.

Alle Felder ohne den Zusatz (optional) sind Pflichtfelder.

Antwort am nächsten Werktag

Abläufe

Fünf Abläufe, die sich bei Softwareherstellern und SaaS-Anbietern lohnen

Softwarehäuser haben technische Kompetenz im Haus, aber selten die Zeit, sie auf die eigenen Abläufe zu richten. Welche dieser Abläufe sich bei Ihnen rechnen, zeigt die Analyse.

  • Support-Tickets klassifizieren und mit bekannter Lösung vorlegen

    Zendesk, Freshdesk, Zammad, Confluence, Jira

    900 Tickets im Monat, verteilt auf drei Produktstufen und 40 Module. Der Ablauf liest jedes Ticket, erkennt Produkt, Version, Modul und Fehlerbild, sucht in gelösten Tickets, Hilfeartikeln und Jira-Vorgängen nach dem gleichen Bild und legt dem Supportmitarbeiter das Ticket mit Einstufung, den zwei bis drei besten Treffern und einem Antwortentwurf mit Quellenverweis vor. Tickets, die auf einen bekannten offenen Fehler zeigen, werden mit dem Jira-Vorgang verknüpft. Was keinen Treffer hat, ist als neu markiert. Gesendet wird erst nach Freigabe.

  • Fehlerberichte und Kundenwünsche in das Backlog überführen und Dubletten erkennen

    Zendesk, Jira, Microsoft 365, Produktboard

    Aus den Tickets und aus Mails der Key-Account-Betreuer entstehen monatlich 150 Fehlerberichte und Wünsche, oft derselbe Punkt in anderen Worten. Der Ablauf liest Ticket und Verlauf, formt einen Backlog-Eintrag mit Schritten zur Reproduktion, erwartetem und tatsächlichem Verhalten, Version und Kundenzahl und prüft gegen das bestehende Backlog, ob der Punkt schon existiert. Bei Treffern schlägt er die Zusammenführung vor und zählt die betroffenen Kunden am bestehenden Vorgang hoch. Der Produktmanager entscheidet über Anlage, Zusammenführung und Priorität.

  • Release Notes, Hilfeartikel und Handbuchänderungen entwerfen

    GitLab, GitHub, Jira, Confluence, Hilfeportal

    Alle zwei Wochen ein Release mit 40 bis 80 Vorgängen, danach Release Notes in Deutsch und Englisch, Änderungen in zwölf Hilfeartikeln und im Handbuch. Der Ablauf liest Commits, Merge Requests und die zugehörigen Jira-Vorgänge, entwirft die Release Notes in Ihrer Hausschrift aus Kundensicht, nicht aus Entwicklersicht, findet die betroffenen Hilfeartikel und schlägt die geänderten Absätze vor, in beiden Sprachen mit einheitlicher Terminologie. Interne Vorgänge ohne Kundenwirkung werden ausgefiltert und als Liste gezeigt. Produktmanagement und Dokumentation geben je Text frei.

  • Sicherheitsfragebögen und Ausschreibungen aus früheren Antworten vorbereiten

    Microsoft 365, Confluence, Vergabeplattformen, Antwortarchiv

    Jeder größere Kunde schickt vor Vertragsschluss einen Fragebogen zu Sicherheit, Datenschutz und Betrieb mit 100 bis 400 Fragen, dazu kommen Ausschreibungen mit Anforderungskatalogen. Der Ablauf liest den Fragebogen, findet zu jeder Frage die passende frühere Antwort und das zugehörige Dokument, etwa Zertifikat oder Richtlinie, füllt den Entwurf und markiert Fragen, die neu sind oder deren alte Antwort älter als zwölf Monate ist. Bei Ausschreibungen ordnet er Anforderungen den Produktfunktionen zu und zeigt Lücken. Der Verantwortliche prüft und gibt die Abgabe frei.

  • Kundenverträge und Lizenzvereinbarungen auslesen und ins CRM übertragen

    HubSpot, Salesforce, DMS, Microsoft 365

    1.400 Wartungsverträge aus zwanzig Jahren liegen als PDF in der Ablage, im CRM steht die Laufzeit, aber selten die Nutzerzahl, die Sonderkondition oder die abweichende Kündigungsfrist. Der Ablauf liest jeden Vertrag samt Nachträgen, zieht Laufzeit, Verlängerung, Kündigungsfrist, Nutzer- und Modulumfang, Preisgleitklausel und Sonderregelungen heraus und trägt sie als Vorschlag in das CRM ein. Widersprüche zwischen Vertrag und CRM sowie Klauseln, die der Ablauf nicht sicher einordnet, sind markiert. Der Vertrieb gibt je Kunde frei, jede Änderung bleibt rückholbar.

Systeme

Typische Systeme bei Softwareherstellern und SaaS-Anbietern

Entwicklung, Support und Vertrieb haben je ein eigenes System, das Wissen ist über alle drei verteilt. Die Abläufe lesen quer.

Systemvernetzung im Detail

  • SupportZendesk, Freshdesk, Zammad, Intercom, Jira Service Management
  • EntwicklungJira, GitHub, GitLab, Azure DevOps
  • Dokumentation und WissenConfluence, Hilfeportale, Handbücher, Notion
  • Vertrieb und VerträgeHubSpot, Salesforce, Pipedrive, Vertragsablage
  • Betrieb und AbrechnungLizenzserver, Abrechnungssysteme, DATEV, Microsoft 365

Einwände

Was bei Softwareherstellern und SaaS-Anbietern besonders zählt

Die Einwände, die bei Softwareherstellern zuerst fallen, und unsere Antwort darauf.

  • Support-Tickets enthalten Kundendaten, wir sind Auftragsverarbeiter. Die Verträge mit Ihren Kunden gelten für jedes Werkzeug, das Tickets liest. Darum laufen die Modelle für Support und Backlog im Haus oder auf EU-Servern unter Auftragsverarbeitungsvertrag, personenbezogene Angaben werden vor der Verarbeitung erkannt und maskiert, und der Datenfluss je Ablauf ist so dokumentiert, dass Sie ihn in Ihre Verzeichnisse und Kundenverträge übernehmen können.
  • Quellcode und Roadmap sind Geschäftsgeheimnisse. Der Ablauf für Release Notes liest Commit-Nachrichten, Merge-Request-Beschreibungen und Jira-Vorgänge, nicht den Code selbst, und läuft in Ihrer Umgebung. Ob ein Modell überhaupt Codezugriff bekommt, entscheiden Sie je Ablauf; für die hier beschriebenen Abläufe ist er nicht nötig.
  • Wird KI Teil des Produkts, gelten Anbieterpflichten nach dem EU AI Act. Die Abläufe hier sind interne Werkzeuge für Support, Dokumentation und Vertrieb, kein Bestandteil Ihres Produkts. Wenn Sie aus einem internen Ablauf später eine Produktfunktion machen wollen, sagen wir das vorher und benennen, welche Pflichten dann hinzukommen, statt es stillschweigend zu bauen.
  • Open-Source-Lizenzen regeln die Weiterverwendung von Code. Kein Ablauf von uns erzeugt oder verändert Produktcode. Was entsteht, sind Texte, Backlog-Einträge und Datenfelder. Die Lizenzlage Ihrer Abhängigkeiten bleibt davon unberührt, und die Werkzeuge, die wir selbst einsetzen, legen wir mit ihren Lizenzen offen.
  • Der Betriebsrat fragt, ob Entwicklerleistung gemessen wird. Die Abläufe werten Tickets, Vorgänge und Commits nach Inhalt aus, nicht nach Person, und erzeugen keine Auswertung je Mitarbeiter. Welche Daten gelesen werden und welche Berichte entstehen, legen wir vor dem Umbau offen, damit die Mitbestimmung nach § 87 BetrVG geklärt ist, bevor etwas läuft.

Nachweis

Was wir aus vergleichbaren Abläufen mitbringen

Das Muster, Wissen aus vorhandener Dokumentation für Antworten mit Quellenangabe zu nutzen, haben wir für einen europäischen Technologie-Distributor mit rund 2.000 Mitarbeitern und zwölf Standorten gebaut: eine Wissensdatenbank aus der Produktdokumentation, die in fünf Sprachen mit Quellenangabe antwortet und an Menschen übergibt, wo sie nicht sicher ist, dazu die automatische Zuordnung von Anfragen aus einem Sammelpostfach nach Markt und Land. Ihre Hilfeartikel und gelösten Tickets sind dieselbe Art Quelle, nur mit mehr Versionen.

Was dort schiefging: Die Wissensdatenbank antwortete anfangs zu ausführlich, und die Zuordnungsregeln für Grenzfälle mussten zweimal nachgezogen werden. Für Ihren Support heißt das: Antwortentwürfe werden auf die Länge begrenzt, die ein Supportmitarbeiter selbst schreiben würde, und die Einstufung nach Produkt und Modul startet im Parallelbetrieb mit gemessener Trefferquote, bevor sie den Stapel vorsortiert.

Fallstudie: Anfragen in fünf Sprachen

Preise

Preise für Softwarehersteller und SaaS-Anbieter

Analyse, Umbau und Begleitung haben feste Preise, die öffentlich auf unserer Seite stehen, und nach jeder Stufe entscheiden Sie neu. Was ein Ablauf wie "Support-Tickets klassifizieren und mit bekannter Lösung vorlegen" bei Ihnen kostet, steht nach der Analyse als Festpreis fest: Vorgehen und Preise. Wo sich KI nicht lohnt, steht das ebenso in der Analyse.

Rückfragen

Fragen von Softwareherstellern und SaaS-Anbietern

Was im ersten Gespräch zuerst gefragt wird. Weitere Antworten stehen unter Fragen und Antworten.

Dürfen Tickets mit Kundendaten und Screenshots durch eine KI laufen?

Unter Ihren Bedingungen ja. Für Support und Backlog bauen wir mit Modellen im Haus oder auf EU-Servern unter Auftragsverarbeitungsvertrag, Namen, Mailadressen und Zugangsdaten werden vor der Verarbeitung maskiert, Screenshots nur gelesen, wenn der Ablauf das braucht, und keine Ihrer oder Ihrer Kunden Daten trainiert ein fremdes Modell. Die drei Betriebsarten stehen unter Datensouveränität.

Wir sind selbst Entwickler, warum sollten wir das nicht selbst bauen?

Viele Häuser können das, und wir sagen in der Analyse, wo das der bessere Weg ist. Der Unterschied liegt selten im Bauen, sondern im Betrieb: Regeln pflegen, Trefferquote messen, Modellwechsel verkraften, Protokolle führen, während Ihre Entwickler am Produkt arbeiten sollen. Wir bauen so, dass Ihr Team alles übernehmen kann, und bleiben so lange im Betrieb, wie es sich rechnet, monatlich kündbar.

Ersetzt das die KI-Funktionen in Zendesk oder Jira?

Nein, es ergänzt sie. Die eingebauten Funktionen arbeiten innerhalb eines Systems mit dessen Daten. Der Nutzen entsteht bei Ihnen quer über Systeme: ein Ticket in Zendesk mit einem Vorgang in Jira und einem Absatz in Confluence verbinden, Release Notes aus GitLab und Jira entwerfen. Wo eine eingebaute Funktion reicht, sagen wir das in der Analyse.

Wie viel Zeit kostet das Support und Produktmanagement?

Die Analyse dauert drei Tage mit den Menschen, die die Arbeit machen: meist der Support-Leiter, ein Produktmanager und jemand aus der Dokumentation. Der Umbau braucht einen Ansprechpartner für Regeln und Freigaben und Zugänge zu den Systemen, keine Projektgruppe. Die Einführung läuft im Parallelbetrieb: zwei Wochen prüft der Support jeden Vorschlag, danach nur noch die als neu markierten Tickets.

Übergabe

Der erste Schritt ist ein Gespräch von 30 Minuten.

Sie erzählen uns von dem Ablauf, der Sie am meisten Zeit kostet. Wir sagen Ihnen ehrlich, ob sich KI dort lohnt und was der nächste Schritt wäre. Ob danach eine Ablaufanalyse folgt, entscheiden Sie.

Gespräch buchenVorgehen und Preise