ServiceNow Reviews

We use it for ITIL/ITOM catalog of services. ServiceNow is the CMDB for our organization, and we use the Discovery, Incident Management, Change and Project Management tools within ServiceNow to keep a centralized view of our enterprise. We have recently begun implementing the Governance and Risk (GRC) features as well.

Discovery has reduced, on average, the time to build/deploy devices within our environment by one hour. This may not seem like much but it adds up over time. It also reaps additional time savings with its ability to capture changes through subsequent discoveries over the life of the device. Discovery is the first piece in the CMDB chain for our organization, making sure that the device appears in the CMDB before it is needed (for, say, a change request).

ServiceNow Discovery is very valuable. It does, however, come at a steep cost of time and effort to implement it correctly. Do not be fooled into thinking it will "just work." Discovery, within any platform, requires meticulous planning and management to have it work for you. No discover solution is ever the "silver bullet" either, so plan to have more than one discovery engine implemented to cover your enterprise.

Where it could be improved is Discovery. This may sound odd since I just praised the value of ServiceNow Discovery, but improvements to its automatic detection, the breadth of devices, and the depth of devices covered, as well as keeping up with new technologies, are all essential.

Microsoft has caused some issues recently with its decision to move away from SNMP and WMI in favor of PowerShell management. ServiceNow will need to make changes to move away from these deprecated services and to discover these devices. Discovery engines universally rely upon SNMP to detect, at least at an initial level, what type of device they are talking to. Without SNMP, some other platform will need to advertise the device and its capabilities. Most applications offer API (ideally REST-based) connectivity and ServiceNow should expand upon its use of these connections.

The SaaS platform has been very reliable. ServiceNow has been one of the few SaaS solutions that we have chosen that has not had major issues. The agility to provide test/dev instances, and the seamless access provided by their support team, have been essential in allowing us to work with the solution.

As designed, the solution is incredibly scalable. It is possible for a customer to create logic, processes, or other rules that will hinder or limit this scalability, but that is not the fault of the platform. Having a knowledgeable staff and/or partner will reap huge dividends in the scale of the implementation.

Technical support is very good. Like in any support organization, there can be technicians who do not meet your requirements, but the vast majority of the ServiceNow support engineers have been helpful. As a side note, support is delivered via predominately Indian personnel. This is common in the IT industry, but we have seen it almost exclusively with ServiceNow support.

We used the CMDB that is offered within the product that we make/sell ourselves (Plex Online). It was not designed to meet the needs of a software company and we took the opportunity to move to something that was a better fit.

The initial setup was incredibly complex. I would pity any customer who decided to self-implement ServiceNow, unless they have experienced, dedicated staff for the length of the implementation. I was largely dedicated to the implementation of the CMDB, Event, Incident, and Discovery pieces of our implementation, with the help of an outside consulting firm, and it still took up a massive amount of my time to implement.

Many parts of the ServiceNow solution do work out-of-the-box. Being flexible also means being complex. Rarely can you just apply a change to all areas or systems. Screens (or forms) are unique to just about every part of the system, so if you want a uniform look and feel you will need to touch a lot of places.

Even if you do not think you will need an on-staff ServiceNow developer, you will want one. Many of the changes to the system are too involved for a standard admin to make (confidently) and there will be no shortage of ongoing work to keep this person (or persons) employed full-time.

We deployed in stages, bringing certain modules online as we were satisfied with the functionality. We are truly still implementing. The core of the system necessary for day-to-day operations was deployed in about one year. But changes and features are still being implemented. We continue to add and subtract from the system as we use it and as ServiceNow offers new or enhanced functionality. We also continue to develop integrations with other business systems.

In terms of our implementation strategy, we took on the system in phases. CMDB was first. This was perceived as necessary for all other functions for our organization since we are using it for ITIL/ITOM. The CMDB was manually populated and maintained at first, while Discovery was implemented. Project came next, along with Time Tracking. After that was Incident, Problem, and Change.

We kept to an Agile deployment methodology focusing on the small pieces needed to keep moving the larger whole along. Customization was kept to a minimum (where possible).

We did use a third-party service provider but it did not go well. I still could not imagine attempting to do it without them, but two years later, we are still replacing much of the work they did. There is a cautionary tale here of not going with the lowest bid.

The biggest failure on the part of our partner was with Discovery. They did not have the depth of knowledge necessary to get this delivered on time or, in fact, working in general. The level of effort needed to implement Discovery, in the end, dwarfed the rest of the platform. The partner absorbed the cost since they failed to understand exactly what it would take to deliver.

