Virtueller Service-Agent oder Rovo-Agent? Der Unterschied entscheidet über Ihren Service Desk

Virtueller Service-Agent und Rovo-Agent lösen im Jira-Service-Portal scheinbar dasselbe Problem, sind aber grundverschieden gebaut: Der eine ist ein Formular, das spricht, der andere ein Kollege, dem Sie eine Einweisung geben. Für die meisten Projekte ist der Rovo-Agent der bessere Einstieg – schneller gebaut, günstiger lizenziert, stärker bei unerwarteten Fragen. Der virtuelle Service-Agent bleibt richtig für streng strukturierte Strecken, für Slack, Teams und E-Mail, und überall dort, wo Sie Menschen ohne Atlassian-Konto erreichen müssen.

Wer heute im Jira Service Management einen AI-Agenten einrichten will, steht vor einer Verzweigung, die niemand richtig erklärt. Auf der einen Seite steht der virtuelle Service-Agent, den Atlassian seit Jahren als Selbsthilfe-Werkzeug im Portal führt. Auf der anderen Seite steht der Rovo-Agent, deutlich jünger, aus einem anderen Baukasten und mit einer anderen Idee davon, wie ein Gespräch funktioniert.

Beide beantworten Fragen im Kundenportal. Beide greifen auf Ihre Wissensbasis zu. Und trotzdem führen sie zu völlig unterschiedlichen Projekten, unterschiedlichen Kosten und unterschiedlichen Ergebnissen. Es gibt bei Atlassian keine Seite, die beide gegenüberstellt. Dieser Beitrag holt das nach, erklärt, warum wir in den meisten Projekten mit Rovo beginnen, und zeigt, was beide Wege gemeinsam brauchen.

Zwei Wege, ein Fundament

Der Unterschied liegt nicht darin, was die beiden können, sondern darin, wie sie gebaut werden.

Der virtuelle Service-Agent wird aus Absichten und Gesprächsverläufen zusammengesetzt. Sie legen fest, welche Anliegen er erkennen soll, trainieren ihn mit Beispielformulierungen und zeichnen anschließend den Dialog: Frage, Auswahlmöglichkeiten, Verzweigung, Datenfeld, Eskalation. Das Ergebnis ist ein Entscheidungsbaum, der genau das kann, was Sie hineingezeichnet haben.

Der Rovo-Agent wird beschrieben statt gezeichnet. Sie geben ihm eine Anweisung in Prosa, sagen ihm, welches Wissen er benutzen darf, und geben ihm Fähigkeiten mit, etwa das Anlegen einer Anfrage. Was er in einem konkreten Gespräch tut, entscheidet er selbst.

Der eine ist damit ein Formular, das sprechen kann. Der andere ist ein Kollege, dem Sie eine Einweisung geben. Und beide sind nur so gut wie die Wissensbasis dahinter, aber dazu später mehr.

Der virtuelle Service-Agent: stark, wo der Weg feststeht

Seine Stärke ist Verlässlichkeit, sein Preis ist Aufwand.

Wenn eine Anfrage immer gleich abläuft, ist ein gezeichneter Dialog unschlagbar. Die Urlaubsbescheinigung, die Bestellung eines Zweitmonitors, die Meldung eines defekten Geräts: Überall dort, wo Sie genau wissen, welche Angaben Sie brauchen und in welcher Reihenfolge Sie fragen müssen, liefert der virtuelle Service-Agent ein vorhersagbares Ergebnis. Er kann dabei bis zu fünfzig Schritte je Verlauf abbilden, Antworten in Feldern speichern und über einen Web-Aufruf im Hintergrund ein anderes System ansprechen.

