Skip to main content

Building a Tutor Roleplay in Yoodli

A guide for builders creating their first tutor-format roleplay.

Written by Anesa Abdullah

What is a Tutor roleplay?

A Tutor roleplay flips the usual Yoodli dynamic. Instead of the AI playing a counterpart the learner has to win over (a skeptical buyer, a tough stakeholder), the AI is on the learner's side. Its only job is to teach them a topic or skill, then check that it actually landed.

The learner is the student, not a rep trying to close someone.

Common uses:

  • Walking a new hire through a capabilities deck before they have to present it

  • Teaching a framework (a discovery methodology, an objection-handling model) before the learner has to apply it

  • Explaining a process or product change and confirming the team actually understood it

Tutors are often a precursor to a Standard roleplay: teach the material with a Tutor, then have the learner practice using it in a Standard roleplays against a simulated buyer.

Use the Tutor template to build from scratch.

Tutor vs. Regular vs. Ride-Along

This is the first fork every builder hits, and mixing it up is the most common mistake new builders make.

Type

What the AI does

What the learner does

Use it when

Standard

Plays a buyer, customer, stakeholder, or interviewer

Practices the conversation

You want to rehearse a real conversation type: discovery, negotiation, a tough 1:1

Tutor

Teaches a topic and checks understanding

Is the student

You need to teach something before anyone practices it

Ride-along

Runs a practice roleplay, plus a separate coach the learner can call on

Practices the conversation, with help on standby

You want practice with in-the-moment support available

The mix-up to watch for: a ride-along still centers on a practice conversation, with a coach on the side. A Tutor is the whole session. There's no separate moment to win, the teaching is the point. Learn more about building a ride-along roleplay here.

If your persona is pushing back, withholding information, or acting like a counterpart, you've built a Standard roleplay by accident, not a Tutor.

The four fields you'll adjust

Every roleplay format in Yoodli, including Tutor, uses the same four fields in the builder. What changes for Tutor is what goes in each one.

A. Describe Your Roleplay

This is the short "what's this about" pitch, 2 to 4 sentences.

For a Tutor, be explicit that this is a teaching session, not a practice-against-a-persona roleplay. State:

  • The topic or skill being taught

  • What the learner should be able to do by the end (for example, "explain the three core capabilities in their own words")

If you don't say plainly that this is a tutoring session, learners (and the AI) can default to treating it like a Standard roleplay.

B. Persona (the teacher)

This is the character card for the teacher. Give it structure:

  • Name: labeled as a Tutor or Coach (for example, "Coach Riley")

  • Role: what kind of teacher this is (a subject-matter expert, an enablement coach)

  • Voice: how they sound (warm, clear, patient)

  • Demeanor: encouraging, never condescending

  • Background characteristics: a few short "you" traits, such as: you know this topic cold, you teach it exactly as written rather than improvising, you keep the session interactive, you adjust your pace to the learner

C. Context (directions to the AI)

This is the field that does the most work and the one most likely to go wrong.

Two rules apply to Context in every format, and matter even more for Tutor:

  1. Write it in second person. "You are...", "You recently...", "Do not..." The AI reads this as stage directions and adopts it directly, not as background information about a scene.

  2. Keep it under Yoodli's 10,000-character limit. In practice, a focused Context is well under that. Piling on rules makes the AI rigid instead of responsive.

For a Tutor specifically, Context needs to cover:

  • Teaching behavior: introduce the topic, explain it in clear steps, and, critically, check understanding by asking the learner to explain it back rather than lecturing straight through. Correct gently. Adapt depth to how the learner responds.

  • Constraints: stay on the assigned topic, don't move to the next concept until the learner shows they get this one, keep turns short and interactive (no monologues), stay in the source material's frame rather than inventing content.

  • Opening line: script the exact first line. For example: Begin by saying, "Hi, I'll walk you through X. Want the overview first, or a specific section?" A scripted open keeps the session from drifting before it starts.

Tip: If you skip the "check understanding" instruction, the AI will lecture straight through without confirming anything landed. This is the single most common reason a Tutor underperforms.

D. Custom Goals

We recommend using binary goals for Tutors where actions are either missed or achieved. Keep the count small, 2 to 4 goals. A long list feels like a test, not a lesson.

For a Tutor, goals measure the learner's comprehension or ability to demonstrate the skill, not how they handled a counterpart (there isn't one). Two rules:

  • Don't name the tutor persona in a goal. Score what the learner can do, generically, so the goal survives if you swap the persona or topic later.

  • Be concrete enough to grade. "Understands the material" isn't measurable. "Restates the three capabilities and gives one example of each" is.

For each goal, you'll fill in three fields:

  • Explanation (up to 2,500 characters): what "good" looks like

  • Achieved (up to 1,000 characters): a concrete pass condition, with an example

  • Missed (up to 1,000 characters): what falls short, with an example

If the topic itself is an acronym-based framework (BANT, GROW, MEDDIC), score it as one compound goal rather than one goal per letter, so the learner isn't graded against a checklist.

E. AI Assets (optional, not pasted into Context prompt)

This section lives in your documents. It's any useful prep for whoever assembles the roleplay and should be attached as an AI Asset for the Tutor to reference during the session with the learner.

  • Common misconceptions the tutor should watch for and correct

  • Check questions the tutor can use to test understanding

  • Grounding material: the actual deck, framework, or document the tutor should teach from, so it teaches the real thing instead of improvising something plausible-sounding

Three pitfalls that trip up new builders

  1. Writing the tutor like a buyer. If your persona pushes back, withholds information, or needs to be convinced, that's a Standard roleplay wearing a Tutor's name tag. A Tutor helps, it doesn't resist.

  2. Lecturing. Without an explicit instruction to check understanding and ask the learner to explain concepts back, the AI will default to a monologue. Build the back-and-forth into Context directly, don't assume it will happen on its own.

  3. Vague goals. "Understands the material" can't be scored consistently. Give the AI something specific to look for, like a restated concept or a concrete example.

Sample Prompt (plug this into Roleplay Builder)

Build this as a TUTOR / teaching roleplay, not a practice-against-a-buyer scenario. The AI plays [Coach Name], a warm, patient [role, e.g. product knowledge coach] whose only job is to teach the learner [topic, e.g. our three core value pillars] until they can explain it confidently in their own words.

[Coach Name] should introduce one part of the topic at a time, explain it briefly, then ask the learner to restate it in their own words before moving on. If the learner struggles, offer a simpler example and try again rather than pushing forward. Keep turns short (2-3 sentences) and interactive, never a long lecture, and stay only on the material provided rather than inventing anything new.

Open by saying: "Hi, I'm here to walk you through [topic]. Want to start from the top, or focus on one part in particular?"

By the end, the learner should be able to restate each part of [topic] in their own words and give at least one concrete example of how it applies. Grade this pass/fail on comprehension, not a percentage, and base feedback on the transcript rather than tone of voice.

Before you publish: quick checklist

  • [ ] Describe field makes clear this is a teaching session, not a practice-against-a-buyer scenario

  • [ ] Persona reads like a helpful teacher, not a skeptical stakeholder

  • [ ] Context explicitly tells the AI to check understanding by asking the learner to explain concepts back

  • [ ] Context includes a scripted opening line

  • [ ] Custom Goals are scored on what the learner can do, not tied to a named persona

  • [ ] Goals are concrete enough to grade, not phrased as "understands X"

  • [ ] Feedback is set to text/transcript, not audio/video

  • [ ] You've previewed the roleplay yourself in Yoodli with a real practice run before assigning it

Did this answer your question?