Methodology

This page describes how Case Management Guide researches, sources, verifies, and maintains information. Structured product data is still being assembled, so much of this page describes the standards that content will be held to as it is published — stated now so readers can hold us to them.

For factual claims about products, we prefer, in order:

1. Primary vendor documentation — official product documentation, published specifications, release notes, and vendor statements, identified as such.
2. Public documentation — publicly accessible materials such as knowledge bases, published contracts, and procurement records.
3. Government and association sources — agency guidance, funding-program requirements, and standards from relevant professional associations, where applicable.
4. Reputable third-party sources — established publications and researchers, cited by name.

Published facts will carry source labels (vendor documentation, public source, third-party source) so readers can see where information came from.

A vendor's claim about its own product is reported as a vendor claim. Our own assessment is labelled as Case Management Guide analysis. The two are never blended into a single unattributed statement.

Software changes constantly, which means information about it decays. Structured facts will carry "last verified" or "last reviewed" dates so readers can judge freshness for themselves. An old verification date is a signal to double-check, and we treat it the same way.

Pricing appears only when it can be supported by a documented source and will carry the date it was verified. We do not estimate, extrapolate, or invent pricing. When reliable pricing is not available — common in this market — we say "Pricing not publicly disclosed" rather than guessing.

Product comparisons will be built on a published feature taxonomy applied uniformly to every product, including QG Case Essentials, which is developed by our publisher. Comparison criteria are published before conclusions are drawn from them, and comparisons state what was and was not evaluated.

When information cannot be verified to our standard, we either omit it or publish it clearly marked as unverified — never silently presented as fact. Absence of a feature claim is not evidence a feature is missing, and our content will avoid implying otherwise.

Errors get corrected, not quietly buried. When we correct a substantive error, the correction is applied promptly and materially affected content is annotated. Vendors and readers can report inaccuracies via the Contact page; vendor-submitted updates are verified against documentation before publication, just like anything else.