Der Preis dafür sind drei Dinge. Erstens die Lizenz: Er ist ausschließlich in Premium und Enterprise der Service Collection enthalten und rechnet über ein eigenes Kontingent von 1.000 unterstützten Konversationen je Monat ab, darüber ab 0,30 US-Dollar je Konversation. Zweitens die Pflege: Jede Absicht will beschrieben, mit Beispielsätzen trainiert und gegen Überschneidungen mit anderen Absichten geprüft werden. Drittens, und das ist der wunde Punkt: Was Sie nicht gezeichnet haben, fällt durch. Der Agent versucht immer zuerst, eine Absicht zu treffen. Passt keine, landet die Frage in der Rückfallebene.

Der Rovo-Agent: stark, wo die Frage offen ist

Er beantwortet auch das, was Sie nicht vorhergesehen haben, und er ist deutlich schneller einsatzbereit.

Ein Rovo-Agent entsteht in Rovo Studio aus drei Bestandteilen: einer Anweisung, einer Auswahl an Wissensquellen und bis zu fünf Fähigkeiten. Für einen ersten brauchbaren Agenten reicht eine gute halbe Stunde, und Sie brauchen dafür keine Premium-Lizenz. Die Erstellungsseite nennt als Voraussetzung einen Standard-, Premium- oder Enterprise-Plan, und die Nutzung läuft über Rovo-Credits, von denen jede Edition ein monatliches Kontingent je Nutzerin und Nutzer mitbringt.

Praktisch macht das drei Unterschiede, die im Betrieb schwer wiegen.

Er kennt keine Lücken bei den Sonderfällen. Die immer gleichen zwanzig Anfragen sind das eine. Das andere sind die hunderten Varianten, die niemand modelliert. Genau dort spielt ein wissensgestützter Agent seine Stärke aus, weil er formuliert statt auswählt.

Er wechselt die Sprache, ohne dass Sie etwas tun. Ein Entscheidungsbaum ist in der Sprache gefangen, in der Sie ihn geschrieben haben. Ein Agent, der aus Ihren Artikeln antwortet, kann die Frage auf Polnisch entgegennehmen und aus einem deutschen Artikel antworten.

Er kann inzwischen mehr als antworten. Die Fähigkeit zum Anlegen einer Anfrage leitet über bis zu fünfzig Servicebereiche hinweg an den richtigen Anfragetyp weiter und füllt dabei Pflichtfelder vor. Das entschärft genau den Einwand, den erfahrene Serviceteams als Erstes bringen, nämlich dass automatisch erzeugte Tickets unvollständig ankommen und die Nachfrage teurer wird als die eingesparte Bearbeitung.

Dazu kommt ein Punkt, der in Ausschreibungen selten auftaucht und in der Praxis viel wert ist: In Rovo Studio lassen sich Agenten auswerten, bevor sie live gehen. Sie hinterlegen eine Menge echter Beispielfragen und lassen prüfen, ob die Antworten treffen. Für eine Organisation, die zu Recht Sorge vor erfundenen Antworten im Kundenkontakt hat, ist das das einzige Argument, das ohne Vertrauensvorschuss funktioniert.

Der direkte Vergleich

Warum wir in den meisten Projekten mit Rovo beginnen

Weil der Aufwand in einem anderen Verhältnis zum Ergebnis steht.

Ein virtueller Service-Agent verlangt, dass Sie Ihre Anliegen vorher kennen und modellieren. Diese Arbeit ist nicht verschwendet, aber sie kommt zu früh. Am Anfang eines Projekts weiß niemand genau, welche zwanzig Anfragen wirklich das Volumen treiben und wie Menschen sie formulieren. Ein wissensgestützter Agent liefert diese Information nebenbei, weil Sie hinterher nachlesen können, welche Fragen gestellt wurden und wo die Antwort nicht getragen hat.

Unsere Erfahrung aus dem Aufbau vollständiger Demo-Umgebungen ist eindeutig: Für wissensgetriebene Selbsthilfe schlägt der Rovo-Agent den virtuellen Service-Agenten deutlich, bei ungleich geringerem Aufwand. Der virtuelle Service-Agent rechtfertigt seine Klickarbeit dort, wo eine Strecke wirklich streng deterministisch sein muss.

