Coveo Relevance Cloud vs iManage Insight

• Coveo is fast, search results come up quick (though it's not always great).
• Not much complexity to run.
• Coveo is implemented within our portal and doesn't require extra steps to use it.

Read full review

• It adheres to traditional Microsoft standards such as: fact-dump documentation with no coherent story or 'best practices' information, inability to automate common tasks, intentional obfuscation of its basic operations.
• It provides OK search results. Not great, but OK.

Read full review

• It would be great if Coveo 6 allowed you to rebuild indexes from a certain subtree instead of needing to rebuild the entire tree to see changes. This functionality was added in Coveo 7 and is very useful.
• In Coveo 6, integration with Sitecore is more difficult than one would expect. This integration is much improved in Coveo 7.
• I have seen cases where an exception thrown when crawling a specific document will cause the indexing to stop completely. I believe this only happens in implementations using custom faceting but it could be handled more efficiently if the trouble document was skipped and the indexing could continue.
• Relevancy ranking editor is good but not as powerful as GSA. GSA offers a self-learning scorer which automatically analyzes user behavior and the specific links that users click on for specific queries to fine tune relevance and scoring.
• We've ran into issues on multiple clients with Sitecore items being indexed multiple times in Sitecore 7 and Coveo 7. The fix Coveo suggested was to upgrade our Sitecore version and Coveo but unfortunately this didn't resolve our issue. After months of testing we were finally able to resolve this by implementing our own CoveoItemCrawler to get around the issue (based on https://developers.coveo.com/display/public/SC201404/Items+in+the+Same+Language+Gets+Indexed+Multiple+Times;jsessionid=3C1A2AE33540E0A0B8BB52BA3A64AF70).
• Integration with RabbitMQ in Coveo 7 seems error prone. We often see the error "The AMQP operation was interrupted" and on occasion, need to restart the Coveo service to get this operating again. In some extreme cases, we have also had to restart the server because of issues when attempting to restart the Coveo service.

Read full review

• There are about a dozen different config files to maintain, and the most important one is dynamically modified by Autonomy itself while it runs. Which means that it is impossible to automate the configuration or keep the configs in versioned source control. Even `cp *.cfg ~/cfgbak/` won't help you roll back a change, because it is never safe to restore a previous config. You'll be using `diff new.cfg old.cfg` a lot.
• The Linux port is poorly thought out. The binaries are named *.exe. The StartService.sh scripts contain both `echo 'Are you sure you want to start the service? Hit ctrl-C to cancel''; read dummy` and, I kid you not, a `chmod a+x /path/to/my/binary.exe`.
• Many features are poorly documented, leading to lots of back and forth with the support department just to answer basic questions like "what does this error code in my logs signify?"
• It seems to reinvent the wheel, poorly, everywhere. E.g. the scheduled backup feature rolls through a user-defined finite list of directories in which to store backups. On day 0 it uses directory 0, on day 1 it uses directory 1, and after day N it rolls back and overwrites directory 0. Why would this be preferable to using a single directory and naming zip files based on the current timestamp?

Read full review

• Quick to find things in a massive database when needed.
• Results need to be more concise - sometimes we spend more time looking for the right file than if we were to just search amongst our own networks instead.
• Coveo is not always the most useful but does its job when general information is needed.

Read full review

• I have learned to tack a zero onto the end of any estimate I make for how long an Autonomy change will take in both planning and implementation.

Read full review