The Day That Determines Whether Your AI Project Succeeds
Most AI agent projects that fail don't fail because of the technology. They fail because the wrong problem was chosen, the scope was never quite clear, or three stakeholders walked into the project with three different mental pictures of what they were getting — and nobody noticed until the demo.
A discovery workshop is how you stop all of that before it gets expensive. One day, the right people in the room, real workflows on the wall, real numbers attached to them. By the end, you've decided what the agent will and won't do — and just as importantly, everyone in your business has decided the same thing.
This guide walks you through a full-day discovery workshop: who to invite, what to cover in each session, the specific questions to ask, and what outputs you should leave with. It works whether your team is running it internally or whether you've engaged an AI development partner to facilitate. (We run a lot of these. The structure below is the one that consistently produces a clean scope and a project we can confidently price.)
Before the Workshop
Who to invite (4–8 people is the sweet spot):
- The business owner or decision-maker who'll approve the spend.
- The operational manager most affected by the workflow being automated.
- Two or three team members who actually do the work that's being automated. These are your most valuable participants — not because they're senior, but because they know how the work really happens, not how the org chart says it happens.
- Your IT or technical lead if you have one.
- Your AI development partner, if you've engaged one.
A note worth taking seriously: do not invite people who are only going to observe. Every person in the room should have something to contribute. We've sat in workshops with twelve people, half of whom said nothing for six hours, and they were worse workshops than the four-person ones.
What to prepare:
- Access to your current workflow data — volume, timing, error rates, anything quantitative.
- Examples of the interactions you handle (anonymised if needed).
- A list of your existing tools and systems.
- Any previous attempts at automating this area, including the ones that didn't work — those are often more informative than the wins.
Pre-read for participants:
Send a one-pager 48 hours before: the purpose of the workshop, the specific area of the business you'll examine, and three to five questions they should think about before walking in. Primed participants produce dramatically better workshops than cold ones. This step costs you twenty minutes of prep time and saves you two hours of warm-up.
Session 1: Problem Definition (90 minutes)
Goal: Agree on the problem you're solving and why it actually matters.
Opening (15 minutes)
Quick round of introductions, then have each person complete this sentence out loud:
"The thing that frustrates me most about how we currently handle [this workflow] is…"
Listen closely. Take notes. These frustrations are your requirements — they're more useful than any formal requirements document, because they're real and they're concrete.
Workflow Mapping (45 minutes)
Draw the current workflow on a whiteboard or shared document. Every step, every decision point, every handoff. Ask the people who do the work to correct you as you go — and they will, often loudly. That's the point.
For each step, capture: who does it, how long it takes, how often it happens, how often it goes wrong, what goes wrong, what information it needs, what it produces.
This map will surprise you. Things you assumed were simple turn out to have three exceptions. Things you assumed were complex turn out to be five lines of logic. The people in the room will disagree about how the workflow actually works — and that disagreement is some of the most useful output of the whole day. You're not learning the process. You're learning the gap between how leadership thinks it works and how it actually works.
Impact Sizing (30 minutes)
Quantify the problem. Get numbers on the wall:
- How many times per week or month does this run?
- How much staff time does it consume in total?
- What does that cost?
- What goes wrong, how often, and what does that cost?
- What would the team do with the time saved?
These numbers become the basis for your ROI calculation and your success metrics later. They also tend to be the first time the team has actually counted, which can be a quiet shock.
Session 2: Automation Opportunity Assessment (60 minutes)
Goal: Figure out which parts of the workflow are actually worth automating.
Automation Spectrum Exercise (30 minutes)
Take each step from your workflow map and place it on a spectrum:
- Fully automatable: Rule-based, structured, predictable. Same input always produces the same output. No judgment.
- Partially automatable: Mostly predictable, with exceptions. AI handles the common cases, humans handle the exceptions.
- Not automatable: Requires judgment, relationship, creativity, or authority that an agent shouldn't be making.
This exercise consistently produces the same insight in workshop after workshop: most people overestimate how much judgment their routine work requires, and underestimate how repetitive their day actually is. This isn't a criticism of the team — it's how memory works. The five interesting decisions a week loom larger than the three hundred boring ones.
Prioritisation Matrix (30 minutes)
Plot each automatable step on two axes:
- Impact: How much time or pain does automating this remove? How much does it improve life for customers or staff?
- Feasibility: How well-defined is the step? How clean are the inputs? How available is the data?
High impact + high feasibility = your first automation. Start there. Not with the most impressive-sounding automation. We've watched plenty of teams pick the second-most-valuable, hardest-to-build option first because it photographed better. Don't.
Session 3: Scope Definition (90 minutes)
Goal: Define exactly what the agent will do — and exactly what it won't.
In-Scope Definition (30 minutes)
List every specific interaction type the agent will handle. Be precise. Vague scope is the single biggest cause of overrun projects.
For each, write:
- What triggers it (the input)
- What information the agent needs
- What the agent does (the process)
- What it produces (the output)
Example:
- Trigger: Customer asks for order status
- Needs: Customer email or order number
- Process: Look up the order in Shopify, retrieve tracking status
- Output: A specific update with tracking link
The more concrete this list, the easier the build.
Out-of-Scope Definition (20 minutes)
Equally explicit about what the agent will not handle. This is the step most teams skip, and it's the step that quietly determines whether your project goes well.
Ask the room: "What are five things a customer might ask that we definitely do NOT want the agent to try to answer?" Write them on the wall and put a big red line through them. They go to humans, full stop.
Escalation Design (40 minutes)
Map every escalation path. For each out-of-scope situation or edge case:
- What does the agent say to the customer?
- Where does the conversation go?
- Who picks it up?
- What does the agent hand over with the conversation?
Draw the escalation flows on the whiteboard. They are exactly as important as the main flows — arguably more so, because they're what users remember when the agent reaches its limits. A graceful escalation can leave a customer happier than a perfect resolution. An ungraceful one can lose the relationship.
Session 4: Integration and Data Requirements (60 minutes)
Goal: Surface what the agent has to connect to, and whether your data can actually support what you want it to do.
Systems Inventory (30 minutes)
List every system the agent needs to read from or write to. For each:
- What data does it need from here?
- Does it need to write back, or just read?
- Who can give us API access? (Have we checked that this is possible?)
- Are there compliance restrictions on this data?
The "write or just read" distinction matters more than people realise. Read-only integrations are dramatically simpler, faster to build, and safer. Write access is where the genuine risk lives.
Data Quality Assessment (30 minutes)
The agent is only as good as the data it can see. For each data source:
- Is the data complete? Are there gaps that would cause the agent to fail?
- Is the data accurate? When was it last audited?
- Is the data consistent? Does the same fact live in multiple places with different answers?
Data quality problems found in discovery are cheap to fix. Data quality problems found after the build is live are very, very expensive — usually a combination of emergency fixes, rebuilt prompts, and a stretch of low trust in the agent that takes months to recover.
Session 5: Success Definition (45 minutes)
Goal: Agree on what success looks like in numbers, not adjectives.
Metric Agreement (30 minutes)
Write three to five metrics on the board. For each: a target number and a measurement method.
Worth considering:
- Automation rate (% of in-scope interactions handled without a human)
- Response time (average time from contact to first response)
- Customer satisfaction (CSAT)
- Human hours saved (per week)
- Error rate (% of responses requiring correction)
Get everyone in the room to agree on the targets. Disagreements here are important to surface and resolve now — stakeholders with different definitions of success will be disappointed by the same outcome. We've seen the same project be celebrated by the COO and called a failure by the head of customer service, purely because they had different metrics in their heads at the start.
Failure Definition (15 minutes)
Ask the room: "What does this look like if it's failing? At what point would we stop the project?"
It's an uncomfortable question. Ask it anyway. Defining failure clarifies the project as much as defining success. It also gives you a clean off-ramp if the project genuinely needs one — something most teams don't have, which is why they end up keeping projects alive long past their useful life out of pure sunk-cost momentum.
Workshop Outputs
By the end of the day you should walk out with:
- Workflow map — current state, annotated with volume, time, and pain points.
- Automation opportunity list — prioritised by impact and feasibility.
- Scope document — in scope, out of scope, and escalation flows.
- Integration requirements — systems, data, and access needs.
- Success metrics — agreed targets with measurement methods.
These five documents are the foundation for a development brief, a vendor evaluation, and a project tracking framework. Any half-decent AI development partner should be able to turn them into a specific, accurate proposal. Any partner who can't is a partner you've already learned something useful about.
After the Workshop
Within 48 hours: Document the outputs cleanly and share them with everyone who attended. Ask for corrections. Confusion that surfaces in review is gold — it means something wasn't clear in the room and needs resolving before development starts, not after.
Within one week: Share the scope document with your AI development partner for a project estimate. A well-run discovery workshop dramatically reduces estimate uncertainty. Developers can price against a defined scope rather than a vague brief, which means the proposal you get back is one you can actually trust.
Before development starts: Have the team review and sign off on the scope document. Scope changes after sign-off are manageable. Scope disagreements after development starts are expensive — and almost always trace back to something that was assumed rather than written down.
Talk to us about running a discovery workshop — we facilitate them as part of every client engagement, and we're happy to run one for your team before you commit to a build, even if you ultimately go elsewhere.