Daraus folgt eine Reihenfolge, die sich bewährt hat. Beginnen Sie mit einem Rovo-Agenten auf einer sauber angebundenen Wissensbasis. Lesen Sie nach einigen Wochen mit, wo er trägt und wo nicht. Und bauen Sie erst dann gezeichnete Dialoge, wo Sie sie nachweislich brauchen, nämlich bei den wenigen Strecken mit strenger Datenerfassung. Sie kaufen sich damit die Modellierungsarbeit nicht weg, aber Sie machen sie zum richtigen Zeitpunkt und auf Basis von Zahlen.

Zwei Fälle sprechen weiterhin klar für den virtuellen Service-Agenten. Der eine ist der Kanal: Wenn Sie Ihre Leute in Slack, in Microsoft Teams oder per E-Mail abholen wollen, führt an ihm kein Weg vorbei. Der andere ist die Reichweite, und der ist der wichtigere.

Die Reichweiten-Frage, die viele Projekte kippt

Ein Rovo-Agent im Portal erreicht nicht jede Person, die Ihr Portal benutzt.

Die Grenze verläuft nicht zwischen lizenziert und unlizenziert, wie oft angenommen wird, sondern zwischen Menschen mit und ohne Atlassian-Konto:

Für die dritte Zeile verweist Atlassian auf ein eigenes Produkt, Customer Service Management, das anonymen Zugriff vorsieht und Teil der Service Collection ist. Für interne Serviceorganisationen, also den häufigsten Fall, ist die Frage meist unkritisch, weil Mitarbeitende ohnehin ein Konto haben. Für ein Portal, über das externe Kundschaft Anfragen stellt, entscheidet sie über die Produktwahl. Klären Sie sie früh, nicht nach dem Aufbau.

Wenn Antworten nicht mehr reichen: Rovo Service

Die dritte Stufe beantwortet nicht mehr, sondern bearbeitet.

Rovo Service ist kein Kanal im Portal, sondern arbeitet am Vorgang selbst. Aus Ihrer internen Wissensbasis erzeugt er einen Lösungsplan und arbeitet ihn ab, entweder unter Aufsicht oder selbständig, und das ist je Anfragetyp einstellbar. Er hält von sich aus an, wenn ein Schritt unumkehrbar wäre, etwa beim Löschen von Dateien oder beim Versand externer E-Mails, oder wenn ihm ein Werkzeug fehlt.

Damit schließt sich die Reihe: Der Rovo-Agent im Portal macht Anfragen überflüssig oder wenigstens gut. Rovo Service erledigt sie. Atlassian empfiehlt ausdrücklich, mit dem beaufsichtigten Modus zu beginnen. Zwei Einschränkungen gehören dazu: Rovo Service ist nicht HIPAA-konform, und der selbständige Modus ist ausdrücklich nicht für Entscheidungen gedacht, die rechtliche oder ähnlich erhebliche Wirkung auf Personen haben.

Was beide Wege brauchen: eine Wissensbasis, die AI lesen kann

Egal für welchen Weg Sie sich entscheiden, die Antwortqualität entsteht in Confluence, nicht im Agenten.

Atlassian sagt es in der eigenen Dokumentation ungewöhnlich direkt: Der häufigste Grund für falsche AI-Antworten ist, dass die Quellinformation falsch ist. Die Regeln dagegen sind kurz und überprüfbar.

• Aktualität geht vor Vollständigkeit. Vages, Widersprüchliches und Veraltetes gehört weg.
• Ein Artikel je Thema, keine Duplikate. Wer einen Artikel pflegt und die Kopien vergisst, riskiert, dass die AI aus der alten Fassung antwortet.
• Schreiben Sie in der Sprache Ihrer Leute. Gesucht wird nicht nach „Request new hardware“, sondern nach „ich brauche einen neuen Laptop“.
• Nutzen Sie Überschriften. Die AI liest Überschriften und Fließtext und gewichtet beides gleich.
• Länge ist kein Kriterium. Laut Dokumentation darf viel Information in einem Artikel stehen, solange er klar gegliedert ist. Eine empfohlene Wortzahl gibt es nicht.

