Try it again. Sorry. Welcome to the folks online and in the room here. We've got representation from buy-side communities. As I was saying without the microphone earlier, there's an agenda in front of the folks that are present here. There's two sessions specific to the community, one at 9:30 here with CEO, president, and co-founder, Marty Vanderploeg, and our EVP, Jeff Trom. We listened to you guys last year, so there are a limited number of slots. This afternoon, starting at 1:00 to 2:30, our EVP, chief revenue officer, Scott Ryan will present. Everybody will be available for questions. Jeff is only available for the morning session for questions. With that, I'd like to hand it over to a couple.
Good morning, everybody. I got assistance from everybody. Thank you for coming and taking the time. A really great event. Appreciate you being here very much. As Stuart said, we did listen to you, what you said about decks, and the decks we put together are really trying to be focused on what's new and relevant. Obviously, you have questions about tailored to these decks. The other thing I wanted to mention was Jeff is speaking next. One of the best product guys, probably the best product guy I know. He'll be available to ask a lot of questions. He'll be available for you to ask questions about the product, because obviously that's something we've heard a lot about from you guys, your spend on R&D.
It's been a significant investment, we know that. One thing I hope you come away with today, understand that investment did it. Please feel free to ask questions. We will address later this afternoon what we expect that spend to do in the future. It's not something that we plan to grow. Most of that spend is winding down in terms of what we're building right now, which is the platform. That, I will turn it over to Jeff, who's just going to go through a slide deck and talk about the platform that we're building. It's a true microservices multi-tenant platform, and it's built all on APIs. Those APIs can be exposed over time based on our strategies, and it allows us to really build a lot of different applications very quickly.
Obviously, to build the underpinnings takes time. Jeff's going to give you an overview of that right now. Jeff?
Okay, I'll just spend a few minutes. I'm going to, at a 20,000-foot level, give you an idea of where our technology is and our architecture is at. I'll try to relate that to what's new, from what you've seen from last year's and previous years. Walk through that. We've got a safe harbor thing up here. Everybody see it and read it, small? Let's just walk through this. The first thing I want to start with is to say a couple words about the core foundations that we're built on. These are not things that we necessarily spend a lot of energy on, but these are what we've chosen as our foundational elements to build our applications on. A couple of things. First, around data storage. Number one, we've chosen, obviously, we're in the cloud, so cloud technologies for data storage.
We've chosen three things. Everything, all of our applications funnel down into three things. Either a SQL database, large SQL database, blob storage, things like file storage, anything large, file, that kind of thing. Or the third thing is a key-value pair storage. These are the three fundamental aspects where all of our software boils down to this as far as storage goes. These things are low cost. They cost almost nothing to store, which is important to us, right? Because we keep a history of everything, right? We don't delete anything. For us, having a low-cost storage is important. Redundant, all of the cloud providers provide redundancy in these storage mechanisms as well. If you've got a SQL database up, we can replicate it. It gets automatically replicated for us. We can handle a disaster recovery fairly easily as well.
Just as important, we can encrypt all of these things. These are sort of the fundamental tenets that were built on. These are the foundational pieces of just our data storage. If we take that up a level and we talk about our core service infrastructure, what is that built on? This is new for us as well, is to build all of this. It's all been built in the last couple of years on Docker containers that are managed by Kubernetes. Most of you have heard those terms in the industry, kind of the core standard these days, we've moved entirely to this model. That gives us the ability to scale in different ways, scale our services in different ways, also portability between cloud providers, right? Because all the cloud providers are making available Kubernetes access across the thing.
We could go to an Amazon or a Google or a Microsoft, depending on the cost for each of those things, we'll use each cloud provider as we need to. These are sort of the foundational pieces that were built on top of. If you look at this is an extremely high level of how we're viewed. I kind of almost laugh at this one. It's such a high level, but if you want to ask more detailed questions, please do, either at the end of the talk here. Essentially, if we were just to describe what our core services are, Marty mentioned we have a microservice architecture. You've heard the terminology a lot. We actually live and breathe on this. This is how we develop software.
Each of these items that you see up here, for example, a linking service or a table service or a text service, to be perfectly honest, we don't even have services named those things, just to give you conceptually what we're doing here, each one of them scales independently. You take linking, it can scale as it needs to 50 servers if we need to, right on the back end. 50 virtual servers, or it can scale down to 20, or at night at 3:00 in the morning, it might need three to run. Each one of these can scale independently. We can release independently, we can develop independently for each of these services, which is a key thing, right? This is not a monolithic application.
Each of these services can be developed by itself, have its own development team on it, we can release those things independently. We can have some things that have been out for a very long period of time that are stable, then we may have a new service that we're working on doing something different in a different space, we'll start that one up and just integrate it into the environment really easily. We can plug these new services in very easily as well. The messaging bus that connects everything together is one of our key secret sauce areas, right? This is super important for us. When I talk about the messaging bus, it's really this central component in the middle. It can handle billions of messages a day.
The key thing here is that any of our services, they really don't talk directly to each other. They all communicate through a central messaging bus. That's all they have to know about is each one of them has an API that we publish. Makes it easy to add new services to it, makes it easy to discover those services and publish them out. Likewise, the users up here were showing up, let's say up in a browser somewhere in the world, they communicate through this central messaging bus as well. That's really how the system works. Again, this is extremely simplistic view of life here, essentially that's kind of where we're at. Each of these services, the fact that they are microservices allows them to communicate separately and to be developed separately, we can also deploy them in different ways, right?
Service like calculation might require a lot more memory than something like linking or even text, right? We can pick and choose our virtual servers based on the memory size that they need and the amount of CPU that's required to actually perform at a high level. We can basically customize, we can fine-tune all of these services to a point where it's cost effective for us to do that, right? It becomes less expensive, it becomes more performant for the user, that's kind of what they see. One of the big things about our central messaging bus and our messaging strategy in general is that we've chosen an async messaging system. If you just understand what that is, I'll put it in terms of a client, for example.
A user might send a message in, they may want to do something like generate a PDF of this document, for example, they may send the message in. As soon as it gets to the messaging bus, we can return to the user and say, "Okay, we got it. We'll notify you when that's done." Even if you've been out to our booth, even if you see our calculation engine, it works that way, right? You make a change to a number, sends it into the messaging bus, returns. The calculation engine goes, pulls all that data it needs to out of a SQL database, runs a computation on it, sends the result back to the client. That might take 200 milliseconds through the whole system for something that's short.
Generating a PDF or something like that might take five seconds, or it might take 50 seconds if it's a 500-page PDF, right? It just depends on the complexity. Building it that way allows us to be fault-tolerant, that's a big thing for us, right? As soon as we get to the messaging bus, if the whole system were to come down, if Amazon or Google were to come down, for example, we were spun back up, everything would run, everything would finish just perfectly. That's what this is all built for. It's built for fault tolerance. It's built for scalability. The other part of this is this can support hundreds of services. In our production environment today, we probably have around 80, 85 services that we're running.
When we actually work and develop on these things, we'll do test services all the time. We may have several hundred, 200 or 300 of these things running at a time. They're all communicating, not only between the users and the services themselves, but the services all communicate amongst themselves as well. You can imagine that developing in this way requires a lot of fundamental stuff to be built, right? That's where we've spent a lot of our energy over the last year, the last two years. You've heard about our platform being built. We feel really good about it. We feel really good about where it's at. All of that core stuff that's out there, all the monitoring. Each one of these services, of course, has to be monitored, you have to watch it.
If we feel like one of these, instance number 3 of a tables thing is starting to use too much memory or starting to go down, you need to know that, you be able to take it down and spin up a new one. All that kind of stuff is handled for us now. We put all the software in place to make sure that all the fundamentals are here. Another good example is tracing. If you ever do want to debug something, or you want to optimize a call to a user for some reason, some request, you got to trace it all the way through this system. You can make a request in there, it may ping pong back and forth from service to service and come back out again.
All of that mechanism for us has been developed and is operating at a high level right now. We feel great about where the core services, where our core infrastructure and our core platform is at. This allows us to build software much faster and add new services and new capabilities to the platform as we grow. Now I'm going to take it up a notch and just say, if you take a look at our reporting platform in general, these are the kinds of outputs that our users look at, right. If you go to the pods over here and you walk through our user conference and you talk to the users, this is what they're looking at. They're looking at Spreadsheets, they're looking at text docs, presentations, maybe regulated filings with XBRL, audit reports, any kind of dashboard.
These are the end things that the user looks at. If you take a look at just one of these, let's just focus in on text docs for a second. It's not made up of just text, right. Just raw text, obviously. But within text docs, it may have tables in here, it may have images, it may have charts, all kinds of different things that are inside of a text doc. It's actually composed of fragments of these things, right. A typical text document might be a single file that someone stores on the back end somewhere in storage. We know our system doesn't work like that, right. It's all built out of all of these fragments. We may have multiple text fragments that make up a document. We'll have, obviously, multiple images, multiple charts. We'll have individual formulas, individual calculations.
Even our calculations are not stored as a table or as a Spreadsheet, right. They're stored as calculations or as a graph of calculations. That's very important to understand. If you look at how the fragments are actually applied, we can apply the same fragment, the same formula fragment, for example, to a document, a Spreadsheet, and a presentation. Of course, the advantage to this kind of fragment relationships is that if I go in here and I change this, I come in, I change my 58 to a 113, that ripples through everywhere we need. You guys have seen that in the past. That's a lot of the linking that we can do, and it's a general way of being able to change data that ripples through all kinds of documents. We can propagate this stuff everywhere.
What I'll say is that, in this case, we've gone in here, and some users come in, and they've changed an 85 to a 113. They've done it manually. If you look at all of the complexity that's going on here, what our users have asked for, and something that we've been working on pretty hard in the last year, has been a workflow engine. Our users actually want to do this stuff, but they want to do it automatically, right. They want to be able to monitor certain processes, certain steps in our environment, and then when something happens, they want to be able to go in and kick off a workflow that might notify a bunch of people to go review a document or a section of a document, that sort of thing.
That's really what workflow is all about, and we've built a very general workflow engine that's very powerful. If fundamentally what it's all about is really to automate repeatable processes, these things that you do over and over again. We don't want to do anything manually, any kind of repetitive process. Our goal is not to have to do those kind of repetitive things manually. We want to unlock every action in Wdesk. Everything that you can imagine, we want to be able to unlock through a workflow engine. I'll even drop down to this bottom point here. You want to be able to trigger those workflows of individual content pieces. That's something that's very unique to us, right?
Because we can go in and do this stuff at a very, very low level of granularity, you saw in the keynote yesterday where we could look at an individual number, for example, within a Spreadsheet, and you can say, "Hey, conditionally, if this thing gets above whatever, 200,000," I think was the example they gave, boom. Not only do I want to just turn it red visually to someone, but I might actually want to notify someone, or I might want to kick off a workflow or a process. It's those kinds of things that we are now enabling ourselves to do. We can monitor everything that happens at a very low level of granularity in our system, and that's what our general workflow engine has been built to do, and now it's a question of unlocking those use cases for our users.
We feel like we're in a pretty good spot with workflow in general to be able to do that kind of thing. Of course, you want to be able to monitor all of these processes when they're out there, and our workflow engine can do that kind of thing too. Workflow is also a way to connect to external applications and drive processes within our system, either externally or for us to drive external systems also. That's workflow. If you look at where we're moving as a company, and we've spent a lot of energy on workflow in the last year, and we'll continue to spend energy there over the next year, but you've got documents, Spreadsheets, presentations, dashboards, audits, regulated filings, and then you add workflow on top of that.
You can imagine that if you just open this up to a user, this kind of looks like the Wild Wild West to them. The user interface for that would look pretty daunting. Like there's a whole bunch of stuff to do. The question has been, how do you scope this down to a point where just, it's very directed what a user needs to do, or what they were trying to accomplish. What's the scope? How do you pull that down? We've been working hard on a thing that we call Workspaces. You've probably seen that demoed out here as well. Workspaces allows you to take all of these complex processes. Based on the solution that you're in, let's say an SEC filing that you're doing, or it could be a SOX reporting report that you're working on.
Based on the solution you're in, based on the role that you're in, and based on the workflow status, we're able to customize a workflow or customize a user interface for you. For this example, you see the left-hand navigation in a SOX Workspace is going to look very different from what it looks like in an SEC team. If you're doing XBRL reporting or you're doing audit managing, and it's based on your role as well. If you're the manager of an XBRL filing, you're going to see the filing report here. This one doesn't have it, apparently no one gives me permission to file anything. You get all of these kinds of things are based on your permission or your role within an organization or within a solution. This is from the user's perspective.
This is one big advantage that Workspaces has given us, and this is a thing we've been working on really hard, but it's more than just the user perspective here as well. Workspaces really becomes easier to manage within an organization. An org itself, within an organization, if they enable Workspaces, we're able to expand our solution use cases in their org much easier than we could do in the past. It was fairly painful for us to manage the set of users or for the customer to manage the set of users, but here they can do it themselves. Our whole goal is, hey, if I want to be able to spin up multiple Workspaces, multiple solution types, I could have four SEC solution Workspaces within the same organization.
They all might be working on separate types of filings, and they may want to manage that and have different sets of users in there. I can do the same thing for audit, and I can do the same thing for any of our solution Workspaces, SOX, audit, general audit, whatever. We're finding Workspaces to be extremely valuable to allow us to proliferate within an organization because it allows the customer to do this themselves rather than having to go to the IT group to say, "Hey, I want to spin up a new group, and I want to manage the people that I'm allowing in it," and all that kind of thing. The users can actually do that themselves, and that's a huge advantage for us.
Managing those user administration across Workspaces is a big deal for us. We spend an awful lot of time on Workspaces. Again, this is our next generation product that has not yet gone out to all of our organizations, but it'll be shipping soon. If you look at, okay, we've got all these great applications, we've got a way to configure it, we've got a way to administer it, but how do we get data into our system? In the past, you've seen in previous years where we've talked about our APIs. We've got APIs available where a software developer in a company can write to it, and they can send data in, pull data out, all that kind of thing. Again, you've got to be a software developer to do that.
We have packaged connectors that allow them, for certain applications or certain connections, they're set up automatically for you. You can do a limited amount of things with those package connectors as well. Again, that's a no-code kind of thing. That's managed, and that's worked for us fairly well in the past. What we're finding and what we've been hearing from our customers over time is that, "Look, this is great if I've got my data already in a form that is suitable for reporting. I basically have got a few Spreadsheets, or I'm getting down to a point and I want to repeat a process. These two types of connectors and APIs work fine, but we're still having the problem of, I've got tons of data out there. I've got all kinds of data sitting in front of me.
This is where we talked in the keynote yesterday. This is our DataPrep tool on the right, which is hundreds of millions of rows of data. More importantly than that is, I want to couple that or I want to combine that together and pivot data in different ways with ad hoc data. Virtually every company that we have dealt with, and we deal with a lot of them, it's not just fully structured data that they're dealing with here. They have structured, and they have unstructured data that have come from some homegrown system someplace within a company. Everybody's got it. They want to be able to combine those two things together.
That's what DataPrep allows us to do, is it's a new product for us that allows us to take these huge sets of data, combine it with some of the unstructured data that's out there, pivot it in different ways, and then say, "Okay, now I want to pull that data into Wdesk and use it in all my reporting applications." It's a way to take us upstream in the company's processes. We're pretty excited about the product in general. That's kind of where we're at today. These are the big things that are coming out is the DataPrep tool, which I think you guys, if you walk around the booth, you can see demoed for you. They can show you some pretty impressive demonstrations with that.
This is what DataPrep really does, right, is it takes the marketing data, your sales data, a lot of stuff that might come from all of your structured stuff. The important thing at the top is called Spreadsheets data, but that is the unstructured piece of it. That, every company, like I said, has got that everywhere. DataPrep is really this tool in the middle that just combines all that together and allows you to do it in a repeatable fashion, right? I can do this quarter's data, then I can do next quarter's data and the following quarter's data. I can start to see a time history of that as well. DataPrep will keep that history of data as well. We don't delete that data either. It's not something you write over. Essentially, that's what DataPrep's all about.
The last slide that I have is just to let you know where are we at with our next generation platform. We've been talking about it for a couple of years. We feel really good about it. This is our goal as a company, is we've got companies using it now. Spreadsheets has actually been out for a year and a half, in full force. Pieces of it have been out for a long time, but we're trying to unlock different solutions with all of our new technology levels and our next-gen stuff. The SEC one is obviously one we're focusing really heavily on. The goal is to have that available for all users, for anyone who wants to convert or use it by the end of the year.
We've got something like 60 customers that are in beta with it right now, it's pretty far along. We've been filing with it ourselves for the last 4 quarters. It's something that we've been filing with for a while, and now we've got customers doing it as well. We've been doing a beta program with customers for the last 2 quarters. It'll be our third quarter on it. That's kind of where we're at, generally, where we sit. We expect to be done fully with the SEC solution space by the end of the year. Then there are several other solutions that will trail off and be completed by the end of the Q1. That's essentially where we're at in terms of our core platform. Then the sky's the limit after that.
Just one quick comment. We've had quite a few customers file with the new platform too, and I think last quarter, we had 30, approximately, file with the new platform, and all we're getting is positive comments. Now and then we get a comment about when is this feature coming, because we're still catching up on features. They love the performance, a lot of the new enhancements. To Jeff's point, we're, toward the end of this year, getting back to, I hate the word parity, but we're getting back to where we can move our customers over, and then from then on, it's all about new stuff. That's sort of where we're at.
Up to
Thank you. In terms of DataPrep, that has been out. There was a press release earlier in the year, that's not like a beta thing. I'm curious where it stands in terms of what kind of traction you're seeing with DataPrep. What kind of uplift you see. Just what can you tell us a little bit about DataPrep and what you're seeing with that product in the market? Thank you.
I'll take that one. Clearly, for us, it's an ecosystem play. You look at DataPrep, I'm not aware of, and if someone is aware of it, let me know, but I'm not aware of a true cloud, really complex Spreadsheet directly attached to a large data prep tool like that. We can, as Jeff said, put in hundreds of millions of rows of data, process it, and then kick it right into a Spreadsheet. We have a lot of users trying it right now. We have had some sales that were assisted or were uniquely just that product. It's an ecosystem play, just like I talked about yesterday in the keynote. We listen to our customers.
Getting data in was a big thing, we've solved that, as far as I'm concerned. We'll be able to expand in a lot of other use cases, move farther upstream. It really, at the end of the day, it's about how that helps us sell a lot more solutions, and we're convinced that it will help us sell a lot more solutions in the marketplace. It's not a standalone product. It's an ecosystem play.
Thank you. Ryan Mulinchuk from Bartlett. Quick one on the going back to your first slide, when you talked about the data, where you capture the data. You have SQL, you have key-value store, and blob storage. Is there a primary store, or how do you decide to dump them into the different vehicles? What are you doing there? As you're on the cloud, did you go with the cloud guys or are you staying neutral with kind of
We use cloud services obviously for that, right? There are core services that we use from Amazon and some from Google to store that data and replicate it, right? We use their services to replicate it. The truth is, a layer above that is where sort of all of our secret sauce, all of our indexing goes, all of that kind of stuff. We take those complicated indexes that we develop that are really the business logic for what we do, and then those get propagated down and stored in either a SQL database or blob storage or a key-value store, depending on what the business logic looks like, right? These are decisions that are made at a product level, for each service, depending on how it needs to store data, right?
It's stored the way it needs to store based on performance or based on other aspects of how we want to store the shape of the data, really. We decide how to store it based on that. It's really more about performance. We've simplified this way down, right? We have caching layers between all of this stuff, so things are fast to load and you can access it quickly. Couple of tech guys in the back here that are laughing at me for even showing that slide. There are a bunch of layers in the middle here. Our business logic sits above that, and we do a lot of our own indexing that makes things much faster and able to find data much quicker, and we do some in-memory stuff that our secret sauce is kind of built on.
Just to sort of second part of your question is that, currently we're running on two commercial clouds. It's all either on AWS or on Google right now. To Jeff's point, we can run cross clouds even, in terms of how these services are deployed. Anytime you sit on one cloud a while, you start to develop a few dependencies. In general, the fact that we're settled on Docker and Kubernetes, we can move from cloud to cloud. As we grow, I envision a day where we'll be sitting on different clouds for business reasons, not only cost, but competitive things for certain customers and things like that. That day could come, and because of the architecture, that's not going to be a big spend to move from cloud to cloud.
It's been built so we can move from cloud to cloud and use the best of what each cloud has to offer. We're always going to use third-party providers for that core infrastructure and for computing.
Hi, thanks. Rob Oliver from Baird. Quick one for Jeff and then for Marty. Jeff, can you talk a little bit about the technological challenges around the WorkSpaces product, and where we are right now with that? Then for Marty, certainly workflow, collaboration, and compliance are key themes with all of our public companies. So maybe you can touch on what the WorkSpaces offering gives you guys in terms of the platform and how much of that is pull from customers. Thanks.
Yeah. I would say the biggest. There are two aspects of the technological challenges around WorkSpaces. The first one is an easy one for us to solve over time, which is transferring our customers from the way we used to store them. We have a lot of customers that have multiple accounts for us, and now we want to get them into the same organization under WorkSpaces. There's a technical challenge of making all of that stuff happen. That's a big one, but that's a one-time transition thing to worry about. The second big one for us is sharing data between WorkSpaces, right? This is a huge thing. We spend a lot of time talking with our customers about what they want and what they don't want, right? The reason we have WorkSpaces is they want to isolate data in a lot of ways, right?
You want to get into this safe space, call it a whatever, a double secret probation kind of a space, right? You can go into and it is just the people that you want in that space that are there with you, and it's your own data, and you need to know if anything is shared outside of that WorkSpace, you want to know it, right? If you're going to share it outside, then we provide gating mechanisms for that, right? Our strategy so far has been, okay, if I want to share, let's say, a Spreadsheet outside of this WorkSpace, I'll allow you to do it, but it's going to be gated both on the push and then on the other end of it, if somebody wants to pull data into their WorkSpace, it would be a pull model, right?
We can gate on either ends of that, which is a technological challenge for us. Those are things that we work hard on. It's the sharing of data between WorkSpaces that's probably the biggest issue for us. People. We're hearing some really interesting ways that people want to share data. Just to see if we can conceptually restrict that down to a gating unit is a goal for us, because I think that's the way most of our customers see it, right? They want control. If you're in a WorkSpace, you want control of that WorkSpace. You as a user, not as an IT person, right? You can manage your own group of people, and you can manage your own data, and you really want to know if anything is shared outside that WorkSpace. That's a key thing.
Before, I just wanted to comment too on that. Sorry. Couldn't get the mic turned on. In terms of how we see workflow and Workspaces affecting our customers, to Jeff's point, to move across an organization in a low-friction way, we had to have Workspaces. We just had to have that so that this group could come on, that group could come on, and if it's all managed by one group within IT, there's another layer of communication every business group has to have on how they want stuff set up, and there's a delay built in there, and it just doesn't work. It became clear that this concept of Workspaces, which was developed with the help of our customers, was something that would allow us to spread across enterprises in a frictionless way. Obviously, it'll also get into how we price our products.
The Workspaces gives us a huge advantage in how we price solutions, Scott will get into that later. The number 1 thing, after Workspaces, and obviously, we had to rebuild this entire platform, and build better scale for all the different things we do, and better performance, and all those things. Once you get that done and you get this Workspaces component done, the number 1 thing that was requested was workflow. I want processes that are automated. If this number gets too high, I want to be alerted to it. I want to send it down to somebody to double-check the number. Those types of things now are still all email. They are. They just are still email. That's just a fact.
Manually, I have to check the number some time period, and if I see it's too high, it's extremely inefficient. We've had almost every use case we do asking for workflow for quite some time. We don't quite know everywhere this is going to go, but we know that this is something customers need, want in this day of compliance and trying to automate processes within organizations. This is something that's, once we are able to spread and then provide workflow, it's something that organizations are very favorable on.
How much of development resources have been devoted to the replatforming that you've described?
A large percentage, to be honest. It's been a pretty high percentage for us. That's a hard thing to measure. I've been asked that probably a million times internally. I think Stuart probably asks me that every day. You can ask him. He probably knows better than I do. It's been a high percentage. It will be coming off in Q1. That's the exciting part for us, right? It already is in a lot of ways, right? Like the Data Prep tool is new for us. Workspace is new. I wouldn't call that the Gen2 transition stuff. We do have efforts going on, our new audit stuff that's out, that was announced here at the conference as well. There are new projects going on as well now.
A big part of what we would call, say, getting us back to where we were for square one, and I hate to say that because we're way beyond where we were in our Gen1 app as far as capabilities go, call that parity if you want to. It's been a big lift for us for the last 2 years, and we feel like we're going to be through that by the end of the year. We feel really good about it. We've got another quarter to go, but we're getting there now, and we have customers, like we said, we have 60 customers that are running really some of our most complicated solutions today on all of the new stuff, right? Nothing but new, and we're getting pretty good responses back from them. They're pretty happy. We know we're really close.
Understand, we've been running Spreadsheets for 2 years, and that's all in the new platform too. The new platform isn't that green. It's pretty hardened already because Spreadsheets has been running in that for 2 years now, and we have hundreds of customers using Spreadsheets.
I will say, when you ask that question, there's all that foundational stuff that I get it, because it's not product stuff, right? That foundational things of being able to put a new service out, being able to monitor it, being able to trace the request all the way through it, being able to scale it automatically, all that kind of stuff, I know we don't get credit for, which we shouldn't, right? Because it's not a product. It's not something you go sell. It's not something a user appreciates necessarily until if something were to go down, right? Those are the things foundationally that you have to spend energy on as a development group, and we're through all that. We're long since through that.
To Marty's point, we've been on Spreadsheets for two years, and those sort of foundational things have been built, and they're there, and they work great. We feel good about that stuff. My only point there is we spend a lot of energy on that stuff. If you're going to go beyond kind of a one-trick pony for a company, you have to get good at these things, like to be able to scale and build other solutions and products. We have spent a lot of energy on this, but we feel like we're kind of at the tail end of that now.
Just to this whole platform thing, there's one other point I wanted to make that is really important from our point of view. The last sort of piece of the puzzle that we started to develop for this new generation was the presentations module. We started that in January of this year. We will complete it by the end of the year. Now think about that, how much is involved in putting together the presentations module. It's like building PowerPoint in some ways. Five person years are going to go into that. That is a minuscule amount of effort because all of the services are available to build it. The charts were there, the Spreadsheets were there, the user interface components, the outline, all that stuff.
If we can build something that complex with that small amount of manpower, obviously 2019 and 2020 will be where do we use that power and where do we build new things for new markets? I just want you to understand that that investment not only creates a much better product and ability to scale, but it also gives us great efficiency moving forward, building applications. Then the last thing is, I think that in terms of assets, we have one of the most talented development teams on the planet. For a company our size to build a platform like this is extremely unique, and it is a huge asset for us. These guys are top-flight computer scientists, engineers, and so on, and it's really built us a platform that we feel is going to be very powerful for the future.
Reflecting on the 60 customers who are on V2 now, you said kind of use cases. What's the most valuable piece of No battle plan drives contact with the enemy product, change with the kind of a related question to that, how do you overcome what I might expect Customers to move mission-critical platform that's supporting from something that worked fine and that works even better?
I think, how do you move it forward? The way you move it forward is by giving them some confidence, right? We work with them. We work very closely with those 60 customers. We work very closely with the 30 from the previous quarter, right? They had success, the previous 30 had success, then that begets success the next time. We double that number, right? We can go to 60. The only way that you're going to gain the confidence is when you get enough customers that are using it, and you can come say, "Okay, look, we've got 60 people now filing on it." After that, it'll be 200. Pretty soon, you're the laggards that are not on it, right? It's not up to us necessarily to move people totally onto that solution.
We've got a lot of customers, the way we gain a lot of confidence, by the way, is by not moving them wholesale over, right? We've got, I think it's 850 customers that are using Spreadsheets, which is our replacement for our first generation Workbooks product. Those people are not all on They haven't used it for their SEC product, but they have exclusively moved over to our new Spreadsheet product, right? That's happening. We can do this in an incremental fashion as well. It doesn't have to be a wholesale move. This is all an incremental thing.
Just to echo what Jeff says. It's interesting, this isn't an ERP system, right? This isn't a huge, complex system. It's complex, but it's not like an ERP system. Our customers are pretty progressive. There's a lot of people that want to do this already. We've built transition tools that let them just move over quite efficiently. We're comfortable that the transition over is not going to be a big cost item for us. We're also comfortable that it's not going to be a big hardship for our customers because we've spent part of that talented research team building tools where they just take all their files, transition them over, and they come right up in a new app. Obviously it's never that simple, but it's not that challenging, frankly.
I'm very comfortable, the whole organization is very comfortable that transitioning these customers is not going to be that challenging. In terms of second question, what motivates them, or I guess it was your first question, what features do they like? They just like the performance. They like the feel. We have a much better UI. In full scroll, the whole document now. You can have multiple people in any part of the code or any part of the text, I'm sorry, or any part of the Spreadsheet. It's just a superior experience. These people talk. They talk and they say, "You got to try this. This thing's amazing." That's the type. We're not really, as an organization, that concerned.
It'll obviously be some work, the transition over, in its entirety, will take some time, we're not concerned about it, to be honest. In terms of features, it's like I said, just mostly just improvements everywhere, incremental improvements everywhere, performance, feel, user interface. When I use it now compared to Gen1, it's like a breath of fresh air. It doesn't take them long to see that. We're signing up people out here like crazy to convert next quarter. They go into the pods, they look at it, they talk to someone who's already using it. It's going to go fast, and I just don't see a lot of issues.
The other thing I'll add to it is, you start out by saying, "Hey, how do you get your enemies to come over?" The truth of the matter is, we work really closely with our customers, each one of them has a customer success manager. We've got a first-class, probably the best in the world in terms of success managing, just making sure that everybody is successful. These are not our enemies. These are our friends, right? That's a big part of this, is that we work in parallel with them. They want to see us successful. If you walk around at the user conference, you'll find that out. Customers, they are pulling for us, too. They do not treat us like an enemy. We do not treat them. It is the opposite.
Remember, it's a cloud environment, right? That's why CS is so effective. They log into their account. "There's something weird here. Could you log in?" They log in and look, "Oh, I know how to fix that." They fix it for them, logs it in the audit trail. When you have a true cloud app like that, it's really seamless how customer success works with the customers. Really interesting process.
Thanks. Matt VanVliet from Stifel. I guess, not to harp too much more on Workspaces, building on the last point of how do you influence the customer to come over, maybe looking at it from a different perspective. The last couple of months, there's been more talk about profitable growth as a company. How are you thinking about balancing your resources on whether it's building out these transition processes, training to help those customers move, versus now shifting your resources to building new products, new elements of it that can now drive growth going forward and sort of limit the resources of understanding there's going to be certain cadence for move. How are you focusing maybe on Q19 and beyond?
Well, I would answer it a couple ways. First off, I think that we as a company Our strength has been our R&D org, traditionally. We just build these world-class products. Something like a transition problem, we view that as a technology problem. We've already, to your very point, made most of the investment for transition tools. That's 80%-90% done, the transition tools. Now, that doesn't mean it won't be tweaked going forward. The other thing to say is that it becomes a customer success type of activity. It's not an R&D activity. By middle of the year, it'll be primarily a customer success, customer services activity.
Customers who have very large installations that do very complex things, obviously, we'll be talking to them, and some of those, they've even indicated they want to bring us in and pay us to actually do it all for them. That'll be part of our services activity. That won't touch R&D. R&D is we're in the midst of a process of figuring out where is the biggest ROI moving forward in terms of new products. That's why we brought in a pretty much almost a whole new product marketing leadership team. A lot of that team has been refreshed, and their job right now is to figure out where we make those investments that have a strong ROI. You can use this product for so many things now. Obviously, that's why we're bringing in the partners.
Some of the more smaller niche markets and for other things we don't want to chase, we want to enable partners to do that. That's why we're investing heavily in partners. The R&D decisions, we're at a place now where there's very little technical debt, much less than most of the tech companies I know of. After you go through all this and you come out of it and you have a brand-new platform like this, it's a great place to be. It's just a great place to be. Now I would speculate by mid to third quarter, half of our R&D team will be working on new stuff.
Terry Tillman at Truist. You said ecosystem multiple times, Marty, and partners, sometimes partners, sometimes larger company. You all had an interesting press release earlier in the year, though, with SAP and might be getting it to go to market. What I'm curious is with the work you're doing around next generation, what is the relationship with the next platform and what's going on with SAP, maybe an update on that? With next generation, should we see more opportunities or more volume and velocity of partnership situations like the SAP relationship? Thanks.
I'm sorry, I'm sitting. I'm not trying to be disrespectful. We went to, what, 11 customer parties last night, and my feet are still killing me. I sit down now and then, so don't take that the wrong way. Let me break that question to several components. First is the SAP. We're sort of getting into the afternoon's agenda, but I'll touch on it briefly, and then Scott's smiling. He likes that. Good. Not as much to answer this afternoon, but in terms of the SAP thing, I'll answer from a technology point of view, and then we can get into business issues later. For me personally, and for the organization, what we're doing with SAP right now is a huge net positive as it sits today.
We have very high-level attention from them on building a tight interface, native tight interface, no third party in the middle of us. When Stuart talks about TAM or we talk about market opportunities, having a very seamless technical data interface with SAP is just huge for us. For us, we can go to any SAP customer and say, "We can integrate seamlessly with your data, whatever data you want out of SAP, all the way down to the general ledger if you want, right down to any level of granularity." You only get that type of connectivity when the partner is fully invested, and they have shown that in terms of building this interface. We're getting support, very strong support. What happens on the business side, the options there, we haven't really explored that yet.
We're starting to look into that, and we're starting to go to market jointly and understand how the relationship like that would work. Regardless of what happens there, we've already hit a home run in my mind because we're going to have a seamless integration with SAP, with their cloud and their native, I mean, their on-premise solutions. They've built a really nice hub where you can get at all the data, and that's just huge for us. SAP. We're looking at interfaces. It's real interesting. Our own accounting team, I was talking to our Chief Accounting Officer, and she said that I don't think that's her title, actually. Is she here? Yes, it is. There you are, Jill. I'm going to put words in your mouth. Her antennas are up to see if I'm lying. I don't lie.
My memory is shot, so I'll give you that. Anyway, it was really interesting because I was just chatting with her, and out of the blue, she said, "Yeah, we're loving Data Prep." "Oh, that's interesting. Tell me more." She said, "Well, yeah, we're pulling in all of our expense data from Concur and our whole general ledger from Intacct. We're running all sorts of reports automatically into Spreadsheets. All the reports I get when I look at travel and expense spend and all these different details of metrics on the business, it's all automated.
Pull it right out of the core system into Wdesk, boom, out comes the table I get or the chart or whatever it is, and it's automated. Connecting with other, Jeff had this slide up there a couple back where it was showing who we were connecting with. We will connect as well as we can with the strategic players in terms of what enterprises are using for all their different types of things, Salesforce for customer data, obviously their general ledgers, expense data out of systems like Concur. Those are very important, and the APIs we built through Data Prep and into both into Data Prep and into Spreadsheets are going to enable that. Some of the companies actually are starting to embrace that at the IT level.
That's a really positive sign for us because once IT starts to embrace us and say, "We should promote this internally so we have high value to the org," that's when things can really go well. Did I answer that question, Gary? Okay.
Yeah. You guys announced earlier, I think earlier this year, that you've achieved FedRAMP certification. Looking into the end of the year here for the U.S. government, it seems like the budget's pretty large, but maybe unexpected this go. What are you feeling like that enables you from both attacking the federal market, but also going into maybe customers that are significant contractors for the federal government and having more cloud solutions within their organization that are certified and don't have to go through extra steps of security or firewalling?
Well, we have a whole part of this this afternoon on FedRAMP, Scott knows more about the federal government than I'll know about it my entire life, I'll tell you. I'll defer to him this afternoon on what the market implications are. I will say this about FedRAMP. If you're an organization in today's environment where cybersecurity is such a high risk, if you're not looking at how to secure your data and your customers' data at the highest level, then from my point of view, you're not doing your job. We have gone through a natural maturation process of a company our size. If there's one area in terms of our maturation we're leading, it's security. We have really pushed the envelope there.
We started when we were young, the effort it took to do our first IT, the SOC 1, that was extremely painful when we were small. Every one of these, we pushed it out as soon as we could. If you look at organizations our size, how many achieve FedRAMP at our sort of point in our evolution or our life cycle, it's impressive that we did that. That shows discipline within the organization. Even the FedRAMP people who reviewed our documents said, "You guys took this really seriously," a lot of people just try to get it through. I'm very proud of that from an organizational point of view, because we're really maturing rapidly, and we're ahead of the curve there. It's interesting.
This will have a big impact on the federal market, that's only one part of going into the federal market, I'm going to let Scott address that. In terms of what commercial, what any company thinks about our security, when we say we're FedRAMP approved, that's huge. They go, "Oh my, you're up at that level already." That's like if you're manufacturing, you say you're ISO or whatever. That just tells the customer that we're doing our homework to be here. The ATO we got from FedRAMP, we are very proud of. We're going to continue to work on that and go to the next level. It affects every single security discussion we have. Doesn't matter what, if it's federal government or if it's an oil company or bank. When we say we're FedRAMP approved, that's like, "Oh, wow. Great.
Let's move on." It's going to be a big thing for us. I'll let Scott address all the federal market stuff this afternoon.
I can add something from the technology side of it was when we first discussed getting FedRAMP compliance, there was some arm wrestling going on whether we wanted to do it or not. It has got a pretty negative connotation in the software world, in terms of it being really tough to get and work into it. We were saying, "Do we really want to do this? Is this something we want to get into?" We said, "Well, let's just take the first step and just see what it really entails. What does it really require us to do?" As we got deeper into it, we found that number 1, as Marty alluded to, technically we were already there for most of this stuff. They were kind of surprised at how along we were already. That was good.
The only things really that changed for us were some of the process requirements, and those were not onerous for us. Actually, everything that we had to do for FedRAMP, we were planning to do anyway. Just made us more secure and made our systems FedRAMP. It was not nearly the biggest lift. I was fighting it. I fought it before we actually knew what we had to do, and I'll raise my hand and say it was a mistake.
Jeff is talking about from the software side of things.
Yeah.
FedRAMP requires real continuous monitoring of your controls. You have to monitor it all the time. If you find one deficiency, you have to more or less tell on yourself and call the agency that monitors and say, "We had this deficiency. Here's our plan to fix it." Report when it's fixed. It's a very onerous, ongoing process. Ironically enough, guys put it into Wdesk and made even that process much easier. We have our whole continuous monitoring of controls all set up in Wdesk. It's another market opportunity. When you first hear about it, you go, "Geez, not another one of these things." It's actually very good. A company that gets that level of discipline is really much more secure, and it just shows a lot of maturity in the whole organization, every part of the organization. We're dealing with I screw up my acronyms.
GDPR, is that it?
GDPR.
Huh?
GDPR.
GDPR. I knew I'd screw it up. There's so many acronyms nowadays. GDPR, the European cybersecurity and information stuff. We adhere to that. Anything we see now in that realm, we embrace it and go for it because we know it helps us. These are well-thought-out programs. They're not shoot from the hip, let's make it more onerous for business. That's what someone like in our situation first thinks, "Oh, here's another one of these darn things." It turns out when you really dig into them, they're well-thought-out. FedRAMP's a well-thought-out program. As much as people complain about it's really thorough and well-thought-out. It isn't perfect, and they're working to make that better, but it's really good.
Is there much duplicative cost in supporting Gen2 and Gen1 simultaneously for customers?
There is some. There's not a lot, though. When customers get on the new generation, they pretty much turn off the old generation, except for having some archival of documents. We expect to see our spend, and we look at infrastructure spend on both platforms. Well, Gen1, that's a stretch to call it a platform, but we look at how much we're spending on each of those, and we expect that to just shift over time. I think there'll be a little overlap, but not much.
I'd say it's very low. It's maybe 10%.
Infrastructure cost keeps dropping. The amount we pay Google and AWS as a percentage, Stuart will cringe right now, is not that much. It's a big number, but as a percentage, it's a small number, really. There will be a little bit of overlap, but in my mind, not that much.
The thing I would mention is Gen1's pretty mature, so there isn't a lot of maintenance that has to go on there. The kinds of things you have to do are update the taxonomy to the current year for XBRL, that sort of thing. We've done that a number of times. It's pretty low overhead for us, so there's actually very little work that has to go on. It's not a big deal for us.
That's a good point. In terms of developer time, there's been very little going into it for two years. Didn't want it just sat there grinding away. The back end, the actual cost of the servers and the memory is, there'll be slight overlap there, but not a lot. It won't be that much.
Question from me again, sorry. Now that you have a full microservices architecture, you kind of have a next-generation product, it should be much easier to come up with new solutions compared to the Gen1. What do you think about the scope of what you offer to clients? You now do the reporting and SOX reporting, et cetera, but does this platform not allow you to go a little bit broader with clients and addressing some of the other issues around what you're doing?
I don't think there's any doubt that that's the case. The next frontier for us is, like I mentioned earlier, where do we go? If you want to look at the general collaborative workflow platform or that type of thing, you hear about people talking about collaborative workflow environments and things like that, it has really broad implications of where you could take it. We're trying to figure that out. Obviously, a company our size, we have to find use cases that are profitable right away. We can't say, "Oh, we're going to come into Exxon and cover everybody's desk with this." That's just not a feasible thing to try to do right out of the chute.
If you have enough successes and you get IT bought in, when IT is bought into the solution and they want to start to push it, which we're starting to see in a few instances, that's where things can get really exciting because they become your sales team and your installation team in many situations. They're trying to find work, right? They're trying to make sure they're valuable in the future. In the next few years, it's going to be us finding use cases that we can address with partners or without, in a financially viable way, and then sort of wait for the momentum to build or market to the IT people even, and try to build momentum from that side, too. That's really the strategy. You're spot on.
We would like to see this platform used for all sorts of business processes in the back office, even more importantly, we're starting to see some potential use cases where you're out in the revenue generation side of these businesses, and that's where the budgets exist.
I'll add to that, obviously one of the things you take into account when you decide what next new solution to build is, hey, how does this line up with technically where we're at also, right? The services that we've already built or the components that we built for the front end, you want to have 70% or 80% of it already there before you step into another market area to build a new solution, right? To give you one clue, we're probably not going to go do self-driving cars in the next few months, right? We're not heading in that direction because our service is there, and it's hard to step from a text document to a self-driving car. We could do it. It just would be a lot of work. Those kinds of things.
We'll be adjacent to our current solution space. That's the strategy, is to build out. As you build out a platform, you put in more components, you put in more core services, more front-end components and more back-end services, then you try to pick one of those solutions now that you've already got 70%, 80% of it there, and just build that last 20% to get you there. That is the strategy in moving forward.
We're going to talk about this a little bit in the afternoon session, it's a really good point that I wanted to underscore. As we evolve now to the next-generation platform, we think about that from a go-to-market perspective, part of the reason we've made a significant investment in product marketing that Marty alluded to, bringing in some really talented folks that can help us think about some of those trade-off decisions around the use cases. We're blessed with a lot of different things that we can go after, that is a bit of a blessing or a curse.
It's really important for us, we prioritize internally on what we think we can get after with our direct motion, where we need to be recruiting the right partnerships and relationships in the market that can help us achieve scale in some of the areas, be it via industry or geography or specific personas from a sales perspective, that we don't believe we're going to be able to get to as quickly as we need to grow.
Question for Jeff.
Yeah.
As the market for developer talent has heated up in the past two, three years, what are you doing to keep people challenged and excited as a relatively small organization relative to behemoths out there?
Sure. There's a couple things there. First of all, talent for us is the biggest thing for us, right? We want to keep our key talent, and retaining key talent and attracting new talent is number 1 thing for R&D, in general, is what we try and do. As you've noticed, and you've looked at our office locations, in the past, sometimes people say, "Oh, you've got too many," right? We're not built in Silicon Valley, right? We're not competing with the Silicon Valley crowd necessarily. We're spread around in places where we can attract and retain people. We pay pretty well, to be honest. We pay, for the most part, Silicon Valley rates all over the country, and we've got a couple offices in Canada as well. We pay fairly well, and we want good people.
I think probably the biggest thing for us is This is what we always say to our developers. I hate to say it here because our customers may hear, we're in the most boring area you can be in as a company, right? You're doing accounting stuff and financial reporting, and it's hard to find anything more boring than that to do. We use the most innovative technology out there, and that's what the software developers really love. They love being state-of-the-art. They love pushing the envelope and doing new things, and we'll continue to do that. That, frankly, if you don't do that, you're not going to keep good developers. They're going to go elsewhere. If you're not doing all the new stuff, and if you're not staying with cloud infrastructure technologies, you're going to start to lose your key people.
Those are the kinds of things that we do, is attract and retain in certain areas that are not as competitive as it would be in Silicon Valley, and then make sure that we're state-of-the-art in terms of technology and obviously pay well.
Culture's a big thing, too. We really spend a lot of time trying to make being a part of the Workiva team fun. I maybe talk about fun too much, but what makes humans happy is something I'm really interested in, read about a lot and talk about too much probably. You have to have key ingredients in your organization that keep people happy, motivated, and we work really hard at that. I'll just say that Jeff and his team is about as good at that as I've ever seen. Our R&D turnover is single digits, isn't it, Stuart? Stuart doesn't like that sometimes. He would like to see higher turnover. I'm just pulling his leg. That's not true. A stable, talented R&D team like this is a huge asset. It is our number one asset.
When you talk to the customers, they're thrilled about the product. On top of that, think about the fact that we are world-class in terms of release scheduling, that whole architecture. Hello? There we go. We do releases daily. We push releases all the time, and you can't name another SaaS B2B company that does that. Just can't find one. They have Brian? Much see.
Yeah, I'll add to that, too, while Martin is getting a new microphone here, is that we do continuous release. We have our warts, to be honest, we're continuously improving. I think that's the thing that people like in our company. We always challenge ourselves to get better. We don't sit still. We always try something new, just in terms of our internal process and the development organization continually improve and.
Test, test. There we go. Got it. I got it working now. Jeff is one of the few people in the world I know that's more modest than I am. He understates everything, the fact that we have single-digit turnover in our R&D org is a real feat, it really speaks to the culture, it speaks to the problems we let developers or need developers to work on, actually. Part of our day one commitment we made to ourselves was that we were going to be a customer-centric company, we were going to have the best technology. We were going to push the envelope all the time. You think about what we did in 2009, we went, and we're trying to sell cloud apps.
Back then, it was like the only other cloud app in 2009 that was in any of these companies was Salesforce. Most of them had never used cloud. We are going to always do that, because if you don't do that in this industry, someone runs right by you. I hear everybody on the R&D spend. We're going to work on that, and we'll talk about that this afternoon. If someone's spending 12% on R&D, I'm not going to own that stock, ever. It's just a philosophy we have, and we're different. We're very proud of our R&D team.
We get confirmation from all sorts of different sources that it's one of the best ever, and the customers just love those products for that reason, because we push the envelope all the time to make it just stuff that they can't get anywhere else and capabilities they've never had before.
When you look at the evolution of the platform, with starting the SEC, you're moving to next gen. I've heard the word one-stop shop quite a bit this week. Is that a new sort of mindset shift in your thinking of the platform longer term, an end-to-end platform across SEC controls risk? Is the new internal audit platform you announced this week sort of a reflection of that, which is integrated with SOX, enables you to bring in audit people, which can then buy SOX and sort of, as you mentioned, increases adoption across the entire enterprise?
Yeah. I lost mine now.
You lost yours. Hello? Back there? Hello? We lost the whole deal.
Yeah, one.
Okay, we'll pass it around. Like I tell people, it still goes back to what I said. We have to figure out where the ROI is in this thing, because we could build a cutting-edge GRC platform on this if we thought that was a good business decision. All the pieces are there. I don't know if that's a good business decision. Gut tells me it's probably not a good business decision. Scott is shaking his head. It's not a good business decision, but you could do it. The way I really look at it's a really comprehensive reporting, and to some extent, analysis platform that you can take a lot of different business processes and automate on top of it. Certainly we're going to look at where there's synergy in the markets, like SOX and audit.
To be truthful, a lot of the SOX customers would say, "Well, we don't want two different solutions. Please build internal audit." We heard that over and over and over. We think that the synergies of internal audit are going to help us get more SOX deals too. We're hearing, "Well, our IT controls, we'd like to be in the same system. We don't want to have to have a whole different system for monitoring IT controls." We have customers putting IT controls in our SOX product right now. It's the same thing. It's a database. It's a testing regime. Yeah, we're going to look for places where there's a lot of synergies between a lot of different business processes and try to settle there, build momentum, and get IT interested obviously, and get our partners interested.
certainly that is the strategy.
I was going to add also that from a technology standpoint, clearly we are pretty tightly integrated, right? Everything we do, we try to integrate. That's harder to develop software that way, but it has huge value for our customers. It's much harder, for example, to put a working Spreadsheets embedded into a text document or into a chart, right? Have that thing actually be fully functional. Fine, and yeah, by the way, perfect for extremely important to them, and they have the exact placement of the dollar sign. All that stuff is super important to our customers. Doing that sort of tightly integrated from a technology standpoint is harder to do, but it's what adds the huge value to a customer. It doesn't mean that we give them everything, all capabilities at all times in front of them.
They'll want to scope that down to whatever they need to accomplish the task at a certain point. It gives us the ability to add. We'll be able to build much easier because of that. Kind of the whole goal is to have it really tightly integrated from a technology standpoint, but then from a user interface standpoint or a product standpoint, we do want to separate those.
Your question was in part, how do we message this? How do we position in the market? We're going to talk a little bit about that this afternoon, but while we're on the topic, the point that Marty made about the GRC piece, yes, absolutely, we have more than 600 customers in the SOX space. Great business for us. Our customers in that space have asked us to build out additional capabilities like internal audit, like support for GDPR, for IT controls. Very interested in that space as an adjacency, and particularly how the information is shared from Core Wdesk into that platform.
From a general positioning standpoint, as we're going through the transition as a company, we're nearing the end of the journey from a next generation perspective, we're really asking our customers and partners to think about us more from an enterprise platform for reporting. Today, the market thinks of us as the world leader in financial reporting. Being able to connect back into that ERP system, being an extension of that value chain for us in a market where there's $220 billion being spent, yet companies are taking the output of that investment and dumping it into 35-year-old technology and passing things around via email and Spreadsheets. That's where we believe we fit best. Today that's integrating with back-end financial ERPs.
It could be supply chain ERPs, it could be customer relationship ERPs, really providing that enterprise value for reporting and highlighting the important part that reporting plays in the end of that process. That's really, as we go to market, how we think about the positioning.
Very good, thank you. I guess thinking about from an R&D perspective, building new products versus expanding these use cases, building on internal audit, how much more maybe time-consuming or man-hour intensive is building something like presentations that maybe for making it more robust versus spending it on perfecting the intricacies of internal audit versus SOX versus your reporting and maybe where you're, from a strategic standpoint, thinking about that on a.
Yeah, Marty wants to take it.
Let me just start at the top. You can get in a situation where if you're not carefully monitoring your R&D investments, you can be building stuff that just doesn't help you. I mean, for instance, presentations. When it's general release, the end of the year, the new next-gen presentations, there'll be a gazillion requests come in, and product marketing has to process those requests. In the past, we haven't been as disciplined as we will be moving forward about making sure every one of those has business value to our customers. There's a combination of things you do to manage that. Obviously, you want to see how many people request a feature. I've told many customers we can't do that because you're the only one that wants it. That's number one. You have to build the 80% for the 80%. You can't build every feature.
We have to have a more disciplined structure for knowing when it's good enough. We're not going to burn R&D dollars making it perfect and pretty and everything else because we're perfectionists. It's all going to be driven by product marketing in the future. That's it in a nutshell, and I understand what you're getting at. At the end of the day, we want to build a product that provides value up to a point. We have to have customer satisfaction up to a point. We have to have customer retention up to a point. None of those are 100%, right? Because the last tail of that percentage making a customer happy generally has no ROI in it. We have to make sure we go far enough, but not too far, and we will do that.
Thank you guys for the questions. We're going to wrap it now and ask you to come back here at 1:00 P.M., where you'll hear Scott Ryan talk about go-to-market, and then I'll finish up with a little bit on the finance side. In the interim, please go to the Wdesk lounge, which is right outside the main sort of event room. There's lunch there, and you can also scroll through and test drive some of the software demos and talk to customers freely. Thank you very much