IBM FileNet Reviews

We usually use it for document management in insurance or finance companies. Some of our clients are using the workflow for insurance cases. In these companies, FileNet is ingesting a lot of documents and a lot of insurance claims.

In terms of automation, we're using IBM Content Collector and we have started using RPA a bit. We're using ICC for some of our customers to ingest and automate the upload of multiple documents in bulk. We've just started using automation with RPA but not with the P8 system; rather for other functionality that customers need.

Ninety percent of our customers in the insurance industry, here in Israel, are working with FileNet.

Most of our customers use FileNet on-prem.

Filenet saves time in terms of clearance of insurance claims. Building a claim, from the customer side, is often easier as well. Not everything is perfect but it's good enough to work in most of the big insurance companies here in Israel.

Most of our customers are not using some of the most valuable features, like analytics, text search, or case or workflow features. They are generally not used by our customers because they're using other programs that are built-in to their networks. So if a customer has a workflow system already, he won't use the workflow system that is built-in to FileNet, although it's available.

It's the same with the content analytics. If the client has Kibana and Elasticsearch for searching text, they won't use that feature that comes with the FileNet P8 because it's only for the P8 system and not for the whole network.

The analytics in FileNet are too complicated and they consume too much infrastructure, memory, and CPU. They're too expensive to work with.

The usability, with the addition of Content Navigator, is not good enough. We're building our own interface, doing a facelift of the product, to satisfy our customers. People here in Israel are generally more Microsoft-oriented. They're used to the SharePoint look and feel, the Outlook look and feel. When they see Content Navigator and its features, it's a bit different for them. It's hard for them to get used to it.

Most of our customers and users are asking for features with a file-system-type look and feel. For example, when they open a folder in their file system they want to see the hierarchy of the folders. If IBM built something like other products, like M-Files for example, with a file-browsing feature, into P8, it would be a very good feature. Most customers around the world would use it.

That is what we're trying to build on our own. It would be easier for the customer to work with, in the same way IBM did with the Content Navigator Office Integration. There, you can browse through Office, the folders, and find things. You can drag and drop documents from Word, from Outlook, straight into the file folder in FileNet. If they would bring these kinds of features into the file system itself, without Office, it would be a killer feature.

We have been working with it for a long time. It's one of the older versions. Both it and the new version are probably very stable.

We generally don't have any issues with the stability of the system. That could be because we are too small. In Israel we have small companies and they don't have very complicated systems, like in the United States or Europe. We have medium-size customers, compared to companies around the world. We don't have 500 users at a customer's site so these are not huge systems. And they're usually in the same geographical area. It's not like there is a site in New York and another one in Chicago or Philadelphia.

There are no issues with scaling. It's based on WebSphere Application Server so it's very easy to scale up.

I've contacted tech support many times. I don't have very much good to say about it. The people in support are changing often so most of the people there aren't familiar with the product. They are always asking for the basic information about the system, even though we've worked with finance customers for many years and we know the product. We try to provide the actual error to customer support and to get an answer about it. But until they forward it to first-level support or engineering, we lose time. We are not usually satisfied with customer support.

We used to use M-Files and we are a little familiar with Alfresco and Documentum. Generally, the biggest difference between those solutions and FileNet is the price. The others are much cheaper but most of them are less robust and less stable than FileNet. Programming and manipulating other programs to work with FileNet is easier than in Documentum, as far as I know. Each one has its own best features. It depends on the use case.

The initial setup depends. If we're talking about a Windows-based installation, it's very easy. For other operating systems, like Linux, it's a bit complex. If we're talking about the whole P8 suite, it's very complicated. Documentation on how-to, screenshots, or step-by-step instructions are missing in all of IBM's P8 finance products.

Unlike Apple or with other vendors, where you've got to book, you can install it without any understanding of the underlying system. In finance, with P8, if you are not familiar with bits and bytes you won't end up completing the installation.

In terms of how long it takes, if we're talking about only Content Navigator and FileNet P8, a basic system, just the installation could take three to five days. And that's not talking about the implementation. It depends on the customer's site, on the operating system, on the database vendor. Sometimes the version doesn't support it. It also depends on the network. It depends on a lot of things that are not straightforward.

We have a standard implementation strategy that we use for our customers. We're usually asking for Microsoft Windows operating system and either a SQL or Oracle Database, and we are not doing any other complex installation configurations like a very sophisticated single sign-on. That's because it doesn't work very smoothly.