Dazu die einzige technische Einschränkung, die Atlassian ausdrücklich nennt und die regelmäßig übersehen wird: Panels innerhalb von Tabellen werden nicht gelesen. Tabellen ja, aufklappbare und hervorgehobene Panels ja, aber nicht, wenn sie in einer Tabellenzelle stecken. Wer seine Wissensbasis mit Hinweisboxen in Tabellen gestaltet hat, hat diese Inhalte für die AI unsichtbar gemacht.

Drei weitere Punkte stehen in keiner Anleitung, haben uns aber beim Bau echter Umgebungen Zeit gekostet.

Verknüpfen Sie den Space, nicht den Ordner. Die Dokumentation erlaubt es, nur einen Confluence-Ordner als Wissensquelle anzubinden. In unserem Aufbau zählten danach alle Konfigurationsoberflächen die Artikel korrekt, während im Portal kein einziger Artikel ankam: keine Vorschläge im Formular, keine Treffer über die Schnittstelle, beim Aufruf die Meldung, der Artikel sei nicht auffindbar. Mit dem Space als Quelle griff alles sofort. Interne Runbooks gehören deshalb in einen eigenen Space, der als interne Quelle angebunden wird.

Halten Sie Anweisungen für Agenten aus Kundenartikeln heraus. Ein maschinenlesbarer Block am Artikelende mit Auslösewörtern klingt nach guter Idee. Im Portal zog er die Artikelvorschau an sich, weil die Vorschau die Stelle mit dem Suchbegriff ausschneidet und die Auslösewörter genau die Wörter sind, die Ihre Leute tippen. Der Kunde sah dann Codezeilen statt Prosa, ausgerechnet im Moment der Selbsthilfe.

Pflegen Sie die Beschreibung Ihrer Anfragetypen. Die Portalsuche durchsucht die Beschreibung, nicht nur den Namen. Bei uns fand „my WiFi is broken“ den Eintrag nicht, „my WiFi is not working“ schon. Das kostet nichts und ist meist der schnellste sichtbare Erfolg im Projekt.

Wie Sie messen, ob es funktioniert

Der Rückkanal aus den Konversationsdaten ist das wertvollste und am wenigsten genutzte Werkzeug.

Jede Konversation trägt eine Aktion, also ob eine Absicht getroffen wurde, ob die AI aus der Wissensbasis geantwortet hat oder ob gar nichts passte, dazu ein Ergebnis und die Zufriedenheit. Filtern Sie auf die Gespräche, in denen aus der Wissensbasis geantwortet wurde, und prüfen Sie, ob diese Fälle überdurchschnittlich oft eskalieren. Wenn ja, liegt es an Ihren Artikeln. Öffnen Sie die Gespräche, sehen Sie sich die Quellartikel an, ergänzen Sie das Fehlende.

Ergänzend meldet Ihnen Jira Service Management fehlende Themen, sobald mehr als fünf verwandte Anfragen aufgelaufen sind, und erzeugt auf Wunsch daraus Artikelentwürfe.

Eine Zahl noch, weil sie überall zitiert wird: Die bekannten 30 Prozent vermiedener Tickets stammen aus einer von Atlassian beauftragten Forrester-Studie von Dezember 2024. Diese Studie misst Jira Service Management insgesamt, nicht den virtuellen Service-Agenten isoliert. Nehmen Sie deshalb keine fremde Prozentzahl als Zielwert. Ihr Potenzial hängt an Ihrem Ticketaufkommen und Ihrer Wissensbasis, und beides kennen nur Sie.

