Atlassian Corporation (TEAM) Earnings Call Transcript & Summary

Investor Forum. It's really great to see everyone, especially those that flew all the way here from -- to Anaheim as well as those that are joining us online via webcast. So the plan for today is to showcase Rovo innovation with a short demo with Mike, and then we'll jump into Q&A with Mike, Anu and Brian. For Q&A, we will take questions live from the audience as well as via the webcast for those that are joining virtually. And as a reminder, we're in quiet period. And so we won't be discussing or taking any questions about current business trends or the quarter results. And lastly, this event is being recorded, and a replay will be available on the IR website. So now before we started, I do need to mention our typical legal disclaimers. This session may include forward-looking statements and may include a discussion of Non-GAAP financial measures. Information about risks involving forward-looking statements and limitations regarding the use of non-GAAP measures is discussed on this slide. Please take a moment to review this information. All right. So please join me in welcoming Mike to the stage for a Rovo demonstration.

Hi, everyone. I would have given you a great summary of that legal disclaimer, but I think you can probably all repeat it off the top of your heads by now. So Martin doesn't often ask me to do demos for investors. So I was like, sure, why not? Let's have some fun. I wanted to recap. I know there's a lot of people watching online who maybe you didn't get to attend a keynote or anything. So we've got a few small repeats. I can talk to them in a slightly different way probably and a couple of new ones in here, probably trigger some conversations. I figured there'd be at least 1 or 2 questions on AI. So Martin's probably in a very smart place as to what we should demo. Quick recap on our portfolio slide because it's quite interesting to look at it this way. Rovo is at the center. We're really placing it at the heart, the jewel in the crown, if you might say, the heart of the Atlassian platform. It's both visually there and strategically, that's really important to us. And you saw that it's a part of the platform. So new products, the strategy collection over there on the right, focus, talent, AI native from day 1 by being built on the platform, on the Teamwork Graph on Rovo. All of those features just appear from day 1 with new products. So that's part of the platform. A few demos of Rovo capabilities. So a quick demo of search. You may have seen this one earlier. Rovo Search available via the app, also by the browser extension on the mobile, et cetera. Importantly, we have more than 50 different connectors now. You can see those on the right-hand side here or a handful of them. All of the major SaaS products, all of the products that our customers have asked for over the last 12 months. We continue to make those and work with partners to make those, I would say. You can see that we get results from all of the different applications threaded together. We spent a lot of time on relevance, ranking and search quality. We have an amazing search team at the moment. That is very, very difficult. It's very, very hard. And it requires the Teamwork Graph. It requires the social signals from how work happens to get good results and ranking in the enterprise. And we feel really confident about where we are in terms of search. Search is important because search is at the core of everything. So the Teamwork Graph, search, chat, think of them as different interfaces to the same data set that we have underneath. That's a really valuable data set. In chat, obviously, we see 2 things in the Deep Research demo that I think are interesting. Firstly, it's showing the Teamwork Graph and all that information in a totally different way. Secondly, it's taking the best of AI models that are available. So in this case, planning and reasoning models, things that do multi-turn takes between 5 to 10 minutes to actually generate this report in actual clock time. But both of those are actually using what's inside. So here, the data from the Teamwork Graph, the Deep Research mode for chat instead of saying, I'm going to give you an answer back in, say, 15 seconds, it will take a much longer period of time and go off and do much more deep calculation. So here it's telling you we're doing our research planning. It's going to get information from Confluence, Slack and Google Drive, other places, and it will come back and write you a much bigger report. Again, sometimes you know you want more information, it will go and do it. All a different modality of the same Teamwork Graph and data that we have underneath. What's important for us is then to take that human and AI collaboration. So you'll hear that from us a lot. The idea that AI, you hit a button, magical things happen and we're done. I think it's kind of fanciful. It makes for a really nice demo. The reality is we're going to go off and do a lot of research. We're going to take all the historical information that an organization has. We're going to bring that back into a report, and we're going to take that report into Confluence, share that with colleagues and they're going to comment on it and say, this is really good. This paragraph is bull***, whatever they're going to say, that's great. That's exactly what we want, right? AI has done a bunch of the work, then humans are going to come in, and it's going to be an iterative process between the 2. Hence, why everything ends in one of our collaboration apps as well. Agents, out of the box, we have a whole series of different agents. We've showcased a bunch of new ones at Team '25. One of the ones that is perhaps more visual, a little bit different than some of the agents that we otherwise showed. Meeting Insights agent is a good example where it reads meeting transcripts, many recordings and gives you insights, but it's very textual. The diagram creator is a little bit different. It starts from a whiteboard, so it takes the information from various places in the Teamwork Graph. The whiteboard is full of different ideas. This one actually is plotting out an e-mail campaign. So you can think about it as drawing like a flow chart from the information you have, but it's not just drawing the flow chart, it's actually drawing it and taking different sorts of information to put it into the flow chart. So again, it's generating you a flow chart of an e-mail campaign and thinking through who the audience would be based on information you have in your Teamwork Graph. The point is it's generated a visual artifact here, but these are just whiteboard objects. So now people can come in, they can move them around, they can add new ones, delete them, et cetera. So again, we're trying to get to that human AI iterative improvement, where at the same time, the AI is helping you get started, helping you give you a lot of ideas and moving you forward all based on grounded in the data that your organization already has. Probably some questions on software, just guessing. So a little bit of a deeper look at the Rovo Dev Agents and how they work. So using the same Teamwork Graph, we'll use that in all of our demonstrations. We know that people plan their work in Jira. Again, the magical demo where you hit a button, just everything is finished, doesn't actually exist in the real world. So this is a very real-world example. We have a whole bunch of customers using this. Again, we use this hundreds and hundreds of times at Atlassian. We talk down at the booth, they'll tell you all the examples of things that we've built with this. The first thing this is going to do is actually link work items. So this is much more of a simple Teamwork Graph demo at the start. So it's finding out what work do we have that's linked to here. Similarly, what related documents do we have to hear. So if you're going to build a piece of software, the hardest thing is prompting the software agents nowadays to give you the right things. So we have, in this case, linked work items, linked documents and written a description of the issue from all of that. Again, there would likely be humans in this flow as well, but all of this is running code. Then you've got a much more full-fledged issue. The next thing you need to do with that issue is turn it into some sort of a plan. So it's not just going to go and write code for you. It's going to take that task, assign to a developer. Again, they probably make edits, they make changes, not exactly what I want you to do. I want to do more like this, more like that. Then it will go and make what's called a code plan. So this is telling the developer, here's what I think I'm going to go do. So here are the files I found. I found code repositories, I found related things. I'm going to go and modify these files up here. I'm going to modify some tests. Here, we're showing off that it can use different languages. This is go. And it will generate that and tell you what it's about to do. Again, this can be edited. You can say, no, this code plan is wrong. I want you to do this. All of these steps are there. Partly also, I would say, for customers, it's very scary to do 25 steps at once. So breaking it down into a series of sections we've learned over the last 12 months is really helpful for them because they might want to use a few of them. They're scared by some. They want to use some, they want to walk through it, babysitting on the way through, totally fine. And then obviously, it will then go and you can actually turn that into running code. Point here is that it generates some code. It will go off and write the code. Where do we review the code? We review the code in our pull request, which is over here. Well, I should say also, we didn't go into some detail. You can give it your engineering standards and your existing code base and obviously, all in the Teamwork Graph, no matter where you store your code. That is really important because it generates pull requests that are close to what your human developers would do in terms of your personal standards and your existing either strict standards or not. Importantly, though, what it will do is create a pull request here. We didn't see the pull request in this demo. Sorry. It will make a pull request in bit bucket and then other agents can come in and modify it as can human beings. So again, pushing the standard that we think that humans and AI are going to work together in lots of different ways, in different processes, maybe more AI, in different processes, more humans. We're trying to make sure all our parts can be compiled in those sequences. Finally, the last demo here, we've showed off in various places. This is actually an internal agent that we've built for ourselves. So you can think of this as a demo of what you can build with Studio. So this is a code-driven agent. So it's written with code and prompts. It is written inside. We have more and more customers running their own agents. They generally start with the no-code agents, prompt-driven. They'll combine them with automation and then they move into code-driven as they get more familiar with all of the technology. This one is called Customer 360, uses all the data in our Teamwork Graph and lots of different internal systems that we have. So there are lots of systems that we can't get to. In the Teamwork Graph and in Search, we have a bring your own data connector, so you can write your own connectors to put data into the system. In this case, we're showing off an agent that can use that data. So you can ask to get a brief overview of the customer. I did actually think if we could do this with some of your banks, but Martin said that wouldn't be a good idea. But apparently, we can show you directly your own data. So if anyone wants to demo later, maybe you can get it. In this case, we're using Vitafleet again. So this gives you an overview of Vitafleet. Now this has gone off to Salesforce, Databricks and our internal billing system to pull back the data. A good example of multiple systems coming back, giving you a single answer. Then it goes off and ask about CSAT. I want satisfaction. I want sales data, I want CSAT. Again, this goes to purely internal system to get CSAT. Interactions goes to service desk. I think some other place, which I've forgotten, I apologize for that. And then it goes and generates a Confluence page with all the things that I've just generated. Again, I have prompted it. I've gone back and forth. I've gotten the data I need, and now comes a Confluence page. I can share this with the team, et cetera. A great example because we used to have people generate these for me all the time. I got to sit down with a customer, a bunch of customer meetings every single week. I get a customer brief before I walk in with all this detail. And I want to ask a question, I've got a fixed document, I can't at this point. So I use this maybe not every day, let's call it, 3 to 4 days a week realistically, but almost every single day, do I use this agent to go look up a customer and do things, and I'm very familiar with our internal customer systems. So it's really handy, and I can just say, give me a brief and then I can share it with someone or vice versa, just saves time for people internally. So super brief demo of what we can do with the Teamwork Graph. I hope that was helpful, probably spur some questions. Let's go to Q&A. 10 minutes, close 10.5 minutes.

