. Duke: All right, folks. Today we have a very, very special treat for you. We are joined by our guest of honor, Mr. Paul, Charlie from Automate Pro. Paul, why don't you give a quick intro and tell us exactly what Automate Pro is.
Good morning, Rob. Uh, delighted to be here. Thanks for having me on. Uh, super excited about this. so Automate Pro fundamentally, it's a test automation and DevOps solution. Solution targeted specifically at ServiceNow, and our vision of what Automate Pro was all about was to create the world's leading platform to enable customers of ServiceNow to release and upgrade as quickly and easily as cost free and as risk free as possible.
that sounds like something I want. Um, and I, I'm excited about this because Paul and I have, done a showcase on Automate Pro before if you wanna actually see it happen. We'll have a link in the description below, to the video. Paul and I did a while back. It should be still a good video, right Paul? I mean, it's a couple years back now.
It was a few years ago. Enjoyed doing that. , it was a great video things have moved on obviously since then, but a lot of the while all of that content's still valid. We just do it even better and even faster now.
Yeah, I can't, like, this is why, another reason why I was dying to get you on the podcast because the whole concept of testing is evergreen because basically nothing out there is making it easy. I'll just go ahead and say it, like is a really scaled, like, has everybody really got. The, the sum of their platform in a f ready, and they're pushing that button every release just to make sure, or is that an illusion that we've built for ourselves?
I think the, the reality is that people are, are struggling to make it do exactly what they want it to do and give, give them the coverage that they need. I think there is, there is a place for a tf I think certain, uh, smaller ServiceNow customers may find that, gives them what they need. Where we really find the white space, for Automate Pro is, especially with large. quality focused, I'm gonna call 'em, or quality oriented organizations.
So you, you've got the Rolls Royce of the world, the Toyotas, those kinds of, where quality is inbred in their, brand. but also then you've got the, organizations where quality is, you know, is not an option. So highly regulated organizations, they have to follow strict processes around testing and verification of any change they make to their systems, their platforms. And that includes ServiceNow.
so what about quality for the rest of us, right? Like, um, you mentioned folks like Toyota, right? And they're just world renowned for their commitment to quality. They. Like literally invented a framework, right? Um, that the f that a lot of folks have adopted, um, because they've been so really good at it. Then you have like the other folks who like pharmaceutical companies and such that are regulated and so they need to have this validation from point to point to point, right?
And, and that's not an option either. But then there are the rest of us who d maybe don't fit into either of those buckets. Maybe our management doesn't necessarily, want or value like the Toyota letter level of quality and they aren't government regulated. Like, how do, how do we get that le that same level of quality, especially in something like ServiceNow.
Yeah, I mean, I think it's, it's equally a problem, right? No one wants to be spending money on testing, um, when they don't need to be. Everyone's looking for more efficient ways of doing things, especially at the moment, the macroeconomic climate. So we've gotta do more with the people that we've got, not everybody's, you know, has a budget to, get more resource in. So we need to be more efficient and effective.
So, The, the conversation with those sorts of organizations is, well, look, you've got a team of five people or 10 people, or wherever it is, and you want to be getting the maximum amount of those people as possible. What you don't want your developers doing in that situation, and we know that especially ServiceNow at the moment to ServiceNow developers are, are scarce and they're high cost. The rates are rising, you know, all the time. So you want those guys, those skilled guys to be.
Making configuration changes, configuring new modules, bringing out the real power from ServiceNow. What you don't want those guys doing is writing some code. in tools like atf, which need, you know, I think generally accepted, you need to be quite a competent developer to be able to use. So really maximizing the efficiency is the, sound bite for those sorts of organizations.
I just wanna go over one thing that's just, it kind of keeps me up at night. And it's not just the, the efficiency of it, right? Or how many, like how much extra oomph can I get per person who's focused on the testing? It's just how bad is it in the trenches? Like we have to, we have to upgrade basically twice a year. Right? This platform keeps growing horizontally, there's always some new process module rolling on.
There's always some new or trialed out tech that we need to like move to or think about moving to, and so you've got that. Twice a year and your stakeholders are all across the organization. So it's not like, it's not just, okay, hey, it, who's probably used to like stopping whatever they're doing and testing something.
Yeah.
But can you do that for hr? Can you do that for SecOps? Can you do that for, facilities management?
Yeah,
do that to your finance department? Like they're in the middle of close, right? They're in the middle of financial close for the organization and you're like, Hey guys, you gotta stop for 10 days and like
yeah,
test your stuff like, How did we get here?
this is the problem, isn't it? ServiceNow has been so successful now that it's rolling out, as you say, across the organization and everybody's jumping on and wanting the, you know, the latest module that fixes their enterprise workflow problems for their functional area. And that's fantastic. But what that's brought with it, as you say, is the increase in the potential for things to go really wrong in a bad way.
brilliant example, Rob, is the, we had a customer who, they had the HR module and they tweaked an ACR rule, nothing to do with the HCR HR module, or so they thought they tweaked this ACL rule, and it blew up HR. And of course Monday morning when it all went wrong, the head of HR was jumping up and down and saying, what the hell is going on? ServiceNow's not working. , and everybody was, you know, saying, well, we haven't changed anything. It, it should all be working.
And of course, it's the potential for knock on impact across those functional areas now, which is increase every time we roll out a new module. That's the, the risk increases.
can I just say a couple more things that just. Again, they keep me up at night and I'm hoping you got an answer. For us, this idea that what we build is invisible. It's not like we're manufacturing cars and we can like look at the car and say, what's that thing sticking out the side? Like that's not supposed to be there.
Yeah.
there's such visibility problems to the things that we build. And the second thing is that our consumer, who I would say a lot of the ecosystem expects the consumer is kind of. Very responsible for their part of the testing, right? So, oh, how did this get all the way to prod? Well, maybe you didn't test as much. And they're like, how are they? It's not their job.
Yeah.
They know what their job is. This is just like a tool about the job, and they're not the tools manufacturer. And again, the visibility, visibility problem. So you can almost see why things aren't documented as well, right?
Yeah. Yeah, I mean the, the, the visibility thing is, is a really interesting one, and that's why, you know, our approach to testing is that the system should be tested in a way that will. As closely as possible represent how the user's gonna use it. I always use, I always call it the Monday morning test, right? you are gonna make some changes.
You put a new release in on a weekend, on a Monday morning when somebody goes in and raises a. Critical security incident at nine o'clock on a Monday morning. They need to be able to raise that if the system hasn't been tested in the exact same way as that, US will do that on a Monday. There's a potential that it could go wrong and there'd be egg on the face of, you know, a lot of people if that happens.
So that, that visibility of, and the ability to be able to test exactly like the end user is really, really important. I think that's the first thing. The second thing is you're absolutely right about, the business are, they're, these are busy people, right? They're, they're busy running the business, um, making their, their functional areas productive as possible. They haven't got the time to spend a week testing, user acceptance, testing a new release, or a, an upgrade of service.
Now, they just, they just want it to work. So, you know, we've tried to build in tools. Inside of Automate Pro that help those people be able to verify that their Monday morning process is still gonna work, but without having to spend hours and hours or, days at the keyboard making sure it's gonna work.
Yeah. So that's a, that is a very good, and, and I think very, um, succinct value message, right? For Automate Pro. cuz when I think about testing, I think about a part of the project that is often under-resourced, right? And often, the last thing to be done and therefore the first thing to be squeezed.
Yeah, totally. I spent many years of my career as a project manager, and the number of times I had to go to the, the, the QA manager in, uh, in my project and say, Hey guys, uh, we're, we are running over a little bit on the development, can you squeeze your testing into, you know, a week rather than two? it's the thing that gives, isn't it? in a project, it's the thing that can get condensed, and that means that you're taking risk. You know, at the end of the day, that's what it's about.
And you don't really want to be doing that, and you can't be doing that in these, you know, large organizations, cross-functional areas. ServiceNow's come business critical. Now, Hannah, haven't we, as you know, let's face it, it's, it used to be an IT help desk tool. Service portal. if your mouse broke, you needed a new one, you'd request it. It's not like that anymore.
You know, businesses are running their, enterprise workflow, they're ordered, the cash processes are engineered on service now. It's critical.
so that's a good point, ServiceNow is becoming business critical. I like that. Um, because especially when I started, it wasn't acknowledged as such. I. And then after you built, say like change management on it, and change management was rigorously enforced, then you'd start to see where the business would be like, Hey, this thing actually can't go down. You actually need to put the change management system through change management processes if you want to upgrade it. Right.
And you know, and now like there's obviously so much more. That ServiceNow is running, uh, especially horizontally, with all the different verticals that are, that are out there now, that the business can't afford that downtime for ServiceNow. And
yeah, and, and you know, crucial part of change management, as we all know, is testing verification. You know, so, you know, as soon as a change goes to the change board, the first thing they're going to look at is what testing has been done and what, has this change affected anything else in the system?
and that ability to produce that evidence, especially in heavily regulated quality focused organizations, but not just those that, you know, everyone wants to know that their system is not gonna be brought down by this change that they're implementing. And that's why Fraud Rank Pro, you know, we weren't just thinking about, let's automate the testing, make that simple, easy, quick as possible, uh, with a hundred percent coverage.
But also what are the outputs that the change board need to be able to look at when they're reviewing the change and assessing the risk of that? And they're gonna need documentation. They wanna see the test plans, they're gonna wanna see the results. They're gonna wanna see what defects were raised and how they were fixed. They wanna see that UATs been, completed and acceptable, and they wanna see the documents have been updated.
So this is, you know, we were thinking when we, when we had the vision for Automat Pro, we had the vision that it was gonna help all. Team members within the delivery process, not just testers,
Right, because you're saying it's not, it is not enough just to test and hit a checkbox that the testing was done. You actually need the evidence that the testing was completed.
right?
Corey, how many change controls have you done where it's like test plan, will you write it in the ch the test plan and then maybe you put in the work notes like, I tested
Yeah, pretty
it and that was it. I just like, like broke into a cold sweat here. Thinking about, thinking about like, cuz ServiceNow really. I am sure there's someone over there, but I like, I just don't know if somebody has seriously thought about if this thing is so successful and people start trusting serious operational workflows with it,
Yeah.
let's put our life sciences technology on this. Let's put our, our manufacturing safety mechanism stuff on this, where eventually, some flows out there are so important that they are measured in lives lost per failure
it's happening, you know, it's because it's a, it's a great platform, So, it's becoming more of the business processes, the critical business processes are being run on it. And that, that's why we are super excited because the more critical it gets, the more you need to test. The more you need to assure yourself, the more you need to have control of the ServiceNow environment.
it worries me that ServiceNow instances and update sets can be moved around and, put in without, with very little control of what's going on, what versions of configurations, you know, in what environment, you know, who put them there, what evidence was there that they're, we, that they actually work. Have we verified that they work in that new environment and we haven't broken anything else? Scares me.
there without trusting you? You know what I mean? Like that zero trust reassurance. Like I don't want to have to just trust that you did it. I don't want to see evidence of it. And I think evidence, like we've talked about the scary bits of testing and kind of why. the status quo doesn't cut it.
but evidence I think is a great angle into what you guys do, Paul, and before we entirely screwed up the first recording and got halfway through with that, with the recording, you were mentioning something about , quality controlled organization has to even take screenshots.
Yeah, so if I think back to my first career, was an an analyst programmer for investment company and we were testing then a. Pretty much in the same way as I see companies still test today, and that is Word documents of the test script X, Excel spreadsheets of the R, the output outcome of the tests with, you know, defects tracked in X Excel spreadsheets. This is still being done today. You know, it staggers me that we walk into organizations and this kind of thing is still going on.
Yes, those things might be, you know, there's Word documents and Excel is maybe stored in Agile or something like that, but you know, this is still going on. We haven't really moved forward and the organizations that we. Typically talked to are the large, heavily regulated or, you know, quality focused organizations.
And they, they have really strict requirements for the, for example, the screenshots have to, in certain organizations to meet regulations, they have to have a u r URL at the top on the screenshot, and they have to have a date timestamp at the bottom. And the reason for that is because what they don't want is people, Being able to go into paint and sort of adjust a screenshot and take it two weeks after the test cuz they forgot the, you know, they should have done that step of the test.
These have to be, rigorously controlled, in an environment where you can't go in and tamper and just squirt a screenshot in just the last minute cause you forgot it. And the requirements are really strict. these are the kinds of levels of rigor that these organizations need. To meet their regulatory requirements.
and just following up on that. Right. Cuz I find that fascinating. how many of these organizations right, are tracking the, the resources needed to make that happen? And like, what that spend looks like and as a percentage of, of maybe their total tech spend or their total, total, uh, ServiceNow spend. Right? Like, it, it sounds like to me, in order to do that effectively, you need to devote a significant portion of your ServiceNow team to just that action.
Yeah, I, I mean, I think that's absolutely the case and, and what startles me a bit is that that's become acceptable, that, large teams of people and need to be brought together, especially for upgrades. I. And we've got a couple of organizations that we work with. They spend three months, you know, sometimes three months more with a, a large team. We're talking, 20, 30 people. Often it's provided by a ServiceNow provider as well. so they're, you know, these aren't, Low cost resources.
These are expensive resources. They're brought together. , all the focuses on upgrades. I think organizations are starting to realize, especially now that Automate Pro, you know, is starting to, grow and get a visibility in the market, I think people are starting to question. the spend on upgrades is too high. That money could be better deployed on, rolling out new upgrades of, modules of service now, or, increasing the usage in certain areas and getting more value from the platform.
It shouldn't be money spent just keeping up to date on the, the latest version. That's, not good spend.
that's one of the things that folks look at, when you start talking about testing because they slot testing in as like a maintenance kind of function and they slot development in, it's like the new and pretty, how can we get the next feature that is gonna create that value? But that, uh, sometimes I don't think that they really realize that testing is actually a really huge value creator as well.
Yeah, absolutely. it's interesting to see with customers that are struggling with upgrades. I was talking to a customer the other day and they said the great thing about Automate Pro is. Now that we have confidence that we can do upgrades at the click of a button, we will now move to twice a yearly upgrades. They were only doing once a year. Not out of choice, but because the whole damn thing was so painful and extraordinary, resource hungry and costly, that was almost enforced on them.
They were so exhausted by the upgrade process that they did one year Now. They're gonna move to two a year and that will mean they can jump on the new modules that Service Now. I mean, they were, they were going to knowledge events and going, that's fantastic. New module. But we are not on that version. You know, we're not gonna be on that version for a year and a half, so we can't take advantage of it. So, you know, that's when testing becomes a value add.
If you can test and upgrade seamlessly and quickly, then you can, get the value out the platform.
So we know that it's, it's something that's gotta be done. The more often you can get it done, the better. it's gotta be done thoroughly. But how do you take the effort out of the system?
this is the big problem especially with automated testing, , automated testing's been around for quite a while now. And what we wanted to do was to solve some of the fundamental problems with automated testing. And those typically are not around the initial build of the tests. You know, you'll see a lot of systems available, commercially that. Have you believed that you can create tests, , in, a matter of seconds? They're typically kind of click and record stuff.
I dunno whether you've seen those. You, you know, you open up service now and you say, right, I'm gonna record a test now. And you start filling in the form and it sort of tracks what you're doing. And then, oh, there's your, there's your test script. Uh, that all looks great until ServiceNow come along and change the ui. You know, and they're great. A great example of that was the next experience, right?
So if you've created your test using that click and record method, Every single one of those tests is gonna break when you move to the next experience So we wanted to solve that problem. We didn't like that. We don't even have click and record actually. And because of that very reason, it looks great, but it's not robust. And that's the biggest problem with test automation. It's not the initial creation, it's the maintenance.
You've gotta have a system whereby if ServiceNow upgrades their ui, those tests are still gonna work. So that, you know, any defect that's raised is not related to your script being out of date or wrong. but it's actually a genuine defect. in the world of testing that's called test rot. I dunno whether you've, come across that phrase, but it's, it's basically like the decay of your tests over time.
I love that turn right test rot.
Yeah.
might be a nice band name. Um, but, but one, of the things that I really just got from that is you don't really want your testing to, to also become like a maintenance sink. Right. Like, like you're, like, you're implementing testing to reduce the amount of time or automated testing, right? You're implementing automated testing to reduce the amount of time that your testing takes, but then you need to test and maintain the testing. That's reducing the testing and, you know what I mean?
Yeah.
so, how does Automate Pro like help us with that?
I I totally get that. And it was interesting, one of the projects I was worked on a few years ago before Auto Automat Pro I called them out and I said, look, you've got a project to test your project, you know, You've got an entire other project just testing, you know, test automation and there was code, and the code was under code control and config management and it had to go through a release process. I was like, oh my God, you've created a whole project here.
So anyway, putting that to one side so that the approach that we've taken is to. make it as simple as possible to update the tests in line with the configuration changes that you're making. and you've gotta do that, there's no getting away from the fact that you've got to keep your tests in line, you know? But, we try and make that as simple as possible. And the, the way that we've made that as simple as possible is, is with something called model blocks.
and these are reusable components, They're like, almost like procedures in, in code. So that you're not, creating the same, test over and over again. you've got a block of, of tests and that block may be used in, you know, a hundred different tests. Let's say it's, you know, how you navigate to a particular part of the service portal or something that would be a model block, and you'd reuse that model block over and over in different tests and navigate into the portal and get to certain places.
Now, if the navigation changes, and this happens a lot, we find with our customers. They might change the, top level menu structure of their portal. They might put another layer in or, rejig it. So in traditional sort of test automation, you'd have to go into every one of those hundred tests and go and amend that to, you know, to change it, to follow the, new navigation and automate. Yeah, all for it. I mean, it's horrendous.
And, the same we've heard, in atf because there's no way of doing this in atf. So you've gotta go in a hundred and as you say, that then becomes bigger than the actual change you were making. You know, that change to the navigation, I don't know, I'm not a developer, but let's say it's half a day's work, changing a hundred test scripts, that might be two or three days work, I don't
right.
so. You know, in Automate Pro, you go into that model block, you make that one change once you test it, and then that affects, that ripples through, if you like, all those a hundred tests. So, you know, what we've tried to do is bring new best practice and innovation into this world of test automation and solve these problems. if the tests aren't up to date, they're no use, and, you know, so that, that was a critical problem that we wanted to solve.
so it sounds like to automate pros to service now for testing.
Yeah. Yeah. we're a really innovative company. We want to, you know, we thought about these problems. it's hard for us cuz people see click and record and they say, oh yeah, that looks good. That looks really easy, looks great on a sales demo. in reality it's really not very good. So,
Paul, there's, one thing that I was super blown away by with the video that we did, is that if you're careful enough, you can hit two birds with one stone in a lot of ways. So can you talk a little bit about. automate pro as software delivery, not just testing.
Yeah. Wayne is my business partner. he's worked in the IT delivering projects just like me for, you know, 30 odd years. and we've involved, because we've done multiple roles throughout our careers, we've done pretty much everything you do in the software delivery lifecycle. Our philosophy around testing is that you should test as the end user is gonna use the system on a Monday morning. Right? So almost like.
Use cases, user scenarios, and it follows the process, the user will, follow through, on a Monday morning. Now, if you take that approach to building your test, not only does that make sure that on a Monday morning it's gonna work for your user, but what we realized was we are also capturing the screenshots as we went through that process step by step. When you come to create a user guide or a process guide or a training guide, Of that process. What do you need?
Well, you need step by step going through each step of the process, and you're probably gonna need a screenshot of what it looks like along the way. And you need a description of what you're doing well. Okay, so if we take what we've done from the test, the output of the testing, and we repurpose that, so we've got a clever function, which basically. takes that output from the test execution, all the screenshots, all of the descriptions, all of the steps.
Recasts that in the form of a user guide so that turns into a knowledge-based article, step-by-step instructions. Hey, Presto, you've just created yourself a training guide, user guide, process, document, whatever you want to call it. And it's branded. You can change the colors. It's got a contents page, you know, all the stuff. Now, I used to be a business analyst in my, one of my roles years ago, and producing user guys used to be a completely separate activity from testing.
And you would open up Word and what would you do? You'd go into, ServiceNow. You used to grab a screenshot, you'd put it in Word, you write some text around it, grab the next one. So we are saving, I dunno, days. I mean, I used to produce user guides. I used to take. two to five days to create, a decent user guide. You can do that in Automat Pro in a, few seconds with a click, on your mouse.
the great thing about that as well, going back to the test rot thing, you also got user guide rot, So as soon as you Yeah, I like that. I just made that up. Um, if you, you know, as soon as you change the system, you're at a field onto a catalog item. You, what's happened is you user guide is how date that instant that's done.
So, this stops that because you've updated the test to test that and you field on the catalog item, press the button, and you user guide is updated with all the new screenshots. So, you know, it's killing two birds with one stone is a great way of looking at it. we are trying to repurpose the information as many times as possible.
so tell me you love developers without telling me you love developers, right? Like that's just what I heard.
I mean, the thing is developers, are, you know, absolutely key in all of this. And what we want to be doing is making them as efficient as possible. So we all know ServiceNow developers at the moment. they're scarce, right? And everyone's chasing after the same set of developers. Uh, and that makes them high cost. I mean, I, I saw this way back in the eighties with sap, uh, resource where the, you know, the, the rates were ridiculous.
And the, I can see the same thing happening with, with ServiceNow. So what we've gotta do is make sure those developers are doing what they're. Niche skillset is, and that is configuring ServiceNow, introducing new modules, making sure that we are using it in the best way, you know, making it efficient code. And what we don't want those guys doing is writing tests. We don't want 'em creating documentation.
We want to create those, you know, take those sort of non-value added activities as much as possible. I think I saw a stat recently. That about 30% of a developer's time is actually spent developing code and 70% is on sort of non-value added moving update sets through environments. You know, trying to, handle all of that deployment stuff and things. So we, one of our aims is to make that 30% move that dial 30% to size. I know 70%, 80% get them really efficient in doing what they're great at.
I think on the documentation side, we're not gonna get much more efficiency because I just don't think it's being done right. I think it's a fraction of the ecosystem that does documentation, but here we are, how many years have I ranted about it, Corey? How many years? And it's a button away. It's a button away.
the value, right? The value here, duke, right, is just immense. Um, from a lot of different perspectives, right? Push button documentation, oh my God, Push button, test, deployment, oh my God. the ability to scale that and to scale the updates on that. Oh my God. And, and look, this is last piece, right?
that management doesn't really care about, but I'm, I'm still in the trenches and I absolutely love is that you're gonna take all the things that I don't want to be doing and do them in a automated fashion, right? Like, I don't want to be writing documentation, right? This, it's absolutely necessary. So I do it I hate moving update sets from instance to instance, right? Like, I hate running the test and writing the test, right? Like all of that stuff. I don't wanna do any of that.
and you're telling me not only can automate pro do that for me right now, I don't have to do it, which is great, but it's gonna do it better than I could anyway.
absolutely. Developers are developers because you love developing code, right? You don't love doing, you don't love doing documentation and, moving up there, that's not why. You know, we've got, we, we've got developers, uh, in our organization obviously developing Automate Pro, and they wanna be writing the code, and doing clever, you know, clever things with the configuration. this is the way that we see the world.
Let's get everybody in the software delivery lifecycle involved with ServiceNow. This. Remove the mundane, repetitive, the manual activities make everybody more efficient. and as a result of that, everyone will be happier and the ServiceNow platform's gonna be high quality. It's gonna make the users more happy cuz there's less defects in it. So this is, we're trying to aim for.
One last thing, Paul, you, you get HR shipped with your instance, but the second you start making your own configurations to it, you've essentially got like HR 1.01, right?
Right. Yeah.
we have things going, development, going in parallel, some things, reaching, prod before other things, even though they're started later. And were you mentioning that Automate Pro has something to help with that? with the actual deployment of the work?
Yeah, we have, and, and really it stems back to fundamental realization that we, we, uh, arrived at. So we under, we are looking at the ServiceNow environment, the different instances, development, test, staging, you know, production. And what's really interesting is that there's no real concept in ServiceNow of the release. To production route, The instances don't know about each other and they don't know their purpose and they don't know where they sit in that route to production.
So what we've done as part of our auto deploy module, which essentially moves update sets from one environment to another, um, automatically, so you don't have to mess around with, you know, moving updates. That's manually, but more than just doing that kind of a bit of rpa, really moving things around. It's the control around that, and it's the understanding of what products you are creating. So we have the, the concept of products, so that might be , hr, you could define as a product.
And then you've got the concept of product versions. So just as you say, as soon as you install version one of HR that's in Dev, you configure it. We understand that that configuration now is version 1.1 of hr and we un understand the update sets that make that up. And we also of course link that to the test that verifies what. Means 1.1 works, you know, what does good look like for version 1.1?
And then we understand, because we're automatically moving that product through the different environments, we understand where each of those instances is in terms of the version. So we've got version 1.1 on dev. We've got version one on test, and we've got nothing in production. And as we gradually make these incremental changes, we're controlling those.
Versions of those products and we know which version of which product is on what instance and whether it works cuz we've also got the testing piece coming in. And importantly, we've also got, which is the kind of nirvana situation. We've also got the linkage back to the requirement. The original requirement, so we can track that requirement is tested by this, it's in this release, it's in this instance, and we know where everything is and in full control.
Any organization that is gonna be using ServiceNow as a business critical or enterprise platform is gonna need that kind of level of control across all these environments.
Wow. So sometimes I feel like, you know, the, the proper question to ask is what, what doesn't auto automate pro do?
Doesn't make a cup of tea on.
Yeah, I mean, there's some smart teapots out there now, right? I mean, we could probably figure that out,
There's organizations as customers of ours that are realizing that what they thought was good was actually not good. They were putting up with, good enough. and they're, they're really starting to see that. I mean, we're, we are getting stats back now of. 90% cost savings on upgrades I think the number is 72% more test coverage. We've got 83% reduction in team size. And so these, you know, we were talking earlier about the team size needed for testing.
You can reduce that by 83% as this is big, big numbers start to come in.
this is paying for itself.
Yeah, absolutely. I mean, the r there are ROI is simple calculation simp because of the, you know, the sorts of costs involved. and we haven't in factored in which you should do really in a full business case, is the risk reduction side of things. So, you know, as we talked about before, if we go, if ServiceNow becomes business critical, if it's frontline, I think Coca-Cola actually use ServiceNow for their B2C app. Uh, I understand.
So you can actually go on your mobile phone now and buy a crate of Coca-Cola and have it delivered to your door. You know that if that goes wrong. That is, you know, as customer impacting and that's gonna affect Coca-Cola's reputation. So, we need to make sure those sorts of things work. So you can start the factor in, well what's the risk to reputation if that app is not available, for two hours while they fix a bug that was introduced in the new release.
You know, just on a cost efficiency and time saving. bases, it stacks up. If you're factor in things like risk reduction, then you know it's a no-brainer.
okay, and this is why I had to have you on the show, Paul, is just. It's a miracle app as far as I'm concerned. In the ServiceNow space. It's just talking about if I'm regulated, it's easy passes on my regulations, even if I'm not regulated, but I'm quality conscious. It's push button whenever I want, receive my test results.
It's ridiculous savings of labor, which means I can push this app even wider, and as the product owner, I can get more, victories under my belt so I can move on to my next thing.
Yeah.
then you finally get Robert to shut up for two seconds about the doom and gloom if you don't have documentation about what you've built. it checks all the boxes. It checks all the boxes. So Paul, if somebody listened to this episode and they wanna like, find out more, how would they go ahead and do that? , and we'll still have links in the description below. Everybody take a shot. we will have a link in the description below for how to contact Automate Pro. But what else could they do, Paul?
Yeah, , absolutely. I, I mean, I don't mind people reaching out to me. I'd love to speak about this stuff. You know, it's my, it is my baby. So, reach out to me in LinkedIn. happy to have a conversation. Obviously there's a website, www automate pro.com. loads of information on there. There's a contact button. the guys who were a super friendly team, we're all like me. I would say, and friendly. we love ServiceNow. We love everything about ServiceNow. Hit us up on the, the website.
We'll get you sorted. let's have a conversation about it.
All right, Paul, final War is yours.
Um, oh, you caught me out there, Rob.
My final
Was that.
episodes in.
It's brilliant. No, no. Thanks. Uh, thanks Aaron. I'm Rob. Super, uh, great conversation. Love talking about this stuff as I say. So, uh, anytime you want me on again, happy to, happy to come in.
Pleasure was ours. Paul. Thank you so much.
Thanks Paul.