ServiceNow Reviews

As I'm a developer, what I would say is that it's very flexible. The tool can be fully customized. You can do anything to everything, and so I would say that would be the key feature for me as a developer. I can do whatever the client asks for as everything is possible.

Let's say what happens is the customers want rapid delivery to get their operations. So for that they need something to be implemented, at least a vanilla system very easily. So ServiceNow's out-of-the-box features are so good to start with and then down the line, let's say they use it for three months, then it's very easy to just change things.

First of all, nowadays customers are moving all their native applications into ServiceNow. So it's definitely a kick start for them to start using the out-of-the-box features, and then realizing the potential of this tool, and then start getting their native applications loaded to ServiceNow. And eventually down the line after a few years, all their applications will be in ServiceNow. So now you have a single source of truth.

It's mature, but I would say that there are a couple of models, which I think in ITSM, they are not that mature yet. They're still doing it, and definitely even to customize it, but I am talking the out-of-the-box product. When you say ITSM, some of the processes I would say aren't that mature enough because I also have gone through the ITL training.

In particular I would say the SLA, but they have a new release. They have added a couple of features and that should suffice. That was the gap of the earlier version.

There were issues deploying Fuji, but not after that.

It's a very new system, and we see bugginess. In Helsinki we found that we were using one feature but we kept getting errors. I thought it was something that I did, so I spent three or four hours and I couldn't get my answers. So then I realized I basically re-realized when I spoke to ServiceNow people and they troubleshooted that it was a bug. In terms of performance it's very good.

It's very scalable. I've been working with two major clients and they're pleased with scalability.

The biggest part is the ServiceNow community. It's very active, and you can just type anything in Google, it's very easy. You'll get answers that way.

I have experience with HP Service Management. That's how I started my career. So in terms of the processes, both are good. While HP was also mature, ServiceNow processors have flexibility which is and that's amazing, and it's easy as well.

When a customer starts with ServiceNow, they go with it out-of-the-box, that's very easy. Just a couple of configurations here and there without any customizations. That's very easy in terms of implementation, and even customizations, it's pretty easy. It's smooth, and that's why we as product developers like the product, because it's too flexible. It's very flexible.

You need to look at what tool you're currently using, what gaps you have, and what pain areas could easily be fixed by the flexibility of ServiceNow. Based on that I would say, OK, why go with ServiceNow and not continue with the one that you're using.

The most valuable features at this point in time for me is the ability for tracking changes, for tying changes in the problem tickets together, tying incidents together to the problem tickets. The interaction between our user to IT aspect, from top to bottom, has been fantastic. Whereas users submits a problem because they have a problem, then we've got to find out if it's a bigger problem, or if it's bug, or SDLC, all this stuff. For me in my role at this point in time, which is changing, it's just tracking everything from bottom to top. We're making sure that stuff is getting done and then communicating back to teams, and it's a full loop.

ServiceNow was implemented over seven years ago. When I came on it was already implemented and I didn't have much of a role in getting ServiceNow changed, add-ins, whatever. They weren't reaching out to other companies. I was basically brought in to do monitoring buildouts, and get our very baseline infrastructure more organized.

I actually don't know. To be perfectly honest, I feel that just about any tool, as long as they have the same offerings, can be modified to fit the company that is attempting to use it. Take a look at an ERP solution. ERP has been around for a lot longer, to a certain degree than say ServiceNow and there is a massive amount of offerings. You can go with SAP. You can go with Oracle. I can't even remember the other guys' names. No matter what, you can always make them work for your company.

They may not have been the best choice for you, maybe there are pluses and minuses. Once you actually get into the application, you start figuring it out at that point it's like, "Well, it would have been better if we went with this, if we focus more on this." The thing is once you get an offering, you still have the ability to go in and configure it to your heart's desire. ServiceNow, it's the full suite of offerings. You have a lot more to sit in and actually go in and configure, as opposed to it's just another ITIL based application that I can sit in and configure.

I know there are places that they can do better at. While I'm not an administrator, I'm not sitting there configuring it, I know our person who does configure it does have his foibles. There are certain things that are difficult to get out of ServiceNow, which is why I suggested going to partner companies that are using ServiceNow already in your similar environment. You go to ServiceNow and say, "Hey. This is what we want to do. How can we accomplish this?" ServiceNow says, "You can do it any way you want."