We have not done an actual ROI evaluation at this point. We determined that it was necessary from a business standpoint to change to a scalable SaaS solution and ROI was not necessary as part of the project scope. I believe that through Discovery and Automation we could likely create an ROI case. In other aspects, systems like Change and Incident may have introduced some toil to our process, but this may eventually become less of an issue as we continue to refine our process.

Isn't pricing always too much? We really do chafe at the ITIL licensing. ITOM is also pretty expensive.

We evaluated Service Cloud and ScienceLogic. ServiceNow really seemed to have the most complete offering.

If you plan on using Discovery, double whatever hours/manpower/money you had planned that it would cost. Do not let sales convince you that any part of the system "just works." You will ultimately end up modifying absolutely everything. Definitely look at using a reputable partner for implementation, unless you have a dedicated knowledgeable staff of ServiceNow users who have done it before (and not who just went through training).

We have 60 users for ITIL. We have provided limited access to our development and external management users.

For maintenance, we have two full-time employees. One is a dedicated ServiceNow developer tasked with customization and managing version upgrades. The other maintains the CMDB and Discovery process. I could see adding one more of each.

Deployment was an entire team effort, with different teams championing different modules of the application. At any given time, there were ten to 15 internal employees working on implementation with the assistance of five partner resources.

ServiceNow manages and maintains our ITOM/ITIL daily operations. It is a core piece of our environment that will only continue to grow. We have thought about removing the ITOM piece as we have not been able to implement or leverage it as we had initially planned, but we are still working on understanding what other tools we would need to replace the features and functionality. The primary limit we have on increasing usage across our company is the cost to license ITIL users.

The analytics - we like to keep track of how much work everyone is doing. We need to make sure that everyone is being efficient and being utilized. At the same time, regarding hardware, we want to make sure all the hardware is being utilized.

The other valuable feature is the asset management. It is the same thing, but with hardware. We want to know how much hardware - computers and anything else that we have in stock before we actually order them. Again, it probably boils down to the cost.

We're getting a good cost-efficiency. In my line of work, we deploy between 50 to 80 computers per day, break/fix new computers, laptops, you name it, we have it. We want to keep track of whether or not we need to replace a whole laptop, or just replace a hardware component that's failing on it. At the same time, we also want to make sure that we're keeping on par with the new technology, so that way we don't get left behind.

Most people are discussing UIs, but I'm a developer. I would say 80-90% of the people would appreciate that, that's easy for them, but from a developer perspective, it's hard for me, because for me it's clunky. Just give me a spreadsheet or give me a Notepad and I can write it down. For me, I would rather have that - give me an option to do that, maybe a CLI, instead of a UI.

Earlier today we were doing things such as merging data. What happened was I tried to merge one company to another. It's the same company, it's just a misspelled name. There was a bug - that there was supposed to be an undo button, but it wasn't there. It's one of those things, but then I asked a person how to do it, and they can't figure it out.

ServiceNow is such a complex piece of software. It's trying to be everything. The way I look at it, sooner or later, it's going to fail, because it's trying to do a lot of stuff. I can't say what or where, but it will. We've seen it a lot of times already with other products. You can't be everything, and that's what they're trying to do.

We don't really use much of ServiceNow except for the ticketing system, for now, so we don't have any issues. If there's a new hire we can add them fine, and it's quick. If there is new hardware, our admin just creates a new hardware form, and it's there, so I don't see any problem with that.

From my standpoint it's easy. As long as you attend an event where they teach you how to do it, you'll pick it up right away, because before I attended one, I had no clue how ServiceNow worked. I went to one for three days and now I at least have, about 25% knowledge of how ServiceNow works. I guess if you attend an event, you'll pick it up right away.

Right now we use ServiceNow, we use SCCM, we use Case. It's three different bits of software but basically what we use them for is as a reporting tool, like I said for the analytics of how we need hardware or tickets are coming in, but ServiceNow is mostly just for tickets.

Granted there's pros and cons in being everything that it wants to be. In our experience, we have Case, we have SCCM: sure, you're generating a report in SECM, and then you're generating another report in Case, there's a slight chance that the result will be different. If you have one thing, one software that's doing everything for you, the reports and the results will be consistent. I see that it's not done yet, it's not complete yet, but in the long run I also see it coming up with a bunch of problems.

The first thing is it's openness, since we're a Remedy shop right now. With Remedy, half of it's probably how we implemented but it's very closed off. It's really difficult to get anything new added to it. 

The big 'features' are the openness and ease of use. It's very intuitive, and it seems very straightforward to the point where, "It's got to be something I'm missing here." It's very simple to do things versus Remedy. I feel like, "Are there features missing here?" It doesn't seem hard enough to use. 

