Why Eligibility and Policy Topics Break Most Explainer Videos
Every membership-driven organization eventually faces the same question: can someone close to me get the same access I have? A spouse, a partner, a parent, a sibling, a household member, a long-term roommate — the wording changes, but the underlying question is identical. It is one of the highest-volume searches in military-affiliated finance, professional associations, alumni networks, union benefit funds, cooperative groceries, employer perk programs, and community health plans.
And it is almost always answered badly on video.
The reason is structural. Eligibility is not a topic, it is a decision tree. Real eligibility rules read like this: a person qualifies if they have a qualifying relationship to an existing member, and that member must be in good standing, and the relationship must fall within an approved category, and in some cases the organization must also offer an extended-family or household pathway, and if none of those apply there may be a fallback path through an association, employer, or geographic group. That sentence is a flowchart with four gates and three exits. When a video tries to narrate it linearly, viewers lose the thread somewhere around gate two.
Most teams default to one of three failure modes:
- The rulebook read-aloud. The script paraphrases policy text in the same order the policy document presents it. Accurate, unwatchable, and it answers a question nobody asked.
- The vague reassurance. "Family members may be eligible — contact us to find out!" This is safe and useless. It generates support tickets instead of reducing them.
- The over-promise. "Your partner can join today!" This gets flagged by review, pulled after publication, and erodes trust in every other video the team produces.
This guide is a production workflow for the fourth option: an explainer video that models the decision instead of describing it. It covers scripting, visual systems, character consistency, review loops, accessibility, and repurposing — using AI-assisted video tools where they help and human judgment where they are irreplaceable.
Step 1: Turn the Rules Into a Decision Tree Before You Write a Word
Do not open a script editor until the logic is mapped. The map is the asset; the video is a rendering of the map.
Build the tree in a spreadsheet or a plain text file. Use three columns: condition, outcome, evidence required. Every row is a possible branch. A simple structure for a relationship-based membership question looks like this:
- Is there an existing member with an active, good-standing relationship to the organization?
- If yes — is that member a spouse, partner, parent, grandparent, sibling, child, or household member?
- If the relationship is a household member with no legal or family tie, does the organization's definition of household require shared address proof, shared finances, or both?
- If the relationship falls outside the approved list, is there a secondary pathway — an association membership, an employer group, a professional body, or a geographic requirement?
- If no pathway applies, what is the honest answer, and what is the next useful step for the viewer?
Each numbered gate becomes a scene. Each "no" exit becomes a card, not a paragraph. This has three practical benefits:
- Scenes map to branches. When a rule changes, you re-render one scene instead of rewriting the whole video.
- The video becomes navigable. You can publish a full walkthrough and separately publish each branch as a short clip, which is exactly how people search.
- Review gets faster. A reviewer can approve logic node by node instead of reading a script and guessing which sentence encodes which rule.
Questions that map cleanly to video branches
Not every policy question deserves a video. The ones that do share a shape: a fixed set of conditions, a yes/no or a small set of exits, and a high volume of repeated support questions. If the answer is "it depends on a case officer's judgment," a video can still help — but the video's job changes from answering to explaining what the reviewer looks at. Be explicit about which one you are making.
Step 2: Write a Script That Survives Review
Compliance and legal review rarely reject facts. They reject certainty. The single most common reason a policy explainer gets bounced is absolute language applied to a conditional outcome.
Rewrite rules that work in practice:
| Instead of | Write |
|---|---|
| "You will qualify if…" | "Eligibility is determined by…" |
| "Anyone can join." | "Several pathways exist; most people qualify through one of them." |
| "It's easy." | "The application takes about ten minutes once you have the documents listed below." |
| "Guaranteed approval." | "A membership specialist reviews each application." |
Two habits make scripts review-friendly. First, name the authority — "the membership team confirms this at application" — so the video never appears to promise an outcome. Second, put conditions in the same sentence as the benefit, not two scenes later. Viewers clip short videos; a condition that lives in a different scene effectively does not exist.
A reusable five-beat script skeleton
- Beat 1 — Hook (0:00–0:12). State the exact question in the viewer's own words. "Can my partner open an account if I'm a member?" This is the line that determines whether the video gets watched.
- Beat 2 — The map (0:12–0:35). Show the whole tree on screen for a few seconds. People who only need branch three will stay because they can see where their answer sits.
- Beat 3 — The branch walkthrough (0:35–2:15). One scene per gate, one visual per condition, one yes/no card per exit.
- Beat 4 — The documents beat (2:15–2:45). List exactly what gets checked: proof of relationship, proof of address, member identification, an application reference number. This is the most screenshotted part of any policy video — design it as a standalone card.
- Beat 5 — The next step (2:45–3:00). One action, one place to go, and an honest statement of what happens if the answer is no.
Step 3: Lock a Visual System Before You Generate Anything
Consistency across scenes is what separates a professional explainer from a pile of unrelated clips. Decide these once, write them down, and reuse the same phrasing every time you generate a new asset:
- Palette: two base colors plus one accent used only for "yes" branches and calls to action.
- Typography: one heading face, one body face, one caption style. Nothing else.
- Illustration style: flat vector, papercut, isometric, line art, or 2.5D — pick one and never mix.
- Motion language: one easing curve, one transition set, one duration for on-screen cards.
- Iconography: a single icon family, drawn at a consistent stroke weight.
Prompt fragments worth saving
Write a reusable style block and paste it into every generation: "flat vector illustration, deep navy and warm sand palette with a single amber accent, thick uniform outlines, no gradients, centered composition, generous negative space, clean geometric shapes." Save that string in a text file. Do not improvise it scene by scene; small wording changes produce visible style drift that reads as carelessness to viewers who know nothing about your production process but notice everything.
Step 4: Keep Characters Consistent Across Scenes
The hardest technical problem in AI-assisted explainer video is a face that changes between shots. Viewers forgive an imperfect illustration. They do not forgive a narrator who becomes a different person at the 90-second mark.
What works:
- Build a character sheet first. Front, three-quarter, and profile views, plus two expressions. Treat it as a reference asset, not a one-off generation.
- Freeze the wardrobe. One outfit per character for the entire series. Changing clothes between scenes is the fastest way to break continuity.
- Lock the description. Write the character prompt once — age range, hair, build, clothing, art style — and never paraphrase it. If you must change a word, change it everywhere in that series.
- Control emotion through pose and scene, not adjectives. "Concerned" in a prompt produces inconsistent faces; a tilted head, a hand on a document, and a soft background does the same job reliably.
- Reduce the cast. Two characters can carry an entire eligibility walkthrough: a host who explains and an asker who voices the viewer's question. Every additional character multiplies drift risk.
If a shot absolutely requires a new angle, generate it from the character sheet using image-to-video referencing rather than a fresh text prompt. Reference-based generation is the difference between a series and a collection of strangers.
Step 5: Voice, Pacing, and Captions
Voice selection is a trust decision, not a taste decision. For eligibility and policy content, aim for warm, neutral, unhurried, and non-promotional. Fast, excited, sales-flavored delivery contradicts the message and makes viewers suspicious that they are being upsold into something they may not qualify for.
Pacing rules that hold up:
- 140–155 words per minute for instructional narration. Faster feels rushed on complex content; slower feels condescending.
- A 0.6–1.0 second pause at every branch point. The pause is what tells the viewer a decision just happened.
- One idea per sentence. Policy language nests clauses; narration cannot.
- Numbers spoken and shown. Say "ninety days" and display "90 days" on the same frame.
For captions, deliver two assets: burned-in captions for vertical social cutdowns and a separate subtitle file for long-form and accessibility. Never let captions overlap a documents list — that card gets screenshotted and it needs to be legible on a phone at arm's length. Also avoid encoding yes/no branches in red and green alone; use icons, labels, and position as well, because a meaningful share of your audience cannot distinguish those colors reliably.
Step 6: Review Loops That Do Not Kill Momentum
Run two parallel review tracks from the start:
- Accuracy track: the person who owns the policy reads the script, not the render. Approve logic before visuals.
- Clarity track: someone with zero domain knowledge watches the video with sound off, then with sound on. If they cannot restate the rule afterward, the script needs another pass.
Keep a source-of-truth document that pairs every claim in the video with the line in the policy it came from. When the policy changes, you can search the document, find the affected scene, and re-render only that scene. Freeze the script after approval and version it — date-stamped versions prevent the classic failure of publishing a corrected video while an older cut is still circulating.
Include a visible "last reviewed" stamp on the closing card. Policy content without a revision marker ages badly and quietly becomes misinformation.
Step 7: Repurpose One Master Video Into a Distribution Set
One three-minute master can feed a month of publishing if you plan the shot index up front. Tag every generated clip with its branch number and the duration, then cut:
- Six to ten vertical clips — one per branch, 15–45 seconds each, each opening with the question that branch answers.
- One 60-second summary for the audience that will never watch three minutes.
- Quote and document cards as still images for feeds and email.
- A looping GIF of the decision tree for landing pages.
- An audio-only version for podcast feeds and phone trees.
Because the master was built from a decision tree rather than a linear narrative, each cutdown stands alone without awkward re-recording. That is the payoff of doing the mapping work in Step 1.
Common Mistakes and How to Avoid Them
- Answering a different question than the one people search. Write the hook first and test it against real search phrasing before producing anything.
- Burying the answer. If three of four branches lead to "yes," say so in the first fifteen seconds and use the rest of the video for the exception.
- Over-promising. Never let a script assert an outcome that a human reviewer determines.
- Skipping the documents beat. Most support contacts happen because people do not know what proof is required.
- Style drift. Unlockable style prompts produce visible inconsistency; save and reuse them.
- Ignoring accessibility. Captions, contrast, and non-color-dependent branching are basics, not extras.
- No revision marker. Undated policy video is a liability the moment rules change.
- No honest "no" path. If a viewer does not qualify, tell them clearly and give them a genuinely useful alternative. That scene builds more trust than any call to action.
FAQ
Should I use an AI avatar or an illustrated narrator?
For regulated or policy-adjacent topics, illustrated or stylized narration usually ages better than photorealistic avatars. It avoids the uncanny gap between realistic faces and scripted delivery, and it sidesteps the awkwardness of a synthetic person appearing to give a definitive answer about a conditional rule.
How long should the video be?
Three to four minutes for the master walkthrough, 15–60 seconds per branch clip. Long enough to cover the documents step, short enough that the branch logic stays visible in working memory.
Do I need human review if AI wrote the draft?
Yes, and on the script rather than the render. Accuracy review is cheapest before a single frame exists. Treat the AI draft as a structuring tool, not an authority.
Can I show real documents on screen?
Show blank or clearly fictionalized samples with visible redactions. Real documents on screen invite confusion about what the viewer is supposed to submit, and they create privacy exposure during repurposing.
What happens when the rules change?
If you built from a decision tree and kept a source-of-truth map, re-render the affected branch scene, update the revision stamp, and re-export the affected cutdowns. Teams that skipped the mapping step end up rebuilding the entire video.
Is one long video or a series better?
Publish both, but lead with the series. Branch clips match how people search, while the master video serves the audience that wants the full picture in one sitting. The master also becomes the source for every future cutdown, which keeps your answers consistent across channels.
How do I keep a small cast visually stable across many scenes?
Reference-based generation from a fixed character sheet, locked wardrobe, and a description you never reword. Consistency is a documentation habit more than a technical setting.