It's like, "That's not an answer." It's like, "What should we do? We need guidance." Well, "No. you can do anything with it." Okay. That doesn't quite help me as a user, and future administrator, or as an executive. I'm sure it sounds great for an executive, but when it comes down to it, when it starts growing in your own environment, executives starts asking questions, "Why hasn't it been doing this?" It's like, "We don't know how to get that matured within our own environment." It really comes down to I think they can improve upon. They are doing that here with the networking, but for as themselves, have their own best practices to a certain degree.

To a degree, yes it's stable, but mostly it's due to data center issues on their side, or it's come down to network issues on our side. Since it's external, it's not internal, you're looking at having to deal with Internet weather, or data center hosted environments, or our instance had the issues, which is pretty rare.

It's been a long time. It's been a very long time. I think mostly they had a roll back of, not a build or an update. It was some type of data change, but I don't recall the details as it was several years ago.

I wouldn't know because I don't actually handle any of that aspect. Again, I'm still pretty new to actually having my hand in helping with ServiceNow. I don't have any of the hands-on experience. I'm more of a user at this point than an administrator of certain degrees.

I've used many other types of applications such as HEAT, or Remedy, any of those guys and a couple others that I can't remember the name of. They're all customizable to a point. Obviously, not many of those previous ones actually had a full ITIL buildout, or full offering as ServiceNow does. From my point of view and my aspect, I'm more concerned about user experience, and more concerned about backend experience as an IT professional coming in and trying to fix issues, and track said issues. ServiceNow has a much bigger offering in the sense that you've got new changes. You've got your problem ticket findings. You've got tracking for CIs, and the CMDB database, and sitting on the backend trying to provide all that data for those tickets, and whatnot, throughout the company. It makes it a lot easier. It's definitely a one-stop shop for being able to actually come in and help your users, but also help your full infrastructure, your backend.

From what I've heard, and all I can go off of is hearsay, it was pretty easy comparatively. I don't know what they were using before for any ticket tracking system, but that's initially what they jumped into was ticket tracking. We needed something to be able to support our IT infrastructure and our service desk. They also wanted to be able to track changes, and do that. It was just like, "Okay, we'll start with this, and start growing more and more." It turned into quite a bit more. We have definitely stepped up using a lot more of the offerings that ServiceNow has, mostly because we have to, to some degree, to be able to make things a lot more efficient. It's worked for us from what I can tell.

You want to sit there and plan. You probably don't want to turn everything on right from the get go either, because then you're just going to overload yourself. The same goes with any type of a larger offering that has hooks into other aspects of your infrastructure. If you turn everything on, you're just going to get overwhelmed, and not actually have proper resources to be able to handle those. It's always start turning things on, start figuring out what the workflow is, and go from there.

Make sure you flesh out what you're doing. Honestly, I see all the pitfalls are the ones where you'll have a misunderstanding, or make a bad choice in configuration. If you believe that the offering is going to work for you, then you need to make sure you reach out to people who are going through similar situations, or rather it's three years in advance in your same situation. Find another partner company that has already gone through the preliminary, but not too far in the future because then you just look and say, "Wow. They completed so much. How are we ever going to get there?" A year or two, maybe three, and talk with them, figure out what their pitfalls were, a similar type company hopefully.

Most of our tickets go through ServiceNow.

Any tickets that we need to open in order to interact with other teams and make things happen go through ServiceNow. 

When I need to create an AWS account, I use ServiceNow. I need to use ServiceNow to request a new machine. 

We use ServiceNow for everything that requires us to interact with other teams.

They use it for internal communication across all departments.

What I believe works well is the chain of tasks that occurs when you follow up after completing a task. The subsequent chain of tasks, I believe, is valuable.

The interface, in my opinion, is not very good. It's very unclear where the status is and what steps I need to take next. I don't think the layout is very good.

The interface requires an upgrade. I'm not sure if I'm using the most recent version, which could be the issue. However, I don't have control over which versions we use, and I do find the interface to be very cumbersome, there is a lot of information here, and it's difficult to find what you are looking for. 

I find myself occasionally looking at the request and wondering if I already approved it or not because the status is a little strange. It's not great.

It's not very intuitive.

I interact with ServiceNow quite a bit. I have been using it for eight years.

ServiceNow is relatively stable. I haven't noticed any problems with stability.

I believe it scales well, but I'm not sure. I'm not familiar with the back end or how it's set up.