All right. So as I mentioned earlier, joining Mike is going to be President, Anu Bharadwaj; and our Chief Revenue Officer, Brian Duffy. And then just as again, as a reminder, we are in quiet period, so we won't be taking any questions about business trends or any financial performance since our last earnings call.

Second from the right. No, I think you're here.

So for live attendees, raise your hand. We have some mic runners around the room. And as well as you can scan this QR code and submit it via the platform. I can answer questions here. Also for those watching virtually, you can submit questions, and we can take your questions. All right. Let's start in the front. Keith?

Appreciate you guys doing this. I know it's sort of an awkward time for you, Martin. So I appreciate doing this. I wanted to ask one of the -- I thought larger, more interesting announcement was Rovo is now for free. And I just wanted to try to understand the puts and takes associated with that, making that decision. It was a pretty -- $20 to free is a pretty significant change. But maybe just walk through the logic of that. And I also thought -- I'll just ask the second question is I thought your diagram was really interesting where Rovo is now at the center of everything. And as I think about that, I was just hoping maybe you could elaborate a little bit on how that might pull some of the other things, particularly JSM and how you think that it may differentiate JSM from ServiceNow having Rovo on the front end of that. Sorry, Keith Bachman from Bank of Montreal.

Sure, Keith. I can take that. A few things on both sides, puts and takes is maybe a good way of explaining it. Firstly, what have we learned over the last 12 months? Rovo is super popular. You heard that if you're in the room today, right? People are really excited. It's super popular. It's got amazing customer reception, which is awesome. Secondly, it's ever more essential to our platform, actually. So when you think about it, you kind of can't have a piece of your platform that's off to the side. So we've been really trying to get it closer and closer to the core of the platform, and then we can build amazing features in all applications. The put and take there is, obviously, we think it's better for us to have it in the platform as a part of every application. The net gain from that is higher in terms of going wall-to-wall in companies and more seats of whatever it is that Rovo is inside rather than Rovo by itself. Thirdly, the pieces of Rovo also are really essential even when broken apart, right? Just the great search that we have makes a difference to every single customer. So you start to get into a system where you're like, you know what, we should put it in the middle and we should work hard to get there. The last part on the opposite side of the ledger is we know a lot more about running Rovo now at large scale. I think 12, 18 months ago, people are much more afraid of the costs of these types of things. And not only have the costs come down externally in various different forms, I would say. Some features are running like 3 orders of magnitude cheaper than we were 18 months ago. not only the costs come down, we're much better at running it at scale. We understand what our usage costs are likely to be. We're obviously very capital efficient and very careful with that sort of thing. So it's probably a combination of these factors. And we feel we're doing really well in this space, right? And we have an advantage. We have a very thoughtful graph. We have a very thoughtful platform. We have a very coherent story, and we have a product in the market out there usable by customers today with customs actually testing. And so we want to press that advantage. We think it can make a big deal with customers. And they've been -- I think it's only been a few hours, but they've been super excited. Obviously, we had the enterprise customers here on Monday and Tuesday, but they were really, really excited about its potential and possibility.

