A room, a whiteboard, four questions, and sixty minutes: how to leave with one AI workflow chosen, not a list to argue about over email.
This is a facilitation guide, not an argument for why AI adoption matters. It gives you the room list, the minute-by-minute agenda, the four questions that separate a real candidate workflow from a wish, and what to do with the person who wants to skip straight to comparing tools.
Picture the last time someone above you said “we need to be using AI more.” Maybe it came out of a leadership offsite, maybe it followed a competitor’s press release. Somebody got asked to do something about it, so they wrote a memo: three or four ideas, a bit of context, a request for feedback by Friday.
You already know what happened next. A couple of replies with a thumbs up. One clarifying question nobody answered. By the following month, the memo is buried under forty other emails, and the team is exactly where it started, except now everyone quietly associates “AI” with a slide deck nobody finished reading.
The problem was never the ideas in the memo. It’s that a memo is one person’s judgment call, dressed up to look like a team decision. Nobody in the room watched it get made, so nobody feels responsible for defending it when the first output is mediocre, or when someone senior asks why the team picked this workflow over that one.
A session fixes that, not because a room is smarter than a memo writer, but because a decision people watched happen is a decision people will defend. The five or six people who sat through the argument about which task to automate are the same five or six people who’ll still be running it in six weeks, because they own it, not because it was assigned to them.
A decision nobody watched get made is a decision nobody defends.
You can run everything in this guide yourself, with a whiteboard, a printed agenda, and the right five or six people for an hour. Plenty of teams do exactly that and land on a workflow worth keeping. Where an experienced facilitator earns their place is the follow-up question your own team is too polite to ask each other, the one that turns a vague “customer research takes forever” into an actual, buildable workflow. That question is usually what separates a good first choice from a great one.
The session only works if the right people are in the room, and “right” is narrower than most teams assume. You don’t need the whole department. You need the person who actually does the task today, their manager, one person who’ll push back, someone who can say yes or no on tools and data fast, and ideally one person from outside the team who’s already tried something similar.
Skip the person who does the work today and you’ll spend the session solving a problem nobody described accurately. Skip the skeptic and the workflow you choose will fall apart the first time someone outside the room asks the question nobody thought to ask inside it. Skip the person who can approve tools and data access, and your chosen workflow sits in limbo for three weeks while someone “checks with IT.”
Send a two-line invite, not a brief. Ask everyone to bring one thing: a real, recent example of a task they find repetitive or draining, in enough detail that a stranger could do it. A described task is a guess. A real one is evidence. “Bring the real thing” means, literally:
| Who | Why they’re in the room | What to ask them to bring |
|---|---|---|
| The person who does the task today | They know where it actually breaks down, not where it’s assumed to | Last week’s real version of the task, unedited |
| Their manager | Owns whether the change survives past the session | One sentence describing what “better” would look like |
| A skeptic | Asks the hard question before a customer or a director does | Their best objection, written down in advance |
| Whoever approves tools and data access | Turns “maybe” into a same-day yes or no | A ruling on whether the tool being considered is even allowed |
| Someone who’s already tried an AI tool on something | Saves the room from relearning a lesson someone already paid for | One thing that worked, one thing that didn’t |
Five to seven people, no more. Every invite carries the same instruction: bring the real thing, not a description of it.
A finance analyst and a social media manager will nominate completely different first workflows, and that’s fine. You’re not trying to find the workflow that’s right for the whole company. You’re trying to find one that’s right for this room, this quarter. Getting genuine buy-in on that choice also means knowing who outside the room can slow the rollout down after the fact; our guide to stakeholder engagement for AI adoption covers who that usually is and how to bring them in early rather than after the workflow is already chosen.
This is the part you can print and hand to whoever’s running the session, even if that’s not you. Sixty minutes, six blocks, one whiteboard split into two sheets: one labeled “Candidates,” one labeled “Decision.” Nothing about the wall needs to be fancy. It needs to be visible from every seat. Before anyone sits down, have ready:
| Time | What happens | On the wall | If it stalls |
|---|---|---|---|
| 0:00–0:05 Open | State the goal out loud: “We’re leaving with one workflow and one owner, not a list to argue about over email.” | A blank sheet titled “Candidates” | If people start pitching tools immediately, redirect: “Tools come after. What’s the task?” |
| 0:05–0:15 Name candidates | Each person names one task using the real example they brought. One sentence each, no debate yet. | One sticky note per task, one per person | If someone can’t name a task, ask what they did right before this meeting that they’d rather not have done |
| 0:15–0:30 Score together | Run every candidate through the four questions in the next section, out loud, as a group | A tick or cross against each question, next to each sticky | If a task fails every question, take it off the wall and say why, out loud |
| 0:30–0:40 Narrow to two | Debate briefly, then narrow the wall to the two strongest candidates | Two stickies moved to the “Decision” sheet | If the room splits evenly, the facilitator asks which candidate has a real example sitting in someone’s inbox right now, and picks that one |
| 0:40–0:50 Choose one | Pick one. Name the owner. Name the date of the first real attempt | One sticky circled, owner’s name written next to it | If nobody volunteers as owner, the manager in the room names one before the meeting ends, not after |
| 0:50–0:60 Close | Fill in the decision card, confirm the two-week check-in date, end on time | The filled decision card, photographed by everyone’s phone | Nothing. This block doesn’t stall if the previous five didn’t |
Print this and run it. The timings are deliberately tight: a room with a hard stop at sixty minutes behaves differently from a room with an open afternoon.
The tight timing is doing real work, not just keeping the meeting short. An hour with a hard stop forces the room to choose. An open-ended afternoon lets every candidate stay theoretically alive, which is how teams leave “AI workshops” with a list of eleven possible use cases and no workflow actually running six weeks later.
Pick one workflow, not the shortlist. The shortlist is where good ideas go to become nobody’s job.
The scoring block in the middle of the agenda runs on four questions. They’re deliberately blunt, because the point isn’t to be thorough. It’s to eliminate candidates fast enough that the room still has time left to choose.
| Question | A strong answer sounds like | A weak answer sounds like |
|---|---|---|
| 1. Does this happen every week, not just once a quarter? | “We do this every Monday, sometimes twice” | “It comes up occasionally, maybe when we’re onboarding a new client” |
| 2. Would doing it faster actually change what happens next? | “If this took ten minutes instead of two hours, we’d start the follow-up the same day” | “It’d be nice, but we’re not really blocked on it” |
| 3. Can you describe the input and the finished version in one sentence each? | “Raw call notes in, a one-page recap out” | “It’s kind of a judgment call every time, hard to say exactly” |
| 4. What’s the worst outcome if the first attempt is bad? | “We reread it before it goes anywhere, so worst case we lose ten minutes” | “It goes straight to the client, so worst case is a client sees something wrong” |
A candidate needs a strong answer on at least three of four to survive to the “narrow to two” stage. A weak answer on question four doesn’t kill a candidate outright, it just means the first attempts need a human check before anything leaves the building.
That fourth question matters more than it looks like it should, and the right threshold for “worst case” isn’t the same for everyone in the room. A worst case an internal analyst can shrug off, a slightly wrong number in a draft only they’ll see, is a real problem for a customer-facing role, where the same mistake reaches someone outside the company. Weigh each candidate against the actual role doing the work, not against how cautious the room feels in general.
Here’s what a candidate that survives all four questions looks like once you push it one level more specific. Say the room lands on turning raw sales call notes into a one-page recap for the deal owner:
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts the one-page recap from the raw call notes: key points, objections raised, next step discussed | Decides whether the recap accurately reflects what actually mattered on the call, and rewrites the next-step line if it’s wrong | Deal owner reads every recap before it’s filed, every time, for the first month |
This is the level of specificity a workflow needs before it’s ready for the agenda above. If a candidate can’t be described this precisely, it isn’t ready to be chosen yet.
This is also usually the moment someone in the room realizes the task they nominated is really three loosely related workflows wearing one name. Fine to discover that at minute twenty. Expensive to discover it six weeks into building the wrong one, which is the gap our piece on what actually makes someone AI-powered at work gets into: rarely tool skill, usually just being this specific, this early, about what the tool is actually doing.
There’s always one. Somewhere around minute twelve, someone says “shouldn’t we figure out if we’re doing Copilot or Claude or one of the meeting-notes tools first?” They’ve usually got three tabs open already, and they’re not wrong to be curious. They’re just early.
Say the room includes an operations manager who’s spent the last two weeks reading comparison posts about AI note-takers. She isn’t trying to derail the session, she genuinely believes picking the tool is the hard part, because with most other software rollouts she’s run, it usually was. Reasonable instinct. It’s also the exact one this session is built to interrupt: park it, don’t shut it down.
| What they say | Redirect with |
|---|---|
| “Shouldn’t we figure out Copilot vs Claude first?” | “Once we know the job, the tool question usually answers itself in five minutes. What’s the task?” |
| “I already tried Tool X for something similar” | “Good, write that on the parking lot sheet. We’ll want it once we’ve picked a workflow” |
| “We should just buy the enterprise license and figure it out” | “That’s a real option once we know what we’re pointing it at. Let’s finish naming the job first” |
Keep a sheet titled “Tool Parking Lot” on the wall next to the two candidate sheets. Every tool mention goes there, unargued, so the person raising it feels heard instead of shut down.
If someone keeps steering back to tools after two redirects, that’s usually a sign they don’t trust the room to actually land on a decision, often because the last few “let’s use AI more” conversations at this company didn’t go anywhere either. Naming that directly, gently, tends to work better than a third redirect: “I hear you, and I think the fastest way to a tool you’re happy with is picking the job first. Trust the process for the next twenty minutes?”
A workflow without a named owner doesn’t fail loudly. It just quietly reverts to whoever happens to remember it exists, which is usually nobody, three weeks later. The session isn’t done until someone’s name is next to the workflow, in writing, with a date attached.
The decision card is the artifact that leaves the room with everyone, not just the facilitator’s notes. Fill it in at minute fifty, out loud, and have someone photograph it before people scatter.
| Field | This team’s answer |
|---|---|
| Workflow chosen | Turning raw sales call notes into a one-page recap for the deal owner |
| Why this one won | Happens every week, survived all four questions, and the deal owner already has real notes sitting in her inbox to test it on Monday |
| Owner | Priya, sales operations |
| First real attempt by | This Friday, using this week’s actual call notes |
| Two-week check-in | Next-but-one Tuesday standup, five minutes on the agenda |
| What “working” looks like | Deal owner opens the recap and doesn’t need to go back to the raw notes to trust it |
Six fields, filled in the room, in front of everyone who has to remember it exists. A card with blanks in it hasn’t actually been decided yet.
Notice what’s deliberately absent from the card: which AI tool to use. That decision belongs to whoever’s closest to the work, made in the days right after, once the workflow is specific enough that the tool choice is easy. Naming the tool in the room drags the session back to the memo problem from the start of this guide: a decision made by whoever talks fastest, not whoever has to live with it.
Here’s the part that matters more than the session itself: what happens in the two weeks after everyone leaves the room.
The session designs the workflow and names an owner. That’s necessary, but it isn’t the same as the workflow surviving contact with a normal, busy week. What turns a chosen workflow into something that actually sticks is reinforcement: whether the owner runs it without being reminded, whether someone checks in when they don’t, and whether anyone’s paying attention to whether the output is actually any good.
Without that, a workflow that looked great on the decision card quietly stops happening by week two, and nobody notices, because nobody was checking.
Owner runs the workflow on a real example, the one promised on the decision card. No exceptions for “too busy this week.”
Owner runs it again, unprompted. If they haven’t, the manager from the invite list sends one message: “How’d the recap thing go?” Not a status report, just a nudge.
Someone other than the owner looks at one output and asks whether it actually changed anything: a faster follow-up, a recap someone trusted enough to skip the raw notes.
Five minutes on an existing meeting agenda. Not a new meeting. The only question that matters: is this still happening without anyone chasing it?
Reinforcement is the whole job in these two weeks. Nobody needs a new dashboard. They need one person willing to ask “did you run it?” out loud, twice.
Resist the urge to measure this by how many people logged into the tool. A login count tells you access happened, not that anything changed. The real questions: is the owner still running the workflow two weeks later without being reminded, and is the work it touches actually better, faster, more consistent, something the team trusts more than what came before. That gap, between a workflow tried once and one genuinely adopted, is the same distinction our AI adoption checklist walks through for what to plan once you’re ready to roll this out past the first workflow.
The session doesn’t decide anything by itself. What happens in the two weeks after does.
If this first workflow survives its two-week check-in, you don’t need a bigger session to pick the second one. You need the same room, the same four questions, and another hour. Book it before this one ends. And if your team gets through this once and wants a wider map of what comes after the first workflow sticks, our guide on taking an organization from AI awareness to AI fluency picks up exactly where this one leaves off.
Invite five to seven people who actually do the work, and have each bring a real, recent example of a repetitive task, not a description of it. Run a tight sixty-minute session built around four screening questions, and end with one workflow chosen, one named owner, and a date for the first attempt, not a list of ideas to revisit later.
The person who does the task today, their manager, one skeptic, whoever can approve tools and data access, and ideally someone who’s already tried an AI tool on something similar. Five to seven people total. Leaving out the person who does the work is the most common reason these sessions choose a workflow that doesn’t match how the job is really done.
Sixty minutes, timed in six blocks, works better than a longer open-ended workshop. A hard stop forces the room to narrow to one workflow instead of leaving with a wishlist of eleven ideas that all stay theoretically alive. If a team genuinely can’t decide in an hour, that usually means the room has too many people in it, not too little time.
Keep a visible ‘Tool Parking Lot’ sheet, write down every tool mention without arguing about it, then redirect: ‘Once we know the job, the tool question usually answers itself in five minutes.’ The tool conversation almost always resolves itself once the workflow is specific enough, which is why it belongs after the workflow is chosen, not before.
A filled-in decision card naming the exact workflow, why it won over the other candidates, a named owner, a date for the first attempt, and a two-week check-in already on someone’s calendar. If the session ends with a list of good ideas instead of one decision with an owner attached, it hasn’t actually finished.
This article was written by Sana for Future Factors AI as a runnable facilitation guide, not a general argument for AI adoption. It draws on Future Factors’ own workshop facilitation practice for helping teams choose their first AI workflow. It doesn’t lean on third-party statistics or named studies, because none of the guidance here depends on one; the agenda, the questions, and the timings are our own method.