It performs well, I have never had any problems with performance.

The company employs over 40,000 people. I'm going to say that the majority of people will need to use it, or maybe half of them use ServiceNow extensively.

I've never had any contact with technical support.

Black Duck, Veracode, and SonarQube are some of the tools we use.

I wasn't involved in the initial setup because it was already in place when I joined the organization.

I've heard that some of its features are difficult to implement. I've never done it myself, but from what I've heard from other teams, it takes a long time to create a full flow. It's not quite that easy.

We have a team that handles updates, patches, and fixes.

I would rate ServiceNow a seven out of ten.

Our use case is around the core idle processes in general. We use it as a service management capability for managing intercom and so forth.

Primarily, we use it for incident management and change across the landscape. It is the virtual repository for our incident management processes. It gives us visibility about what's happening from the change management perspective across our CABs, including our enterprise CABs.

We find it good in general. Obviously, there are areas of improvement for every capability. As they evolve more, if they keep on adding more intelligence into the capabilities, it will improve. The improvement areas are more integration across the landscape and more intelligence for the overall capability of the solution.

We've been a ServiceNow customer for around five years.

It is stable. It has been one of the more stable capabilities that we have for operations.

It is an enterprise solution. Scaling has not been an issue for us.

We have got technical account managers for our account. They are available and responsive. When we go through customary support channels, they are responsive as well. There are no issues.

We did use a different solution, and there were a couple of reasons why we went through the transformation. One of them was to have enhanced capability and being able to do more with singular capability versus multiple capabilities. This was the primary reason for the switch.

For the most part, it was straightforward. We were doing a bit of a transition, transformation, and concept. We were transitioning from one capability to another, and we had all those at the right touchpoints from an integration perspective. Overall, it was relatively stable and smooth.

The major thing is to stay close to out of the box and limit those customizations. This would be the bit that I would share with others.

I would rate ServiceNow a seven out of ten.

Originally when we first rolled out, it was obviously the fact that we had full IT service management in one area. We were extremely scattered and had many different tools all over the place and none of them were integrated. That was our initial sell feature for us.

As time has gone on and ServiceNow has evolved and matured, we are loving the ease of the product. Each year, each version, each release they come out with is all that much more configurable for us. One of the biggest things for us is the fact that we've had the opportunity to be a partner with them and have had the opportunity to have some input and feedback on their product to begin with and have seen some of that that have come to fruition. In fact, I just saw a demonstration and there were several things that I know were a part of suggesting and the input that they received from their customers.

I hadn't really thought much beyond the improvements that I'm seeing that they're putting out in Helsinki. My organization is currently on the Fuji release. We were going to be upgrading to the Geneva release in July. One of the things we were coming here [to Knowledge16] specifically to look at is jumping on the release and going straight from Fuji to Helsinki. Considering some of the things that I just saw that they rolled out, I'm going to be pushing pretty hard for that.

Many of the things that we felt needed a little bit more shoring up was their CMBD product and their discovery, they seem to have covered that in the Helsinki release. I'm not really thinking of what the next step is going to be at this point. I was wowed with Helsinki, so at this point I'm looking forward to rolling that in and working with it.

We implemented it back in 2011.

I like the scalability of it. We need an instance that we will have it within 24 hours. In fact, we have several instances in the Cloud. We have our production instance, we have a test instance, and we have four development instances.

I'm not necessarily involved in the day to day support that we would have to reach out to. Our architect is more involved with that. However, I do know that I have been the contributor of a few of the bugs that have been found. They seem to be very responsive, work with our developer and our architect team and work through the issues.

When we started out, we did it in phases. Our very first phase was the change management application in a very condensed version of the incident management application. Phase two rolled out in late 2014. At that point, we went to a full incident management application. We revamped our change management application, rolled out problem service catalog, discovery, our CMDB. We have quite a few, some 38, applications that are currently turned on. They were pretty basic and we've been over the years developing and expanding those.

I'd have to say it's the CMDB. When we first started our project it was a security focused project, and what we wanted to do was bring in all of the assets that we have on our network and know where they are and what they're connected to. That was one of the first things that we went live with in December 2015, and it was the big benefit right out of the gate, the CMDB and out of discovery.

We didn't really have a good handle on where our assets were, the state of them, what software was installed, things like that. We had a very disparate group, the telecom group had their spreadsheets, the Unix group had their MySQL database, the Intel team had their Windows Server database, and it wasn't in one location. This brought everything into a single location so we could see how our business applications were related to servers, switches, and firewalls.

