OpenText Capture Reviews

I use OpenText Capture for any digital format or hard copies, everything that needs to be digitalized and stored in a content management platform. Before storing in any content management platform, I have to do processing. All this processing happens on OpenText Capture.

The processing capacity depends on how we set up our hardware. In one scenario, we achieved one million paper scans in a single day using IBML scanners. IBML scanners can be integrated with OpenText Capture. IBML scanners are very huge scanners, enabling the processing of one million hard copies within a day.

The best features include multiple channel capabilities such as fax, different file transfers, and paper scans. It can be integrated with multiple channels and can capture images, even from mobile devices integrating into OpenText Capture. Currently, it has introduced AI for data extraction and document processing.

OpenText Capture's impact on automating document-intensive tasks such as accounts payables or loan processing is significant. It has the capability to capture table structures or multiple line items from images, including line items and final amounts for invoice processing.

The main benefits of OpenText Capture are particularly valuable when capturing content and extracting structured or unstructured data. This product can be integrated into any point-of-sale system, Salesforce, SAP, or other environments, reducing manual data entry and related tasks.

This feature has helped organizations handle large volumes of data with precision, especially regarding resource consumption. The automation reduces human effort that would otherwise be required for classification and extraction tasks.

There is room for improvement regarding the data extraction and OCR capabilities in OpenText Capture, especially with the advancements in LLMs and various extraction methods such as CVision.

The product is not simplified, particularly on the developer front. While they are introducing many AI capabilities, this is making the product more complex. They need to work on making the technical aspects more accessible for developers and users as they add more AI capabilities.

I have been working with OpenText Capture for more than 14 to 15 years.

I have experienced performance issues with OpenText Capture during data extraction. When we had to move to Paradatec, it was taking more time to process the documents. However, the data extraction is much faster and more accurate with Paradatec. Performance issues arise when loading many documents for extraction.

The technical support and customer service of OpenText are favorable and always good.

On a scale of one to ten, the technical support of OpenText rates around six.

I have worked with other IDP products, specifically Paradatec, which is particularly useful for mortgage systems.

Compared to other products, Paradatec is more accurate. Its extraction capabilities, even with very unstructured data, yield around 95% accuracy. In comparison, OpenText Capture provides about 75 to 80% accuracy. However, Paradatec's setup is complex, making it more suitable for heavy volumes.

The setup of OpenText Capture is not too complex, but with the introduction of cloud capabilities, it is becoming more complex.

I have not seen any return on investment from OpenText Capture.

There are measurable benefits such as time saving, cost saving, and resource saving. I estimate at least 80% of manual effort savings. When a task takes 100 hours manually, with OpenText Capture it may take just 20 hours, resulting in an 80% reduction.

I don't have exact figures about the pricing aspect, but overall what I understand is that it is relatively expensive compared to the market.

Based on my rich experience with OpenText Capture, I would advise organizations considering it for their environment that this product is useful for handling heavy volumes or more complex documentation and integration requirements. However, for simpler requirements, it may be better to explore multiple open-source options instead of OpenText Capture.

It is too early to give a review on other products or solutions since I just started working on LLMs and NLPs.

We are not using analytics and reporting extensively. Within what OpenText Capture provides, I have done customizations and generated reports. However, OpenText Capture is not providing a robust solution in terms of reports.

On a scale of 1-10, I rate OpenText Capture an 8.

We use it to cover calls and documents.

We use it to improve the image and the documentation for cases. Sometimes, some cases have more than fifteen different types. We use some tools as fixed standard analysis and provide information to support those different types. This helps us automate processes. We choose the case type and subtype DNS scanning documents from the data entry.

OpenText's enterprise and capturing feature is valuable, as we have integrated our CRM with OpenText.

It is a stable solution. I rate the stability a nine out of ten.

It is a scalable solution. I rate the scalability a nine out of ten.

