The SquadScore™ Methodology

Step one: pick specs you can verify

Each category has a fixed list of specs. Price per seat. Security tier. Context window. Whether admin controls exist. Every one of them has to be checkable against something the vendor publishes, because an unverifiable spec is an opinion wearing a lab coat. Marketing adjectives never become specs — “enterprise-grade” is not a measurement.

Step two: normalise each spec to 0–100

For a numeric spec with raw value x and published bounds min and max (the ratio is clamped to the 0–1 range, so values outside the bounds score 0 or 100):

• Higher-is-better: quality = clamp₀₋₁((x − min) ÷ (max − min)) × 100
• Lower-is-better: quality = 100 − clamp₀₋₁((x − min) ÷ (max − min)) × 100
• Ranges (e.g. a 128K–272K token context window) are reduced to a scalar first — the midpoint, span, or upper bound, as published per spec below.
• Categorical specs (e.g. security tier: consumer vs SOC 2 vs SOC 2 + SSO) map to a published 0–100 quality value per option.

The bounds are per category and printed in the tables below. That matters more than it sounds — bounds are the one place a scoring engine can hide a thumb on the scale, so ours sit in public where you can argue with them.

Step three: weight and average

Each normalised value is multiplied by its published weight. The overall SquadScore is the weight-normalised average: Σ(qualityᵢ × weightᵢ) ÷ Σ(weightᵢ), computed only over the specs that have data. Which brings us to the rule that does the most work.

Missing data is excluded, never penalised

If a vendor doesn’t publish a number, we store it as unknown, drop that spec from the calculation, and renormalise the remaining weights. We don’t zero it. A blank isn’t a bad score, it’s an absent score, and treating silence as failure would quietly reward whoever writes the chattiest spec sheet rather than whoever builds the better product.

There’s an honest cost to this, so let’s name it: a score built on six specs leans harder on those six than a score built on eleven. Two tools with the same SquadScore may not rest on the same evidence base. Each product page prints exactly which specs were unavailable — read that note before you treat two numbers as equivalent.

Reference-only specsare the other exclusion: some published figures aren’t comparable across designs and get flagged reference-only in the engine — shown in tables but never scored. None of the specs live today need this flag; the mechanism exists for the day one does.

The exec-fit rubric is separate. On purpose.

This is the part that distinguishes SquadScorefrom most scoring systems you’ll meet, so it’s worth being blunt. A second layer of assessment runs on this site — how well a tool suits a non-technical executive. Setup without engineering help. Whether the admin console makes sense to a business owner. Whether a rollout to fifty people needs an IT project or an afternoon.

That layer is a rubric. It involves judgement. It’s published on its own scale, disclosed as editorial in every table it appears in, and shown next to the SquadScorerather than mixed into it. It never enters spec normalisation — not as a bonus, not as a tiebreaker, not as a quiet multiplier on a “usability” spec. The moment a judgement call gets laundered through a formula, the formula stops meaning anything, and every vendor who loses a ranking is entitled to assume you rigged it. So the two stay apart, and you get to weigh them yourself.

Role re-weighting (the “Best for…” lists)

A CFO and a broker working from a car shouldn’t use the same weights. So they don’t. Our role-specific lists take the same normalised data and re-weight it for one kind of buyer — the Finance & Operations list, for instance, cares far more about security tier and setup effort than a Real Estate Brokers list, which leads on mobile coverage and price because the buyer is a 1099 agent paying for their own seat. The weights for each role are published on its list page. The underlying data never changes.

Versioned, with a public changelog

Every material change to weights, bounds or formula increments the version and gets logged below with a date and a reason. Cosmetic changes don’t bump the version, and new products scored under existing rules count as cosmetic. Anything that would move an existing score does.