The ROI on the automation aspect of FileNet is a big question. I don't have specific numbers. We're dealing with between 30 and 40 customers here in Israel, and every customer is different.

Within the IBM DBA (Digital Business Automation) portfolio we use Datacap and we do see a return on investment from that. The automated document scanning and email scanning show a very good return on investment.

If you are a small or medium-sized company, I would advise working with other programs before you put money into FileNet, even though I've worked with it for a long time. If we're talking about a large company, for the robustness, stability, performance, and the growth — that you can grow it within seconds — I would advise using FileNet, without any doubt.

The performance is dependent on the database. Issues with performance are usually associated with databases issues. And, as I mentioned, the GUI of IBM Content Navigator caused a lot of issues with performance, but it's working well with our GUI.

I would rate FileNet at eight out of ten. It's not a ten because of issues like the flexibility of the system, the ease of working with or manipulating or programming and enlarging it. It needs to be more flexible to work with, not hard-coded and not closed like it is now.

We had several use cases. We used it for all of our loan processing and we took a 21-day manual process down to three. We also used it for all of our credit applications, and that took a 45-day process down to two. It housed about 4TB of data.

Performance was great. It was our system of record.

No one was wondering where a document was. They could all go and find out exactly what they needed, when they needed. It wasn't, "Who's got this and who's got that?"

The most valuable features are the interconnectivity and the collaboration. No longer do I have to wonder what system I need to go to for the data I need. I know it's in FileNet.

We wrote several custom applications for the users to dive in and be able to find the data they need. 

If there was more AI capability, into Watson, that would be a benefit.

Also, where are the users going to find the documents? Because that's a path we don't see. We know that they're looking at documents, but we don't know what documents they're actually going and finding the most, or where the bottlenecks might be. It would be nice if there was some interconnectivity back into Bluemix to say, "Ok, you've got a workflow problem here." That would be a neat feature moving forward because we've got a lot of users that would just say, "The system is not working." We had a few threads would get hung up because they were just constantly banging on these few documents. If that were the case, if we knew that ahead of time, then we could fix that, change the search sequences to make it more efficient. But we were blind to that until the users said it's not working.

It's extremely stable. The only time it ever had a problem was if we lost power to the servers. It never really went down.

It was very scalable. If we needed to add more processing power we could just add another server, turn it on, and then we had more power. We didn't have any scalability problems.

We did use technical support for a while. enChoice was one of the partners we used with IBM. They're a great partner. Eventually, I was able to hire enough of our own staff that we did much of our own support.

My experience with technical support was good. Any time we needed them they were right there for us.

We were all manual before and we knew we needed something.

The most important criteria when selecting a vendor are

• commitment
• partnership - we're in this together.

IBM doesn't succeed if I don't succeed, and I can't succeed if the product doesn't work well. If there isn't that mutual give and take, then no one succeeds. It's more about: Any solution can be thought of and fixed and made to work, but you have to be able to work together. If I just sign up and give you a check and then you walk away, that doesn't help me. I need to sign up and then you be there with me, through the process.

I was not involved in the initial setup. From what I understand, when they first set it up it was rather complex. They had some hurdles to jump through. It took about two years to really iron out all the kinks. We had a vendor prior to enChoice that we weren't successful with. When we found enChoice, things started to turn around. So it's important to pick the right partner.

They evaluated Documentum, they evaluated FileNet, they evaluated a few other tools. The company actually bought FileNet before IBM bought FileNet, so we had a contract with FileNet and then IBM came in and bought it. That was a good thing because of the innovation that IBM did bring to the platform. We were also a heavy C|MAN user and the content management on-demand system integrates well with FileNet too. With the new Content Navigator, it allowed for one pane of glass. So what IBM is doing in that area is just going to keep getting better.

I would give the solution a nine out of 10. If it were free I would give it a 10.

Go find an industry that is the same as yours, that is using the tools you want to buy, and find out if they're successful. If they're not, don't go with those tools. For example, I'm in energy now and I'm looking for people who are using Maximo, who are using the other tools from IBM, and I want to talk to them: Are you successful using these tools?

Don't do it in a vacuum, you've got to talk to people.

FileNet gives a lot of flexibility to the different problems we run into within our environment. It gives us flexibilities for ingest in multiple different ways of different products in order to store the content in FileNet P8, as well as flexibility of where we want to store it; the flexibility of creating metadata associated with your documents. It helps in the metadata, as well the security aspects as well. The flexibility is really the biggest advantage, I feel.