From us it started with the security perspective, so we're a regulated utility, so we have requirements under various Federal guidelines, so we need to respond quickly to various CERT advisory, government advisories for security events. We needed to be able to determine what applications, what servers, what work stations had these issues that were in the CERT advisory and so we needed to respond to that quickly. That is the real business benefit for us right now for the product.

I would have to say that the documentation on the knowledge site can sometimes be very confusing.

They had suggestions for how we could do certain things, and I guess what I was expecting was ServiceNow to push - since ServiceNow can do so much. I can code it to do anything that I want, and so the issue was that they should have pushed back more and said, well, that really isn't how you should do it, you should do it this way. It was more, "OK that sounds good" and they let us do something that we shouldn't have done, and then it bit us, so we ended up having to come back and we ended up doing basically our own home-grown SDLC process in the system through requests, and we're on version 3.25 of that. It just took us three months longer than it did to implement change. It was a struggle.

We have. We implemented some various complex ACLs and they've impacted our performance significantly, and we've had several incidents open to help with performance, and it's been kind of a struggle to get the ServiceNow support group to say "Yup, I see it's a problem, let's do this." Eventually they say "Oh yeah, it is." They've upgraded our incidence, they've added indexes to certain tables and things like that, it's just been a struggle, two to three months of constant back and forth to get our performance and our production instance the way that we want it.

We only have about 250 users, so other than that we haven't rolled out it to our 5000 employees yet, that's going to be in August, and that's going to be for incident problem and knowledge. So far for IT it's OK, other than those slight performance issues that we've had.

We have not used a solution at all, so this was the first.

Honestly, if we wouldn't have gone as far outside the box as we did, it would have been really easy. Change was actually the easiest thing that we've done, and doing the configuration management stuff, the auto-discovery, I would say that we had a great approach. We decided to go discovery by class of device, Unix servers, Cisco switches things like that, and we had a 13 to 14 week process to go - it was like September, October we began, and in December we had our CMDB pretty much good to go with our 6500 servers, workstations, and Cisco devices and it was actually functional in December in about four months. Which according to ServiceNow, is a rare thing. Not a lot of people get it that complete within four months.

We actually had ServiceNow as our consultants. The way that the consultants at ServiceNow approached our implementation of change in request, we actually had to redo it a couple of times because there are so many different ways you can approach change in request items, in the catalogues themselves, that we ended up having to do two or three different redesigns to get to what we wanted. I guess I was kind of expecting when we implemented with ServiceNow that they would know the platform inside and out and they would have a "this is the way that you should do it", and that was actually kind of a shortcoming that I had in the implementation. That was kind of a shortcoming for us. Love the product, but it was just that the development phase was a rocky three months that we had.

It's a great platform but it's so open that you can get bogged down pretty quickly in trying to make all of your customers happy. I would stress try to keep it out of the box, vanilla as possible, and you'd actually be a little bit happier, let the system do what it's supposed to do. I really like it, I really, really do. There's a lot there. We've struggled on some things, but I think overall it's a great platform for our company.

Flexible platform to build applications and to extend our service management. We have the normal idle processes we actually implement and ServiceNow provides good value in supporting these processes.

For us it's beneficial because we are switching from a single provider environment to a multi-provider one. We use ServiceNow as a platform and it's described as really flexible. It supports this transformation for us and now we are in the position to deliver our own multi-provider application platform. They are no longer hosted at our providers, so we can switch the provider in an easier and quicker way, and we are in a better position to discuss prices for different services because we can offer the whole platform and framework to our customers.

Last week, we had a discussion with the support leader at ServiceNow, and what we miss a little. ServiceNow is growing really fast, so they have two versions per year, and for a company (or for a large company), I think it's really hard to switch to the next version because you have to migrate and test things. What's not so good for us is also the support for problems and regressions. If we are using an older version and the next version is coming out, we always recognize if we open an incident, that we get an answer which in most cases is to switch to the next version. That is not so good for us because we know that we could switch to the next version but we have to perform a lot of effort that it's not too easy to do that. So basically we're looking for answers other than just go on to the next version.

ServiceNow supports the two version or three version support so if we are in the actual supported version we know that it's really hard to fix something in the current versions because the architecture is different from the new one but we would wish to have more fixes for our versions.