Anything specifically on JSM?

Yes. So for JSM and AI, we've had that an early access program for a while now. So we see more data, and it's performed really well, like we talked about in the keynote this morning. We've had several customers deploy our virtual agents in a service management scenario. And that's one of those places where there is a natural evolution to be able to use AI. So there, we see it in HR service management, customer service management, IT support, a lot of the traditional use cases, et cetera. I think that is a particularly interesting market for us because it really plays to our strengths. With the investment we have made in the Rovo and the platform, it really enables us to punch above our weight and be able to deliver for customers things that we would not have been able to deliver a couple of years ago. But now with the combination of Rovo plus JSM, we see customers use it in a lot more expansive and creative ways.

And this stuff I will say, just to zoom out of the JSM space in general, it's very expensive and hard, right? You're always asking, I think you've asked probably a number of times over the years, where does all the R&D go, right? This is not an uncommon question. This is a good example, right? There's no doubt we're investing very heavily in the search space, in the graph space, in all of the underlying platform components. So we want to distribute that across as many of our products as possible. There's sort of a logical distribution of the sort of CapEx spend, if you like, on the R&D there. But secondly, if you don't have a world-class R&D team, this is not as easy as just getting some model off the Internet and plugging it into data. It takes a lot of learning and a lot of iteration and a lot of continuous improvement that we feel we're doing better than a lot of other people out there at the actual R&D and the quality of the product. We hear that back from customers as well when they go and compare our results to other people, whether that's in virtual service agents or in just sheer search ranking or anything else. That's come from a lot of hard work and grit and an amazing engineering team.

A good follow-on question that's come in from Michael Turrin from Wells Fargo attached to kind of Keith's question is how do you factor in potential surge usage on Rovo? Are there usage-based components of pricing can mitigate the surge in costs?

Michael, yes, there are. So we put it up online. There's definitely some consumption-based pricing aspects to the billing, which is there. Again, surge is probably a good word is used in the question, right? The goal is to have that as a, I guess, at the moment, a constraint or a limiter on overuse or excessive use, much like our pricing on things like storage have been in the past. We're long familiar with that model. You want the vast majority of customers to not have to think about it. And then when they do have to think about it, it's really like they have an extreme use case, and they see value in that extreme use case. But we do have that consumption-based billing aspect in there. It's a little different between the different mixes of products and other things. So we've tried to be pretty clear about how we put that up for customers. On the Rovo and AI side strictly from -- think of that as the agents or AI usage. We then also have the consumption-based pricing on Forge and automation rules. So you have automation rules in sort of one stack, you have Forge or sort of cloud services that are underneath Forge from databases, all the other sets of Forge services and then you have AI. So think of them as 3 different credit stacks. From a studio perspective, it depends on how you remix stuff. But the more customers build on the platform, yes, we want them to be really clear on what they're paying for that.

We'll go with Adam in the front.

Adam Tindle, Raymond James. Mike, one of the other announcements here at Team '25 was the Teamwork Collection. I thought was particularly interesting in the $15 bundle of Jira, Confluence and Loom and I guess, theoretically, Rovo into that as well. Reminded me a little bit of Atlassian Together that you announced a couple of years ago. So I wonder for the question, some observations since you launched Atlassian Together a couple of years ago. And then as you kind of think about this Teamwork Collection, the risk from potential headwinds of the existing SKUs are priced much higher than this. So does it introduce some level of existing customers maybe moving to this bundle and saving money and hurt growth? And then the reward would be, I would theoretically think this could lead to more wall-to-wall adoption at customers. So as you kind of weigh the risk/reward of bundling those products together and what it might introduce, just touch on that.

Was that a question or a question and answer? You did a great job answering your question there. Yes. Sure. No, there's no doubt that's the case. Look, we've learned a lot over the years about how to put things together. We've always said, if you've listened to me for probably the last 10 years, packaging and repackaging and changing pricing structures to adapt to the market and what is the expectation of what's included. We defragmented our pricing continually over the last 20 years, in fact. So see this as just a continual evolution of that, firstly. Secondly, it certainly has much more attractive economics for customers that are going wall-to-wall, which we see. And obviously, we want to encourage. It's a really good thing, and we believe it has amazing value as both a platform and then a set of platform apps and the core collaboration apps. That set together is amazing value, and we've always looked to have amazing price/value ratio among those things. So there's no doubt that the goal there is to go wall-to-wall. I don't think that's a bad thing at all. Secondly, it also has a fixed addition structure and a fixed seat structure. So there is a trade for the customer to always think about there, which is really good in the case of things like Loom or other things where often they might think I'll just get it for 100 people. And you're like, actually, you know what, I'll get it for everybody because you've got one seat count across the Teamwork Collection. That tends to be a good thing, and we're certainly using all the learnings we have from past history.

