Creating effective AI interview templates

Overview

An interview template is a checklist of bracketed sections, each containing a question the AI assistant asks the witness. How you structure that checklist directly affects whether the interview feels like a conversation or a wall of questions — and whether the resulting statement is clean and usable. The principles below are based on how the interview engine actually processes templates, not just how they read on the page.

One question per section — always

The single most important rule: every bracketed heading should contain exactly one question.

Grouping several questions under one heading — even related ones — can cause the interview engine to fire them all together as a block, rather than asking one, waiting for an answer, then asking the next. This turns what should be a conversation into a wall of questions the interviewee has to answer all at once.

Don't do this:

[PERSONS OBSERVED]
"Did you see any people in the area?"
"How many did you see?"
"What were they wearing?"
"What was their approximate age?"

Do this instead:

[PERSONS OBSERVED - PRESENCE]
"Did you see any people in the area during that time?"

[PERSONS OBSERVED - COUNT]
"Approximately how many people did you see?"

[PERSONS OBSERVED - CLOTHING] 
"What were they wearing?"

[PERSONS OBSERVED - AGE]
"What was their approximate age?"

Yes, this makes your template longer. That length is the cost of predictable, sequential pacing — it's worth it.

Use literal, static conditions — not conditions that require judgment

The ### conditional syntax works well for simple, literal branches:

[VEHICLES OBSERVED - PRESENCE]
"Did you see any vehicles in the area during that time?"
### If no: 
→ Skip to [HOME SECURITY FOOTAGE].

Avoid conditions that ask the engine to make a judgment call about content it would need to parse from earlier free-form answers, such as:

(Check against [OPENING NARRATIVE] before asking.)
"What color was the vehicle?"

Instructions like this assume the engine can retroactively scan an open-ended answer, extract structured facts from it, and decide whether a downstream question is now redundant. Don't build your template's structure around that assumption unless you've specifically tested and confirmed the platform does it reliably — if it doesn't, you'll get the same batching or repetition problems you were trying to avoid.

Rule of thumb: if a condition can be phrased as a simple yes/no gate ("if no, skip to X"), it's safe. If it requires the engine to interpret or extract meaning from a prior open-ended answer, treat it as unreliable until proven otherwise. If you're not sure whether a condition is supported, contact Truleo support rather than guessing from behavior.

Order matters: consent and role first, narrative before detail, closing last

Consent and eligibility go at the very top. Recording consent, voluntariness, and (if applicable) guardian consent for a minor should be confirmed before you collect any other personal information. If consent is declined, you want to have collected as little as possible.

Confirm role before collecting identifying details — especially in cases involving a parent or guardian consenting on behalf of a minor. You don't want to have already gathered a child's ID, date of birth, and address before learning whether a guardian will authorize the statement at all.

Open narrative before detailed follow-ups, not after. If you use an open narrative question, place it before detailed follow-up questions. Asking someone to describe events in their own words before you've asked about weapons, injuries, or vehicle details produces a cleaner, less-leading account. Asking it afterward just invites them to repeat what they already told you, which reads as redundant.

That said, only include an open narrative if the follow-on questions actually get skipped when already covered. If the engine can't extract details from a free-form answer and skip the corresponding structured questions, an open narrative doesn't save you anything — it becomes one more thing to answer, with every follow-up still coming afterward. In that case, it's often better to leave it out entirely and rely on the structured questions to build the record.

Don't build your own closing section if the platform already has one. Many templates auto-generate a summary and final follow-up question ("Is there anything further you'd like to add?") once all checklist items are complete. If your checklist also ends with its own closing question, you can end up with duplicate summaries or looping behavior, since the interviewee's answer to your closing question can re-trigger the platform's own summary-and-follow-up logic. Check completion behavior before adding a closing section of your own — if one already exists, let your checklist end at the last real content question instead.

Split compound questions

A compound question forces the interviewee to track and answer multiple things in one breath, and makes it harder to know whether the question was fully answered.

Avoid:

"Did you see any people, and if so, how many?"
"Can you describe their appearance — age, sex, race, hair color?"
"Was there any property stolen or damaged, and what is it worth?"

Prefer:

"Did you see any people in the area?" → "How many did you see?"
Separate questions for age, sex, race, hair color
"Was there any property stolen or damaged?" → "What items?" → "What is their approximate value?"

Splitting compound questions also makes any redundancy-checking logic more reliable, since it's easier to verify whether one atomic fact was covered than whether a four-part question was fully answered.

Design for repeatable elements

Most checklist syntaxes have no native loop construct — if an incident could involve multiple suspects or vehicles, a single-suspect or single-vehicle question set won't automatically repeat itself. If this is a common scenario for your interview type, contact Truleo support to check whether repeating a block of questions is supported, rather than assuming the structure will handle it.

Test with real edge cases before deploying

Before relying on a new or revised template operationally, run it through a few test interviews that specifically probe:

A "no" answer at every gate — confirm skips land where you expect, and that skipped sections still count as reasonably attempted if completion requires it
A "yes" answer at every gate — confirm every follow-up fires and none are skipped incorrectly
A vague or rambling answer, if you're using any redundancy-checking — confirm the engine doesn't over-credit a vague mention as a fully answered question
A declined consent — confirm the interview stops or redirects appropriately rather than continuing through the full checklist

When something isn't working, isolate the layer

Unexpected behavior — a section firing as a block, a question repeating, a duplicate summary — can come from more than one place:

Your checklist's structure — grouped questions, ambiguous conditions
Section-naming collisions — built-in behavior can be tied to specific words (for example "closing" or "summary") that fires regardless of your content
Platform-level logic — summary generation, completion detection, or follow-up loops that sit outside your checklist entirely

When troubleshooting, change one variable at a time (for example, remove a section or rename a heading) so you can tell which layer is actually responsible, rather than assuming the fix belongs in your checklist when it might be a platform-level behavior Truleo support needs to address.

Quick checklist for a new template

Every heading contains exactly one question
Consent and role/eligibility questions come first
Compound questions are split into atomic ones
Conditions are literal yes/no gates, not judgment calls requiring parsing of prior answers
Open narrative (if used) comes before detailed questions, not after — and only if extraction is confirmed to work
No custom closing/summary section if the platform already provides one
Tested with yes-path, no-path, vague-answer, and declined-consent scenarios