It helps put structure around unstructured content. Having the structure there makes it easier for people to find their content, in many different ways, whether it's in a mortgage space or some sort of other space. It gives us the ability to unify all the content and makes it easier to find.

Over the years, it's actually improved quite a bit. I do like what they are putting into the product itself. Previously, your process engines and all these different components were outside of the actual FileNet Content Manager product and now more of that is coming internal to it; that makes it easier to deploy. I like the fact that it's easier to deploy; upgrades are much easier.

From an improvement perspective, one of the things we often have challenges with is, within the FileNet product, changing properties or just general configurations within the product to support a business. That's been one of our biggest challenges, to automate that and make that an automated deployment, rather than somebody having to go in all of the time and click on the button to make that configuration. More automation in that area would probably be one area I would like to see.

I've worked with the FileNet product for over eight years.

I feel it's very stable. I've never had any real challenges with it.

It gives us flexibility to expand it and grow it and scale it really simply.

I've always had a great experience with technical support. I've used them enough that I know most of the tech support people by name. The good feeling is, yes, they recognize you as well and they understand your experience and where you are coming from. They are easy to work with, to get on the phone. Having that phone conversation usually speeds up the resolution time quite a bit.

We were previously using an earlier version of FileNet.

We were looking for the next generation, where we were. We had used FileNet Image Services, and we still use FileNet Image Services, but we were trying to move on, grow and get into newer technologies. That's part of the decision to do that as our strategy to move forward.

The product itself, I wouldn't say it was complex to set up. It was to integrate it within our environment’s current systems. Not every environment was ready to go or integrate into a FileNet product like that when we first implemented it. Eventually, we worked with IBM, we found the right solutions, had to make some product changes at the time and it worked out just fine.

We reviewed different vendors that we had worked with. Our organization is quite large, so we had multiple, different types of products where we are. Everything was analyzed, and we came to the decision to move on with FileNet. I think it has to do with the supportability. With our organization being large and IBM being large, they are able to support the types of volumes and types of challenges that we have. That played a lot into it, along with the fact that we do have some other IBM products already. That worked out well.

The most important criteria for me when selecting a vendor to work with is having that ability to contact them easily and communicate our challenges because you always have to have that open dialogue and collaborate and understand our challenges so they can suggest improvements for us. There might be something we have to change as a client of IBM but we have to have that collaboration in there so that we can get that done.

It was probably a year-long decision-making process, to fully go through it, because of the size of our environment. One of the key factors to actually move forward was the fact that IBM was able to change some of their connectors that work with our environment. If that wouldn't have happened, it might have been a different decision. Knowing that they were able to make some adjustments to the product; that helped.

In the content management space, we probably did not think too much about building a solution in house. That’s not something that we would typically do in our environment. If there is a product that does it, we tend to lean towards the product.

You have to look at the requirements you have for your business. Then, based on those requirements, look at your options. Look at the different vendors and different products and make sure you are making the right decision for your requirements in your organization, because the skillset of your organization is key, too. You have to have the support within your organization to have support for the product, whether it's the FileNet solution or some other solution.

My rating reflects the fact that there is always room for improvement. The product is very good; its stable; its served us very well for 8+ years, but there is always room for improvement. The technologies and the industry changes; having that flexibility. As long as the product keeps improving, it will continue to be a great product. I’m not sure I would give anything a perfect rating because there is always room for improvement. As far as what might earn it a perfect rating, I would almost have to use Watson to think into the future to tell me what I don't already know.

We've been looking at ways to analyze content that’s at rest or been sitting on file shares, SharePoint sites and different areas within the bank that people might not be aware of or don't really know how to classify it, and using different IBM tools in order to do that.

As far as existing services that we are now able to provide better than before, in general, it’s the find-ability for our content; exposing more of our web services to different applications that we support with our environment; give them that flexibility so they can actually find the content.

Regarding usability, I hesitate to describe it as simplistic, but it is simplistic, yet it can be complex if you need it to be. You can keep it simple if you need to keep it simple but yet, if you need a little bit more complexity in your business requirements, it's there and it's available.

For internal customers, I think the experience has changed a lot. FileNet has made it much simpler for our clients to get to their content. They understand that it's one place, now they know how to find it and it's more repetitive, rather than trying to search this way here and another way somewhere else. It's improved from a time perspective for clients, with our basically internal associates, to find content. It’s a great time saver.