Also, the wiki is good, but it could be a little bit better. It is lacking all the information and could be more in-depth. We are not on the newest version actually, but we will switch this time because the one we're on is not so good. The information about the included features in the next release is lacking.

They said OK in December and we got access and then I received an email with, "Hey Geneva is available." And we were really waiting for that because we would like to upgrade. Then I go into the support system, try to upgrade, and then I get an email which says that I have to wait three days, then I received an email about an hour later, and they said Geneva is available and they have to wait three days before my upgrade can be done. This process should be better.

There were no issues with the deployment.

The instance is always up and running.

We're not running out of space so the platform is cool and it's running. It's good for us because it's in the cloud. We don't have to put effort in to look for things. That is why we decided to choose ServiceNow as a cloud provider.

We have support and so we bought a service and if we are at the end of the space or something like disk space, then I think ServiceNow contacts us to let us know so I have no need to look into that.

You can do a lot of things in different ways and that is why we define some coding guidelines, because the best practice are not enough to restrict some implementation partners or our self to bring implementation. For us it's really important to do that to the GIF guidelines, development restrictions, as it can be too open for us as a company because we would like to have the same result from different implementation partners. Everything works in a different way, you can do it like that or do it like this, but in the end if you have over 200 service catalog items I would like to have them built all the same way and look the same way.

After they're built and it's up and running, you have to maintain them, and if they are difficult in a lot of ways it is difficult and produces a lot of cost because if you have an incident or something else, you have always go deep inside of that and look, "Okay what is going wrong?" This can be prevented with more restrictions and standardisation.

With such a platform you can easily build and really quickly with new applications to help the business do things. We recognize also that you have to build and not grow too fast, because then it becomes a little bit of chaos. We also recognize from our business groups that say, “Oh ServiceNow, we do not have that, can we build that with this? Or that and that?" And you have a lot of demands and requirements you have to handle and maybe you have to block. We would like to have architecture throughout ServiceNow blocked from before we start building such small instances.

ServiceNow is a very good platform, but do not build up things too fast. That's what I'd say, because the problem is recognized from our companies and they say, "It's easy to throw things out into the business." But if you have a role model or such then you have so much effort to implement or rebuild those things during these things are in operational mode. I would say yeah, do it, but not too fast.

We use this solution for handling help desk tickets and tasks.

I like the workflow functions that are available in ServiceNow and the ability to actually integrate all of the information that you have such as travel tickets or assignment tickets for your team, onto your dashboard, depending on your setup, or if you create a ticket and a dashboard for your team.

When you update them in one place, it will show you updates in other places. 

I like that functionality.

ServiceNow has more capability and the ability to integrate other solutions such as Excel or tables.

You can put information in or export it out quickly, which is very useful when you have weekly or monthly reports.

When it comes to changing some of the features, I would like a little more leeway.

This may not apply to every version but there are certain capabilities that you have to specifically order a la carte in order for the developers or your administrators to have access.

Having more integration without having to pay the a la carte, otherwise, you have to put in a ticket and have it approved, and if not you have to find a workaround for the solution.

I have been working with ServiceNow for five years.

We are using the most up-to-date version.

I definitely like the scalability, because if you have a small company or if you have a large enterprise, It allows you to tailor it.

The scalability of it is very good and putting it on the server, makes it very useful.

Their technical support was overall helpful. 

A lot of it ended up actually being directed to the administration. ServiceNow developers and any support issues primarily go to them. 

When I was researching to implement ServiceNow for another group, I contacted technical support and they were extremely helpful.

They set up meetings and were willing to talk through everything, to help us meet or help answer questions for our stakeholders.

It was very easy to set up. It was very easy to make sure things were activated.

Once you get the base up, it's easy to start to build out.

There are templates that are available, and you also have the ability to create your own.

It's very quick to implement.

The cost is the only area that I have never been privy to. 

I know that the price is not too bad because people continue to use it and they are happy to renew their contract. But I've never been given the actual cost of it.

I would recommend that they have a meeting with their salesperson and go through the demo that they offer. I also recommend that they have their administrators or the people that are going to use it, sign up for the ServiceNow training that they offer. 

Those are the two things that I definitely recommend before they use it. Other than that, it's really integrated.

I still have my ServiceNow login where I can go to a test site and test things out before we put them into real production.

I would rate ServiceNow an eight out of ten.