Deployed Works Guide
How To Scope AI Implementation Work You Don't Fully Understand Yet
A practical guide for teams that know AI or automation could help, but are not ready to specify the solution.
Audience
Founders, operators, hiring managers, product leaders and startup or scaleup teams
Time
10 minutes
Outcome
A clearer AI or automation capability brief, even when the solution is not fully known
Share this guide
PDF guide
Download and share with your friends and colleagues.
Use the PDF version to align your team before speaking to an AI, automation or product specialist. The web guide remains the canonical version.
Related guides
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- A founder who can see an AI or automation opportunity but cannot yet name the right solution.
- An operator trying to reduce manual work across systems, teams or handoffs.
- A product leader deciding whether the first phase is discovery, architecture or implementation.
- A hiring manager exploring specialist capability before creating a permanent role.
- A startup or scaleup team that wants a calm way to turn uncertainty into a useful brief.
The problem
Start with the problem, not the model.
AI implementation work is hard to scope because the buyer may not know what is technically possible, the available data may be unclear, the workflow may be poorly documented and stakeholders may expect different things from the same project. AI may not be the right answer. A simpler automation, reporting change or data fix can sometimes solve the problem faster. The useful starting point is not a perfect technical solution; it is a clear description of the workflow, pain, desired outcome, systems, constraints and unknowns.
AI scoping map
Map the work before guessing the model.
Use this canvas to turn a vague AI opportunity into a practical first specialist conversation.
Workflow
Affected process
What process, decision or handoff is affected?
Pain
Current friction
What is slow, manual, inconsistent, risky or expensive?
Data / systems
Inputs and tools
What information, tools or systems are involved?
Desired outcome
Better state
What should be faster, clearer, cheaper or more reliable?
Specialist question
First provider ask
What do you need a provider to diagnose, design or build?
Diagnose / design / build
Decide the first phase before asking for a build.
Start with the problem, not the model
Do not start with “we need an AI agent.” Start with the workflow and pain: support tickets arrive faster than the team can triage them, and 30% are routed to the wrong person. The same pattern works for onboarding workflow, internal reporting, document review, sales and CRM data cleanup, or operations handoff problems.
Map the workflow and affected decision
Name the process, decision or handoff that is affected. Include who touches it, where it starts, where it ends and where work slows down, gets copied, gets lost or becomes risky.
List the systems and data involved
Describe the tools, records, messages, documents or databases involved, even if you do not know whether the data is ready. Useful uncertainty is better than silence.
Choose the first phase: diagnose, design or build
Use diagnose when the problem is real but the workflow, data or approach is unclear. Use design when the problem is clear but the architecture or product approach needs definition. Use build when scope, systems, data and success criteria are clear enough to implement.
Make risks and constraints visible
Call out security, compliance, access, human review, decision ownership, stakeholder expectations and anything the provider should not assume. These constraints shape the right first conversation.
Give timeline and budget signal
A rough range is enough. Providers need to know whether this is likely to be a short diagnostic, design sprint, pilot build or larger implementation before they can shape a useful response.
Example
Vague request into useful brief
Before: “We need AI for support.” After: “We receive around 800 support tickets a month. The team spends the first hour of each day manually categorising tickets and routing them to product, billing or customer success. We want to explore whether an AI-assisted triage layer could classify tickets, suggest urgency and route them for human review. We use Zendesk and Slack. We need a specialist to assess feasibility, data requirements and a first pilot scope.” This is a clearer starting point, not a promise that AI is the answer or that any outcome is guaranteed.
Template
AI implementation capability brief checklist
Current workflow: Current pain: Users or teams affected: Tools and systems involved: Data sources: What has already been tried: Desired outcome: First phase needed: - Diagnose - Design - Build Timeline: Budget or rate signal: Security or compliance concerns: Internal owner: What we do not know yet: First specialist question:
Common mistakes
Avoid these traps
- Starting with an AI buzzword instead of a workflow.
- Assuming an agent is the answer.
- Hiding uncertainty from providers.
- Ignoring data quality.
- Forgetting the human handoff.
- Skipping internal ownership.
- Asking for a fixed build before diagnosis is complete.
- Overpromising business impact too early.
Checklist
Ready to publish when
- I can name the workflow or decision affected.
- I can explain the current pain.
- I can list the systems and data involved.
- I can describe what better would look like.
- I know what is uncertain.
- I know whether I need diagnose, design or build first.
- I have a named internal owner.
- I can give a rough timeline and budget signal.
FAQ
Questions this guide usually raises
Do we need to know the exact AI solution before starting?
No. You do not need to know the exact model, agent pattern or automation architecture. You do need to describe the problem, workflow, desired outcome, systems, risks and unknowns clearly enough for a specialist to respond.
What if AI is not the right answer?
That is a valid outcome of the first phase. A provider may recommend simpler automation, data cleanup, reporting changes, workflow redesign or a narrower pilot before AI implementation makes sense.
Should the first phase be diagnose, design or build?
Choose diagnose when the workflow, data or feasibility is unclear. Choose design when the problem is clear but the approach needs definition. Choose build only when scope, systems, data and success criteria are clear enough to implement.
Does Deployed Works provide AI matching?
No. Deployed Works uses structured capability briefs, capability profiles, guided drafting, fit indicators and human-reviewed shortlist support. It does not claim automated ranking, guaranteed fit or guaranteed outcomes.
Take it with you
Download and share with your friends and colleagues.
Use the PDF version to align your team before speaking to an AI, automation or product specialist. The web guide remains the canonical version.
Share this guide
Use the canonical page link. No social scripts or tracking widgets are loaded.
Use the guide
Not sure yet is still a valid starting point.
If you can describe the problem and the outcome you want, you can start a capability brief and let the first conversation clarify the work.