I went through training and everything. I realize that it does as much as Remedy plus much more. Openness and ease of use are the two big things right there.

We have Remedy right now, and currently, we struggle with process, as does everyone, so we're hoping that because ServiceNow is easier to use, easier to build and that we can actually get our processes up and running. I know personally you have to have processes before you buy a tool set. We tend to do it at the same time. The whole business that with this new tool set we can finally get our processes define, implemented, because that's really a struggle.

I don't have enough experience to really say a lot about this. Maybe, the one thing we're looking for especially, after being at Knowledge 16 is best practices. I'm looking at it going, "I'm a developer by training. I could cause so many problems with this system. I could create things in it that I shouldn't. I could use it for things that I shouldn't."

That's the one thing, it's like a Swiss Army Knife. I shouldn't do surgery with it, but I probably could. That'll probably be the biggest thing, is right now since we're new to it. We need to learn how to answer "What shouldn't we do?" It's so flexible to actually build things with, it's what should we do and what shouldn't we do that we need to determine.

We've got Remedy completely tailored for us, and now we have to upgrade but can't. So we need to figure out what we can and can't do so we don't run into the same upgrade problems with ServiceNow. We are working with Fruition Partners and they're doing all of our implementation. We're looking to them to help us with some of that.

We haven't used it in production yet so I can't really answer.

We're on Remedy now, and we implemented a previous version of it about 10 years ago. We made tons of changes and customizations to it. When it came time to do the upgrade we couldn't.

We're working with Fruition Partners to implement it.

If you have an existing Remedy installation I'd say, "Run, run away from it. Run to ServiceNow." To me that's a no-brainer. If you have nothing I would ask to get a demo to understand what ServiceNow will do for you. You need to really get into the whole ITLL realm and get some training. The thing would be is to realize what it can do for your company. What we've really done is realized what going in that direction can actually do for our company. Therefore, this is a far superior tool to implement that.

Again, it's a tool, it's not going to help you if you don't have that great understanding of processes. The first step would be is get some kind of a basic demo. Understand ITIL and really look at it and see how can help you guys.

We are a system implementor and ServiceNow is one of the products that we provide to our clients.

I have customers in the banking and retail industries that I manage using ServiceNow. I primarily use the ITOM module and don't use the ITSM features.

The technical support SLA can be improved because sometimes they take a long time to answer our queries.

I have been working with ServiceNow for five years.

This is a stable platform.

ServiceNow is scalable.

I have been in contact with technical support and I would rate them an eight out of ten. The support is good but the response time can be improved.

ServiceNow is very easy to set up.

The CapEx version is great.

This is a product that I recommend.

I would rate this solution a nine out of ten.

Overall, I've been satisfied with the product.

I've found the solution to be scalable.

The stability has been good overall. The performance is reliable. 

It's mostly an intuitive product. It's actually easy to understand. 

Technical support is decent. They are helpful when we have issues. 

The pricing could be lowered. It's pretty high.

We have had a few issues with the Agent Client Collector setup, however, that's probably at our end for some network blocking reason, or something like that.

Their GUI could be updated. It's a little bit old-looking right now. 

I've been using the solution for three or so years now. 

The solution is stable and the performance is good. there aren't bugs or glitches. It doesn't crash. It's reliable. 

The product is scalable. If a company needs to expand it, it can do so. It's not a problem.

Technical support has been fine. We are happy with their level of service in general. 

The price is high. However, I don't pay for it. I'm just an employee. I can't speak to the exact costs. That said, I know it's an expensive product.

While we are working with ServiceNow, we are looking into Device42 to see if that could be used for scanning our infrastructure right now.

While I have used ServiceNow for some time, I'm not an expert. I was sort of admin in a previous company where I worked, however, now I'm only, more or less, a user of ServiceNow. I'm a consultant. 

I'd rate the solution at an eight out of ten, based on my overall experience. 

One of the things that I've only recently learnt is how flexible it is and how much you can do with it that I wouldn't have thought of. I've only been using ServiceNow for a short time, so it's been great to learn about all the different stuff you can do with it. So definitely consolidating everything and just putting a nice visual interface and a nice visual experience to all the data and information.

Having quick easy access to information is crucial in any business but especially in the medical field. Real-time information that's it easy to understand is critical. In some cases, it could mean life or death for our patients, so just having that readily available and digestible and easy to interpret is critical. We have customized so much, so I think that might have contributed to the learning curve for me, just figuring out where the organization had put things and what terminology they use and where to look for certain things.

In the time that I've been using it, it's been a pretty great experience.