We are not considering using or employing IBM on cloud, hybrid or box solutions at this time.

We do not have any plans to include mobile at this time.

The most valuable feature of FileNet is that it's a secure location for us to store our documentation, where we can put some rigor around it so people can find it and use it for an archiving type system.

Before, we would have things on server stores, hard drives, SharePoint. It allows us to have a central place that everyone knows that it's the official copy of something that they can go and access. FileNet has given both internal and external customers a way to access central data that they might not have had access to before. It allows access out in the field to documents that, before, they would have to get a paper copy of, sometimes.

That makes us more efficient, and saves us time and space.

We have Content Navigator and it seems like we still need to do a level of our own coding for plug-ins and so on. I'd like to see something a little bit more out of box, where there are plug-ins that we can get to do some of what we need to do, instead of having to build it ourselves, to make it simpler. Faster time to market is important and we're not really there.

I still think it's kind of expensive. I didn't notice that the cloud offerings were going to be any cheaper. Expense is probably another area with room for improvement.

Also, when I attend conferences, activities are shown that sound very easy. "Oh, look at this bright, shiny thing." But then, when you really start digging, it takes a lot more work to implement the bright, shiny thing. It's a nicer on a PowerPoint.

We have a lot of content stored on server shared drives, and because there is often no naming or filing standards, or metadata, users find it difficult to locate documents. Also, users tend not to go back and delete items per our records retention policy (which can be decades depending on the document), and content can continue to clog up servers. It is helpful to setup automation of records retention.

Users also keep documents on their computer drives making it difficult to share. We also have a lot of legacy documentation in file drawers that could be digital for easier sharing.

We have an enterprise license. We've been able to scale it up to large groups, as well as very small independent areas.

I don't actually put in tickets; my dev team does. Sometimes they've been a little frustrated with response times, especially for production systems. It’s hit and miss.

I was consulted during the decision process as well to invest in FileNet.

We were starting to acquire a lot of little, home-built document management systems. It didn't make sense to build something when we could buy a package that already had a lot of capabilities. We had already built, I think, three or four little scanning applications. It just didn't make sense to keep building. We had a hodge podge of stuff.

We acquired FileNet back when it was owned by FileNet, and it was much more complex then. You had to hire them to come in and do all the installation. Now, we can do our own installation. That’s because of the steps IBM has taken. Before, you had to hire them, you had to hire FileNet to come do it; you couldn't do it yourself.

Usability all depends on how it is set-up. FileNet itself is good, but it relies on just how complex does the business want to get.

We had an external consultant group that was coming in to do a significant amount of work for us. They were bringing in new technologies and they were the deciders of bringing in FileNet.

Nonetheless, when I select a vendor to work with, cost is very important and a level of expertise in a similar type of industry is helpful, peer experiences. If they've worked with a company that is similar to ours, it seems like there is faster ramp-up time for them.

Really understand your use case and capabilities that you're going to need, especially because we start out thinking it's just document management or content management, but then there's always all this other stuff. Does the product or product line have the ability to expand to the other stuff that the business wants?

I think Box has potential for us because of our interaction with external consultants, but not at this time.

As far as any pre-existing services that we're now able to provide better than we did before, we’re now able to provide better centralized access by using FileNet; that's where we're at, at this point and time.

We have plans to include mobile. We have folks out in the field, so we want them to have access to electronic documentation via a tablet or other mobile device.

It is our unstructured record archive solution.

It is mainly for internal users. We don't have end users for it, since it is only used internally. It has captures a maximum part of our organization to help with the efficiency in our records.

It has a process interface for a lot of different aspects of our business, which makes record archiving very efficient.

With our organization being in the financial sector, it has a lot of records: millions to billions. These were very tough to manage overall. A solution like FileNet has definitely improved our business. It keeps legal focused on what is required, and what is not. It has also helped the overall organization to focus on what is really needed, and what is not.

The product has helped with compliance and governance issues. There are some archiving policies which a financial organization has to keep. Our organization can keep up with them because of the IBM product.

It does help the legal team with their decision-making. They can hold and sweep the records based on legal actions required on any particular record. Therefore, it does help on the compliance.

It is very user-friendly.

In the next release, I would like to see automation and simplicity in the installation.

I feel that there is not enough ease on the initial front part. The ease and flexibility could be improved.