Grenzen, die Sie vor dem Start klären sollten

Drei Punkte entscheiden über Governance, und alle drei lassen sich vorab beantworten.

Die Datenverarbeitung folgt nicht Ihrer Datenregion. In Atlassians eigener Übersicht zur Datenresidenz stehen AI-Daten in der Spalte der Inhalte, die sich nicht an eine Region binden lassen, und unter Jira Service Management ist der virtuelle Service-Agent dort eigens aufgeführt. Wer Datenresidenz im Europäischen Wirtschaftsraum gebucht hat, hat sie an dieser Stelle nicht.

Seit dem 17. August 2026 gilt eine neue Regelung zur Nutzung von Kundendaten für die Verbesserung von Atlassians eigenen Modellen. Die Abstufung ist ungleich: In Free und Standard lässt sich die Sammlung von Metadaten nicht abschalten, in Premium nur der Anteil der Inhaltsdaten, volle Kontrolle über beides hat nur Enterprise. Welche Einstellungen Sie davor prüfen sollten, haben wir in Rovo und die neue Atlassian-Datenpraxis zusammengefasst.

Rovo lässt sich nicht je Nutzergruppe freischalten. Steuerbar ist die Ebene des Produkts oder der Site, ein Teilpilot mit einer kleinen Gruppe ist auf den meisten Plänen nicht vorgesehen. Wer das für eine Abstimmung mit dem Betriebsrat braucht, sollte das früh prüfen.

Fazit

Die Frage lautet nicht, ob Sie einen AI-Agenten im Service Desk einsetzen, sondern welchen und in welcher Reihenfolge. Für die meisten internen Serviceorganisationen ist der Rovo-Agent der bessere Einstieg: schneller gebaut, günstiger lizenziert, stark bei allem, was Sie nicht vorhergesehen haben, und vor der Freigabe überprüfbar. Der virtuelle Service-Agent bleibt die richtige Wahl für streng strukturierte Strecken, für Slack, Teams und E-Mail und überall dort, wo Sie Menschen ohne Atlassian-Konto erreichen müssen. Und wenn Antworten nicht mehr reichen, steht mit Rovo Service die nächste Stufe bereit.

Was in allen drei Fällen gleich bleibt: Die Qualität entsteht in Ihrer Wissensbasis. Ein Agent macht sichtbar, wie gut Ihre Dokumentation ist. Deshalb beginnt ein gutes Projekt mit einer Messung und nicht mit einem Versprechen.

Häufige Fragen

Wie geht es weiter?

Am direktesten treffen Sie das Thema dieses Artikels mit unserer Lösung Agentischer IT-Support mit Atlassian: Auftragsannahme, Auftragsverarbeitung und Wissensabgleich mit AI-Agenten, erprobt im echten Betrieb, nicht nur behauptet. Genau die Kombination aus virtuellem Service-Agent und Rovo-Agent, um die es in diesem Beitrag geht.

Je nachdem, wo Sie gerade stehen, passt aber auch einer dieser Wege besser:

• Sie wollen das große Bild verstehen? Lesen Sie, was Atlassian Rovo eigentlich ist, wie der Teamwork Graph funktioniert und wie Sie Rovo im Alltag richtig nutzen.
• Sie wollen praktisch anfangen? Unsere ersten Schritte mit AI im Atlassian-Alltag zeigen, wie Sie Ihre Ausgangslage einschätzen.
• Sie überlegen, ob statt eines Rovo-Agenten eine eigene Forge-App der bessere Weg wäre? Rovo-Agent oder eigene Forge-App? hilft bei der Einordnung.
• Sie haben Rovo lizenziert, aber niemand nutzt es? Das ist der häufigste Zustand, den wir antreffen. In unserem Rovo-Enablement-Workshop bauen wir gemeinsam in Ihrer eigenen Umgebung die ersten Agenten, die danach bei Ihnen bleiben.