How a Forward Deployed Engineer Scopes an AI Workflow in 2 Hours
Why most internal AI projects fail at scoping, not implementation, and the single 2-hour session that decides whether the next 10 days produce a shipped workflow or a refund conversation.
By the end of this article, you should understand why the leverage point in any AI workflow project is the scoping session, not the engineering, and you should have the exact five questions, the one-sentence template, and the eight-dimension scoring matrix I use to scope an AI workflow in 2 hours.
I run paid 2-hour scoping sessions with founder-led B2B SaaS companies considering AI workflow work. $500 each. The session ends in a written go/no-go memo within 24 hours. About half of these end in “this isn’t a Sprint, here’s what to do instead.” The honest no is a feature, not a bug. The session pays for itself by saving both sides from a bad engagement.
Here is the playbook. If you are running internal AI projects, you can compress it from a 2-hour external session into a half-day internal workshop and get most of the value.
Why scoping is the leverage point
Most internal AI projects don’t fail at the engineering. They fail at the definition.
The pattern is the same every time. A team gets excited about “AI for customer support.” Someone proposes a chatbot. An engineer prototypes something in a weekend. The team can’t agree on whether the prototype is good. The product manager isn’t sure what success looks like. The CEO asks why this isn’t shipping yet. Six months later, the prototype is in a Notion page and nobody is working on it.
Every step of that path looks like an engineering execution problem. None of them is. They are all definition problems:
Who is the user?
What’s the input shape?
What’s the output shape?
What does “good” mean, and how will the team review it?
Where does the workflow run inside the existing product?
Who reviews the output before action is taken?
Answer those questions on paper in 2 hours and the engineering problem becomes tractable. Skip them and the engineering problem becomes infinite.
That is why the scoping session does more for the eventual success of an AI workflow than any of the days that follow it. The scoping is the leverage point.
The five questions
Five questions get asked in roughly this order in every scoping session.
1. What made you interested in AI workflows now?
Surfaces urgency and what the buyer has already tried. The answers separate genuine pressure (”our board asked, our competitor shipped, our team wasted 6 weeks on a prototype that went nowhere”) from vague interest (”we should be doing something with AI”). Genuine pressure is a green light. Vague interest is a yellow flag, because the workflow probably won’t get adopted after handoff if nobody actually needs it.
2. Where do you think your team is losing time, quality, or speed today?
Surfaces real pain rather than imagined use cases. Most teams arrive with the AI use case they read about in a TechCrunch article. The real opportunity is usually somewhere else in their operation, somewhere they have been quietly losing 10 hours a week for months. The most valuable workflows are rarely the most exciting ones.
3. How does that workflow happen today, step by step?
Tests whether the workflow is well-understood internally. If the team can’t describe the manual version step by step, the AI version won’t ship. The workflow has to exist as a process before it can exist as code. This question filters out about a third of candidate use cases on its own.
4. What data is involved and where does it live?
Tests technical feasibility in a 10-day window. If the data is locked in a vendor system with no API, or scattered across PDFs in someone’s email, or behind a compliance review that takes 6 weeks, the workflow needs either a different scope or a different starting point. This is the question that catches most of the “this is a great use case but it won’t ship in 10 days” cases.
5. What would make this sprint obviously worth it?
Surfaces the actual success criterion in the buyer’s words. The answer becomes the acceptance criteria. If they can’t answer, they are not ready. The most common bad answer is “make it work” or “feels useful.” Both are unworkable as acceptance criteria. The most common good answers are time-based (”reduce average prep time from 90 minutes to under 15 minutes”) or accuracy-based (”classify 80% or more of sample tickets correctly”).
The one-sentence template
Every workflow worth shipping fits into one sentence:
For [user], when [trigger/input] happens, the workflow will [process/action] and produce [output], so that [business value].
Worked example: For the founder, when monthly metrics and 3 to 5 sentences of context are added, the workflow drafts a clean investor update covering metrics, risks, and asks, so that the founder sends consistent updates in 8 minutes instead of 90.
That sentence ships in 10 days. “AI summarizer for founders” doesn’t.
If you can’t fill all five brackets during the scoping session, you don’t have a workflow yet. You have a slide. Sending the team away to fill in the brackets and come back is a better outcome than starting a Sprint with vague answers.
The opportunity matrix
When a customer arrives with multiple candidate workflows (common), each candidate gets scored 1 to 5 on eight dimensions.
Business value: does this matter to the company now?
Frequency: does it happen often enough for an AI-supported version to be worth it?
Pain intensity: is the current manual process painful enough that the team will adopt a replacement?
Data availability: do we have the inputs the workflow needs, accessibly, in 10 days?
Technical feasibility: can we build a v1 in 10 days given the stack and integrations?
Risk manageability: is the failure mode acceptable, and is human review built into the workflow?
Adoption likelihood: will the team actually use this after handoff?
Reusability: does this become a pattern that can be re-applied for future work?
The first workflow worth shipping has high business value, high feasibility, low-to-medium risk, a clear owner on the customer’s team, clear inputs and outputs, and a visible result. Bias hard toward workflows that produce trust early. The most exciting candidate is rarely the right first one. The most boring one with a 5 on business value and a 5 on feasibility almost always is.
Risk tiers, and why some workflows shouldn’t be first
Not every workflow is a good first project. Three risk tiers, in order of how much trust the team needs before deploying.
Low risk: internal-only workflows. Summaries, drafts, reports for human review. The user reads and edits before anything leaves the company. Most first workflows sit here, and they should. This is where trust gets built.
Medium risk: workflows touching customer-facing data such as support tickets, CRM notes, sales call transcripts, internal financial data. Still typically with human review. Acceptable for a first project with careful scoping and explicit logging.
High risk: workflows in legal, medical, compliance, or payment domains. Or workflows that take customer-facing actions autonomously. I decline these as a first project. The right move is for the team either to redefine the workflow to lower the risk tier (”draft the legal response for a lawyer to review” rather than “generate the legal response”) or to wait until trust and tooling are mature.
The pattern here generalizes: AI workflows earn autonomy. They don’t start with it.
The three scoping outcomes
A 2-hour session ends in one of three places, all of them acceptable.
Outcome A, strong fit. Use case is clear, data is ready, the team can support it. Memo recommends a specific scope and timeline.
Outcome B, weak fit but fixable. Good use case but a precondition is missing, usually data accessibility or a key team member’s involvement. Memo names the gap and recommends “do these three things, then come back.” Some of these teams return in three to six months and become the strongest customers, because they did the prep work.
Outcome C, not a fit. Their actual problem isn’t an AI workflow problem. Or they need an enterprise engagement, or their data isn’t ready and won’t be soon. Memo says so, honestly. Where possible, I refer out.
Conversion from scoping session to engagement is not the only success metric. A team that pays for the session, hears “this isn’t right yet, here’s what is,” and walks away unhappy in the moment will often return six months later, and refer others in the meantime. Selling the wrong customer is more damaging than declining one.
TLDR
Most AI projects fail at scoping, not engineering. The 2-hour scoping session is the leverage point. It does more for project success than any of the days that follow.
Five questions, in order: why now, where’s the pain, how does the workflow happen today, where’s the data, what would make this obviously worth it.
One-sentence template: For [user], when [trigger], the workflow does [action] and produces [output], so that [value]. If you can’t fill the brackets, you don’t have a workflow.
Opportunity Matrix: score candidates across business value, frequency, pain intensity, data availability, technical feasibility, risk, adoption likelihood, and reusability. The first workflow should be high-value, high-feasibility, low-to-medium risk, with a visible result.
Three outcomes: strong fit (proceed), weak fit (come back when ready), not a fit (honest no). All three are acceptable. The honest no protects both sides.
If you are a B2B SaaS founder trying to decide which AI workflow to ship first, or a product manager scoping internal AI work, run the five questions and the one-sentence template before you commit any engineering time. It is the cheapest thing you will do all quarter.