Get SMEs past 'looks good' on doc reviews

The "looks good" problem

You send a draft to a subject matter expert. Days later: "This looks great, nice work!", which tells you nothing. You still don't know if the content is accurate, if you missed something critical, or if the steps match what actually happens in the field. Then it ships, and a support ticket tells you what the SME didn't.

If this is the most stressful part of your job, you're not alone. Technical writers say it constantly: "hounding people to answer my questions was a much bigger stress than the actual writing." Getting timely, useful feedback from SMEs is consistently named the hardest part of documentation that tools still don't solve. It hits hardest when you're the whole docs team, with no peers to lean on and every review riding on one outside expert.

It's solvable, but not by asking harder. It's solved by asking differently and removing the friction that makes experts skim. This guide covers both: how to structure the request (the 80% that's about your process), and how to make reviewing effortless enough that SMEs actually do it (the 20% that's about tooling).

Why SMEs say "looks good"

It's rarely laziness. Three things are happening:

1. The question invites it. "Can you review this?" and "Does this look right?" are yes/no questions, and "yes" is the path of least resistance. A vague ask gets a vague answer.
2. Hedging feels safer than critiquing. Pointing out problems feels like criticizing your work. Most SMEs would rather thumbs-up than risk seeming difficult, unless you explicitly give them permission (and a job) to find faults.
3. Reviewing is a chore. If the SME has to make an account, learn a tool, or read a 40-page export to leave one comment, they'll skim and rubber-stamp. Every unit of friction converts a careful review into a "looks good."

You can fix all three.

The reframe: ask if it's true, not if it's good

This single shift changes the answers you get:

"Does this look right?" invites a thumbs-up. "Would you be confident if a new hire acted on this exactly as written?" invites a wince, and a wince is the feedback you wanted.

You are not asking the SME to judge your writing. You're asking them to protect the reader from acting on something wrong. That's a job they take seriously, and it's not personal. Say it out loud: "I'm not asking you to review the design or the prose. I need your expertise to validate accuracy, realism, and risk."

How to structure the ask

Replace one open request with a few specific, answerable prompts. These consistently outperform "what do you think?":

Lead with failure modes. The fastest way past "looks good":

• "What's the one thing in here that would get someone into trouble if they did it wrong?"
• "Find me three things a reader could misunderstand."
• "If you had to remove one section, which and why?"

Ask closed accuracy questions:

• Is anything inaccurate or outdated?
• Is anything important missing that you'd expect to see?
• Does each step reflect what actually happens, or the ideal that rarely does?
• Is any wording risky, misleading, or out of line with policy?

Shrink the ask and make more of them. A reviewer faced with "review this whole guide" skims. A reviewer asked three pointed questions about one procedure engages. Break large reviews into small, specific asks tied to the sections that carry the most risk.

Go synchronous when it matters. SMEs talk far more than they type. A 30-minute screenshare where you ask "would this really happen?" at each step, recorded and turned into notes, frequently beats a week of waiting for written comments. Use async review for breadth, a live pass for the high-risk core.

Switch to closed questions at sign-off. Open questions are for discovery; closed questions are for accountability. As you approach release, ask explicitly:

Do you approve Section 1 for delivery? Yes / No, and if No, state corrections. Do you approve Section 2 for delivery? Yes / No, and if No, state corrections.

This makes approval a decision the SME owns, per section, with a paper trail, not a vibe buried in a thread.

A reusable SME review request

Steal this. Adapt the questions to your domain:

Subject: 15-min review: [Topic name], accuracy check

Hi [name], I need your expertise to make sure this is accurate, not to review the writing. Please focus on these:

1. Risk: What in here would get a reader into trouble if they did it wrong?
2. Missing: What would you expect to see that isn't here?
3. Reality: Which step is least like what actually happens in practice?
4. Sign-off: Do you approve this topic for publishing? Yes / No, and if No, what's the one change?

Comment directly on the text where you can. Deadline: [date] so we can hit [release]. Thank you. This is the part I can't do without you.

Remove the friction so they actually review

A perfectly structured request still fails if reviewing is a hassle. The deciding factor is usually how easy it is for a non-team expert to leave feedback on the exact passage in question. This is where most tools quietly lose you reviews:

• GitHub PR review assumes the SME knows Git. Product managers, support leads, and external partners don't, so they paste edits into Slack or email a marked-up PDF, and the feedback never reaches the source.
• Account-gated tools ask the SME to sign up before they can comment. Plenty won't, and the ones who do resent it.
• Per-reviewer pricing makes you ration who gets to review, exactly backwards from what you want.

Topicary's review sessions are built to delete that friction:

• No account, no login. Reviews use a token-based shareable link. Send it through Slack, email, or any channel, and anyone with the link can read and comment. No sign-up wall.
• Comment on the passage, not the page. Reviewers select text and leave inline comments anchored to the exact sentence, and reply in threads, so feedback is specific by default, not "something in section 3 is off."
• Per-topic Approve / Request Changes. Reviewers approve or request changes on each topic individually: the closed, accountable sign-off from above, tracked per topic instead of buried in a thread.
• No per-reviewer charge. Add every SME, stakeholder, or external partner the content needs. (GitBook, by contrast, requires a paid account per reviewer.)
• Send invites or share a link. Add reviewers by email to send invitations with a due date and a personal note, or just copy the link. Sessions are read-only and expire after 30 days.

The structure gets you better answers; the frictionless link gets you answers at all. See Create a review session for the step-by-step.

Put it together

1. Reframe the ask: true, not good; accuracy, not design.
2. Lead with failure modes and 3 to 5 closed questions tied to risk.
3. Shrink and multiply the asks; go live for the high-risk core.
4. Close with explicit, per-section sign-off.
5. Remove the friction: let SMEs comment on the exact passage with no login, so structure actually turns into feedback.

Do the first four with any tool. Do the fifth and you'll stop hearing "looks good," because reviewing finally costs the expert almost nothing.

For how this fits a full draft-to-publish flow, see respond to review feedback and the Topicary vs GitBook comparison (review workflow section).