I haven't noticed any major issues. Again, I've only been there for a short period of time.

The entire time I've been here we've been using ServiceNow.

We have customized so much, so I think that might have contributed to the learning curve for me, just figuring out where the organization had put things and what terminology they use and where to look for certain things.

I'd definitely recommend that you take a look and figure out what their needs are really. What are their goals, why are they looking at ServiceNow in the first place, and just go in there and take a look and get a demo or something and just jump in and give it a look.

It's pretty great, especially being at Knowledge 16 where I saw all the different possibilities and all the different things you can do. I'm really excited to take that knowledge and get back to do more cool stuff with it. I'd say coming in I maybe would've said 7/10, but coming out of the event I'd say it's definitely a great product.

It's serving our end-user community, making it simple for them to order products, get service from our incident help desk, and perhaps even helping everyone across the globe because we have to stay connected somehow, and ServiceNow does that for us.

We've just launched the visual task boards in the last year, so we're still learning how to do that effectively. Right now, we're trying to do a comparison of what we do with our internal chat and using the chat inside ServiceNow, so a lot of things that we're still learning, and we're trying to break ground so to speak, so that we can get better.

I think I want to focus in on our assets. We do many things for studios, and internally, we use a lot of hardware, so we want to be able to find and understand where our assets sit. If there's a breakdown in communication, how do we service that? We've recently launched with one of the certified partners. How we do a better job in tracking those assets once it comes on location, and then it gets into the inventory. That's the key piece. It's how do we manage those assets, manage the cost, manage where they are, and make sure people have access to that equipment.

Maybe cost in one sense because when you make that investment from the other side of it, you're looking at the cost, but we've been having that ongoing debate. Empty glass could be your cost, but the full glass or maybe half full, or half empty. If it's half full, that means you're getting great things out of it. If it's half empty, you're so worried about the cost. Where are you going to trim. We're going down the path of, "How do we shape our roadmap so that we understand what that investment is going to do for us?" We're using the Champions Enablement Tool to help us chart that out. We have our own internal tool, and there's a lot of similarities, but I think what we want to do is just channel it the way ServiceNow is intending it to.

We've been on it since Calgary, so we were early adopters. We're currently on Fuji. We will probably move to Geneva probably in the fall.

Recently, we've been working with the support because they've been notifying us that there are certain things that may be slowing down our system. Right away, they've advised us that they have that ability to transition us seamlessly and to help us with our connectivity. There are some complaints internally still that we're trying to wade through, but overall we've been quite happy with it. Connectivity for the most part has been very good.

It's tremendous. Just recently, we rolled out the GRC module. It was specific to one of our security teams. At the moment, it was just to help them with their auditing, how they manage their compliance. Now, the part of the business has gotten wind that this is out there. It was demoed. Now, people are coming to us in that sense.

The Service Catalog continues to grow over a hundred service catalog forms, and people want to get rid of the old email in our office, department envelopes, the email, and the shoulder tapping. Now, we're able to centralize them through the portal. In fact, that's another thing, the portal that we have. We had user issues with the community portal on Eureka.

It was scattered. It was decentralized, so people in their own locations were tracking a certain way or doing things a certain way. Some people had barcoding systems and scanned assets, while other locations were just eyeballing it and logging it onto spreadsheets. We knew there's a problem, and just like the Chief Product Officer is saying, you want to automate where you can, and this is where we want to go.

We went out to go get a certified partner's product and cross-views, and they've helped us really just make it look and feel more friendly than when now you look at Helsinki, it's like right in alignment of where we are today and where we want to continue to go, so those are the other things that we have to weigh out.

I wasn't part of that implementation team. I came in to really get the program together because we had our enterprise architect team implement it. However, I think the guys had fun implementing it because they were looking forward to actually getting it in place, start using it, and start deploying it. 

Upgrades through the years have been pretty tough. We didn't get the sandbox right away, so it made hard on our users where we have to do all the testing and make sure we understand the differences between out of the cloud versus what we did with custom development. That took just a little bit longer in analysis and testing implementation.

First question I would ask is, "What are you waiting for? You've described to me all your problems that you're having. You're decentralized. You're disparate. You have all these things that are hanging out there. You don't have a way to communicate essentially through people. Come on board."

I took the governance class. It was a day and a half, and I sat at a table with people that had the same problems. We had a new implementation in the two months prior. We have someone that's on a competitor's application, and they've already made the decision to come in ServiceNow, but it took the management team to say, "Hey, we need to do this. We got to get better at what we're doing." Really, it's all practical in the sense of filling the need, and it's making it simple not only for the end-user, but if you saw the key note today, the backend where the developers and the systems. It's going to be really helpful for everyone.

