De Service Collection brengt jaarlijks inmiddels meer dan 1 miljard dollar aan omzet in het laatje voor Atlassian. Het breidt daarnaast ook in rap tempo uit in de breedte, voorbij ITSM. Tijdens Atlassian Team ’26 Europe in Amsterdam spraken we met Shamik Sharma, hoofd productontwikkeling voor de Service Collection. Hoe is Atlassian van plan om concurrenten als ServiceNow op hun eigen terrein te verslaan?
De Service Collection is Atlassians gebundelde aanbod van vier producten: Jira Service Management (JSM), Customer Support Management (CSM), Assets en Rovo Agents. Hoewel elk product een specifieke use case bedient, worden ze samen verkocht als één collectie voor één prijs. Bovendien is er een flexibele toewijzing van licenties over alle vier de producten heen.
De meeste klanten hebben de Teamwork Collection (met Jira, Confluence, Rovo Agents en Loom) al als basis, zegt Sharma. De overstap naar JSM beschrijft Sharma dan ook als een natuurlijke en gemakkelijke stap. Dit komt doordat JSM zeer vertrouwd is voor iedereen die al met Jira werkt.
Tweestrijd met ServiceNow
Atlassian maakte eerder dit jaar bekend dat de Service Collection een omzet van meer dan 1 miljard dollar genereert voor het bedrijf. Het is een van de snelst groeiende segmenten van het bedrijf. Sharma merkt op dat Forrester de ITSM-markt heeft omschreven als een tweestrijd tussen ServiceNow en Atlassian. Bovendien staat Atlassian in het bovenste kwadrant van de ranglijsten van Gartner, Forrester en andere grote analisten voor aanbieders van servicemanagement.
De groei wordt aangejaagd door zowel de diepgang als de breedte van het portfolio. In de afgelopen twee jaar heeft Atlassian het portfolio binnen Service Collection uitgebreid van puur ITSM naar andere bedrijfsfuncties, zoals HR. Meer recentelijk heeft het bedrijf een uitbreiding gedaan richting support management voor teams die met externe klanten werken.
Een moderne aanpak
Sharma schrijft de groei van het marktaandeel van Atlassian toe aan een fundamenteel andere architectuur. In tegenstelling tot traditionele ITSM-leveranciers heeft Atlassian zijn serviceproducten gebouwd op een platform dat is gebouwd met de developer in het achterhoofd. Het is bovendien uitbreidbaar en modulair. De gebruikerservaring moet modern en gebruiksvriendelijk aanvoelen. Dankzij de open marktplaats kunnen partners en klanten het platform uitbreiden voor specifieke sectoren.
Deze ‘platform-first’-aanpak werpt nu zijn vruchten af in het AI-tijdperk, zegt Sharma. Omdat de systemen van Atlassian API’s en MCP-eindpunten beschikbaar stellen, is het aanzienlijk eenvoudiger om Rovo-agents bovenop het platform te bouwen. Bovendien is het volgens hem bij Atlassian eenvoudiger om Rovo-agents vanaf externe AI-platforms in te schakelen dan bij welke van de traditionele tools dan ook.
Nummer 1 MCP
Sharma laat in het gesprek met ons ook terloops vallen dat de Atlassian MCP-server door Anthropic is aangewezen als de nummer één MCP-server ter wereld wat betreft het aantal calls. Dat wil zeggen: er worden meer externe agents naar de MCP-server van Atlassian gestuurd dan naar welke andere dan ook.
Bovenstaande is overigens een logisch gevolg van de strategie van Atlassian om het ‘headless’ gebruik van zijn producten actief te ondersteunen. Klanten kunnen de Atlassian-gebruikersinterface gebruiken, maar ze kunnen ook Rovo-agents binnen het platform bouwen, of de API’s en MCP-lagen van Atlassian aanroepen vanuit een extern agentplatform.
Volgens Sharma maakt het Atlassian niets uit welk van de drie benaderingen gebruikers kiezen. Het maakt niet uit welke interface gebruikers gebruiken, zolang het resultaat maar terugvloeit naar de Teamwork Graph. Zoals altijd is dat de basis waarop Atlassian als geheel is gebouwd en waar het omheen is gebouwd.
Uitgebreid asset management
De Assets-component in de Service Collection maakt gebruik van een asset store die buiten de eigenlijk Service Collection staat. Binnen de Service Collection worden de workflowtoepassingen geleverd die daarop zijn gebouwd: het beheer van de hardware-assets, beheer van software-assets en de mogelijkheid om assets te zoeken en vinden.
Atlassian hanteert een behoorlijk brede definitie van een asset. Volgens Sharma is alles met tastbare waarde dat op de balans van een bedrijf staat, van laptops en projectoren tot ziekenhuisscanners, injectiemateriaal en havenkranen een asset. Voor standaard IT-assets biedt Atlassian kant-en-klare tooling. Om grote organisaties te helpen die al een speciale tool hebben, zoals Flexera of Lansweeper, werkt Atlassian samen met die leveranciers om gegevens rechtstreeks in Assets op te nemen.
Voor zeer gespecialiseerde sectoren maakt Atlassian gebruik van partners en system integrators om sectorspecifieke workflows te bouwen. Deze worden uiteindelijk allemaal ingevoerd in dezelfde asset store, die is gekoppeld aan de Teamwork Graph.
AI-native CSM
Customer Support Management (CSM) is vanaf de basis gebouwd als een AI-native product. Het uitgangspunt is dat vrijwel elk binnenkomend ticket door AI moet kunnen worden opgelost. Mensen fungeren als supervisors, trainers en beoordelaars. Wanneer een AI-agent een ticket niet kan oplossen, kijkt het systeem mee bij wat de mens doet. Vervolgens gebruikt het die informatie om zichzelf te trainen voor toekomstige, vergelijkbare gevallen.
Sharma schat dat Atlassian momenteel bij het eigen interne gebruik van het product een AI-oplossingspercentage van 30–40% ziet. Wanneer we wat verder doorvragen, plaatst hij dat cijfer wat meer in de juiste context. Ongeveer 10–15% van de tickets betreft eenvoudige opzoekacties die nooit echt verzoeken tot support waren. Nog eens 10% bevindt zich op de grens van automation. Die gecombineerde 25% werd al vóór het AI-tijdperk opgelost via eenvoudige automatiseringen en opzoeksystemen.
Het cijfer van 30% van Atlassian, zo vervolgt Sharma, wordt gemeten bovenop die basis van 25 %. Hij geeft aan dat hij vermoedt dat concurrenten die oplospercentages van 60–80% claimen doorgaans hoogstwaarschijnlijk met kleinere klanten en eenvoudigere use cases werken en ruimere definities hanteren van wat als ‘opgelost’ geldt.
Twee onopgeloste problemen in AI-gedreven servicemanagement
Niet alles is echter opgelost door Atlassian Service Collection. Sharma noemt twee grote onopgeloste uitdagingen in AI-gedreven servicemanagement. De eerste is het ‘cold start’-probleem: AI is slechts zo goed als de context waartoe het toegang heeft. In tegenstelling tot programmeren, waar enorme hoeveelheden openbare code op GitHub en Bitbucket rijk trainingsmateriaal bieden, is documentatie voor support aan klanten en IT binnen bedrijfsomgevingen vaak schaars, als het er al is. Atlassian werkt hieraan door menselijke medewerkers te observeren. Daarnaast doet het proactief suggesties voor wat er in kennisbanken zou moeten staan.
De tweede uitdaging is vertrouwen. Technisch gezien is het eenvoudig om hoge oplossingspercentages te behalen door een AI-medewerker onbeperkte autonomie te geven. Er zullen echter ook meer hallucinaties optreden, en de algehele klanttevredenheid zal achteruitgaan. Gebruikers krijgen mogelijk antwoorden die tickets technisch gezien weliswaar afsluiten, maar waarmee ze niet tevreden zijn.
AMP moet vertrouwen mogelijk maken
Het AMP multi-agent-framework is Atlassians structurele antwoord op het bovengenoemde vertrouwensprobleem. AMP maakt samenwerking tussen meerdere agents mogelijk. De ene kan het werk uitvoeren, terwijl een andere het werk controleert. Weer een andere kan de betrouwbaarheid verifiëren (wat dat ook moge betekenen). Pas daarna kan er actie worden ondernomen op basis van de output. Dit lijkt op de ‘maker-checker’-processen die in menselijke workflows worden gebruikt, waarbij een tweede paar ogen het werk controleert voordat het wordt afgerond.
Sharma beschouwt AMP als een cruciaal onderdeel van de infrastructuur om AI-aangedreven servicemanagement op het juiste niveau haalbaar te maken.
Bekijk/luister/lees ook: ROI van AI voor developers is er (nog) niet: wat te doen?