Phase 0 for an AI or automation project: the readiness and design work before the build

A few weeks back, the head of operations at a company that processes millions of tax documents a season asked us a version of a question we hear constantly: could we add AI to cut the manual review, without ripping out the pipeline that already works?

She framed it well. The team's whole model depended on the current file format flowing into downstream tax software, so the safe move was to layer intelligence on top rather than rebuild underneath. But whether it would pay off depended on things nobody could answer from a sales call: how clean the source data was, which documents were genuinely worth automating, and where a human had to stay in the loop. That is what Phase 0 is for.

What Phase 0 is here

Phase 0 for an AI or automation project is the same idea as the design phase we run ahead of a platform build, pointed at a different outcome. It is a standalone engagement with a fixed fee and a stopping point at the end, and nothing production gets built inside it.

The output is a documented design: which use cases are worth pursuing, what data feeds them and in what condition, where the automation makes decisions and where a person reviews, and what governance has to be in place first. That comes with a fixed-fee proposal for the build, priced against scope we have confirmed, and the documentation is written to stand on its own so any qualified Microsoft partner could execute from it.

If you proceed with the build within three months of Phase 0 closing out, we credit 100% of the fee toward it. The discovery is work we would do at the start of the project anyway, so it shouldn't be paid for twice.

Why the build can't be quoted first

With AI especially, the answer to "what will this cost" is usually "let's find out whether it works." For a build like document extraction, that means a proof of concept: a short, time-boxed exercise, a week or two, run against real historical data with no production rewiring, to see whether the model clears the bar you set. If it takes much longer than that to prove the concept, it has stopped being a proof of concept and started being the project.

The gate is whether the payback justifies the build. A process running millions of documents a season against a tight turnaround, with hundreds of seasonal reviewers hired to hit it, clears that bar easily. A once-a-quarter task that takes someone an afternoon does not. Phase 0 is where you decide which is which before committing budget.

What AI discovery inventories that a process or infrastructure one doesn't

• Data readiness. Where the data lives, and whether it is good enough to act on. If the source capture never recorded a field, no model conjures it back. As the operations lead above put it when we walked through her documents, if the data isn't there, it isn't there, and that is the right answer to hear early rather than late.
• Permissions and oversharing. Microsoft 365 Copilot answers from whatever a user can already open. Turn it on over a SharePoint where sharing has sprawled for years, and it will surface things quietly and confidently. So a permissions and oversharing review comes before you provision a single license, not after someone gets an answer they shouldn't have.
• Which processes are worth automating. Not every manual step earns a build. Discovery ranks candidates by volume, error rate, and return, and is willing to conclude that some of them should stay manual.
• Confidence and human-in-the-loop design. The useful question is rarely "can the machine do this," it is "where do we trust it and where does a person check." A good design scores each output and routes it: pass the high-confidence cases through, send the low-confidence ones to review. That is how a review team shrinks without anyone losing sleep over what slipped past.
• Governance. For regulated data, this is the part that has to exist before the AI does: a Business Associate Agreement (BAA) where health data is involved, Data Loss Prevention (DLP) and sensitivity labels, audit logging of AI interactions, and a decision about which public AI tools are allowed at all.

What discovery tends to turn up

At a residential-care nonprofit handling Protected Health Information (PHI), the real finding came before any Copilot rollout: staff were already pasting case notes into public AI tools to save time. Education alone was not going to hold that line reliably. The design put a governed Copilot in front of them so the data stayed in the tenant, but only after tightening permissions and standing up DLP first, so the tool would not surface protected information the moment it turned on.

A second pattern shows up often enough to name: licenses that sit unused. Hand a team Copilot with no playbook and it mostly stays on the desktop. Discovery is where the actual use cases get written down, role by role, with the specific tasks people will hand to it, because adoption is a design problem, not a licensing one.

When you don't need one

A single, well-understood flow, a Power Automate approval, a form that routes to the right person, with clean data and a clear owner, does not need a design phase in front of it. Bring us the specific automation and we will build it.

Phase 0 earns its place when the use cases are still a wish list, when nobody can vouch for the data or the permissions the AI would rely on, when the process touches regulated data, or when you want a fixed fee on a build whose feasibility hasn't been proven yet.

If you are somewhere in that territory and want to work out whether an AI idea is ready to build or still needs proving, bring us the process you would most like to stop doing by hand. That is the right place to start.