If you are about to hire someone to automate part of your business with AI, the first two weeks will tell you most of what you need to know.
Two weeks is usually not enough to design, build, connect, make reliable, and roll out a whole production system. Be wary of anyone who promises that. It is enough to get one piece of real work running on your own examples, so you can see whether the approach holds up before you spend more.
That evidence is worth more than a slide deck. It shows whether the vendor understands your workflow, whether automating it is technically workable, whether your team can trust the result, and whether the next phase is worth paying for.
This guide covers what a good first phase should produce, what to ask a vendor before you start, what "done" should look like, and when to stop.
Start with one workflow
The first mistake is scoping "AI for the whole company." That is too broad to build, too vague to judge, and too easy to turn into meetings.
Pick one workflow that already exists, costs you something every week, and has a clear owner. For example:
- a recurring report someone rebuilds by hand
- sorting and routing incoming requests
- an invoice or document flow
- a handoff between sales, operations, support, or hiring
- research that feeds a real decision
Your team should already know what goes wrong when this work is late, skipped, or done badly. That gives the first phase a real target.
Expect the first phase to show that not every step needs AI. Some steps need simple automation, some need better checks, and some should stay with a person.
Put the scope on one page before work starts
The most useful document in a first phase is a one-page scope sheet. It is short, and it heads off most of the arguments later. It should cover:
- The workflow: what starts it and what it should produce
- In scope: the specific slice being automated first
- Out of scope: what is deliberately left for later
- Data and access: which systems it reads from, which (if any) it writes to, and who grants access
- Approvals: where a person approves, and what the system may never do on its own
- What done means: the working result you will review at the end of week two
- When to stop: the signals that would end the work, agreed before anyone is invested
Take matching supplier invoices to purchase orders, walked through in Your team uses ChatGPT. Your workflows haven't changed. A first scope might be: typed PDF invoices from one group of suppliers; read from the ERP but never write to it; matches and mismatches go to a review screen; no automatic posting or payment.
Questions to ask a vendor
Before you sign, ask:
- Which one workflow will you automate first, and what is out of scope? A good answer is narrow and specific.
- What will I be able to see and test at the end of week two? Look for "working on your real examples," not "a demo" or "a plan."
- Where does a person approve, and what can the system never do by itself? Payments, customer messages, and changes to financial records should have a clear approval step.
- What access do you need, and can the first phase run read-only? Starting read-only often works and lowers the risk.
- How will we know the output is right? A good answer uses past cases where you already know the correct result.
- What happens when the system is unsure or wrong? It should hand the case to a person and record why, instead of guessing quietly.
- What will you tell me at the end? You want what worked, what failed, and what it needs before wider use, in writing.
- What do I pay if the first phase does not deliver what we agreed? And if we stop, what do we keep?
What "done" looks like at the end of week two
A good first phase ends with something you can inspect. Depending on the workflow, that could be:
- a working automation connected to one of your existing tools
- a review queue where a person approves or corrects each output
- a component that handles one repeatable step
- a working version running on your real examples, with its limits written down
The format matters less than whether you can check it. At the review, you should be able to see:
- what went in
- what the system did
- what came out
- where a person reviewed it
- what failed or needed a fallback
- what must be made more reliable before wider use
A strong review is specific: here is the workflow we scoped, here is the part we automated, here it is running on your examples, here is where a person still reviews, here is what failed, and here is what we would do next. If the vendor cannot show you those things, you are still looking at a concept.
What a good first phase brings to the surface
A serious first phase exposes problems while they are still cheap to deal with:
- missing or messy data
- limits on access to tools
- approvals that still need a person
- checks the system needs before wider use
- security and permission boundaries
- parts of the workflow that should not be automated yet
This is useful news. It is what the first phase is for. A weak vendor hides these problems until later. A useful one shows them while the scope is still small enough to adjust.
When to stop
Decide your stop signals before the work starts, so nobody moves the goalposts later. Common ones:
- Reviewing and correcting the output takes longer than doing the work by hand.
- The data the workflow needs cannot be reached, or is too messy to fix in reasonable time.
- On cases where you already know the right answer, the system is wrong too often for the risk involved.
- Connecting to your systems costs more than the workflow is worth.
- The work turns out to be mostly one-off judgment calls, with no repeatable pattern to automate.
Stopping is a legitimate result. A fast no is worth more than a slow, expensive maybe.
At the end of the phase there are three good outcomes: extend the work to more of the workflow, make it sturdier for wider use, or stop. Each is valid if it rests on working evidence instead of optimism.
How CoEdify runs a first phase
At CoEdify, we start with one scoped two-week phase that ends in a reviewable working deliverable against the scope we agree with you. That is not a promise that the whole system is finished in two weeks. If that first phase does not satisfy you, you do not pay for it. If it does, you choose whether to extend it, make it sturdier for everyday use, or stop, with no obligation to continue.
The takeaway
A two-week first phase is a discipline, not a magic timeline. Pick one workflow. Agree on what done and stop look like. Get something working on your own examples. Learn from the real constraints. Then decide the next step from evidence.