Just as a data point to that, we recently concluded our early access program for Teamwork Collection. And there are plenty of customers who proactively come to us and say, we want to displace other tools across the organization and standardize. And this is a great way for us to get a foothold and do that at one shot and standardize on the platform. And that's been particularly effective for our larger customers.

Let's go with Alex in the front.

Alex Zukin with Wolfe Research. Maybe another variant of probably a question you're going to get a lot today on Rovo. So if you think about just the transition to free in terms of getting it really unlocking the potential and getting into the hands of as many people to play with it and try it and use it. And how do we think about the monetization of that functionality? Like I think there's a lot of anxiety from some people in the investor community, like this stuff is just going to basically be built into most of the enterprise software vendors basic or premium functionality. And gee, there's a whole lot of CapEx being spent on something that is -- makes the product better, increases retention, maybe drives premium functionality. But at a basic level, are there -- kind of how have you thought through the equivalency of that initial per user pricing with consumption ramping, use cases getting used, agents being deployed, particularly some of the ones that you demoed. Like how are you guys thinking of kind of 12 months from now when we're thinking about how much either AI adjacent or consumption revenue you guys are starting to drive? How do we start thinking about those equations?

Look, I don't -- I think you can believe in a series of future worlds, right? If all this stuff becomes free and included with everything, well, we want to have the best thing, and we want to make sure we get there as soon as possible. So if that is the future world that you believe in, this is probably a really good move for that because we know we've built something really good. And the general jobs that people hire us for in broad collaboration and project management and communications and all this are still going to be jobs many years in the future. And so the best thing for us is to get as much wall-to-wall penetration in as many customers as possible with the highest sort of value ratio of our products. So that's all good. If the usage turns out to be again much higher than we anticipated, we do have the consumption billing for any sort of overage. And obviously, the ability to move those levers around in time as we learn about potentially consumption levels that we can't expect right now. I still think even in that world, though, customers are going to look for really great products. And it has to start with something that's really, really good. It's very easy to make AI demos. It's very hard to make large-scale shipping enterprise products that deliver value to the customers in a way that they can describe. So we spend as much time on the design and the implementation and the quality of the results and the team. I'll tell you, the search team, the graph team, the conversational AI team, all the teams we have are week in, week out trying to measure their progress with real customers and make their answers better and their quality better and applying across all those weapons. That is -- it's really, really hard to do. So we do think it's something that we can deliver to the customers unique answers, unique both in the data sets we have and the interfaces we have that they already play in, but also unique in the quality of what we can give them back on top of that data and that knowledge, which will hopefully gain us more data and more knowledge from that company and that -- there is an ability to stay ahead in that. I do believe in that, that we can stay ahead in this race because it will be very hard for other people to catch up or keep up, and we're certainly trying to run that as hard as we can.

And maybe a supplemental perspective on that is it's very early. So consumption-based pricing is going to be an important component for us for sure. But it's too early to predict exactly how that's going to pan out. To his point around it's easy to build demos, hard to build real products. I think we will find out a lot over the coming quarters. We will find out from enterprise customers, which are the patterns that light up. So where are the places where consumption-based pricing makes the most sense, where are the places where we need to go figure out what kind of customization customers want, et cetera. So I think we will go through a learning loop over the coming quarters.

And maybe one thing to add, Alex, is within my organization, then there's the opportunity to get closer to our enterprise customers to understand the challenges that they have. And rather than introducing barriers to AI, we're actually doing the opposite. So embedding teams that are going to be able to partner with our customers to understand where those use cases are then are going to lead to expansion, but not only within our 4 walls, also working with the ecosystem. And earlier this week, we had them together on Monday, and we will over the next couple of weeks in terms of enabling them so that we can actually partner further with our customers.

And maybe just a follow-up, Brian, for you. Welcome to the organization. Just I guess, maybe what are you seeing the kind of -- I wouldn't say low-hanging fruit, but the most earnest opportunities. The team has done a great job of painting the picture of how much enterprise dollars are available within the current configuration of the customer base. When you think about applying your previous experience at SAP here, kind of how do we -- what are you finding is like getting you really excited incrementally from when you started?

Well, firstly, the journey that Atlassian has had has been amazing. And with all of the customers that we have and how they all came through effectively the same door in 90 days in the company now approximately, meeting with customers, seeing how mission-critical we are to their organizations is a great strong position to be in. At the same time, also seeing the very healthy positive relationship that we have with customers and users is very refreshing for me personally. And at the same time, we have an opportunity now to really lean into the customer-centric selling motion. So to move away from our products to build out the organization more, so we have more feet on the street, but also more of a VAT team to really understand what are the problems that our customers are facing and how we're going to best serve them. At the same time, a big opportunity is around customer success, back to my earlier point around how we embed teams to really help them adopt solutions. I also believe there's low-hanging fruit internally within our 4 walls in terms of building best practices from a rhythm, cadence perspective associated with a sales organization. And then we have a really healthy and thriving ecosystem, which has played a huge part in getting us to this point, and we can get closer and closer with them for sure. And then I would say the other low-hanging fruit in time that we can go after is new markets where, quite frankly, we're not there yet. And there's a lot of new markets as we roll into FY '26 and '27 that we'll be looking to see how much business we can take from those markets.

