Writing a good scorecard

A scorecard is a diagnostic, not a quiz. Someone answers honest questions about their own situation and gets back a reading of where they stand, plus the most useful thing to do next. It earns its keep when the result tells them something they had not already put into words.

Most of what makes that work comes down to four decisions.

Pick dimensions that lead somewhere different

A dimension is one axis on which people genuinely differ, and on which being weak has a different remedy from being weak on the others. If two dimensions would produce the same advice, they are one dimension.

Name the thing being measured rather than the virtue — “Clarity on Scope”, not “Excellence”.

Three to five. Two reads as a false dichotomy. Six or more and the results chart becomes hard to read, with too few questions behind each score to mean much.

Write questions nobody can game

This is the one that decides everything else:

Every answer option must be a plausible thing for a competent person to admit.

If one option is obviously the right answer, the question measures self-flattery. Do that across a whole scorecard and everyone scores highly, nobody learns anything, and you conclude scorecards do not work.

In practice:

• Ask what is actually in place, not what someone intends. “How is scope agreed before work starts?” beats “Do you value clear scope?”
• Make the answers describe observable states — “We discuss it at kickoff but nothing is written down” tells you far more than “Somewhat”.
• One idea per question. If it contains “and”, it is probably two.

Four options, worst to best. Four avoids the safe middle a five-point scale invites. Three to five questions per dimension, and 10–20 across the whole thing: under 8 and the result reads as generic, over about 25 and people stop finishing.

Occasionally a question is better asked as open text than as a scale — a name, a URL, “what would make this a 10 for you?” An open question has no answer options, is not scored, and its answer is stored with the submission for you to read rather than folded into a tier. Reach for it only when a scale genuinely cannot capture the answer, not as a shortcut around writing four good options.

Make the tier insights worth the email address

Each dimension’s score lands in a band, and each band carries an insight. This is the payload — someone gave you ten minutes and their contact details for these paragraphs.

Name the band for the state, not the grade: “Firefighting”, “Stabilising”, “Scaling” rather than “Poor”, “Fair”, “Good”. A grade reads as a verdict people argue with; a state reads as a description they recognise.

Two to four sentences each: what landing here means, then the single most useful thing to do about it. Write the top band properly — it is the one people skip writing and the one your best-qualified respondents read.

You never write the score ranges. Those are derived from the questions and recalculated whenever the questions change.

Decide what happens next

The results CTA is why the scorecard exists commercially. A new scorecard ships with a placeholder pointing at example.com, and publishing with that still in place sends every respondent nowhere. Set it before you publish.

Ask for an email and a first name. Every field beyond that costs completions — add one only if your follow-up genuinely changes because of the answer.

Letting an assistant do it

An AI assistant connected over MCP has all of the above as a tool it reads before writing anything, so it should be asking you who the scorecard is for and what decision it should drive rather than inventing both. If it starts writing questions without asking, tell it to read the design guide first.

Before you publish, ask for two things: the output of check_scorecard, which flags placeholder copy and thin dimensions, and the previewUrl, which shows you the real scorecard as a respondent would see it.

Then pick a look — see Themes and branding.