The initial setup is straightforward as we are the site's implementing partner. We do everything by ourselves starting from the design and the navigation to the deployment and ports.

OpenText is an expensive solution. 

I recommend using the solution. I rate the overall solution a nine out of ten.

Until recently, I use the solution at my prior employer for various document recognition and automation processes. 

We developed the solution for customers with various virtual machines and scan stations, some with more than 1,000 resources. 

For one project, I provided full-fledged invoice implementation using the 7.7 version. For another project, I provided upgrade services from the 7.1 to the 20.2 version. 

The solution is very powerful because it allows for custom scripting. It is easy to edit or improve interior scripting and .NET code if you have the knowledge base.

The solution has a very good OCR tool for scanning and image processing that converts to text-based classifications in free form. 

Knowledge of .NET is required to effectively use the solution or it can be complicated. I was able to train customers to use the solution if they had some .NET experience. 

The solution should offer a lightweight version that includes the OCR or document scanning and does not include the entire enterprise package with custom scripting. 

I have been using the solution for five years. 

The solution is stable. 

I used to work with large customers with very high volumes in the real estate and banking industries and stability was good. 

I also upgraded a customer from 7.1 all the way to 22.0 with no issues. The old version was going out of support so documentation for the entire enterprise's core functionality needed to be moved. The customer was nervous because everything was working fine and they did not want to take risks. We were able to complete the process with confidence and no stability or equalization issues. 

The solution is scalable. 

Technical support is good if you pay for the professional services package.

It can be difficult to get help without the professional services package. Support staff have minimal knowledge so they have to escalate tickets to professional services and that takes time. 

The setup can be extra complex because it is not bundled. Different modules need to be installed separately. 

I implemented the solution for customers. 

Some customers say the solution can get costly because it requires licenses or enterprise packages. 

I rate pricing an eight out of ten. 

There are many products in this category. I did not have much time to explore other tools because my workload was heavy for five years and my projects all required the solution. 

Other teams worked on projects that utilized ABBYY, Datacap, or UiPath. It was very encouraging to see so many tools used and I would have liked to explore them but my pipeline was quite stringent. 

The solution requires .NET knowledge but unlocks more validation functionality or backend scripting which makes it a powerful tool. 

UiPath has easy-to-use templates for beginners but does not allow custom scripting.

I rate the solution a seven out of ten. 

OpenText Intelligent Capture is a scanning platform. It's a competitor to solutions like Kofax. It allows you to image capture, scan documents and use machine learning to automatically index and tie them. You can then push them into the system you want to reside in, whether it's an ERP system, workforce management, or enterprise content management system. It automates the image capture process from the OCR and uses machine learning to identify what type of documents they are and helps index those documents.

It is a mature product and a leader in the industry. It competes with Kofax, its major competitor, and there aren't any gaps.

The machine learning capability to automatically classify and identify the scanned document type is valuable. You can index it to extrapolate metadata so that you know what it is. For example, you can identify an NDA agreement, the date and the parties. Or identify an invoice for a vendor, the invoice number and the amount.

It is a stable solution.

It is very scalable. The amount of users depends on the implementation. Some implement it enterprise-wide, where everybody in the company is scanning and capturing. Others have centralized scanning organizations in a mail room or a central control group that does the scanning. The users vary drastically, and it's licensed based on the scanning volume, not users. So it is licensed based on how many pages per year are scanned.

The setup is medium complexity.

For 100,000 pages per year implementation, I believe the software is around 15K. This is a starting point for a lot of organizations unless they're pretty high volume. I have customers running tens of thousands of pages a year to others running tens of millions of pages.

I rate this solution a nine out of ten.

It is designed for the automated capture and recognition of documents. Whether obtained through scanning, emails, faxes, or other sources, documents can be captured and data automatically extracted. This includes information such as invoice numbers, client details, and more. Following the extraction, a verification process is initiated, and subsequently, the data is integrated into the ECM (Enterprise Content Management) platform, which is documented.