Arjun, you had your hand up earlier.

Maybe I'll touch on private cloud and Government Cloud -- or sorry, Isolated Cloud and Government Cloud, which were interesting announcements. What role do you see those playing as you kind of look to migrate DC customers off into the cloud and maybe capture more share in the enterprise? And then from a product perspective, feature parity perspective, should we think of that as equal to existing commercial cloud? Or are there going to be differences in product development and then feature parity?

Maybe I'll go backward to forward there. There is definitely some differences with the Government Cloud and the Isolated Cloud. Government Cloud has already got early access customers running on it. So it's probably a year or 2 ahead of the Isolated Cloud. But obviously, they share a lot of architectural primitives. The important part for customers is they're all running on the fundamental cloud code base, which is really important for them so that the innovations we deliver, by and large, will be delivered to all clouds unless there's obviously an exception that requires it to be eliminated for some particular reason, which is a vastly different architectural model. Secondly, we've spent a lot of time, as maybe you would expect, Arjun, you've been with us for a while, making sure that we have the engineering capacity to run this at scale. So we spent a lot of time on both the Isolated Cloud offering and the Government Cloud offering to make sure that we can do that in an efficient manner continually rearchitecting the base levels of our cloud built on some of the fundamentals we built for data residency and just continuing to push that. We do believe that there'll be more opportunities, let's call them, in that world. There's no doubt Government Cloud is a big space. We haven't really gotten into yet. So it's just getting started. Isolated Cloud for some of the gnarliest complex data center type customers that have that offering. Obviously, they have different pricing schedules and things for both of those and a set of requirements. The reason we've spoken about this before, philosophically, the world is going to have, I think, a lot more regulations and compliance rules that are in a lot more variants around different geographies or areas. And so that's the reason we keep investing in the architecture so much to make sure that we can keep up with that and use that as a strength. And I think we're really in a good spot to do that.

Ittai?

Ittai Kidron from Oppenheimer. A couple from me. First of all, are we at a point where customers -- or how close are we to a point where customers can no longer buy the product without actually using Rovo extensively in their daily usage? Is there a point in time when that happens? Number one. And number two, regarding the agents, you gave a couple of examples of multiple agents in different areas. But it seems like some of them are perhaps overlapping with what other vendors would think there is their area of expertise, Customer 360, for example. Why are you a natural place to do all of this? Or are there agents where you'd say these are use cases where it's more natural to run it through us rather than to run it through a CRM system, for example, or somewhere else? Help me think why you are the gravitational point for that.

I mean 2 different questions. When we say are customers going to use Rovo, I would expect that in 12 months' time, yes. Most users use Rovo every single day. Let's not forget that search is a part of Rovo. So even if you're just using Confluence, using search quite a bit to find stuff, you're going to be technically using Rovo, you'll get better search results. So maybe on that spectrum, that's not quite what you're asking, but technically, that I think would be the answer. The agents and the chat functionality, et cetera, we want that to be a very natural progression. So there are more and more places in the products that will drive you to get a chat-based answer, which you can then interact back with. And even from search, there are paths into chat. So part of what we want to do is build a fabric where they kind of disappear. Yes, you're moving between apps, but you're not really thinking about that. You're trying to find an answer and you're getting your answer. And there'll be modalities where people think chat is more sensible than not. I can tell you inside Atlassian, there are a lot of people who live with the chat sidebar open. I don't. I open it when I need it and I close it again, but there are a lot of people who just seem to like it sitting there all the time. It's like a constant companion that they're using. So there will probably be different work patterns. I think we're all learning about how these work patterns emerge. Agentically, look, we have a great framework for building our model of agents, and we have a pretty clear definition of what an agent is. I would say other people have a very vague definition of what an agent is. So if you fit our clear definition, and we have a very fulsome technology stack today. I heard that from a number of customers over the last 2 days, especially in the enterprise, largely based on our heritage in Forge and in other extensibility mechanisms. So you can build a very, very full-fledged agent today that is not just a chat responder. It actually does a lot of things. It can take a lot of actions. It can be combined into automation rules in various ways. It can manipulate and appear in the UI at lots of different spots. This is very fulsome as a framework. So that is one reason you would choose us is if that makes sense. Second, we have a lot of interfaces, which may be a starting point for your agent journey. Obviously, if you're doing anything with projects, to do with documents, do with data, we have a lot of reasons to be there. I think customers will build their own agents that serve their own purposes. We built Customer 360 because it leverages our data in Salesforce, but it also leverages our data in our internal customer repository and billing systems and customer service and various other systems that we have. So that's maybe a case where we are a consumer of a series of different products. Because of the way our agents interact with each other and with human beings, there's no reason also they can't interact with agents from other agent frameworks if the customer wants them to do that. I don't have an example at the top of my head of customers, but I suspect 6 months and 12 months from now, I'll be able to give you lots of examples where people are doing that. I think that's totally natural for any new sort of technology progress. So again, there's nothing exclusive about them not being able to interact or share data with other services.

I think the -- why are you the natural place for us to build this? 3 clear reasons. And I just came out of a customer meeting with a large chip company that's trying to do this with us on Rovo and they're really excited about 3 reasons. One, as AI native development becomes more prevalent, user personas that used to do traditional tasks before will do a lot more. So where do you call Customer 360 from? Is it really your salesperson that's calling that agent? Or is it everybody else in the org, any customer-facing person? It will be a lot more of the latter. And so the work surface area, I think we have a very broad work surface area. That's a big advantage. This is why they want to build our agents. Second, the Teamwork Graph connects to 50 different connectors and has programmability built in. So we have a heritage of programmability. Customers already have plenty of custom apps, building custom agents just got even easier. So from Forge, we are now down to a point where you can do noncoding. And third, really, it's about the agent building is translating into every single team across your company. Because the things that we're doing in a virtuous cycle around Teamwork Collection, making sure that knowledge workers have wall-to-wall access to our products, et cetera. It's a virtuous loop of it's only going to get better and broader and easier. So we see a lot of customers want to get a head start on that and build agents alongside. I suspect in 12 months, there will likely be overlaps of agents, but I think it's very -- it's going to be very important to say how easy is it to build the agent and how easy is it to use it without asking you to retrain your entire workforce and make them do unnatural things.

