Core · Module 3.5
Evaluate Provided Case
Course outcome 5Also covers: adapting when the product changes
Put on your reviewer hat. Rate a workflow someone else designed, then say how it should change when the product changes.
Big question Is this workflow worth automating, teaching, or reviewing, and how would you know?
Note: Rate the case below, not your own M3 or M4 work.
Best after M3: this module uses the planning ideas from there.
By the end of this module, you’ll be able to:
- Evaluate a provided workflow for outcome clarity, evidence of success, and transfer potential.
- Identify gaps in its desired results (Stage 1) or its evidence (Stage 2).
- Propose how the plan should adapt when Grok Bot’s surfaces or features change.
How you’ll show it: your evaluation of the case (download). Course outcome 5 of 6
What good looks like
This is the bar each part needs to reach (Meets). You’ll get feedback on each part when you check your work.
- Outcome clarity and Evidence of success: a rating plus a specific reason (40+ characters). If you rate something Adequate, also say what you would observe to confirm it.
- Transfer potential: a rating plus where else this would (or wouldn’t) work, beyond this demo.
- Adapting when the product changes: a trigger (“when…”) plus a specific change to one part of the plan.
How you pass: all four parts at Meets or better. This module doesn’t affect the electives; they open after M3.
The automatic check looks for a few signals of these. It can’t judge quality, so aim for the description, not the keywords.
Backward design in 30 seconds
Backward design (also called UbD, “Understanding by Design”) plans a course in three stages: decide what learners should be able to do, decide how they’ll show it, then build the lessons. This Academy was built that way; each module’s objectives and “How you’ll show it” lines are Stages 1 and 2.
- Stage 1, desired results: Is the outcome clear and measurable?
- Stage 2, evidence: Is there something you can observe, like an artifact or a checklist?
- Transfer: Would this still work outside a chat demo?
- Adapting: When surfaces or features change, what exactly gets updated?
The case
Case study
Fast Course Review Bot
What it claims
“Learners will get better at reviewing courses.”
How it works
- One agent answers in chat about whatever the user pastes in.
- The team judges success by whether the SME feels good about the result.
- Review notes are kept in the chat thread.
- The write-up refers to Channels, Routines, and agent surfaces by their current names.
See a strong evaluation (for a different case)
Case: “Quiz Helper Bot” writes practice questions for a sales course and posts them in a channel. It’s a different case, so borrow the reasoning, not the words.
- Outcome clarity: Gap
- “The goal is ‘reps feel more confident’. That’s a feeling, not something a rep does. A clear outcome would be ‘reps can handle the top 5 pricing objections’.” Names the gap and shows what a measurable version looks like.
- Evidence of success: Gap
- “Success is counted as ‘questions posted’. That measures output, not learning. A scored role-play checklist would show whether reps can do it.” Separates activity from evidence and proposes a better type.
- Transfer potential: Mixed
- “The question-writing pattern could work for onboarding, but posting in a channel means nothing is saved for next quarter.” Names a context and the condition that limits it.
- Adapting
- “When the channel is archived at quarter end, move the question bank to a named file and update the owner field.” A trigger plus a specific change to one part of the plan.
Your evaluation
Tip: Feedback is automatic. It looks for specific details, like a number, a named owner, or a “when”. It’s a quick check, not a grade.
Your feedback
How to read this: Meets = good to go. Emerging = needs a tweak. Exceeds = bonus polish, never required.