The area for improvement primarily centers around licensing concerns rather than technical issues. Captiva, intended for larger clients, poses challenges for medium and small businesses due to licensing costs. The current licensing model is based on volume, such as purchasing a volume for one million dollars per year for scanning. This pricing structure may be prohibitive for companies with constrained budgets. Another aspect requiring attention is the mobile capture feature, which, although experiencing recent enhancements in intelligent document processing through AI, could benefit from further improvements. Specifically, there is room for enhancement in enabling users to efficiently capture documents using their smartphones.

I have been using this solution since 2016. 

It is indeed a scalable solution, but it is important to note that Captiva operates on a Windows-based platform. Unlike some other capture solutions, it cannot function, for instance, on a Linux environment. Additionally, it relies on SQL Server as its database. Consequently, when encountering issues related to high availability, especially in environments where higher availability is essential, there is a need for expertise in managing SQL Server configurations. This prerequisite becomes crucial as we navigate the complexities of implementing high availability features within SQL Server before addressing similar considerations in Captiva.

The responsiveness to requests is commendable; however, it's worth noting the time zone difference can pose challenges, particularly for regions like Morocco, which are five to six hours behind. Therefore, improvements in this aspect are needed, considering the impact of a time zone difference of three hours for those based in Morocco.

Positive

We are currently utilizing Kofax Capture and also engaging with Datacap Backup, IBM's counterpart to OpenText. We haven't entirely shifted from Kofax; instead, we continue to leverage both IBM and OpenText products. This dual approach stems from the diverse needs of our clients. Some customers still rely on IBM for specific projects, such as migrations from Kofax to Datacap.

The key strengths of Kofax include its superior performance in handling a larger volume of documents compared to IBM's Datacap. Additionally, Kofax is poised to enhance workflow management, with plans to introduce graphical interfaces for tasks like verification, validation, and export. This is a notable improvement over Datacap, which lacks this graphical capability. Another point of distinction lies in the availability of connectors. Kofax, in contrast to Captiva, offers a more extensive range of connectors, enabling seamless integration with various archiving solutions like Documentum, FindNet, and DocuWare. This extensive connectivity is a notable advantage of Kofax over Captiva.

We primarily use it for the management of vendor invoices. Most invoices come through emails, and that process has been automated so that ICR reads whatever invoice comes through the email. It then automatically processes it to go through a workflow.

The automated version of the vendor invoice management is great. It is helpful because it has reduced the human interaction in invoice processing.

The only issue is if something is handwritten and attached to an email, it doesn't capture the information correctly. So it has to be an invoice from the machine.

It will be good to employ some robotic process automation for future improvements. This feature will be beneficial once we better understand the business requirements.

We have been using this solution for about five months. It is deployed on-premises.

The solution is stable.

I cannot speak to the scalability, but we have not received any complaints from the business stakeholders.

We have support and maintenance from the OpenText site. However, I don't have specific details or know if there are things that have been reported.

A party vendor completed the deployment. We had two consultants that completed the configuration, and it took about six to eight months, including testing and all the phases.

I rate this solution a nine out of ten. I recommend this solution to others, especially if they deal with vendor invoice management.

It is used for vendor invoices. It is most often used for extracting information from different types of PO invoices, but it can also be used for other types of invoices.

Being able to have accurate extraction is most valuable. It has machine learning and other tools to make the extraction more accurate.

It can be more user-friendly, and it should also have more reporting capabilities. There are also a few other things that need improvement.

Its functionality is good, but it has to be made more accurate. If it is not customized and handheld properly, the recognition and captures won't be accurate.

It is scalable.

It is straightforward. Its implementation is not complex. Installing the application is always easy. As you make changes, it can get complex, but it is not very complex. 

Its implementation took 12 to 16 weeks.

You should have a very good process. You should have a process-need gathering session to identify where exactly it is required and what type of problems it will solve. If you have that very well articulated, then it would be a better IDP solution to implement, and you will be able to use it properly.