I have a question from online that I think is good to change gears on. How do you think about the competitive set in CSM? And how has success with JSM and ITSM informed the decision to extend to CSM? And do you see further expansion opportunity?

Yes. So in CSM, today, 25% of our JSM customers already use JSM for customer service workflows. So there is a lot of pull from our customers in this particular area. The way we think about that, our right to win in this space is twofold. One, AI disruption is really completely changing the space. So it's really creating an opportunity for new players to come in and redefine the game. And because of our massive investment in Rovo and the Teamwork Graph and the platform that we've built for several years, this places us in pull position to really operate in a new market to Brian's point. Second, the fact that your developer teams, ops teams are already on our platform and placing customer support teams on the same platform really gives the same ability of breaking down silos that we have seen very successfully work in the JSM space. We bring the same advantages to the CSM space. So across those two, we believe that we have a clear right to win in that space, and that's why we're excited to roll out the beta of the CSM app. What was the second part of the question?

Do you see further expansion opportunities?

Yes. So I think with the whole collection and system of work, as we've spoken about extensively before, our fundamental thesis is that we want to expand beyond our traditional sets of customers that we address to the nontechnical teams, to teams that have no technical backgrounds necessarily, but are adjacent with other technical teams. So technology-driven organizations that have business teams that interact with technical teams and customer support is very much in that definition. So we are very bullish on being able to address that market.

We also showed off the HRSM stuff. So that's a slightly different space, again, an internal use case driven by a lot of people using Jira Service Management in HR, but now we have dedicated templates and connections to Workday and all sorts of other things that is different. And lastly, for those students of history, I forget the percentage of Jira usage that was serviced before we had Service Desk in the first place, but it was somewhere around that 25% to 30% mark...

That's right. Yes. It was on...

of people were using Jira back then for service use cases before we even had a queue or an SLA to speak of. So it's a traditional sort of follow your customer, and that's worked out pretty well so far.

And maybe to add to that, in terms of maximizing on the opportunity, we have a specialized sales force in certain areas of the business. JSM is one of those areas. And as Anu said, CSM directly relating to it gives us the focus that we need from a go-to-market perspective to go after the potential in that particular space.

Rob, upfront over here.

Rob Oliver from Baird. My question is for you, Brian. Since you've only been here 3 months, just be curious, the Atlassian built a really unique and world-class partner network that I think is the envy of most growth software companies. And following the company a long time, we've seen a lot of these partners grow from really small to being able to rent out Disney for their customers last night. So I'd be curious to hear with a lot of talk of platform and clearly a move to enterprise, what your philosophy is on how to manage that both opportunity and potential for conflict as bigger partners start to come in and how that -- what your view is on that opportunity in enterprise?

Yes. Thanks for the question. So firstly, I think, as you said, we do have a great ecosystem, and they have done very well by partnering with us. We now have an opportunity to invest further in our partners. We've taken some initiatives already in terms of rolling out some tools to assist in terms of migrations to help them. In addition, we now need to move our partners away from the traditional transactional selling instead to look at new models whereby we're going to be focused on moving our customers to the cloud, rewarding them for services engagements as opposed to traditional rebates potentially. At the same time, we need to enable our partners more, let's say, better. I think there is -- back to Alex' earlier question, there's low-hanging fruit around that space as well. I think from the 90 days that I've been in so far, it's very clear that our customers are hungry. The ecosystem is very hungry as well for further investment from us and direction. And then finally, I would just say we have an opportunity, like I said earlier, to look at new markets and where we can actually partner with some partners. One of the things that I've gone out of my way to stress to the partners that I have met with is we don't have a plan to roll out a large-scale services organization, which would cannibalize their business, which obviously they're relieved to hear that's the plan. However, we will have a small advisory services team that will reserve for our largest customers so that we can put some hands on keyboards to help in terms of migrations.

One thing I will say I've heard -- sorry, maybe we're piling on, but I've heard 3 times in the last -- once yesterday and then a couple of times last week with different partners. Our scale as a platform is enabling them to start doing things that they couldn't do beforehand. And by that, I mean the maturity of Forge. Forge databases was a big step for them. So they can build real applications now on top of the Atlassian platform, which they couldn't have done 12 months ago. The movements in Forge and also the excitement around AI and agents is letting them go in and sell services to our customers to really solve unique use cases entirely on top of the Atlassian platform that wasn't really possible certainly in the cloud 24 months ago and really excited to see how they do that, right? We've long had a history of not just partners going in and selling software, but solving problems for customers by building unique things by taking Jira and adding stuff on top and solving a customer problem. So to hear them say that cloud has reached a point that they feel like they can do that, supercharged by AI coming in, obviously, customers asking them, how can you solve this problem for me? Giving them Rovo plus Forge plus all the other things, really excited to see the things that they can build for customers, which is I think can benefit us in the long term, too.

Gregg upfront.

It's Gregg Moskowitz from Mizuho. So I wanted to get back to Atlassian Isolated Cloud. I think it's a pretty exciting development. That said, our understanding is that isolated cloud, at least initially is only available to your very largest data center customers. If that is correct, I guess, why restrict isolated cloud so significantly, why not appeal a little bit more broadly to your population of DC customers that feel like they just can't pull the trigger on moving to the cloud today? And then just a quick follow-up for you, Brian. Very helpful to sort of hear your perspective on the business. I think a lot of us look at Atlassian just being so successful over the years, 300,000 customers. And so there's, I think, many who just look at this and kind of say, well, it doesn't seem like there would be many opportunities from a new markets perspective. You just kind of called out, obviously, small advisory services. Do you see other opportunities where maybe Atlassian isn't very present or not at all present today?