The technical support is good and efficient. I would rate it an eight out of ten.

In the past, we did have some other custom solutions. We have also tried some other vendors and they did not covering the platform 360 degrees. When we opted for this particular product from IBM, we saw that it has the overall coverage which is not being provided by any other vendor. This has improved our productivity.

The initial setup was pretty complex. There are too many options, and it can get a bit confusing.

We implemented it in-house.

It has not done much for operations costs because there are still operations involved in it. However, I still see a percent or two difference.

We did a PoC. We tried multiple vendors and compared them on different aspects. Based on the simplicity, ease, convenience, and many aspects of this solution, we made the decision in the past to work with it. We plan on continuing doing so in future.

Do a study and learn about the solution instead of jumping in and finding out about stuff later on. Attend conferences before making decisions and doing things. Then, you can make a smart call.

We haven't used any automation so far. I would like to explore the business partners on automation and find out much more about it.

While it does have business and case management in the tool, we are not really using it.

We use FileNet with our Cognos. We used to store all of our report history within Cognos, inside the content store. We've removed it from the content store and put it inside the FileNet system. Our users can still access their reports, but we don't have to store it in our content store.

Our main benefit is keeping our content store small, where our content store was about 5.5GB. Best practices from IBM is about 3GB, so we were way over that. By moving all the report history out of the content store, we're now down to about 1.5 to to 2GB.

Keeping our content store small. That helps our DBAs when they have to do the backups of our audit system, or of the content store. It's in SQL Server, and to back up SQL Server of something that size takes a lot of time and a lot of effort. But now that we've shrunk that down, it's a little bit more manageable to handle backups. I know if we do ever have to restore our content store - which we hope we never do - we're able to do it in a more timely fashion because it's smaller in size.

It does what we need for it to do. As long as it can continue to handle the volume that we're throwing at it, I don't think that it's going to be a problem.

We've been using it now for about four years. When we first went to it, we were having some issues, communication across the network issues, but we have had very few issues with it. 

We add stuff to it all the time, so it's scaling vertically all the time, and we haven't had any issues with it. We started out around 3GB, and we're up to about 5GB, and we expect to be somewhere at around the 10 to 12GB mark by 2020, just because that's the way our business is growing.

One of our account reps was very instrumental in getting us set up, but we really haven't had, other than network latency issues in the very beginning, a lot of issues where we needed to go to technical support for it.

We were using the out-of-the-box content store of Cognos, and we were just busting at the seams, so we had to come up with a solution. One of our account reps actually came up with the solution. We looked at a couple other things, but this was a solution we decided to go with.

The important criterion for us when selecting a vendor is mostly that it's going to handle volume. Our particular company is a distribution system, and so we have tons and tons of data, so we need to be able to handle volume. What we typically run into is, people give us a proof of concept, and it will handle it with a small use case. But when you try and explode that use case into something that we need, at the volume we're working at, many of those solutions just fall flat at that point. This particular solution, that didn't happen. 

It was pretty straightforward. Like I said, the biggest issues we had were on our company side, the network latency of moving that much data across our network at one time. Once we opened up a dedicated pipe for that data movement, we haven't seen any issues like that.

I'd give it an eight out of 10. Eight's not high, not low, necessarily, but it does everything we need. I'm not going to give anything a 10, but I'm definitely not gonna give it a one.

I would say you need to take a look at the size of your content. If you're going to use it to replace the content store of Cognos, you need to look at the size and make sure you're within best practices. Cognos is a product that's wishy-washy at times, and most of the issues that we've ever had with Cognos were because our content store was too big. Now that we've shrunk the content store, our Cognos is actually better. If you are looking at that, this would be a solution I would suggest to you, just to keep your content store small.

The primary use case is for collaboration of data files through CCM with IBM Connections. It provides an information sharing space and ability to create folders, thus managing the data. We are a worldwide company with offices all over, and there is a community room setup leveraging CCM with FileNet as the back-end. Therefore, all these users upload their files and collaborate on them in this space.

Now, it is performing pretty well, since I have upgraded to the 5.5 version. Historically, we have had a lot of problems with it. 

IBM FileNet has improved our organization with its single collaboration space.

• The ability to manage the content well. 
• To create folders (unknown: how much is on the FileNet back-end versus CCM front-end).
• The ability to tag data, as it seems to be indexed well. It is a good space to manage data, keep track of it, and organize it.

