Most vendor comparison pages are a feature checklist with the author's product winning every row. Ours were too, and we are rebuilding them on the method this post explains: the same matrix, sources and arithmetic for every product we compare, including our own. The pages move over one comparison at a time.
Why a matrix, not a checklist
A feature checklist measures one thing: how much a product can do. That is a single axis. It says nothing about who the product is built for, and two products with the same features can suit very different buyers. So we add a second axis, Enterprise Readiness, and place every product on the matrix the two axes make.
Take two SharePoint connectors with identical features. App A is bought by card for a few dollars a user, comes with email support, publishes no security audit, and is reviewed mostly by small teams. App B is sold per company on a quote, includes onboarding, is independently audited for SOC 2 Type II, and is reviewed by IT managers at large firms. On features alone they tie. On the matrix, App B sits further right, because everything about how it is sold, supported and built points to larger organisations.
Crossing the two axes gives four cells: left or right on Enterprise Readiness, bottom or top on Functionality. Each cell names the buyer a product in that region suits.
- Local Connect: file essentials for a team that buys and runs it itself, no procurement.
- Central Connect: file essentials built for IT-led buyers, with procurement and admin controls expected.
- Local Manage: automation, permissions and governance depth, still bought and run self-serve by a small team.
- Central Manage: the deep feature set, packaged for large organisations with dedicated IT.
The two axes
Enterprise Readiness, left to right
Enterprise Readiness is scored 1–5, 5 = highly enterprise-ready: how far a product is built, sold and bought for large organisations with dedicated IT and procurement, rather than by one person or a small team, self-serve. A product is placed on this axis using a weighted average of four signal types, each read from public sources:
| Signal | Weight | What it reads |
|---|---|---|
| Observed buyers | 3 | Who actually uses it, per review-site data: the company sizes of real reviewers. |
| Commercial & service design | 2 | How it is priced, packaged and supported: per-seat or per-org, support tiers. |
| Technical design | 2 | How deep and enterprise-grade the product itself is: security, compliance, documentation depth. |
| Messaging & ecosystem | 1 | Who they say they are for and who they partner with: site copy, customer logos. |
The heaviest weight goes to observed buyers because it is the only signal that is not the vendor's own choice: pricing pages, security pages and homepage copy all say who a vendor wants; reviewer company sizes say who bought.
Functionality, bottom to top
Functionality is the share of an arena's features a product supports at the top two rungs of our capability ladder. Each arena names a few dealbreaker features, which are checked first; each passes at L4 (Complete) or above. A product that fails one is still placed, and the failure is stated. On the evidence posts, each feature card will name the rung reached and explain why the evidence lands there and what the next rung would need. Each arena defines its features once, in its own method post, so the same capability is judged the same way for every product in that arena. For document management, that is How We Score Salesforce Document Management Apps.
How a score is built
Each signal's score = Vote × Reliability.
- Vote: a 1–5 read of what the available evidence actually shows. 1 Not ready · 3 Mixed · 5 Highly ready.
- Reliability: how much evidence exists, whether independent sources confirm it, and how precise it is.
A strong signal on thin evidence is scaled down; a weaker signal on solid evidence still counts. Evidence counts in full at high confidence, half at medium and a quarter at low, so thin evidence is weighed down rather than ignored. The four signal scores are then combined by their weights into the Enterprise Readiness score.
The Data Reliability Score
Some vendors publish a great deal; some publish almost nothing. Rather than let that difference hide inside the scores, we publish it. The Data Reliability Score is a consolidated score of how much data we could find, from public sources, on the topics used for scoring. It has three components, averaged and shown as Well, Partly or Thinly documented.
| Component | The question it answers |
|---|---|
| Coverage | Is the information public at all? |
| Independence | Is it published by someone other than the vendor? Sponsored reviews and branded articles count as the vendor's own copy on another site, not as independent sources. |
| Precision | Is it a checkable fact rather than a general claim? Counted only where a precise figure is expected. |
Every product is placed on the matrix; a thinly documented one is marked provisional. The score measures what a vendor makes public, not the vendor itself.
What each item measures
The evidence posts, published comparison by comparison, will give each item a one-line summary. Below is the full definition of every Enterprise Readiness item, which is the same in every arena, and the scales every Functionality feature is rated on. The features themselves are defined per arena.
Enterprise Readiness items
Every item casts one vote on the same Enterprise Readiness scale. The scale describes the kind of buyer a product is built for:
Bought and run by one person or a very small team, self-serve, with no procurement.
Mostly individuals and small teams, with occasional adoption by larger ones.
Serves both ends, small teams and enterprise IT alike, with no dominant buyer.
Mostly larger organisations and IT-led buyers, where procurement is typical.
Large organisations with dedicated IT and procurement, where contracts and admin controls are expected.
Each card below says what that item looks like at each of the five levels.
Observed buyers
AppExchange reviewer company sizes
Who buys the product, read from the people who review it. Each identified AppExchange reviewer is matched by name and review date to a public LinkedIn profile, the profile to its current employer, and the employer to its company size; roles are noted alongside. Consultants reviewing on a client's behalf count as channel, not as buyers.
- 1 · Not readyIdentified reviewers work almost entirely at very small organisations, in hands-on admin or end-user roles.
- 2 · Leans lowMostly small organisations, with the occasional mid-size reviewer.
- 3 · MixedA genuine spread of company sizes and roles, with no dominant profile.
- 4 · Leans highMost identified reviewers sit at large organisations, some in IT or architecture roles.
- 5 · Highly readyReviewers are overwhelmingly at large enterprises, often in IT, architecture or platform-owner roles.
Named customers: modal profile
The customers a vendor names in public: case studies, testimonials and logo walls. Each named organisation is sized from public knowledge, and the most common size and sector across all of them is what gets scored. Anonymous case studies add sector and size cues but no name.
- 1 · Not readyNo named customers, or only anonymous case studies, so no pattern can be seen.
- 2 · Leans lowA few named customers, mostly small businesses.
- 3 · MixedA mix of small and mid-size names with no clear centre.
- 4 · Leans highMid-size to large organisations are the most common profile.
- 5 · Highly readyEnterprise or regulated organisations dominate the named list.
Commercial & service design
Pricing unit and tiers
How the product is priced: the billing unit (per user or per organisation), the tiers on offer, and what the top tier holds back, such as API access, automation or multiple sites. Read from the vendor's pricing page and checked against any price shown on AppExchange.
- 1 · Not readyFlat self-serve pricing with nothing reserved for larger customers.
- 2 · Leans lowSimple per-user tiers with little gated behind the top plan.
- 3 · MixedBanded organisation pricing without a clear enterprise gate.
- 4 · Leans highQuote-only enterprise pricing, or a top tier that gates some enterprise capabilities.
- 5 · Highly readyA tiered structure whose top tier gates API, automation or multi-site use.
Customer support
The ways a customer can get help and what the vendor commits to, from community forums and email at one end to live chat, phone, onboarding teams, named account managers and response-time commitments at the other. Read from support pages and pricing tiers, and checked against independent reviews.
- 1 · Not readyA community forum or email only.
- 2 · Leans lowEmail plus self-help documentation, with little real-time contact.
- 3 · MixedSeveral channels, including some real-time help, without tiered commitments.
- 4 · Leans highA broad set of real-time and scheduled channels on every plan.
- 5 · Highly readyA broad range across tiers, up to named contacts or response-time commitments.
Conference and webinar presence
Where the vendor shows up in the Salesforce world, and at what level: its own webinars, community events, or sponsorship of Salesforce's flagship events. Sponsorships are checked against Salesforce's own sponsor directory.
- 1 · Not readyNo events found.
- 2 · Leans lowOccasional self-hosted webinars.
- 3 · MixedRegular webinars or Trailblazer Community events.
- 4 · Leans highPartner-led or regional Salesforce events, or a smaller sponsorship.
- 5 · Highly readyA presence at Dreamforce or a World Tour, confirmed by Salesforce.
Technical design
Security & Compliances
The certifications a vendor claims (SOC 2, ISO 27001, HIPAA, FedRAMP) and what backs them: a named auditor, a public registry, a data processing agreement or a trust portal. Named controls such as role-based access, audit-log retention and encryption at rest count here too.
- 1 · Not readyNo certification claimed.
- 2 · Leans lowGeneral security statements with no certification behind them.
- 3 · MixedA company-level SOC 2 claim, or a basic description of access controls.
- 4 · Leans highSeveral certifications claimed, with limited external backing.
- 5 · Highly readyAudited SOC 2 alongside ISO and HIPAA, residency options or named controls, backed by something that can be checked.
Help-doc architecture
How complete the public documentation is across setup, administration, single sign-on, security, developer reference and release notes, and whether it can be searched. Page and article counts come from the help centre's own sitemap or index.
- 1 · Not readyNo public documentation.
- 2 · Leans lowA quick-start guide or a handful of articles.
- 3 · MixedA partial knowledge base covering setup and some administration.
- 4 · Leans highBroad documentation with one or two areas missing.
- 5 · Highly readyA full, organised set covering every one of those areas.
API depth and gating
Whether developers get a public API, an Apex client, or both, and how deep the reference goes. A pricing tier that restricts access is recorded, but gating an existing capability does not lower the score.
- 1 · Not readyNeither a public API nor an Apex client.
- 2 · Leans lowA thin or undocumented developer surface.
- 3 · MixedOne of the two, a public API or an Apex client.
- 4 · Leans highBoth, with one of them thinly documented.
- 5 · Highly readyBoth a public API and an Apex client, each with a real reference.
Document stack coverage
How much of the wider document stack a vendor covers beyond file management (generation, document AI, migration, controlled sharing and e-signature), whether built into the product or sold as a sibling product by the same company.
- 1 · Not readyStorage and file access only.
- 2 · Leans lowOne adjacent capability, partly covered.
- 3 · MixedSome coverage across two adjacent areas.
- 4 · Leans highMost adjacent areas covered.
- 5 · Highly readyBroad coverage across generation, processing, sharing and signing.
Messaging & ecosystem
Stated ICP and messaging focus
Who the vendor's marketing says the product is for: the industries, personas and use cases named across its solution and industry pages.
- 1 · Not readyMessaging aimed narrowly at individuals or small teams.
- 2 · Leans lowMostly small-team messaging, with some references to larger customers.
- 3 · MixedBroad "any team" messaging, or a focus spread across several segment types.
- 4 · Leans highLeaning towards enterprise segments, with some broader messaging alongside.
- 5 · Highly readyA narrow focus on enterprise segments, such as regulated industries or an IT and security buyer.
Partner ecosystem
Which systems integrators and consultancies the vendor names as partners, what tier those relationships sit in, and whether the partner confirms the relationship on its own site or channels.
- 1 · Not readyNo partner programme, or none named.
- 2 · Leans lowA programme page with no confirmed partners.
- 3 · MixedOne or two boutique partners.
- 4 · Leans highA formal, tiered programme with several named partners.
- 5 · Highly readyA Big Four firm or a global systems integrator.
Team mix
The functions visible in the vendor's LinkedIn headcount (sales, customer success and support) and how many regions the team covers. The mix is scored, not the size of the team.
- 1 · Not readyLittle or no sales, customer success or support presence.
- 2 · Leans lowOne of those functions visible, thinly.
- 3 · MixedSome presence across them, within a single region.
- 4 · Leans highA solid mix of sales, success and support.
- 5 · Highly readyA strong mix across all three, spread across time zones.
Review-site profile richness
How complete the vendor's presence is on G2, Capterra and TrustRadius: whether a real profile exists on each, and how well it is filled in.
- 1 · Not readyNo profile on any of the three.
- 2 · Leans lowOne thin profile.
- 3 · MixedReal profiles on one or two platforms, or thin ones on more.
- 4 · Leans highTwo well-populated profiles, or all three with one of them thin.
- 5 · Highly readyReal, well-populated profiles on all three.
Functionality scales
Every feature, in every arena, is rated on the same five rungs:
Not possible from Salesforce.
Only through the storage's own interface, custom code or a manual step.
Works, with gaps in scope.
The full capability a buyer expects.
Useful extras beyond it.
Each feature also carries a Kano class from our feature map, the same for every product. The class says how much the feature matters to a buyer:
Missing it rules the product out; going beyond the basics adds little. Failing one gates the whole score.
Steadily better the more of it there is, and steadily worse the less.
Buyers manage without it, but notice and value it when it's there.
Rarely noticed either way, so it is tracked but carries no weight.
Where it applies, a feature also gets an automation rating on the same five rungs: how far the operation can run without a person, through Flow for admins and Apex or an API for developers. The automation ratings are averaged into a separate Automation score, reported next to Functionality but not counted in it.
The features themselves differ by arena, so each arena defines its own list, with each feature's Kano class and whether it is rated for automation. Document management: How We Score Salesforce Document Management Apps. Document generation and document AI follow as those arenas are scored.
Where the verdict lives, and where the evidence lives
Our comparisons are moving to this structure one at a time; until a comparison has moved, its older page stays up. Both surfaces will show numbers. The difference is which number, and how much of the working is shown:
- The website (cloudfiles.io/salesforce/compare) will carry the verdict: where a product sits on the matrix, its final composite score on each signal, the Functionality gate result, the Data Reliability band, a like-for-like facts table, and “choose X if” guidance. These will be conclusions, stated once, with nothing showing how they were reached.
- This blog will carry the evidence: the item-by-item trail behind each composite (which source, what it said, when we read it, and the vote that one item got), rolled up into the same composite the website states. If you want to check our arithmetic or see the actual quote a score rests on, it will be here, not there.
Each surface will have three levels: the whole category, one arena (document management, document generation, document AI), and one head-to-head comparison. Every number on either surface will trace back to the same scorecard; the website will state the composite, and the blog will show how each composite was built. On the blog, each arena also gets its own method post that defines its features, starting with document management.
What we do not do
- We do not redefine a feature for a particular vendor. Every product is judged against the same definition and the same rungs.
- We do not hide ties or losses. Where a rival scores higher on a feature, the page says so.
- We do not count seats. Enterprise readiness is read from evidence, never from a seat threshold.
- We do not score architecture. How a product is built is stated as a fact in the facts table, not graded.
Cadence and corrections
Sources are re-read on a cycle; each evidence post will carry a dated what changed section, and rebuilt website pages are regenerated from the scorecard. If a figure is wrong or out of date, tell us and we will re-read the source and record the correction with its date.