I can take the first part there. Isolated Cloud by its very nature, obviously is appealing to a relatively small number of our customer base who actually really, really care about isolated and dedicated networking, dedicated storage, dedicated compute. They understand it's an expensive exercise for us to provide that no matter how great our R&D is because of the volume of services that we're putting into there. And it's quite technical and complicated for us to do. So it's naturally going to have a smaller base at the start. I will say, look, we're targeting the Fortune 500,000. I don't expect to sell 500,000 customers isolated cloud, but we have a long history of believing markets are bigger than their starting point and building the right engineering so that we can scale that out. I would point to our search engine is a good example of where we need to run that at 300,000 customer scale, not 2,000 customer scale, which is a vastly different exercise. So definitely a high potential future opportunity for us.

Brian?

And then maybe in terms of the opportunity, I would say, we've been very fortunate because we have a lot of technical users who are our customers, which has been great. We had Domino's on stage earlier today, one of the customers where they're both on the technical side and on the business side as well. In their words, the wall-to-wall on Atlassian. We now have an opportunity both within the existing installed base that we have to sell up. That can happen from both a top-down play, which many enterprise software companies do very well, and we certainly have the right to do that. But we also have the opportunity to have a bubble up within the same 330,000 customers that we have. And in addition, as we roll out new products, we have an opportunity to cross-sell and upsell into the same 330,000 customers. And then obviously, there is the opportunity to grow that 330,000 customer base significantly. All of our customers -- new customers today come in through, like I said earlier, the same door. There is an opportunity to look at new routes to market and new partnerships that's actually going to open new doors for us and new logos as well, which for me is a big priority.

Karl, back there.

Karl Keirstead with UBS. I've got 2 questions, one on JSM competition and the other on the channel. So on JSM, obviously, Marc Benioff on the last Salesforce call announced that they will be soon pushing deeper into the ITSM space, presumably at the mid-market. I'm just curious, when you think about Salesforce entering that JSM space, what did you think when you heard to make that announcement?

I think commenting on Marc is dangerous. We feel very comfortable where we sit in the ITSM space and our R&D backbone. We just focus on the customers and make sure we're doing what they want us to be doing. I think we feel really comfortable about where we sit at the moment. Made a lot of really good announcements here. We haven't even talked about asset management. Obviously, when we're pushing assets from $3 million to $10 million, and we'll continue to push that scale, it's because customers are hitting those upper limits of the number of assets that they can store in our graph-based CMDB and the ability to show interesting things with that in AI and other places. So I think we have a lot of a lot of really good strengths in that space.

Okay. Makes sense. And then on the partner channel side, I know that Atlassian, I think last quarter, may have lowered the commission structure for partners on data center. I'm assuming it's part of a strategy to motivate them to push the customers harder to cloud. Can you describe those incentive changes? Sometimes on the outside, when we see them, we worry a little bit about channel disruption risk. But maybe you could talk through it and flag why that's not a concern and you feel good about those changes.

Sure. I can take that. So we did have some changes that we rolled out. When we're going to make changes like that, we'll give notice well in advance that this is likely to come. Just like recently, we've started talking about moving away from transactional and then rewarding more in terms of the delivery side. So the changes that we rolled out before didn't come as a surprise to our partners. Now they see obviously a continuous push in terms of moving to the cloud. And they, at the same time, see the push in terms of moving away from transactional. So I don't think there was any surprise when we rolled it out before. And like our commitment to them is as we continue to roll out any other changes, that will be very transparent. And ultimately, for me and for the organization, we want to move our customers to the cloud because they have a completely different experience when they're there as opposed to the data center solution that they're running. And not only is it the right thing for us to do, but we actually owe it to our customers to get them on that journey. And I think leaving this week, and Mike said it earlier, it's coming back loud and clear to our customers and to our partners that it's not a matter of if they're going to move to cloud, it's a matter of when. And the obligation for us and our partners, whether there's somebody who blocked is to run in the door and to figure out what is the issue that's holding you back and embed a team there to help them get on the journey.

Mr. Jason on the end here.

Jason Celino from KeyBanc Capital Markets. I just have a couple more clarification questions for the Teamwork Collection. I just want to confirm that it's only for cloud customers. And then also, you said it starts at $15. So obviously, your pricing is fairly transparent for you different tiers. So maybe are there higher tiers? Or what does that kind of look like? What's included?

Yes, it's only for the cloud. And pricing similar to other things we sell. I guess, obviously, there's premium edition and enterprise editions, which go up in price and then there's volume, which goes down in price. So it's not dissimilar to other things that we have in the way that the whole scheme of works. Customers seem to really understand that they like expect these 2 facilities. We've kept it the same for that distinct reason.

In the back, Tom.

Tom Blakey with Cantor. Michael, you mentioned the asset management product. So just wanted to double-click on that. How difficult is that to unstrangle the strangle hold that some larger service management platforms have had in the CMDB for many years? And if there's any other impediments that you're kind of targeting that you see in the market today that you're thinking about alleviating? And then maybe a second question first. The move from data center to cloud is very encouraging and walk on the floor today, everybody is really excited about that and share with you. Is FedRAMP high needed for some of your government type of businesses to move there? And if so, are there any plans for that?