• A little better control into the ACLs of FileNet and databases. 
• A better administration tool. At the moment, we are using the ACE tool, which is a web-based administration tool whenever we have to deal with the FileNet back-end directly. It is kludgy and slow. They used to have a rich client tool that performed much better, but they discontinued it. I would love to see that tool come back in order be able to do more effective, efficient administration of FileNet on the back-end.  
• It needs better collaboration between the IBM teams on the FileNet and CCM sides.

Now, they are pretty good.

In previous versions of Connections 3.0, 4.5, and 5.0, I had a lot of stability issues. It gets a little muddy, because when I would open PMRs, sometimes they would be on the connections interface on front and sometimes they would be on the back. One of my challenges seemed to be that there seemed to be a lot of disconnect between the two teams. It is empirical evidence, but it seems to me  that the Connections developers leveraged the FileNet capabilities and the right hand did not know what the left hand was doing. There seemed to be a lot of disconnect between the two teams. I would bounce back and forth between the two teams for weeks or months just trying to get support on performance and stability issues. With the most recent upgrade that we did a year ago, these issues pretty much stopped. 

Scalability is so far good. We have great adoption with the tool. For the users that we are supporting to date, it seems to be handling the load and performing well. 

My experience with the technical support is mediocre. Often times, I would open a ticket and the technical support would label it as a FileNet issue, then send it to the FileNet team. The FileNet team would receive it and declare it a Connections issues, thus creating a back-and-forth between teams until I insist on getting both teams on the phone and fight it out. I am the customer in this situation. I just want the issues fixed and resolved.

It has gotten better. However, I do not have many issues with the system now.

I do not know about previous solutions, but the business decided that it wanted CCM, which leverages FileNet. Therefore, I installed, configured, and built the infrastructure.

The initial setup was straightforward.

The Connections teams, as far as the FileNet tool, were able to integrate it with CCM. They made it easy to set up. At the time you install Connections, you point to the FileNet installers and it does all the work for you. There are a few manual steps, but all of that is pretty well documented. It is a lengthy process and straightforward, but it will take a lot longer than five minutes. 

None that I am aware of.

Do your homework. Test it thoroughly (all the standard stuff). Do load testing to make sure it is a stable platform. Look at the life-cycle of the product.

Most important criteria when selecting a vendor: support. Not just technical support when you have a problem, but how long before you are discontinuing a product. Right now, I am dealing with Connections over an issue with Java going out of date and they are not supporting it very well. Their solution is to force us to upgrade. 

Look at the support aspects of the product from life-cycle of the product to technical support. Obviously, stability of the product as a whole is important. I do not want to be opening a lot of tickets.

The most valuable features of this solution are:

• The ability to do version control in the documents that are stored within the IBM FileNet solution.
• To be able to retrieve the history accordingly.
• To be able to work with those in a microservice environment.

The data can be integrated into a microservice architecture. It has allowed us to more deeply integrate the ECM or the FileNet solution into various aspects of our product, where we may need to provide user access to documents, that might be within FileNet. They don't need to open up a specific page or request mechanism to get to them. They can be embedded directly within the page itself or the app itself or within the context of whatever the user is doing. Thus, this just improves the overall efficiency and productivity of our organization.

We've actually had this solution since 2008, so we've had it for a long time; it's really not new to us.

The stability has been good.

Scalability is excellent and actually, it has been really great. It scales really well.

Previously, we were using just a file-based solution. It was not an equivalent solution and that was the reason as to why we moved over to IBM.

It really comes down to our ability to work together so as to address the gaps that we may have, i.e., between what FileNet needs to offer and what we need.

Ensure that the product itself matches the needs in your particular vertical. There are a lot of ECM products in the market space today that actually will vertically integrate into a given space. Whether it's the insurance, banking, manufacturing or whatever vertical that you're talking about, these ECM products will customize into that space so heavily, that it may supersede the existing functionality that you may have today. It's important that you look into what is it that the vendor is trying to resolve. Is it really meeting the gaps that you have? Lastly, does it extend beyond what you need it to do? These are all important factors to consider before selecting a product.

We always look for the ability in our vendors to provide their products in an integrated manner or that it will be integrated into our product seamlessly. This really comes down to the level of the APIs that they present. 

We look at various other factors before selecting a vendor, such as, Are the products themselves scalable and have they been tested out? What's the experience of the vendor in the space that we're in, i.e., for our specific vertical? Finally, we also look at the other customer recommendations.