It's right from our own internal processes, and matching staffing needs, and meeting the customers' needs, and then also ServiceNow coming in where cost has to be helpful to us. We know the platform is there.

The flexibility of the platform, being able to modify forms or modify workflow, building applications, utilizing basics that they've given you and being able to expand them to adapt to your own personal environment. Everybody says that "This isn't how ITIL works" or "You shouldn't be doing this." I'm like, "But ITIL is a framework, that's the whole point of it" so that you can ingest what you need within your environment. The product is malleable. You can change it around to do what you need to do. If you need certain configuration items or certain categories or certain subcategories, you can make it work for your environment.

I think the value comes from centralizing processes across business units. I've seen it where we started in IT and then we've brought in teams like library functions or secretarial support, security auditing for cybersecurity needs, making sure that your meeting a new type of governmental regulations, and things of that nature. I think it's not about just utilizing it in one particular business area. It's something that can be used across departments and I think that's what's best about it.

I think that the product has grown considerably over the last few years. Initially, I had some issues with just ease of use. I was on Fuji before I started at my current employer. I came in and they're on Geneva. Between Fuji and Geneva, it's just total rework of just the way that the UI looks. I think it's more appealing to the eye. I think that it is easier to use than it used to be. A lot of the having to code and having to know how to use java and all that kind of stuff just wasn't as easy for us non-coding type of individuals. Now that you have like the little point and click and more non-coding development, it's much better.

I think more progression like on the visual task boards. There are some things that are there that seem a little quirky. If you want to move something to a visual task board and when you go into it, it can't really update it in the fashion that I would like to see. You have to click on the number and then it opens up another form. I think a little easier updating processes to their visual task board.

I think a little bit more ease of when you're using the email flow. If I'm emailing something into the primary email address for ServiceNow that it could parse out particular things from the content of the email instead of just from the to or from or the subject line. That would be something that would be a value add.

Deployment, no. I don't think it's really deployment, I think it's more of individuals just getting used to if they're not used to something like ServiceNow. Getting used to the way that ServiceNow works. The concept of ServiceNow users and just getting to understand "Can you have notifications for this?" or "Do you want notifications for this?" Those types of things. I think it's hard when users are going through change whenever to modify something and then they take that grace period where they can get used to something new.

Not in the newer versions. I would say that years ago before ServiceNow really went through a big development of backend data infrastructures and fault tolerance. Today, I haven't really seen any of those types of things.

It's actually pretty easy. When you have a new IT person that comes in, you put them in the appropriate groups, you should sit them down, you kind of explain your process flow and how to utilize it. I think one of the easiest things with ServiceNow is the fact that when you log in, you're in groups and if you go to incident, my work, there's all of your work right there. Then the reporting function, it just takes it to the next level because you can go in and say, "Well, this might be my work, but how many things have I closed or opened?" or "What do I have pending?" Just different things that you can do with it to understand.

At my previous firm, we used Remedy. My current firm previously used something called HiQ Tracker or something like that.

There were other products that have been used before, but mostly IT wants to go into making sure we're using the best framework, ITIL framework, ITIL processes, making sure that you're using metrics and tracking and understanding where all of your resources are being utilized across your infrastructure so that you can get the best value out of the people that you have on staff.

For me, it was easy. I would say that for some individuals who are not very exposed to ITIL concepts, it can be very hard because they've never been exposed to the whole language, that whole concept, and framework of your problem, incident, and change. Most people, if they've never used ServiceNow before, continue to call incidents, tickets or calls or cases. For some of them to get used to the language, I think that that's where the implementation can get a little hard for individuals and they can get a little frustrated because not everyone is on the same language.

If you're really wanting to understand the time and the effort and the amount of work that flows through your organization, utilizing ServiceNow can help you really build that infrastructure out by tracking incidents and then taking incidents to problems and making sure you have a changed infrastructure, really understand how much downtime you could have with an environment. You can understand how much time the service desk is spending per call, how long your engineers are taking to really resolve a larger issue or deploy an upgrade. From building those processes and then having metrics and KPIs and dashboards, your executive management can really see how much time and effort and if you need more resources within your environment. I was able to show that I needed more staffing just from using reports out of ServiceNow and I was able to show how much of incident climbed within our environment and the gap between two years before and how large we had grown, just an incident processing. Showing how much downtime within our infrastructure had occurred and were we meeting downtime, requirements from our SLAs and organizational requirements.

I think I've been using it for nine years. I think it has changed considerably over the nine years and has gotten much, much better. You can't give something a 10 because there's always room for improvement.