I would rate it an eight out of 10.

OpenText Intelligent Capture is a document management solution. They acquired Documentum and made it part of their enterprise content management solution.

We use it to capture documents coming through our product and mobile channels and make them available for our business to access and email. We use it to automate the email workflow in our applications, pull the documents, and email them to the users.

The primary reason we looked at this solution was to solve one of the key pain points we had across the business. We had a lot of islands of document stores - network drive documents were stored in individual computers, network drive boxes, and SharePoint-like solutions, et cetera. Once these documents are stored in those places, a lot of time goes into making these useful documents available for marketing and sales to pitch our properties. We are commercially listed to win the business with our clients. A lot of time goes into making those documents because they are stored everywhere with no metadata and no availability to easily search or browse. We almost lost the documents or we have them but we can't find them. We end up recreating them for the next deal instead of reusing them. That was a huge issue. So we chose this centralized store so that we can store them, tag them with metadata, and be able to search them and surface them when we need.

We were looking for basic document management functionality, to be able to capture documents, store documents, access them through services or a web portal, and have the right permission model so we can decide who has access to our documents. We need an API where we can interact with the documents over email, mobile access or web access and be able to expose it as multi-tenant surveys so that multiple lines of business can store documents and have the right permission model.

I would say what most of the document management solutions are lacking is smartness to detect the duplicate storage of the documents. Let's say I stored a pitch document that I created for client X, and then I open it and store it again, even though the name of the document may be the same or different, it should be able to look at the contents and compare the two documents, including content, signatures, and the digital footprint of these two documents and be able to smartly come back and say don't store one more version. It should use the reference to existing documents. That would go a long way. I haven't seen those features. That's something I would like.

This could be done with AI or it could be as simple as in security. You can look at the footprint and you can create a signature of the original document using some security algorithms, like the hashing functions. Then, the next time a document comes you can create a signature and compare these two if any content is different. If content is different, signatures end up being different. If content is the same, they end up being same. You just compare them.

I would like to see OCR capabilities. We also look at lease abstraction. So we have hundreds of pages of lease documents that we need to create a summary of. It could use some AI capabilities that would read the document and create a summary and some OCR capabilities that could extract specific elements off the documents to be used to automate a business process.

We've been using OpenText Intelligent Capture for two, three years now.

Stability has been good. No issues.

Their scalability is fine. For the scale that we chose, it is performing well. No issues.

We have about 1500 or so users.

We haven't been able to consolidate all the depositories yet. We have a lot more repositories to consolidate, but that is the roadmap.

We  plan to increase the usage in the future even further.

Their support been good. Our experience with their professional services and tech support has been generally good.

We have been using all these boutique solutions. Box is one of them. We used custom build solutions on Amazon S3 or Azure Blob. We had used SharePoint. Those are the few that come to my mind.

We were looking for a more robust solution that has robust capture capabilities including search and browse capabilities, the ability to apply document retention policies, with a more mature capability with single sign-on authentication hooked into our corporate AD. The most important requirement was to provide collaboration capability with the documents and the internal and external users.

The initial setup is not super complex. It's not easy, either. It is medium complex.

It took us two and half months to set it up, to configure it, and make it ready to run.

Most of the work was getting the authentication to work. That was not straightforward.

We used their consulting. They were good.

I would advise utilizing a document standard, like CMIS content management interoperability standard. This would be good to use. Think of that as a JMS type of protocol for messaging. You can put the JMS protocol and you can swap out out any messaging infrastructure in the backend. It should work fine. JMS is the abstraction layer. Similarly, in document management, CMIS is the abstraction layer which provides a standardized interface to capture, search, and retrieve all the standard documents through a standardized interface. In the background, we have the flexibility to switch out a document repository to OpenText or whatever is working well.

OpenText Intelligent Capture is pretty good. On a scale of one to ten, I would give it an eight.