Look, I think the strengths of Atlassian have long been our R&D heritage of building really, really great software with architecture underneath it and that behooves you well at times of transition like the movement to AI and secondly, providing incredible value for money for the software and the value -- business value we deliver for the price that customers fundamentally pay and to deliver value first so that they see value and then they continue to consume our software. That's been the same for 25 years. Certainly, in some of those spaces you mentioned, we feel we have significant advantages in the price/value ratio and the technical excellence of what we do, and we intend to keep our strategy pretty consistent for the long term there. FedRAMP High, yes, there are certainly customers, I'm assuming I don't know any of the top of my head. I actually didn't know a couple, but who that may be an issue. FedRAMP Moderate is a much larger leap, I would say, in terms of getting that approval. So obviously, it's a first step on a journey. Whether there's a second step and if and when we take that step would be potentially sometime in the future, I guess. But it's a big step already that we've taken here. It unlocks a huge amount of the government and government adjacent customers. Often, it's not specifically government departments themselves, but obviously, companies that serve the government that need to have that, that tends to be at the FedRAMP Moderate level. And then otherwise, we'll do what we do and listen to those customers.

Steve?

Steven Koenig from Macquarie. I'm curious to get your thoughts as you're pushing the envelope on agentic AI adoption. What are you seeing as the customer concerns and barriers now? How ready is their data? And where do they sit in terms of like needing to be sold the stuff or experimenting with the stuff or actually putting it into production? And then I'll just toss out my other question as well. So if you don't mind. In the Collection seems like a natural fit with Rovo agents as you -- in seeing the demo, like it almost made it irrelevant these walls between your products. It's like your -- the agents help you move across the project -- the products more seamlessly across the apps. What are your future directions in terms of like making the agents more compatible with your architecture? And like with Team '26, what might you think of doing when it comes to like breaking down more of the components of your apps or the walls between your products and how do the agents fit in? Hopefully, that's not too much of a nebulous question, but no.

Anu, do you want to take the first one?

Yes, sure. Actually, just this morning, there was a cool Stanford report around what customers across different sizes are expecting to see with AI products that they use and where it's actually moving the needle. Because we have 300,000 customers, we hear from a wide variety of different profiles. I would say if I had to characterize it as 2 separate buckets towards the smaller mid-market, the categories of questions we typically get is how quickly can we deploy it, what can we do with it, right? So there is a large amount of appetite to go try it and see what sense it makes for the particular scenario. And there, it's easy for us to show because we showed you 1 million demos all of today. So there is a wide variety of choices to pick from. In the case of larger enterprises, I would characterize this as just having been in the tech industry for 20 years, I think enterprises have the largest appetite I have seen for new technology in terms of AI adoption than any of the previous tech waves that we've seen. And I think it's particularly interesting because the state of their data as AI tech evolves more and more, you see that it gets more and more forgiving as to what the state of your data is. A couple of years ago, it was very much well, your data has to be prepped and has to be in a certain format and structured versus unstructured and clearly prepared for it to be making any sense. But as some of those constraints have relaxed, more and more enterprises want to build agents on top of their existing data stacks. So I would characterize that set of customers as they're eager to engage with us and co-design some of these things. And because we have programmability of our APIs, both our apps and agents, as you saw us differentiated across the 2, I think it's very exciting for them to go figure out, here's the broad surface area of users that I can address and customize it for my enterprise use case. So I would say it's been very encouraging across both segments.

I'd say there's also an element for the customers of playing with the technology a little bit. If you've used ChatGPT at home, you have to kind of play with it, use it. You kind of that's interesting and you learn. We're all learning a little bit what's capable and what's possible, then you push it a bit harder, you learn more, et cetera. One of the reasons to include Rovo in the platform is to enable that playing, right? That maker attitude, the creator attitude, a whole bunch of our internal agents are written by product managers and marketers. They're not written by engineers. So we want to put that toolkit in the hands of as many of our tens of millions of users as possible as quickly as possible so that they can learn and go up that curve fast, right, and not have to put a commercial barrier in the way of it is really important, I think. Secondly, on the experiences, certainly something we spend a lot of time on. I think there's almost a duality of movement that's important to understand. The movement from our products to a much larger set of 20-plus, I'm not sure where we're at, 28, 29 apps is to move functionality into smaller areas that are more focused on what they're trying to do. That creates an instant experience problem, but I don't want to jump around all these things. So we showed a lot of examples with more focused apps that do one thing, but those apps and their data are available in lots of other places. You don't need to go to the goals app to pull up goals. You don't need to go to the search app to pull up search. You don't need to go to focus to pull up focus areas necessarily. We are trying to have a very consistent and fluid experience to allow you to flow across all of those apps, first and third party inside our world to give the customer the best experience while still having a focused set of apps. You then get to the -- that's a user experience problem to solve. We're doing a really good job of moving in that. You saw some of the examples of the sliding view. You pointed out that in chat, you can get access to lots of different data despite being an app A, you can get data from app B, et cetera. That's all purposeful. The only challenge for the customer then becomes the commerce complexity. So we want to make sure that we have a user experience device to simplify the world of many, many apps for the end user, so I think tens of millions of people. For the hundreds of thousands of buyers we have, we want to simplify their experience, but that's done through the collection devices in the opposite direction. We don't want them to have to say, do I buy the goals app? Do I have to buy the home app? Do I have to buy talent and focus? Do I want both or one? Like the more choices we put in the way of commerce, it's not helpful to our goal of going all-to-all. So think about on one end, we're simplifying the buying experience for the hundreds of thousands of customers, and we are trying to simplify the usage experience for the tens of millions of end users and also giving us the flexibility to continue to push each of those envelopes while making them more focused. So no pun intended this kind of a duality there.

All right. Well, thanks for all your questions. Thanks for joining us. We really appreciate your support. For those of you here in person, if you exit this door on the right, we'll have a social gathering. Mike, Brian, Anu will all join you in a couple of minutes. And for everyone else that tuned in, thank you again.

Thank you.

Thank you.

Thank you.